One document matched: draft-iab-privacy-considerations-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="no" ?>
<?rfc linkmailto="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.iab-identifier-comparison SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.iab-identifier-comparison.xml">
<!ENTITY RFC2778 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2778.xml'>
<!ENTITY RFC2779 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2779.xml'>
<!ENTITY RFC2616 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml'>
<!ENTITY RFC3261 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml'>
<!ENTITY RFC3325 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3325.xml'>
<!ENTITY RFC3552 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml'>
<!ENTITY RFC3748 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml'>
<!ENTITY RFC3859 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3859.xml'>
<!ENTITY RFC3922 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3922.xml'>
<!ENTITY RFC4017 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4017.xml'>
<!ENTITY RFC4079 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4079.xml'>
<!ENTITY RFC4101 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4101.xml'>
<!ENTITY RFC4187 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4187.xml'>
<!ENTITY RFC4282 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4282.xml'>
<!ENTITY RFC4745 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4745.xml'>
<!ENTITY RFC4918 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4918.xml'>
<!ENTITY RFC4949 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml'>
<!ENTITY RFC5025 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5025.xml'>
<!ENTITY RFC5077 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5077.xml'>
<!ENTITY RFC5106 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5106.xml'>
<!ENTITY RFC5246 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'>
<!ENTITY RFC6269 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6269.xml'>
<!ENTITY RFC6280 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6280.xml'>
<!ENTITY RFC6350 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6350.xml'>
<!ENTITY I-D.ietf-geopriv-policy PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-policy.xml'>
]>
<rfc category="info" ipr="trust200902" docName="draft-iab-privacy-considerations-03.txt">
<front>
<title abbrev="Privacy Considerations">Privacy Considerations for Internet Protocols</title>
<author initials="A." surname="Cooper" fullname="Alissa Cooper">
<organization>CDT</organization>
<address>
<postal>
<street>1634 Eye St. NW, Suite 1100</street>
<city>Washington</city>
<region>DC</region>
<code>20006</code>
<country>US</country>
</postal>
<phone>+1-202-637-9800</phone>
<email>acooper@cdt.org</email>
<uri>http://www.cdt.org/</uri>
</address>
</author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<author initials="B." surname="Aboba" fullname="Bernard Aboba">
<organization>Microsoft Corporation</organization>
<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>
<email>bernarda@microsoft.com</email>
</address>
</author>
<author initials="J." surname="Peterson" fullname="Jon Peterson">
<organization abbrev="NeuStar, Inc.">NeuStar, Inc.</organization>
<address>
<postal>
<street>1800 Sutter St Suite 570</street>
<city>Concord</city>
<region>CA</region>
<code>94520</code>
<country>US</country>
</postal>
<email>jon.peterson@neustar.biz</email>
</address>
</author>
<author initials="J." surname="Morris" fullname="John B. Morris, Jr.">
<address>
<email>ietf@jmorris.org</email>
</address>
</author>
<author initials="M." surname="Hansen" fullname="Marit Hansen">
<organization>ULD Kiel</organization>
<address>
<email>marit.hansen@datenschutzzentrum.de</email>
</address>
</author>
<author initials="R." surname="Smith" fullname="Rhys Smith">
<organization>JANET(UK)</organization>
<address>
<email>rhys.smith@ja.net</email>
</address>
</author>
<date year="2012"/>
<keyword>Internet-Draft</keyword>
<keyword>Privacy</keyword>
<abstract>
<t>This document offers guidance for developing privacy
considerations for inclusion in IETF documents and aims to make protocol designers aware of privacy-related design choices.
</t>
<t>Discussion of this document is taking place on the IETF Privacy Discussion mailing list
(see https://www.ietf.org/mailman/listinfo/ietf-privacy).</t>
</abstract>
</front>
<middle>
<!-- ====================================================================== -->
<section anchor="introduction" title="Introduction">
<t><xref target="RFC3552" /> provides detailed guidance to protocol designers about both how to consider security as part of protocol design and how to inform readers of IETF documents about security issues. This document intends to provide a similar set of guidance for considering privacy in protocol design.</t>
<t>Privacy is a complicated concept with a rich history that spans many disciplines. With regard to data, often it is a concept applied to "personal data," information relating to an identified or identifiable individual. Many sets of privacy principles and privacy design frameworks have been developed in different forums over the years. These include the Fair Information Practices (FIPs), a baseline set of privacy protections pertaining to the collection and use of personal data (often based on the principles established in <xref target="OECD" />, for example), and the Privacy by Design concept, which provides high-level privacy guidance for systems design (see <xref target="PbD" /> for one example). The guidance provided in this document is inspired by this prior work, but it aims to be more concrete, pointing protocol designers to specific engineering choices that can impact the privacy of the individuals that make use of Internet protocols.</t>
<t>Privacy as a legal concept is understood differently in different jurisdictions. The guidance provided in this document is generic and can be used to inform the design of any protocol to be used anywhere in the world, without reference to specific legal frameworks.</t>
<t>Whether any individual document will require a specific privacy considerations section will depend on the document's content. Documents whose entire focus is privacy may not merit a separate section (for example, <xref target="RFC3325" />). For certain specifications, privacy considerations are a subset of security considerations and can be discussed explicitly in the security considerations section. The guidance provided here can and should be used to assess the privacy considerations of protocol, architectural, and operational specifications and to decide whether those considerations are to be documented in a stand-alone section, within the security considerations section, or throughout the document.</t>
<t>This document is organized as follows. <xref target="scope"/> describes the extent to which the guidance offered is applicable within the IETF. <xref target="terminology" /> explains the terminology used in this document. <xref target="threatmodel"/> discusses threats to privacy as they apply to Internet protocols. <xref target="privacy-goals" /> outlines privacy goals. <xref target="guidelines"/> provides the guidelines for analyzing and documenting privacy considerations within IETF specifications.
<xref target="example"/> examines the privacy characteristics of an IETF protocol to demonstrate the use of the guidance framework.
</t>
</section>
<!-- ====================================================================== -->
<section anchor="scope" title="Scope">
<t>The core function of IETF activity is building protocols. Internet protocols are often built flexibly, making them useful in a variety of architectures, contexts, and deployment scenarios without requiring significant interdependency between disparately designed components. Although protocol designers often have a particular target architecture or set of architectures in mind at design time, it is not uncommon for architectural frameworks to develop later, after implementations exist and have been deployed in combination with other protocols or components to form complete systems.</t>
<t>As a consequence, the extent to which protocol designers can foresee all of the privacy implications of a particular protocol at design time is significantly limited. An individual protocol may be relatively benign on its own, but when deployed within a larger system or used in a way not envisioned at design time, its use may create new privacy risks. Protocols are often implemented and deployed long after design time by different people than those who did the protocol design. The guidelines in <xref target="guidelines" /> ask protocol designers to consider how their protocols are expected to interact with systems and information that exist outside the protocol bounds, but not to imagine every possible deployment scenario.</t>
<t>Furthermore, in many cases the privacy properties of a system are dependent upon the complete system design where various protocols are combined together to form a product solution; the implementation, which includes the user interface design; and operational deployment practices, including default privacy settings and security processes within the company doing the deployment. These details are specific to particular instantiations and generally outside the scope of the work conducted in the IETF. The guidance provided here may be useful in making choices about these details, but its primary aim is to assist with the design, implementation, and operation of protocols.</t>
<t>Transparency of data collection and use -- often effectuated through user interface design -- is normally a key factor in determining the privacy impact of a system. Although most IETF activities do not involve standardizing user interfaces or user-facing communications, in some cases understanding expected user interactions can be important for protocol design. Unexpected user behavior may have an adverse impact on security and/or privacy.</t>
<t> In sum, privacy issues, even those related to
protocol development, go beyond the technical
guidance discussed herein. As an example, consider HTTP <xref target="RFC2616" />, which was designed to allow the exchange of arbitrary data. A complete analysis of the privacy considerations for uses of HTTP might include what type of data is exchanged, how this data is stored, and how it is processed. Hence the analysis for an individual's static personal web page would be different than the use of HTTP for exchanging health records. A protocol designer working on HTTP extensions (such as WebDAV <xref target="RFC4918" />) is not expected to describe the privacy risks derived from all possible usage scenarios, but rather the privacy properties specific to the extensions and any particular uses of the extensions that are expected and foreseen at design time.</t>
</section>
<!-- ====================================================================== -->
<section anchor="terminology" title="Terminology">
<t>This section defines basic terms used in this document, with references to pre-existing definitions as appropriate.</t>
<section anchor="entities" title="Entities">
<t>Several of these terms are further elaborated in <xref target="communications-model" />.</t>
<t>
<list style="hanging">
<t hangText="$ Attacker: ">
An entity that intentionally works against some protection goal.</t>
<t hangText="$ Eavesdropper: ">
An entity that passively observes an initiator's communications without the initiator's knowledge or authorization. See <xref target="RFC4949" />.</t>
<t hangText="$ Enabler: " >
A protocol entity that facilitates communication between an initiator and a recipient without being directly in the communications path.</t>
<t hangText="$ Individual: " >
A natural person.</t>
<t hangText="$ Initiator: ">
A protocol entity that initiates communications with a recipient.</t>
<t hangText="$ Intermediary: ">
A protocol entity that sits between the initiator and the recipient and is necessary for the initiator and recipient to communicate. Unlike an eavesdropper, an intermediary is
an entity that is part of the communication architecture. For example,
a SIP proxy is an intermediary in the SIP architecture.</t>
<t hangText="$ Observer: " >
An entity that is authorized to receive and handle data from an
initiator and thereby is able to observe and collect information, potentially posing privacy threats depending on the context.
As defined in this document, recipients, intermediaries, and enablers can all be
observers.</t>
<t hangText="$ Recipient: ">
A protocol entity that receives communications from an initiator.</t>
</list></t>
</section>
<section anchor="data" title="Data and Analysis">
<t>
<list style="hanging">
<t hangText="$ Correlation: ">
The combination of various pieces of information relating to an individual.</t>
<t hangText="$ Fingerprint: ">
A set of information elements that identifies a device or application instance.</t>
<t hangText="$ Fingerprinting: ">
The process of an observer or attacker uniquely identifying (with a sufficiently high probability) a device or application instance based on multiple information elements communicated to the observer or attacker. See <xref target="EFF" />.</t>
<t hangText="$ Item of Interest (IOI): " >
Any data item that an observer or
attacker might be interested in. This includes attributes,
identifiers, identities, or communications interactions (such as the
sending or receiving of a communication).</t>
<t hangText="$ Personal Data: " >
Any information relating to an identified individual or an individual who
can be identified, directly or indirectly.</t>
<t hangText="$ (Protocol) Interaction: " >
A unit of communication within a particular protocol. A single interaction may be compromised of a single message between an initiator and recipient or multiple messages, depending on the protocol.</t>
<t hangText="$ Traffic Analysis: ">
The inference of information from observation of traffic
flows (presence, absence, amount, direction, and frequency). See <xref target="RFC4949" />.</t>
<t hangText="$ Undetectability: "> The inability of an observer or attacker to sufficiently distinguish whether an item of interest exists or
not.</t>
<t hangText="$ Unlinkability: "> Within a particular
set of information, the inability of an observer or attacker to
distinguish whether two items of interest are related or not (with a high enough degree of probability to be useful to the observer or attacker).</t>
</list></t>
</section>
<section anchor="identifiability" title="Identifiability">
<t>
<list style="hanging">
<t hangText="$ Anonymity: ">The state of being anonymous.</t>
<t hangText="$ Anonymous: ">A property of an individual in which an observer or attacker cannot identify the individual within a set of other individuals (the anonymity set).</t>
<t hangText="$ Attribute: " >A property of an individual or initiator.</t>
<t hangText="$ Identifiable: ">
A state in which a individual's identity is capable of being known.</t>
<t hangText="$ Identifiability: ">
The extent to which an individual is identifiable.</t>
<t hangText="$ Identified: ">
A state in which an individual's identity is known.</t>
<t hangText="$ Identifier: ">
A data object that represents a specific identity of a protocol entity or individual. See <xref target="RFC4949" />.</t>
<t hangText="$ Identification: ">
The linking of information to a particular individual to infer the individual's identity or that allows the inference of the individual's identity.</t>
<t hangText="$ Identity: ">
Any subset of an individual's attributes that identifies the individual within a given context. Individuals usually have multiple identities for use in different contexts.</t>
<t hangText="$ Identity confidentiality: ">A property of an individual wherein any party other than the recipient
cannot sufficiently identify the individual within a set of other individuals (the anonymity set).
</t>
<t hangText="$ Identity provider: ">An entity (usually an organization) that is responsible for establishing, maintaining, and securing the identity associated with individuals.</t>
<t hangText="$ Pseudonym: ">
An identifier of an individual other than the individual's real name.</t>
<t hangText="$ Pseudonymity: ">
The state of being pseudonymous.</t>
<t hangText="$ Pseudonymous: ">
A property of an individual in which the individual is identified by a pseudonym.</t>
<t hangText="$ Real name: ">The opposite of a pseudonym. An individual's real name typically comprises his or her given names and a family name. An individual may have multiple real names over a lifetime, including legal names. From a technological perspective it cannot always be determined whether an identifier of an individual is a pseudonym or a real name.
</t>
<t hangText="$ Relying party: ">An entity that manages access to some
resource. Security mechanisms allow the relying party to delegate aspects of identity management to an identity provider. This delegation requires protocol exchanges, trust, and a common understanding of semantics of information exchanged between the relying party and the identity provider.
</t>
</list></t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="threatmodel" title="Internet Privacy Threat Model">
<t>Privacy harms come in a number of forms, including harms to financial standing, reputation, solitude, autonomy, and safety. A victim of identity theft or blackmail, for example, may suffer a financial loss as a result. Reputational harm can occur when disclosure of information about an individual, whether true or false, subjects that individual to stigma, embarrassment, or loss of personal dignity. Intrusion or interruption of an individual's life or activities can harm the individual's ability to be left alone. When individuals or their activities are monitored, exposed, or at risk of exposure, those individuals may be stifled from expressing themselves, associating with others, and generally conducting their lives freely. They may also feel a general sense of unease, in that it is "creepy" to be monitored or to have data collected about them. In cases where such monitoring is for the purpose of stalking or violence, it can put individuals in physical danger.</t>
<t>This section lists common privacy threats (drawing liberally from <xref target="Solove" />, as well as <xref target="CoE" />), showing how each of them may cause individuals to incur privacy harms and providing examples of how these threats can exist on the Internet.</t>
<section anchor="communications-model" title="Communications Model">
<t>To understand attacks in the privacy-harm sense, it is helpful to consider the overall communication architecture and different actors' roles within it. Consider a protocol element that initiates communication with some recipient (an "initiator"). Privacy analysis is most relevant for protocols with use cases in which the initiator acts on behalf of a natural person (or different people at different times). It is this individual whose privacy is potentially threatened.</t>
<t>Communications may be direct between the initiator and
the recipient, or they may involve an application-layer intermediary (such as a proxy or cache) that is
necessary for the two parties to communicate. In some cases this
intermediary stays in the communication path for the entire
duration of the communication and sometimes it is only used for
communication establishment, for either inbound or outbound
communication. In rare cases there may be a series of
intermediaries that are traversed. At lower layers, additional entities are involved in packet forwarding that may interfere with privacy protection goals as well.</t>
<t>Some communications tasks require multiple protocol interactions with different entities. For example, a request to an HTTP server may be preceded by an interaction between the initiator and an Authentication, Authorization, and Accounting (AAA) server for network access and to a DNS server for name resolution. In this case, the HTTP server is the recipient and the other entities are enablers of the initiator-to-recipient communication. Similarly, a single communication with the recipient my generate further protocol interactions between either the initiator or the recipient and other entities. For example, an HTTP request might trigger interactions with an authentication server or with other resource servers.</t>
<t>As a general matter, recipients, intermediaries, and enablers are usually assumed to be authorized to receive and handle data from initiators. As <xref target="RFC3552" /> explains, "we assume that the end-systems engaging in a protocol exchange have not themselves been compromised."</t>
<t>Although recipients, intermediairies, and enablers may not generally be considered as attackers, they may all pose privacy threats (depending on the context) because they are able to observe and collect privacy-relevant data. These entities are collectively described below as "observers" to distinguish them from traditional attackers. From a privacy perspective, one important
type of attacker is an eavesdropper: an entity that passively
observes the initiator's communications without the initiator's
knowledge or authorization.</t>
<t>The threat descriptions in the next section explain how observers and attackers might act to harm individuals' privacy. Different kinds of attacks may be feasible at different points in the communications path. For example, an observer could mount surveillance or identification attacks between the initiator and intermediary, or instead could surveil an enabler (e.g., by observing DNS queries from the initiator).</t>
</section>
<section anchor="privacy-threats" title="Privacy Threats">
<t>Some privacy threats are already considered in IETF protocols as a matter of routine security analysis. Others are more pure privacy threats that existing security considerations do not usually address. The threats described here are divided into those that may also be considered security threats and those that are primarily privacy threats.</t>
<t>Note that an individual's awareness of and consent to the practices described below can greatly affect the extent to which they threaten privacy. If an individual authorizes surveillance of his own activities, for example, the harms associated with it may be mitigated, or the individual may accept the risk of harm.</t>
<section anchor="security-privacy-threats" title="Combined Security-Privacy Threats">
<section anchor="surveillance" title="Surveillance">
<t>Surveillance is the observation or monitoring of an individual's communications or activities. The effects of surveillance on the individual can range from anxiety and discomfort to behavioral changes such as inhibition and self-censorship to the perpetration of violence against the individual. The individual need not be aware of the surveillance for it to impact privacy -- the possibility of surveillance may be enough to harm individual autonomy.</t>
<t>Surveillance can be conducted by observers or eavesdroppers at any point along the communications path. Confidentiality protections (as discussed in <xref target="RFC3552" /> Section 3) are necessary to prevent surveillance of the content of communications. To prevent traffic analysis or other surveillance of communications patterns, other measures may be necessary, such as <xref target="Tor" />.</t>
</section>
<section anchor="stored-data-compromise" title="Stored Data Compromise">
<t>End systems that do not take adequate measures to secure stored data from unauthorized or inappropriate access expose individuals to potential financial, reputational, or physical harm.</t>
<t>Protecting against stored data compromise is typically outside the scope of IETF protocols. However, a number of common protocol functions -- key management, access control, or operational logging, for example -- require the storage of data about initiators of communications. When requiring or recommending that information about initiators or their communications be stored or logged by end systems (see, e.g., RFC 6302), it is important to recognize the potential for that information to be compromised and for that potential to be weighed against the benefits of data storage. Any recipient, intermediary, or enabler that stores data may be vulnerable to compromise.</t>
</section>
<section anchor="intrusion" title="Intrusion">
<t>Intrusion consists of invasive acts that disturb or interrupt one's life or activities. Intrusion can thwart individuals' desires to be let alone, sap their time or attention, or interrupt their activities.</t>
<t>Unsolicited messages and denial-of-service attacks are the most common types of intrusion on the Internet. Intrusion can be perpetrated by any attacker that is capable of sending unwanted traffic to the initiator.</t>
</section>
<section anchor="misattribution" title="Misattribution">
<t>Misattribution occurs when data or communications related to one individual are attributed to another. Misattribution can result in adverse reputational, financial, or other consequences for individuals that are misidentified.</t>
<t>Misattribution in the protocol context comes as a result of using inadequate or insecure forms of identity or authentication. For example, as <xref target="RFC6269" /> notes, abuse mitigation is often conducted on the basis of source IP address, such that connections from individual IP addresses may be prevented or temporarily blacklisted if abusive activity is determined to be sourced from those addresses. However, in the case where a single IP address is shared by multiple individuals, those penalties may be suffered by all individuals sharing the address, even if they were not involved in the abuse. This threat can be mitigated by using identity management mechanisms with proper forms of authentication (ideally with cryptographic properties) so that
actions can be attributed uniquely to an individual to provide the basis for accountability without
generating false-positives.</t>
</section>
</section>
<section anchor="privacy-specific-threats" title="Privacy-Specific Threats">
<section anchor="correlation" title="Correlation">
<t>Correlation is the combination of various pieces of information related to an individual. Correlation can defy people's expectations of the limits of what others know about them. It can increase the power that those doing the correlating have over individuals as well as correlators' ability to pass judgment, threatening individual autonomy and reputation.</t>
<t>Correlation is closely related to identification. Internet protocols can facilitate correlation by allowing individuals' activities to be tracked and combined over time. The use of persistent or infrequently replaced identifiers at any layer of the stack can facilitate correlation. For example, an initiator's persistent use of the same device ID, certificate, or email address across multiple interactions could allow recipients to correlate all of the initiator's communications over time. </t>
<t>As an example, consider Transport Layer Security (TLS) session resumption <xref target="RFC5246"/> or TLS session resumption without server side state <xref target="RFC5077"/>. In RFC 5246 <xref target="RFC5246"/> a server provides the client with a session_id in the ServerHello message and caches the master_secret for later exchanges. When the client initiates a new connection with the server it re-uses the previously obtained session_id in its ClientHello message. The server agrees to resume the session by using the same session_id and the previously stored master_secret for the generation of the TLS Record Layer security association. RFC 5077 <xref target="RFC5077"/> borrows from the session resumption design idea but the server encapsulates all state information into a ticket instead of caching it. An attacker who is able to observe the protocol exchanges between the TLS client and the TLS server is able to link the initial exchange to subsequently resumed TLS sessions when the session_id and the ticket are exchanged in the clear (which is the case with data exchanged in the initial handshake messages). </t>
<t>In theory any observer or attacker that receives an initiator's communications can engage in correlation. The extent of the potential for correlation will depend on what data the entity receives from the initiator and has access to otherwise. Often, intermediaries only require a small amount of information for message routing and/or security. In theory, protocol
mechanisms could ensure that end-to-end information is not made
accessible to these entities, but in practice the difficulty of
deploying end-to-end security procedures, additional messaging or
computational overhead, and other business or legal requirements
often slow or prevent the deployment of end-to-end security
mechanisms, giving intermediaries greater exposure to initiators' data than is strictly necessary from a technical point of view.</t>
</section>
<section anchor="identification" title="Identification">
<t>Identification is the linking of information to a particular individual. In some contexts it is perfectly legitimate to identify individuals, whereas in others identification may potentially stifle individuals' activities or expression by inhibiting their ability to be anonymous or pseudonymous. Identification also makes it easier for individuals to be explicitly controlled by others (e.g., governments) and to be treated differentially compared to other individuals.</t>
<t>Many protocols provide functionality to convey the idea that some means has been provided to guarantee that entities are who they claim to be. Often, this is accomplished with cryptographic authentication. Furthermore, many protocol identifiers, such as those used in SIP or XMPP, may allow for the direct identification of individuals. Protocol identifiers may also contribute indirectly to identification via correlation. For example, a web site that does not directly authenticate users may be able to match its HTTP header logs with logs from another site that does authenticate users, rendering users on the first site identifiable.</t>
<t>As with correlation, any observer or attacker may be able to engage in identification depending on the information about the initiator that is available via the protocol mechanism or other channels.</t>
</section>
<section anchor="secondary-use" title="Secondary Use">
<t>Secondary use is the use of collected information without the individual's consent for a purpose different from that for which the information was collected. Secondary use may violate people's expectations or desires. The potential for secondary use can generate uncertainty over how one's information will be used in the future, potentially discouraging information exchange in the first place.</t>
<t>One example of secondary use would be a network access server that uses an initiator's access requests to track the initiator's location. Any observer or attacker could potentially make unwanted secondary uses of initiators' data. Protecting against secondary use is typically outside the scope of IETF protocols.</t>
</section>
<section anchor="disclosure" title="Disclosure">
<t>Disclosure is the revelation of information about an individual that affects the way others judge the individual. Disclosure can violate individuals' expectations of the confidentiality of the data they share. The threat of disclosure may deter people from engaging in certain activities for fear of reputational harm, or simply because they do not wish to be observed.</t>
<t>Any observer or attacker that receives data about an initiator may engage in disclosure. Sometimes disclosure is unintentional because system designers do not realize that information being exchanged relates to individuals. The most common way for protocols to limit disclosure is by providing access control mechanisms (discussed in the next section). A further example is provided by the IETF geolocation privacy architecture <xref target="RFC6280" />, which supports a way for users to express a preference that their location information not be disclosed beyond the intended recipient.</t>
</section>
<section anchor="exclusion" title="Exclusion">
<t>Exclusion is the failure to allow individuals to know about the data that others have about them and to participate in its handling and use. Exclusion reduces accountability on the part of entities that maintain information about people and creates a sense of vulnerability about individuals' ability to control how information about them is collected and used.</t>
<t>The most common way for Internet protocols to be involved in limiting exclusion is through access control mechanisms. The presence architecture developed in the IETF is a good example where individuals are included in the control of information about them. Using a rules expression language (e.g., Presence Authorization Rules <xref target="RFC5025" />), presence clients can authorize the specific conditions under which their presence information may be shared.</t>
<t>Exclusion is primarily considered problematic when the recipient fails to involve the initiator in decisions about data collection, handling, and use. Eavesdroppers engage in exclusion by their very nature since their data collection and handling practices are covert.</t>
</section>
</section>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="privacy-goals" title="Threat Mitigations">
<t>Privacy is notoriously difficult to measure and quantify. The extent to which a particular protocol, system, or architecture "protects" or "enhances" privacy is dependent on a large number of factors relating to its design, use, and potential misuse. However, there are certain widely recognized classes of mitigations against the threats discussed in <xref target="privacy-threats" />. This section describes three categories of relevant mitigations: (1) data minimization, (2) user participation, and (3) security.</t>
<section anchor="data-minimization-goal" title="Data Minimization">
<t>Data minimization refers to collecting, using, disclosing, and storing the minimal data necessary to perform a task. The less data about individuals that gets exchanged in the first place, the lower the chances of that data being misused or leaked.</t>
<t>Data minimization can be effectuated in a number of different ways, including by limiting collection, use, disclosure, retention, identifiability, sensitivity, and access to personal data. Limiting the data collected by protocol elements only to what is necessary (collection limitation) is the most straightforward way to ensure that use of the data does not incur privacy harm. In some cases, protocol designers may also be able to recommend limits to the use or retention of data, although protocols themselves are not often capable of controlling these properties.</t>
<t>However, the most direct application of data minimization to protocol design is limiting identifiability. Reducing the identifiability of data by using pseudonymous or anonymous identifiers helps to weaken the link between an individual and his or her communications. Allowing for the periodic creation of new identifiers reduces the possibility that multiple protocol interactions or communications can be correlated back to the same individual. The following sections explore a number of different properties related to identifiability that protocol designers may seek to achieve.</t>
<t>(Threats mitigated: surveillance, stored data compromise, correlation, identification, secondary use, disclosure)</t>
<section anchor="further-anonymity" title="Anonymity">
<t>To enable anonymity of an individual, there must exist a set of individuals with potentially the same attributes. To the attacker or the observer these individuals must appear indistinguishable from each other. The set of all such individuals is known as the anonymity set and membership of this set may vary over time. </t>
<t>The composition of the anonymity set depends on the knowledge of the observer or attacker. Thus anonymity is relative with respect to the observer or attacker. An initiator may be anonymous only within a set of potential initiators -- its initiator anonymity set -- which itself may be a subset of all individuals that may initiate communications. Conversely, a recipient may be anonymous only within a set of potential recipients -- its recipient anonymity set. Both anonymity sets may be disjoint, may overlap, or may be the same.
</t>
<t>As an example, consider RFC 3325 (P-Asserted-Identity, PAI) <xref target="RFC3325"/>, an extension for the Session Initiation Protocol (SIP), that allows an individual, such as a VoIP caller, to instruct an intermediary that he or she trusts not to populate the SIP From header field with the individual's authenticated and verified identity. The recipient of the call, as well as any other entity outside of the individual's trust domain, would therefore only learn that the SIP message (typically a SIP INVITE) was sent with a header field 'From: "Anonymous" <sip:anonymous@anonymous.invalid>' rather than the individual's address-of-record, which is typically thought of as the "public address" of the user. When PAI is used, the individual becomes anonymous within the initiator anonymity set that is populated by every individual making use of that specific intermediary.
</t>
<t>Note that this example ignores the fact that other personal data may be inferred from the other SIP protocol payloads. This caveat makes the analysis of the specific protocol extension easier but cannot be assumed when conducting analysis of an entire architecture.</t>
</section>
<section anchor="further-pseudonymity" title="Pseudonymity">
<t>In the context of IETF protocols, almost all identifiers are pseudonyms since there is typically no requirement
to use real names in protocols. However, in certain scenarios it is reasonable to assume that real names
will be used (with vCard <xref target="RFC6350" />, for example). </t>
<t>Pseudonymity is strengthened when less personal data can be linked to the pseudonym; when the same pseudonym is used less often and across fewer contexts; and when independently chosen
pseudonyms are more frequently used for new actions (making them, from an observer's or attacker's perspective, unlinkable).</t>
<t>For Internet protocols it is important whether protocols allow pseudonyms to be changed without human interaction,
the default length of pseudonym lifetimes, to whom pseudonyms are exposed,
how individuals are able to control disclosure, how often
pseudonyms can be changed, and the consequences of changing them.</t>
</section>
<section title="Identity Confidentiality">
<t>An initiator has identity confidentiality when any party other than the recipient
cannot sufficiently identify the initiator within the anonymity set. In comparison to anonymity and pseudonymity, identity confidentiality is concerned with eavesdroppers and intermediaries.
</t>
<t>As an example, consider the network access authentication procedures utilizing the Extensible Authentication
Protocol (EAP) <xref target="RFC3748"/>. EAP includes an identity exchange where the Identity Response is primarily used for routing purposes and selecting which EAP method to use. Since EAP Identity Requests and Responses are sent in cleartext, eavesdroppers and intermediaries along the communication path between the EAP peer and the EAP server can snoop on the identity. To address this treat, as discussed in RFC 4282 <xref target="RFC4282"/>, the user's identity can be hidden against these eavesdroppers and intermediaries with the cryptography support by EAP methods. Identity confidentiality has become a recommended design criteria for EAP (see <xref target="RFC4017"/>). EAP-AKA <xref target="RFC4187"/>, for example, protects the EAP peer's identity against passive adversaries by utilizing temporal identities. EAP-IKEv2 <xref target="RFC5106"/> is an example of an EAP method that offers protection against active attackers with regard to the individual's identity.</t>
</section>
<section title="Data Minimization within Identity Management">
<t>Modern systems are increasingly relying on multi-party transactions to authenticate individuals. Many of these systems make use of an identity provider that is responsible for providing authentication and authorization information to entities (relying parties) that require authentication or authorization of individuals in order to process transactions or grant access. To facilitate the provision of authentication and authorization, an identity provider will usually go through a process of verifying the individual's identity and issuing the individual a set of credentials. When an individual seeks to make use of a service provided by the relying party, the relying party relies on the authentication and authorization assertions provided by its identity provider.</t>
<t>Such systems have the ability to support a number of properties that minimize data collection in different ways:</t>
<t><list style="hanging">
<t>Relying parties can be prevented from knowing the real or pseudonymous identity of an individual, since the identity provider is the only entity involved in verifying identity.</t>
<t>Relying parties that collude can be prevented from using an individual’s credentials to track the individual. That is, two different relying parties can be prevented from determining that the same individual has authenticated to both of them. This requires that each relying party use a different means of identifying individuals.</t>
<t>The identity provider can be prevented from knowing which relying
parties an individual interacted with. This requires avoiding direct communication between the identity provider
and the relying party at the time when access to a resource by the initiator is made.</t>
</list></t>
</section>
</section>
<section anchor="user-participation-goal" title="User Participation">
<t>As explained in <xref target="exclusion" />, data collection and use that happens "in secret," without the individual's knowledge, is apt to violate the individual's expectation of privacy and may create incentives for misuse of data. As a result, privacy regimes tend to include provisions to support informing individuals about data collection and use and involving them in decisions about the treatment of their data. In an engineering context, supporting the goal of user participation usually means providing ways for users to control the data that is shared about them. It may also mean providing ways for users to signal how they expect their data to be used and shared. (Threats mitigated: surveillance, secondary use, disclosure, exclusion)</t>
</section>
<section anchor="security-goal" title="Security">
<t>Keeping data secure at rest and in transit is another important component of privacy protection. As they are described in <xref target="RFC3552" /> Section 2, a number of security goals also serve to enhance privacy:</t>
<t><list style='symbols'>
<t>Confidentiality: Keeping data secret from unintended listeners.</t>
<t>Peer entity authentication: Ensuring that the endpoint of a communication is the one that is intended (in support of maintaining confidentiality).</t>
<t>Unauthorized usage: Limiting data access to only those users who are authorized. (Note that this goal also falls within data minimization.)</t>
<t>Inappropriate usage: Limiting how authorized users can use data. (Note that this goal also falls within data minimization.)</t>
</list></t>
<t>Note that even when these goals are achieved, the existence of items of interest -- attributes, identifiers, identities, communications, actions (such as the sending or receiving of a communication), or anything else an attacker or observer might be interested in -- may still be detectable, even if they are not readable. Thus undetectability, in which an observer or attacker cannot sufficiently distinguish whether an item of interest exists or not, may be considered as a further security goal (albeit one that can be extremely difficult to accomplish).</t>
<t>(Threats mitigated: surveillance, stored data compromise, misattribution, secondary use, disclosure, intrusion)</t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="guidelines" title="Guidelines">
<t>This section provides guidance for document authors in the form of a questionnaire about a protocol being designed. The questionnaire may be useful at any point in the design process, particularly after document authors have developed a high-level protocol model as described in <xref target="RFC4101"/>.</t>
<t>Note that the guidance does not recommend specific practices. The range of protocols developed in the IETF is too broad to make recommendations about particular uses of data or how privacy might be balanced against other design goals. However, by carefully considering the answers to each question, document authors should be able to produce a comprehensive analysis that can serve as the basis for discussion of whether the protocol adequately protects against privacy threats.</t>
<t>The framework is divided into four sections that address each of the mitigation classes from <xref target="privacy-goals" />, plus a general section. Security is not fully elaborated since substantial guidance already exists in <xref target="RFC3552" />.</t>
<section anchor="general" title="General">
<t><list style="hanging">
<t>a. Trade-offs. Does the protocol make trade-offs between privacy and usability, privacy and efficiency, privacy and implementability, or privacy and other design goals? Describe the trade-offs and the rationale for the design chosen.</t>
</list></t>
</section>
<section anchor="data-minimization" title="Data Minimization">
<t><list style="hanging">
<t>a. Identifiers. What identifiers does the protocol use for distinguishing initiators of communications? Does the protocol use identifiers that allow different protocol interactions to be correlated?</t>
<t>b. Data. What information does the protocol expose about individuals, their devices, and/or their device usage (other than the identifiers discussed in (a))? To what extent is this information linked to the identities of the individuals? How does the protocol combine personal data with the identifiers discussed in (a)?</t>
<t>c. Observers. Which information discussed in (a) and (b) is exposed to each other protocol entity (i.e., recipients, intermediaries, and enablers)? Are there ways for protocol implementers to choose to limit the information shared with each entity? Are there operational controls available to limit the information shared with each entity?</t>
<t>d. Fingerprinting. In many cases the specific ordering and/or occurrences of information elements in a protocol allow users, devices, or software using the protocol to be fingerprinted. Is this protocol vulnerable to fingerprinting? If so, how?</t>
<t>e. Persistence of identifiers. What assumptions are made in the protocol design about the lifetime of the identifiers discussed in (a)? Does the protocol allow implementers or users to delete or replace identifiers? How often does the specification recommend to delete or replace identifiers by default?</t>
<t>f. Correlation. Does the protocol allow for correlation of identifiers? Are there expected ways that information exposed by the protocol will be combined or correlated with information obtained outside the protocol? How will such combination or correlation facilitate fingerprinting of a user, device, or application? Are there expected combinations or correlations with outside data that will make users of the protocol more identifiable?</t>
<t>g. Retention. Do the protocol or its anticipated uses require that the information discussed in (a) or (b) be retained by recipients, intermediaries, or enablers? Is the retention expected to be persistent or temporary?</t>
</list></t>
</section>
<section anchor="user-participation" title="User Participation">
<t><list style="hanging">
<t>a. User control. What controls or consent mechanisms does the protocol define or require before personal data or identifiers are shared or exposed via the protocol? If no such mechanisms are specified, is it expected that control and consent will be handled outside of the protocol?</t>
<t>b. Control over sharing with individual recipients. Does the protocol provide ways for initiators to share different information with different recipients? If not, are there mechanisms that exist outside of the protocol to provide initiators with such control?</t>
<t>c. Control over sharing with intermediaries. Does the protocol provide ways for initiators to limit which information is shared with intermediaries? If not, are there mechanisms that exist outside of the protocol to provide users with such control? Is it expected that users will have relationships (contractual or otherwise) with intermediaries that govern the use of the information?</t>
<t>d. Preference expression. Does the protocol provide ways for initiators to express individuals' preferences to recipients or intermediaries with regard to the collection, use, or disclosure of their personal data?</t>
</list></t>
</section>
<section anchor="security" title="Security">
<t><list style="hanging">
<t>a. Surveillance. How do the protocol's security considerations prevent surveillance, including eavesdropping and traffic analysis?</t>
<t>b. Stored data compromise. How do the protocol's security considerations prevent or mitigate stored data compromise?</t>
<t>c. Intrusion. How do the protocol's security considerations prevent or mitigate intrusion, including denial-of-service attacks and unsolicited communications more generally?</t>
<t>d. Misattribution. How do the protocol's mechanisms for identifying and/or authenticating individuals prevent misattribution?</t>
</list></t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="example" title="Example">
<t> The following section gives an example of the threat analysis and threat mitigation
recommended by this document. It covers a particularly difficult application protocol, presence,
to try to demonstrate these principles on an architecture that is vulnerable to many of the threats described above.
This text is not intended as an example of a Privacy Considerations section that might appear in an IETF specification,
but rather as an example of the thinking that should go into the design of a protocol when considering privacy as
a first principle.</t>
<t>A presence service, as defined in the abstract in <xref target="RFC2778" />,
allows users of a communications service to monitor one another's
availability and disposition in order to make decisions about
communicating. Presence information is highly dynamic, and generally
characterizes whether a user is online or offline, busy or idle, away
from communications devices or nearby, and the like. Necessarily,
this information has certain privacy implications, and from the start
the IETF approached this work with the aim to provide users with the
controls to determine how their presence information would be shared.
The Common Profile for Presence (CPP) <xref target="RFC3859" /> defines a set of
logical operations for delivery of presence information. This
abstract model is applicable to multiple presence systems. The SIP-
based SIMPLE presence system <xref target="RFC3261" /> uses CPP as its baseline
architecture, and the presence operations in the Extensible Messaging
and Presence Protocol (XMPP) have also been mapped to CPP <xref target="RFC3922" />.</t>
<t>The fundamental architecture defined in RFC 2778 and RFC 3859 is a mediated
one. Clients (presentities in RFC 2778 terms) publish their presence information to presence servers, which
in turn distribute information to authorized watchers. Presence servers thus retain presence information
for an interval of time, until it either changes or expires, so that it can be revealed to authorized
watchers upon request. This architecture mirrors
existing pre-standard deployment models. The integration of an explicit
authorization mechanism into the presence architecture has been widely successful in
involving the end users in the decision making process before
sharing information. Nearly all presence systems deployed today
provide such a mechanism, typically through a reciprocal
authorization system by which a pair of users, when they agree to be
"buddies," consent to divulge their presence information to one
another. Buddylists are managed by servers but controlled by end users. Users
can also explicit block one another through a similar interface, and in some deployments
it is desirable to provide "polite blocking" of various kinds.</t>
<t>From a perspective of privacy design, however, the classical presence architecture
represents nearly a worst-case scenario. In terms of data minimization, presentities
share their sensitive information with presence services, and while services only share this
presence information with watchers authorized by the user, no technical mechanism constrains those
watchers from relaying presence to further third parties. Any of these entities
could conceivable log or retain presence information indefinitely. The sensitivity
cannot be mitigated by rendering the user anonymous, as it is indeed the purpose of the
system to facilitate communications between users who know one another. The identifiers employed
by users are long-lived and often contain personal information, including real names and the domains of service providers.
While users do participate in the construction of buddylists and blacklists,
they do so with little prospect for accountability:
the user effectively throws their presence information over the wall to a presence server
that in turn distributes the information to watchers. Users typically have no way to verify that presence
is being distributed only to authorized watchers, especially as it is the server that authenticates
watchers, not the end user. Connections between the server and all publishers and consumers of presence
data are moreover an attractive target for eavesdroppers, and require strong confidentiality mechanisms, though
again the end user has no way to verify what mechanisms are in place between the presence server and a watcher.</t>
<t>Moreover, the sensitivity of presence information is not limited to
the disposition and capability to communicate. Capability can reveal the type of device that a user employs, for example, and
since multiple devices can publish the same user's presence, there are significant risks of allowing attackers to correlate user devices.
An important extension to presence was developed to enable the support for
location sharing. The effort to standardize protocols for
systems sharing geolocation was started in the GEOPRIV
working group. During the initial requirements and privacy threat
analysis in the process of chartering the working group, it became
clear that the system would require an underlying communication mechanism
supporting user consent to share location information. The
resemblance of these requirements to the presence framework was
quickly recognized, and this design decision was documented in <xref target="RFC4079" />. Location information thus mingles with other presence information available through the system
to intermediaries and to authorized watchers.</t>
<t>Privacy concerns about presence information largely arise due to the built-in mediation of the presence architecture.
The need for a presence server is motivated by two primary design requirements of presence: in the first place,
the server can respond with an "offline" indication when the user is not online; in the
second place, the server can compose presence information published by different devices under
the user's control. Additionally, to preserve the use of URIs as identifiers for entities,
some service must operate a host with the domain name appearing in a presence URI, and in practical
terms no commercial presence architecture would force end users to own and operate their own domain names.
Many end users of applications like presence are behind NATs or firewalls, and effectively cannot receive direct
connections from the Internet - the persistent bidirectional channel these clients open and maintain with a presence
server is essential to the operation of the protocol.</t>
<t>One must first ask if the trade-off of mediation is worth it, for presence.
Does a server need to be in the middle of all publications of presence information? It might seem
that end-to-end encryption of the presence information could solve many of these problems. A presentity
could encrypt the presence information with the public key of a watcher, and only then send the
presence information through the server.
The IETF defined an object format for presence information
called the Presence Information Data
Format (PIDF), which for the purposes of conveying
location information was extended to the PIDF Location
Object (PIDF-LO) - these XML objects were designed to accommodate an encrypted wrapper.
Encrypting this data would have the added benefit of preventing stored cleartext presence information from being
seized by an attacker who manages to compromise a presence server.
This proposal, however,
quickly runs into usability problems. Discovering the public keys of watchers is the first difficulty,
one that few Internet protocols have addressed successfully. This solution would then require the presentity to publish
one encrypted copy of its presence information per authorized watcher to the presence service, regardless of whether
or not a watcher is actively seeking presence information - for a presentity with many watchers, this may
place an unacceptable burden on the presence server, especially given the dynamism of presence information. Finally, it
prevents the server from composing presence information reported by multiple devices under the same user's control. On the whole,
these difficulties render object encryption of presence information a doubtful prospect.</t>
<t>Some protocols
that provide presence information, such as SIP, can operate intermediaries in
a redirecting mode, rather than a publishing or proxying mode. Instead of sending presence information
through the server, in other words, these protocols can merely redirect watchers to the presentity, and
then presence information could pass directly and securely from the presentity to the watcher. In that case,
the presentity can decide exactly what information it would like to share with the watcher in question, it
can authenticate the watcher itself with whatever strength of credential it chooses, and with end-to-end encryption
it can reduce the likelihood of any eavesdropping. In a redirection architecture, a presence server could still
provide the necessary "offline" indication, without requiring the presence server to observe and forward all information
itself. This mechanism is more promising than encryption, but also suffers from significant difficulties. It too does not
provide for composition of presence information from multiple devices - it in fact forces the watcher to perform this
composition itself, which may lead to unexpected results. The largest single impediment to this approach is however the
difficulty of creating end-to-end connections between the presentity's device(s) and a watcher, as some or all of these
endpoints may be behind NATs or firewalls that prevent peer-to-peer connections. While there are potential solutions for
this problem, like STUN and TURN, they add complexity to the overall system.</t>
<t>Consequently, mediation is a difficult feature of the presence architecture to remove, and due especially to the requirement
for composition it is hard to minimize the data shared with intermediaries. Control over sharing with intermediaries must therefore
come from some other explicit component of the architecture. As such, the presence work
in the IETF focused on improving the user participation over the activities of the presence server. This work began in the GEOPRIV
working group, with controls on location privacy, as location of users is perceived as having especially sensitive properties.
With the aim to meet the privacy requirements
defined in <xref target="RFC2779" /> a set of usage indications, such as
whether retransmission is allowed or when the retention period
expires, have been added to PIDF-LO that
always travel with location information itself. These privacy preferences apply not only to the
intermediaries that store and forward presence information, but also to the watchers who consume it.</t>
<t>This approach very much follows the spirit of <eref target="http://creativecommons.org/">Creative Commons</eref>, namely the usage of a limited number of conditions
(such as <eref target="http://wiki.creativecommons.org/Share_Alike">'Share Alike'</eref>). Unlike Creative Commons, the
GEOPRIV working group did not, however, initiate work to produce
legal language nor to design graphical icons since this would fall
outside the scope of the IETF. In particular, the GEOPRIV rules
state a preference on the retention and retransmission of location
information; while GEOPRIV cannot force any entity receiving a
PIDF-LO object to abide by those preferences, if users lack the
ability to express them at all, we can guarantee their preferences
will not be honored.</t>
<t>The retention and retransmission elements were envisioned as the only first
and most essential examples of preference expression in sharing presence. The PIDF
object was designed for extensibility, and the rulesets created for PIDF-LO can
also be extended to provide new expressions of user preference. Not all user preference information
should be bound into a particular PIDF object, however - many forms of access control policy assumed by
the presence architecture need to be provisioned in the presence server by some interface with the user.
This requirement eventually triggered the standardization of a general access control policy
language called the Common Policy (defined in <xref target="RFC4745" />)
framework. This language allows one to express ways to control the
distribution of information as simple conditions, actions, and
transformations rules expressed in an XML format. Common Policy
itself is an abstract format which needs to be instantiated: two
examples can be found with the Presence Authorization Rules <xref target="RFC5025" />
and the Geolocation Policy <xref target="I-D.ietf-geopriv-policy" />. The former
provides additional expressiveness for presence based systems, while
the latter defines syntax and semantic for location based conditions
and transformations.</t>
<t>Ultimately, the privacy work on presence represents a compromise between privacy principles and
the needs of the architecture and marketplace. While it was not feasible to remove intermediaries
from the architecture entirely, nor to prevent their access to presence information, the IETF
did provide a way for users to express their preferences and provision their controls at the presence
service. By documenting and acknowledging the limitations of these mechanisms, the designers were able
to provide implementers, and end users, with an informed perspective on the privacy properties of the
IETF's presence protocols.</t>
</section>
<!-- ====================================================================== -->
<!--
<section anchor="further-terminology" title="Further Terminology and Examples">
<t>This section supplements <xref target="terminology" /> with additional terminology definitions and examples relating them to protocol design.</t>
<t>
<list style="hanging">
<t hangText="Recipient identity anonymity:">A property of a recipient wherein the recipient's identity is kept anonymous from the initiator. For example, consider an identity management scenario, which is a three party scenario, where an identity provider, who manages the data subjects credentials and attributes, shall not observe activities of data subjects throughout the Internet as they interact with relying parties. [I do not understand this example at all. Who is the initiator? Who is the recipient? Also, isn't "identity anonymity" redundant? Isn't all of anonymity about hiding identity? If not, what else is it about? -ALC]</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="Initiator identity anonymity:"> A property of an initiator wherein the initiator remains anonymous towards the recipient. Within the identity management scenario the initiator role corresponds to the identity provider and the recipients are the relying parties. As such, with this property a relying party will not determine the identity provider used by a data subject for a given transaction. [Again I don't understand this. Are we talking about not revealing the identity of the identity provider to the relying party? Doesn't the relying party need to know the identity of the identity provider in order to do transactions with it? Also, why do we even care about the identity of the identity provider? It seems to me that the protecting the identity of the data subject that uses the identity provider is the much more relevant topic. -ALC]</t>
</list>
</t>
-->
<!--
<section anchor="unlinkability" title="Unlinkability">
<t>
<list style="hanging">
<t hangText="$ Unlinkability: "> Within a particular
set of information, a state in which an observer or attacker cannot
distinguish whether two items of interest are related or not (with a high enough degree of probability to be useful to the observer or attacker).</t>
</list></t>
<t>Unlinkability of two or more messages may depend on whether their content is
protected against the observer or attacker. In the cases where this is not true, messages may only be unlinkable if it is
assumed that the observer or attacker is not able to infer information about the initiator or receipient from the
message content itself. It is worth noting that even if the content itself does not betray linkable information explicitly, deep semantic analysis of a message sequence can often detect certain characteristics that link them
together, including similarities in structure, style, use of particular words or phrases, consistent
appearance of certain grammatical errors, and so forth.
</t>
This term is useful for cases where a sequence of interactions between an initiator and a recipient is necessary for the application logic rather than a single-shot message. We refer to this as a session. When doing an analysis with respect to unlinkability we compare this session to a sequence of sessions to determine whether or not they are linkable. [I don't really understand what is meant by "session" here. -ALC]
</section>
<section anchor="further-detection" title="Undetectability">
<t><list style="hanging">
<t hangText="$ Undetectability: "> The state in which an observer or attacker cannot sufficiently distinguish whether an item of interest exists or
not.</t>
</list>
</t>
<t>In contrast to anonymity and unlinkability, where the IOI is protected indirectly through protection of the IOI's relationship to an individual or other IOI, undetectability means the IOI is directly protected.
For example, undetectability is as a desirable property of steganographic
systems.</t>
<t>If we consider the case where an IOI is a message, then undetectability means that the message is not sufficiently discernible from other messages (from, e.g., random noise).</t>
<t>Achieving anonymity, unlinkability, and undetectability may enable extreme data minimization. Unfortunately, this would also prevent a certain class of useful two-way communication scenarios.
Therefore, for many
applications, a certain amount of linkability and detectability is usually accepted while attempting to retain unlinkability between the individual and his or her transactions. This is achieved through the use of appropriate kinds of pseudonymous identifiers. These identifiers are then often used to refer
to established state or are used for access control purposes, see <xref target="I-D.iab-identifier-comparison"/>. [This para seems like it needs to be at the end since it discusses undetectability, but right now there is no concluding section in which to put it, so I put it here for now. -ALC] </t>
</section>
</section>-->
<!-- ====================================================================== -->
<section anchor="SecurityConsiderations" title="Security Considerations">
<t>
This document describes privacy aspects that protocol designers should consider in addition to regular security analysis.</t>
</section>
<!-- ====================================================================== -->
<section anchor="iana" title="IANA Considerations">
<t>
This document does not require actions by IANA. </t>
</section>
<!-- ====================================================================== -->
<section title="Acknowledgements">
<t>We would like to thank Christine Runnegar for her extensive helpful review comments.</t>
<t>We would like to thank Scott Brim, Kasey Chappelle, Marc Linsner,
Bryan McLaughlin, Nick Mathewson, Eric Rescorla, Scott Bradner, Nat
Sakimura, Bjoern Hoehrmann, David Singer, Dean Willis, Christine
Runnegar, Lucy Lynch, Trent Adams, Mark Lizar, Martin Thomson, Josh
Howlett, Mischa Tuffield, S. Moonesamy, Ted Hardie, Zhou Sujing,
Claudia Diaz, Leif Johansson, and Klaas Wierenga.</t>
<t>Finally, we would like to thank the participants for the feedback they provided during the
December 2010 Internet Privacy workshop co-organized by MIT, ISOC, W3C and the IAB.</t>
</section>
</middle>
<!-- ====================================================================== -->
<back>
<!--
<references title="Normative References">
&I-D.iab-privacy-terminology;
</references>
-->
<references title="Informative References">
&I-D.iab-identifier-comparison;
&RFC2616;
&RFC2778;
&RFC2779;
&RFC3261;
&RFC3325;
&RFC3552;
&RFC3748;
&RFC3859;
&RFC3922;
&RFC4017;
&RFC4079;
&RFC4101;
&RFC4187;
&RFC4282;
&RFC4745;
&RFC4918;
&RFC4949;
&RFC5025;
&RFC5077;
&RFC5106;
&RFC5246;
&RFC6269;
&RFC6280;
&RFC6350;
&I-D.ietf-geopriv-policy;
<reference anchor="Chaum">
<front>
<title>Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms</title>
<author fullname="David Chaum" initials="D." surname="Chaum"> </author>
<date year="1981"/>
</front>
<seriesInfo name="Communications of the ACM" value=", 24/2, 84-88"/>
</reference>
<reference anchor="CoE">
<front>
<title>
Recommendation CM/Rec(2010)13
of the Committee of Ministers to member states
on the protection of individuals with regard to automatic processing
of personal data in the context of profiling</title>
<author fullname="" initials="" surname="">
<organization>Council of Europe</organization>
</author>
<date year="2010"/>
</front>
<seriesInfo
name="available at (November 2010)"
value=", https://wcd.coe.int/ViewDoc.jsp?Ref=CM/Rec%282010%2913"/>
<format target="https://wcd.coe.int/ViewDoc.jsp?Ref=CM/Rec%282010%2913" type="HTML"/>
</reference>
<reference anchor="EFF">
<front>
<title>Panopticlick</title>
<author>
<organization>Electronic Frontier Foundation</organization>
</author>
<date year="2011" />
</front>
<format target="http://panopticlick.eff.org" type="HTML" />
</reference>
<reference anchor="OECD">
<front>
<title>OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data</title>
<author fullname="" initials="" surname="">
<organization>Organization for Economic Co-operation and Development</organization>
</author>
<date year="1980"/>
</front>
<seriesInfo
name="available at (September 2010)"
value=", http://www.oecd.org/EN/document/0,,EN-document-0-nodirectorate-no-24-10255-0,00.html"/>
<format target="http://www.oecd.org/EN/document/0,,EN-document-0-nodirectorate-no-24-10255-0,00.html" type="HTML"/>
</reference>
<reference anchor="PbD">
<front>
<title>Privacy by Design</title>
<author>
<organization>Office of the Information and Privacy Commissioner, Ontario, Canada</organization>
</author>
<date year="2011"/>
</front>
<format type='HTML'
target='http://privacybydesign.ca/' />
</reference>
<reference anchor="Solove">
<front>
<title>Understanding Privacy</title>
<author surname="Solove" initials="D.J." fullname="Daniel J. Solove" />
<date year="2010" />
</front>
</reference>
<reference anchor="Tor">
<front>
<title>Tor</title>
<author>
<organization>The Tor Project, Inc.</organization>
</author>
<date year="2011" />
</front>
<format type='HTML' target="https://www.torproject.org/" />
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-22 03:21:47 |