Network Working Group A. Cooper Internet-Draft CDT Intended status: Informational H. Tschofenig Expires: September 13, 2012 Nokia Siemens Networks B. Aboba Microsoft Corporation J. Peterson NeuStar, Inc. J. Morris March 12, 2012 Privacy Considerations for Internet Protocols draft-iab-privacy-considerations-02.txt Abstract This document offers guidance for developing privacy considerations for IETF documents and aims to make protocol designers aware of privacy-related design choices. Discussion of this document is taking place on the IETF Privacy Discussion mailing list (see https://www.ietf.org/mailman/listinfo/ietf-privacy). Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 13, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Cooper, et al. Expires September 13, 2012 [Page 1] Internet-Draft Privacy Considerations March 2012 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Internet Privacy Threat Model . . . . . . . . . . . . . . . . 5 3.1. Communications Model . . . . . . . . . . . . . . . . . . . 5 3.2. Privacy Threats . . . . . . . . . . . . . . . . . . . . . 6 3.2.1. Combined Security-Privacy Threats . . . . . . . . . . 6 3.2.2. Privacy-Specific Threats . . . . . . . . . . . . . . . 8 4. Internet Privacy Goals . . . . . . . . . . . . . . . . . . . . 11 4.1. Data Minimization . . . . . . . . . . . . . . . . . . . . 11 4.2. User Participation . . . . . . . . . . . . . . . . . . . . 12 4.3. Accountability . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Security . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Data Minimization . . . . . . . . . . . . . . . . . . . . 13 5.3. User Participation . . . . . . . . . . . . . . . . . . . . 14 5.4. Accountability . . . . . . . . . . . . . . . . . . . . . . 15 5.5. Security . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Cooper, et al. Expires September 13, 2012 [Page 2] Internet-Draft Privacy Considerations March 2012 1. Introduction [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. 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, [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. Privacy is a complicated concept with a rich history that spans many disciplines. 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 data about individuals (see [OECD] for one example), and the Privacy by Design concept, which provides high-level privacy guidance for systems design (see [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. 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. This document is organized as follows. Section 2 describes the extent to which the guidance offered is applicable within the IETF. Section 3 discusses threats to privacy as they apply to Internet protocols. Section 4 outlines privacy goals. Section 5 provides the guidelines for analyzing and documenting privacy considerations within IETF specifications. Section 6 examines the privacy characteristics of an IETF protocol to demonstrate the use of the guidance framework. Section 7 provides a concise glossary of terms used in this document, with a more complete discussion of some of the terms available in [I-D.iab-privacy-terminology]. Cooper, et al. Expires September 13, 2012 [Page 3] Internet-Draft Privacy Considerations March 2012 2. Scope 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 some protocols assume particular architectures 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. 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. The guidelines in Section 5 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. Furthermore, in many cases the privacy properties of a system are dependent upon API specifics, internal application functionality, database structure, local policy, and other details that 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 those details, but its primary aim is to assist with the design, implementation, and operation of protocols. Privacy issues, even those related to protocol development, go beyond the technical guidance discussed herein. As an example, consider HTTP [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 [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. Cooper, et al. Expires September 13, 2012 [Page 4] Internet-Draft Privacy Considerations March 2012 3. Internet Privacy Threat Model 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. In cases where such monitoring is for the purpose of stalking or violence, it can put individuals in physical danger. This section lists common privacy threats (drawing liberally from [Solove]), showing how each of them may cause individuals to incur privacy harms and providing examples of how these threats can exist on the Internet. 3.1. Communications Model 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 natural person -- the data subject -- whose privacy is potentially threatened. Communications may be direct between the initiator and the recipient, or they may involve an 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. 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 or DNS resolver. 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 Cooper, et al. Expires September 13, 2012 [Page 5] Internet-Draft Privacy Considerations March 2012 initiator or the recipient and other entities. For example, an HTTP request might trigger interactions with an authentication server or with other resource servers. As a general matter, recipients, intermediaries, and enablers are usually assumed to be authorized to receive and handle data from initiators. As [RFC3552] explains, "we assume that the end-systems engaging in a protocol exchange have not themselves been compromised." Although they may not generally be considered as attackers, recipients, intermediaires, and enablers 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. The threat descriptions in the next section explain how observers and attackers might act to harm data subjects' 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). 3.2. Privacy Threats 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. Note that an individual's knowledge and authorization of the practices described below can greatly affect the extent to which they threaten privacy. If a data subject authorizes surveillance of his own activities, for example, the harms associated with it may be significantly mitigated. 3.2.1. Combined Security-Privacy Threats Cooper, et al. Expires September 13, 2012 [Page 6] Internet-Draft Privacy Considerations March 2012 3.2.1.1. Surveillance 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. Surveillance can be conducted by observers or eavesdroppers at any point along the communications path. Confidentiality protections (as discussed in [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 [Tor]. 3.2.1.2. Stored Data Compromise 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. By and large, protecting against stored data compromise is 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. 3.2.1.3. Intrusion 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. Unsolicited mail 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. Cooper, et al. Expires September 13, 2012 [Page 7] Internet-Draft Privacy Considerations March 2012 3.2.2. Privacy-Specific Threats 3.2.2.1. Correlation Correlation is the combination of various pieces of information about 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. Correlation is closely related to identification. Internet protocols can facilitate correlation by allowing data subjects' activities to be tracked and combined over time. The use of persistent or infrequently refreshed 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. 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. 3.2.2.2. Identification 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). Many protocol identifiers, such as those used in SIP or XMPP, may allow for the direct identification of data subjects. 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 Cooper, et al. Expires September 13, 2012 [Page 8] Internet-Draft Privacy Considerations March 2012 logs from another site that does authenticate users, rendering users on the first site identifiable. 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. 3.2.2.3. Secondary Use Secondary use is the use of collected information without the data subject'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. 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. 3.2.2.4. Disclosure Disclosure is the revelation of truthful information about a person that affects the way others judge the person. Disclosure can violate people's 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. Any observer or attacker that receives data about an initiator may choose to engage in disclosure. In most cases, there is nothing done at the protocol level to influence or limit disclosure, although there are some exceptions. For example, the GEOPRIV architecture [RFC6280] provides a way for users to express a preference that their location information not be disclosed beyond the intended recipient. 3.2.2.5. Exclusion Exclusion is the failure to allow the data subject to know about the data that others have about him or her 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. The most common way for Internet protocols to be involved in limiting exclusion is through access control mechanisms. The presence Cooper, et al. Expires September 13, 2012 [Page 9] Internet-Draft Privacy Considerations March 2012 architecture developed in the IETF is a good example where data subjects are included in the control of information about them. Using a rules expression language (e.g., Presence Authorization Rules [RFC5025]), presence clients can authorize the specific conditions under which their presence information may be shared. 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. Cooper, et al. Expires September 13, 2012 [Page 10] Internet-Draft Privacy Considerations March 2012 4. Internet Privacy Goals 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 privacy properties against which designs may be assessed for their potential to impact privacy. This section adapts these properties into four privacy goals for Internet protocols: (1) data minimization, (2) user participation, (3) accountability, and (4) security. 4.1. Data Minimization Data minimization refers to collecting, using, and storing the minimal data necessary to perform a task. The less data about data subjects that gets exchanged in the first place, the lower the chances of that data being used for privacy invasion. Data minimization is comprised of a number of mutually exclusive sub- goals: o Use limitation: Limiting the uses to which data is put helps contain the spread of data to third parties and protects against uses that may violate data subjects' expectations. o Retention limitation: Limiting the duration of data storage reduces the risk of stored data compromise. o Identifiability limitation: Minimization pertains not only to the amount of data exchanged, but also the extent to which it can be used to identify data subjects. Reducing the identifiability of data by using pseudonymous or anonymous identifiers helps to weaken the link between a data subject and his or her communications. Refreshing or recycling identifiers reduces the possibility that multiple protocol interactions or communications can be correlated back to the same data subject. o Sensitivity limitation: The sensitivity of data is another property that can be minimized. For example, the street address of a building that an individual visits may be considered to be a more sensitive piece of information than the city and postal code in which the building is located. Collecting, using, and storing less sensitive data may mitigate the damage caused by secondary use, disclosure, stored data compromise, and correlation. Cooper, et al. Expires September 13, 2012 [Page 11] Internet-Draft Privacy Considerations March 2012 4.2. User Participation As explained in Section 3.2.2.5, data collection and use that happens "in secret," without the data subject's knowledge, is apt to violate the subject's expectation of privacy and may create incentives for misuse of data. As a result, privacy regimes tend to include provisions to support informing data subjects 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. 4.3. Accountability An entity that collects, uses, or stores data can undergird its commitments to the other privacy goals by providing mechanisms by which data subjects and third parties can hold the entity accountable for those commitments. These mechanisms usually allow for verification of what data is collected or stored and with whom it is shared, again helping to mitigate the threat of exclusion. 4.4. Security Keeping data secure at rest and in transit is another important component of privacy protection. As they are described in [RFC3552] Section 2, a number of security goals also serve to enhance privacy: o Confidentiality: Keeping data secret from unintended listeners. o Peer entity authentication: Ensuring that the endpoint of a communication is the one that is intended (in support of maintaining confidentiality). o Unauthorized usage: Limiting data access to only those users who are authorized, helping to prevent stored data compromise. o Inappropriate usage: Limiting how authorized users can use data. (Note that this goal also falls within data minimization.) Cooper, et al. Expires September 13, 2012 [Page 12] Internet-Draft Privacy Considerations March 2012 5. Guidelines 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 [RFC4101]. 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. The framework is divided into four sections that address each of the goals from Section 4, plus a general section. Security is not fully elaborated since substantial guidance already exists in [RFC3552]. 5.1. General 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. 5.2. Data Minimization 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? b. Personal data. What information does the protocol expose about data subjects and/or their devices (other than the identifiers discussed in (a))? To what extent is this information linked to the identities of data subjects? How does the protocol combine personal data with the identifiers discussed in (a)? 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? Cooper, et al. Expires September 13, 2012 [Page 13] Internet-Draft Privacy Considerations March 2012 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? 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 recycle identifiers? How often does the specification recommend to delete or recycle identifiers by default? f. Correlation. 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? 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? 5.3. User Participation 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? 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? 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? Cooper, et al. Expires September 13, 2012 [Page 14] Internet-Draft Privacy Considerations March 2012 d. Preference expression. Does the protocol provide ways for initiators to express data subjects' preferences to recipients or intermediaries with regard to the use or disclosure of their personal data? 5.4. Accountability a. Verification. If the protocol provides for user preference expression, does it also define or require mechanisms that allow initiators to verify that data subjects' preferences are being honored? If not, are there mechanisms that exist outside of the protocol that allow for verification? 5.5. Security a. Surveillance. How do the protocol's security considerations prevent surveillance, including eavesdropping and traffic analyis? b. Stored data compromise. How do the protocol's security considerations prevent or mitigate stored data compromise? c. Intrusion. How do the protocol's security considerations prevent or mitigate intrusion, including denial-of-service attacks and unsolicited communications more generally? Cooper, et al. Expires September 13, 2012 [Page 15] Internet-Draft Privacy Considerations March 2012 6. Example [To be provided in a future version once the guidance is settled.] Cooper, et al. Expires September 13, 2012 [Page 16] Internet-Draft Privacy Considerations March 2012 7. Glossary $ Anonymity The state of being anonymous. See [I-D.iab-privacy-terminology]. $ Anonymous A property of a data subject in which an observer or attacker cannot identify the data subject within a set of other subjects (the anonymity set). $ Attacker An entity that intentionally works against some protection goal. $ Attribute A property of a data subject or initiator. $ Correlation The combination of various pieces of information about a data subject. $ Data Subject An identified natural person or a natural person who can be identified, directly or indirectly. $ Eavesdropper An entity that passively observes an initiator's communications without the initiator's knowledge or authorization. See [RFC4949]. $ Enabler A protocol entity that facilitates communication between an initiator and a recipient without being directly in the communications path. $ Fingerprint A set of information elements that identifies a device, application, or initiator. Cooper, et al. Expires September 13, 2012 [Page 17] Internet-Draft Privacy Considerations March 2012 $ Fingerprinting The process of an observer or attacker partially or fully identifying a device, application, or initiator based on multiple information elements communicated to the observer or attacker. See [EFF]. $ Identifiable A state in which a data subject's identity is known. $ Identifiability The extent to which a data subject is identifiable. See [I-D.iab-privacy-terminology]. $ Identifier A data object that represents a specific identity of a protocol entity or data subject. See [RFC4949]. $ Identification The linking of information to a particular data subject to infer the subject's identity. $ Identity Any subset of a data subject's attributes that identifies the subject within a given context. Data subjects usually have multiple identities for use in different contexts. $ Initiator A protocol entity that initiates communications with a recipient. $ Intermediary A protocol entity that sits between the initiator and the recipient and is necessary for the initiator and recipient to communicate. $ Item of Interest (IOI) Any data item that an observer or attacker might be interested in. This includes attributes, identifiers, identities, communications, or actions (such as the sending or receiving of a communication). See [I-D.iab-privacy-terminology]. Cooper, et al. Expires September 13, 2012 [Page 18] Internet-Draft Privacy Considerations March 2012 $ 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. Recipients, intermediaries, and enablers can all be observers. $ Personal Data Any information relating to a data subject. $ (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. $ Pseudonym An identifier of a data subject other than the subject's real name. $ Pseudonymity The state of being pseudonymous. See [I-D.iab-privacy-terminology]. $ Pseudonymous A property of a data subject in which the subject is identified by a pseudonym. $ Recipient A protocol entity that recieves communications from an initiator. $ Traffic Analysis The inference of information from observation of traffic flows (presence, absence, amount, direction, and frequency). See [RFC4949]. Cooper, et al. Expires September 13, 2012 [Page 19] Internet-Draft Privacy Considerations March 2012 8. Security Considerations This document describes privacy aspects that protocol designers should consider in addition to regular security analysis. Cooper, et al. Expires September 13, 2012 [Page 20] Internet-Draft Privacy Considerations March 2012 9. IANA Considerations This document does not require actions by IANA. Cooper, et al. Expires September 13, 2012 [Page 21] Internet-Draft Privacy Considerations March 2012 10. Acknowledgements 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. Cooper, et al. Expires September 13, 2012 [Page 22] Internet-Draft Privacy Considerations March 2012 11. References 11.1. Normative References [I-D.iab-privacy-terminology] Hansen, M., Tschofenig, H., and R. Smith, "Privacy Terminology", draft-iab-privacy-terminology-00 (work in progress), January 2012. 11.2. Informative References [EFF] Electronic Frontier Foundation, "Panopticlick", 2011. [OECD] Organization for Economic Co-operation and Development, "OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data", available at (September 2010) , http://www.oecd.org/EN/document/ 0,,EN-document-0-nodirectorate-no-24-10255-0,00.html, 1980. [PbD] Office of the Information and Privacy Commissioner, Ontario, Canada, "Privacy by Design", 2011. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June 2005. [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007. [RFC5025] Rosenberg, J., "Presence Authorization Rules", RFC 5025, December 2007. Cooper, et al. Expires September 13, 2012 [Page 23] Internet-Draft Privacy Considerations March 2012 [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011. [Solove] Solove, D., "Understanding Privacy", 2010. [Tor] The Tor Project, Inc., "Tor", 2011. Cooper, et al. Expires September 13, 2012 [Page 24] Internet-Draft Privacy Considerations March 2012 Authors' Addresses Alissa Cooper CDT 1634 Eye St. NW, Suite 1100 Washington, DC 20006 US Phone: +1-202-637-9800 Email: acooper@cdt.org URI: http://www.cdt.org/ Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland Phone: +358 (50) 4871445 Email: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 US Email: bernarda@microsoft.com Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US Email: jon.peterson@neustar.biz John B. Morris, Jr. Email: ietf@jmorris.org Cooper, et al. Expires September 13, 2012 [Page 25]