summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6973.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6973.txt')
-rw-r--r--doc/rfc/rfc6973.txt2019
1 files changed, 2019 insertions, 0 deletions
diff --git a/doc/rfc/rfc6973.txt b/doc/rfc/rfc6973.txt
new file mode 100644
index 0000000..d442c4d
--- /dev/null
+++ b/doc/rfc/rfc6973.txt
@@ -0,0 +1,2019 @@
+
+
+
+
+
+
+Internet Architecture Board (IAB) A. Cooper
+Request for Comments: 6973 CDT
+Category: Informational H. Tschofenig
+ISSN: 2070-1721 Nokia Siemens Networks
+ B. Aboba
+ Skype
+ J. Peterson
+ NeuStar, Inc.
+ J. Morris
+
+ M. Hansen
+ ULD
+ R. Smith
+ Janet
+ July 2013
+
+
+ Privacy Considerations for Internet Protocols
+
+Abstract
+
+ This document offers guidance for developing privacy considerations
+ for inclusion in protocol specifications. It aims to make designers,
+ implementers, and users of Internet protocols aware of privacy-
+ related design choices. It suggests that whether any individual RFC
+ warrants a specific privacy considerations section will depend on the
+ document's content.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Architecture Board (IAB)
+ and represents information that the IAB has deemed valuable to
+ provide for permanent record. It represents the consensus of the
+ Internet Architecture Board (IAB). Documents approved for
+ publication by the IAB are not a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6973.
+
+
+
+
+
+
+
+
+Cooper, et al. Informational [Page 1]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+Copyright Notice
+
+ Copyright (c) 2013 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 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper, et al. Informational [Page 2]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 2. Scope of Privacy Implications of Internet Protocols .............5
+ 3. Terminology .....................................................6
+ 3.1. Entities ...................................................7
+ 3.2. Data and Analysis ..........................................8
+ 3.3. Identifiability ............................................9
+ 4. Communications Model ...........................................10
+ 5. Privacy Threats ................................................12
+ 5.1. Combined Security-Privacy Threats .........................13
+ 5.1.1. Surveillance .......................................13
+ 5.1.2. Stored Data Compromise .............................14
+ 5.1.3. Intrusion ..........................................14
+ 5.1.4. Misattribution .....................................14
+ 5.2. Privacy-Specific Threats ..................................15
+ 5.2.1. Correlation ........................................15
+ 5.2.2. Identification .....................................16
+ 5.2.3. Secondary Use ......................................16
+ 5.2.4. Disclosure .........................................17
+ 5.2.5. Exclusion ..........................................17
+ 6. Threat Mitigations .............................................18
+ 6.1. Data Minimization .........................................18
+ 6.1.1. Anonymity ..........................................19
+ 6.1.2. Pseudonymity .......................................20
+ 6.1.3. Identity Confidentiality ...........................20
+ 6.1.4. Data Minimization within Identity Management .......21
+ 6.2. User Participation ........................................21
+ 6.3. Security ..................................................22
+ 7. Guidelines .....................................................23
+ 7.1. Data Minimization .........................................24
+ 7.2. User Participation ........................................25
+ 7.3. Security ..................................................25
+ 7.4. General ...................................................26
+ 8. Example ........................................................26
+ 9. Security Considerations ........................................31
+ 10. Acknowledgements ..............................................31
+ 11. IAB Members at the Time of Approval ...........................32
+ 12. Informative References ........................................32
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper, et al. Informational [Page 3]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+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 protocol specifications about security issues. This
+ document intends to provide a similar set of guidelines for
+ considering privacy in protocol design.
+
+ 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", commonly defined as 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 [OECD], for 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.
+
+ Different people have radically different conceptions of what privacy
+ means, both in general and as it relates to them personally [Westin].
+ Furthermore, 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.
+
+ Whether any individual document warrants 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, "Private Extensions to the Session Initiation
+ Protocol (SIP) for Asserted Identity within Trusted Networks"
+ [RFC3325]). For certain specifications, privacy considerations are a
+ subset of security considerations and can be discussed explicitly in
+ the security considerations section. Some documents will not require
+ discussion of privacy considerations (for example, "Definition of the
+ Opus Audio Codec" [RFC6716]). 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
+
+
+
+
+
+Cooper, et al. Informational [Page 4]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+ document. The guidance provided here is meant to help the thought
+ process of privacy analysis; it does not provide specific directions
+ for how to write a privacy considerations section.
+
+ This document is organized as follows. Section 2 describes the
+ extent to which the guidance offered here is applicable within the
+ IETF and within the larger Internet community. Section 3 explains
+ the terminology used in this document. Section 4 reviews typical
+ communications architectures to understand at which points there may
+ be privacy threats. Section 5 discusses threats to privacy as they
+ apply to Internet protocols. Section 6 outlines mitigations of those
+ threats. Section 7 provides the guidelines for analyzing and
+ documenting privacy considerations within IETF specifications.
+ Section 8 examines the privacy characteristics of an IETF protocol to
+ demonstrate the use of the guidance framework.
+
+2. Scope of Privacy Implications of Internet 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.
+
+ As a consequence, the extent to which protocol designers can foresee
+ all of the privacy implications of a particular protocol at design
+ time is limited. An individual protocol may be relatively benign on
+ its own, and it may make use of privacy and security features at
+ lower layers of the protocol stack (Internet Protocol Security,
+ Transport Layer Security, and so forth) to mitigate the risk of
+ attack. 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 Section 7 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 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
+ of the company doing the deployment. These details are specific to
+
+
+
+Cooper, et al. Informational [Page 5]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+ 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.
+
+ Transparency of data collection and use -- often effectuated through
+ user interface design -- is normally relied on (whether rightly or
+ wrongly) as 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.
+
+ In sum, 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 Web Distributed Authoring and
+ Versioning (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.
+
+3. Terminology
+
+ This section defines basic terms used in this document, with
+ references to pre-existing definitions as appropriate. As in
+ [RFC4949], each entry is preceded by a dollar sign ($) and a space
+ for automated searching. Note that this document does not try to
+ attempt to define the term 'privacy' with a brief definition.
+ Instead, privacy is the sum of what is contained in this document.
+ We therefore follow the approach taken by [RFC3552]. Examples of
+ several different brief definitions are provided in [RFC4949].
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper, et al. Informational [Page 6]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+3.1. Entities
+
+ Several of these terms are further elaborated in Section 4.
+
+ $ Attacker: An entity that works against one or more privacy
+ protection goals. Unlike observers, attackers' behavior is
+ unauthorized.
+
+ $ Eavesdropper: A type of attacker 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.
+
+ $ Individual: A human being.
+
+ $ 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. Unlike an eavesdropper, an intermediary is an
+ entity that is part of the communication architecture and
+ therefore at least tacitly authorized. For example, a SIP
+ [RFC3261] proxy is an intermediary in the SIP architecture.
+
+ $ Observer: An entity that is able to observe and collect
+ information from communications, potentially posing privacy
+ threats, depending on the context. As defined in this document,
+ initiators, recipients, intermediaries, and enablers can all be
+ observers. Observers are distinguished from eavesdroppers by
+ being at least tacitly authorized.
+
+ $ Recipient: A protocol entity that receives communications from an
+ initiator.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper, et al. Informational [Page 7]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+3.2. Data and Analysis
+
+ $ Attack: An intentional act by which an entity attempts to violate
+ an individual's privacy. See [RFC4949].
+
+ $ Correlation: The combination of various pieces of information that
+ relate to an individual or that obtain that characteristic when
+ combined.
+
+ $ Fingerprint: A set of information elements that identifies a
+ device or application instance.
+
+ $ 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 [EFF].
+
+ $ Item of Interest (IOI): Any data item that an observer or attacker
+ might be interested in. This includes attributes, identifiers,
+ identities, communications content, and the fact that a
+ communication interaction has taken place.
+
+ $ Personal Data: Any information relating to an individual who can
+ be identified, directly or indirectly.
+
+ $ (Protocol) Interaction: A unit of communication within a
+ particular protocol. A single interaction may be comprised of a
+ single message between an initiator and recipient or multiple
+ messages, depending on the protocol.
+
+ $ Traffic Analysis: The inference of information from observation of
+ traffic flows (presence, absence, amount, direction, timing,
+ packet size, packet composition, and/or frequency), even if flows
+ are encrypted. See [RFC4949].
+
+ $ Undetectability: The inability of an observer or attacker to
+ sufficiently distinguish whether an item of interest exists
+ or not.
+
+ $ 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).
+
+
+
+
+
+
+
+
+Cooper, et al. Informational [Page 8]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+3.3. Identifiability
+
+ $ Anonymity: The state of being anonymous.
+
+ $ Anonymity Set: A set of individuals that have the same attributes,
+ making them indistinguishable from each other from the perspective
+ of a particular attacker or observer.
+
+ $ Anonymous: A state of an individual in which an observer or
+ attacker cannot identify the individual within a set of other
+ individuals (the anonymity set).
+
+ $ Attribute: A property of an individual.
+
+ $ Identifiability: The extent to which an individual is
+ identifiable.
+
+ $ Identifiable: A property in which an individual's identity is
+ capable of being known to an observer or attacker.
+
+ $ Identification: The linking of information to a particular
+ individual to infer an individual's identity or to allow the
+ inference of an individual's identity in some context.
+
+ $ Identified: A state in which an individual's identity is known.
+
+ $ Identifier: A data object uniquely referring to a specific
+ identity of a protocol entity or individual in some context. See
+ [RFC4949]. Identifiers can be based upon natural names --
+ official names, personal names, and/or nicknames -- or can be
+ artificial (for example, x9z32vb). However, identifiers are by
+ definition unique within their context of use, while natural names
+ are often not unique.
+
+ $ Identity: Any subset of an individual's attributes, including
+ names, that identifies the individual within a given context.
+ Individuals usually have multiple identities for use in different
+ contexts.
+
+ $ Identity Confidentiality: A property of an individual where only
+ the recipient can sufficiently identify the individual within a
+ set of other individuals. This can be a desirable property of
+ authentication protocols.
+
+ $ Identity Provider: An entity (usually an organization) that is
+ responsible for establishing, maintaining, securing, and vouching
+ for the identities associated with individuals.
+
+
+
+
+Cooper, et al. Informational [Page 9]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+ $ Official Name: A personal name for an individual that is
+ registered in some official context (for example, the name on an
+ individual's birth certificate). Official names are often not
+ unique.
+
+ $ Personal Name: A natural name for an individual. Personal names
+ are often not unique and often comprise given names in combination
+ with a family name. An individual may have multiple personal
+ names at any time and over a lifetime, including official names.
+ From a technological perspective, it cannot always be determined
+ whether a given reference to an individual is, or is based upon,
+ the individual's personal name(s) (see Pseudonym).
+
+ $ Pseudonym: A name assumed by an individual in some context,
+ unrelated to the individual's personal names known by others in
+ that context, with an intent of not revealing the individual's
+ identities associated with his or her other names. Pseudonyms are
+ often not unique.
+
+ $ Pseudonymity: The state of being pseudonymous.
+
+ $ Pseudonymous: A property of an individual in which the individual
+ is identified by a pseudonym.
+
+ $ Real Name: See Personal Name and Official Name.
+
+ $ Relying Party: An entity that relies on assertions of individuals'
+ identities from identity providers in order to provide services to
+ individuals. In effect, the relying party delegates aspects of
+ identity management to the identity provider(s). Such delegation
+ requires protocol exchanges, trust, and a common understanding of
+ semantics of information exchanged between the relying party and
+ the identity provider.
+
+4. 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 entity, the "initiator", that
+ initiates communication with some recipient. Privacy analysis is
+ most relevant for protocols with use cases in which the initiator
+ acts on behalf of an individual (or different individuals at
+ different times). It is this individual whose privacy is potentially
+ threatened (although in some instances an initiator communicates
+ information about another individual, in which case both of their
+ privacy interests will be implicated).
+
+
+
+
+
+Cooper, et al. Informational [Page 10]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+ Communications may be direct between the initiator and the recipient,
+ or they may involve an application-layer intermediary (such as a
+ proxy, cache, or relay) 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;
+ sometimes it is only used for communication establishment, for either
+ inbound or outbound communication. In some cases, there may be a
+ series of intermediaries that are traversed. At lower layers,
+ additional entities involved in packet forwarding may interfere with
+ privacy protection goals as well.
+
+ 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 Domain Name System (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
+ might generate further protocol interactions between either the
+ initiator or the recipient and other entities, and the roles of the
+ entities might change with each interaction. For example, an HTTP
+ request might trigger interactions with an authentication server or
+ with other resource servers wherein the recipient becomes an
+ initiator in those later interactions.
+
+ Thus, when conducting privacy analysis of an architecture that
+ involves multiple communications phases, the entities involved may
+ take on different -- or opposing -- roles from a privacy
+ considerations perspective in each phase. Understanding the privacy
+ implications of the architecture as a whole may require a separate
+ analysis of each phase.
+
+ Protocol design is often predicated on the notion that recipients,
+ intermediaries, and enablers are 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". However, privacy analysis requires
+ questioning this assumption, since systems are often compromised for
+ the purpose of obtaining personal data.
+
+ Although recipients, intermediaries, 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, collect,
+ process, and transfer privacy-relevant data. These entities are
+ collectively described below as "observers" to distinguish them from
+ traditional attackers. From a privacy perspective, one important
+
+
+
+
+Cooper, et al. Informational [Page 11]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+ 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 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).
+
+5. Privacy Threats
+
+ 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 (for
+ example, monitoring communications to or from a domestic abuse
+ shelter), it can put individuals in physical danger.
+
+ This section lists common privacy threats (drawing liberally from
+ [Solove], as well as [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. This threat modeling is
+ inspired by security threat analysis. Although it is not a perfect
+ fit for assessing privacy risks in Internet protocols and systems, no
+ better methodology has been developed to date.
+
+ Some privacy threats are already considered in Internet 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.
+
+
+
+
+
+
+Cooper, et al. Informational [Page 12]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+ Note that an individual's awareness of and consent to the practices
+ described below may change an individual's perception of and concern
+ for the extent to which they threaten privacy. If an individual
+ authorizes surveillance of his own activities, for example, the
+ individual may be able to take actions to mitigate the harms
+ associated with it or may consider the risk of harm to be tolerable.
+
+5.1. Combined Security-Privacy Threats
+
+5.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, and even to the
+ perpetration of violence against the individual. The individual need
+ not be aware of the surveillance for it to impact his or her privacy
+ -- the possibility of surveillance may be enough to harm individual
+ autonomy.
+
+ Surveillance can impact privacy, even if the individuals being
+ surveilled are not identifiable or if their communications are
+ encrypted. For example, an observer or eavesdropper that conducts
+ traffic analysis may be able to determine what type of traffic is
+ present (real-time communications or bulk file transfers, for
+ example) or which protocols are in use, even if the observed
+ communications are encrypted or the communicants are unidentifiable.
+ This kind of surveillance can adversely impact the individuals
+ involved by causing them to become targets for further investigation
+ or enforcement activities. It may also enable attacks that are
+ specific to the protocol, such as redirection to a specialized
+ interception point or protocol-specific denials of service.
+ Protocols that use predictable packet sizes or timing or include
+ fixed tokens at predictable offsets within a packet can facilitate
+ this kind of surveillance.
+
+ Surveillance can be conducted by observers or eavesdroppers at any
+ point along the communications path. Confidentiality protections (as
+ discussed in Section 3 of [RFC3552]) 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].
+
+
+
+
+
+
+
+
+
+Cooper, et al. Informational [Page 13]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+5.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.
+
+ 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 [RFC6302]), 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. (Note that stored data compromise is
+ distinct from purposeful disclosure, which is discussed in
+ Section 5.2.4.)
+
+5.1.3. Intrusion
+
+ Intrusion consists of invasive acts that disturb or interrupt one's
+ life or activities. Intrusion can thwart individuals' desires to be
+ left alone, sap their time or attention, or interrupt their
+ activities. This threat is focused on intrusion into one's life
+ rather than direct intrusion into one's communications. The latter
+ is captured in Section 5.1.1.
+
+ 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.
+
+5.1.4. Misattribution
+
+ 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.
+
+ Misattribution in the protocol context comes as a result of using
+ inadequate or insecure forms of identity or authentication, and is
+ sometimes related to spoofing. For example, as [RFC6269] notes,
+ abuse mitigation is often conducted on the basis of the 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
+
+
+
+Cooper, et al. Informational [Page 14]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+ 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.
+
+5.2. Privacy-Specific Threats
+
+5.2.1. Correlation
+
+ Correlation is the combination of various pieces of information
+ related to an individual or that obtain that characteristic when
+ combined. 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 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 (and observers) to correlate all
+ of the initiator's communications over time.
+
+ As an example, consider Transport Layer Security (TLS) session
+ resumption [RFC5246] or TLS session resumption without server-side
+ state [RFC5077]. In RFC 5246 [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 [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).
+
+
+
+
+
+
+Cooper, et al. Informational [Page 15]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+ 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.
+
+5.2.2. Identification
+
+ Identification is the linking of information to a particular
+ individual to infer an individual's identity or to allow the
+ inference of an individual's identity. 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.
+
+ Many protocols provide functionality to convey the idea that some
+ means has been provided to validate 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 the Extensible Messaging and Presence Protocol
+ (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.
+
+ 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.
+
+5.2.3. Secondary Use
+
+ Secondary use is the use of collected information about an individual
+ 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
+
+
+
+Cooper, et al. Informational [Page 16]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+ can generate uncertainty as to how one's information will be used in
+ the future, potentially discouraging information exchange in the
+ first place. Secondary use encompasses any use of data, including
+ disclosure.
+
+ One example of secondary use would be an authentication server that
+ uses a network access server's Access-Requests to track an
+ 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.
+
+5.2.4. Disclosure
+
+ 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.
+
+ 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
+ Section 5.2.5). A further example is provided by the IETF
+ geolocation privacy architecture [RFC6280], which supports a way for
+ users to express a preference that their location information not be
+ disclosed beyond the intended recipient.
+
+5.2.5. Exclusion
+
+ 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 in relation to individuals' ability to control how
+ information about them is collected and used.
+
+ The most common way for Internet protocols to be involved in
+ enforcing 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
+ [RFC5025]), presence clients can authorize the specific conditions
+ under which their presence information may be shared.
+
+
+
+
+
+Cooper, et al. Informational [Page 17]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+ 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.
+
+6. Threat Mitigations
+
+ 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 Section 5. This section describes three categories of
+ relevant mitigations: (1) data minimization, (2) user participation,
+ and (3) security. The privacy mitigations described in this section
+ can loosely be mapped to existing privacy principles, such as the
+ Fair Information Practices, but they have been adapted to fit the
+ target audience of this document.
+
+6.1. Data Minimization
+
+ Data minimization refers to collecting, using, disclosing, and
+ storing the minimal data necessary to perform a task. Reducing the
+ amount of data exchanged reduces the amount of data that can be
+ misused or leaked.
+
+ 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 to only what is necessary
+ (collection limitation) is the most straightforward way to help
+ reduce privacy risks associated with the use of the protocol. 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.
+
+ However, the most direct application of data minimization to protocol
+ design is limiting identifiability. Reducing the identifiability of
+ data by using pseudonyms or no identifiers at all helps to weaken the
+ link between an individual and his or her communications. Allowing
+ for the periodic creation of new or randomized 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.
+
+
+
+
+
+Cooper, et al. Informational [Page 18]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+ Data minimization mitigates the following threats: surveillance,
+ stored data compromise, correlation, identification, secondary use,
+ and disclosure.
+
+6.1.1. Anonymity
+
+ To enable anonymity of an individual, there must exist a set of
+ individuals that appear to have the same attribute(s) as the
+ individual. 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.
+
+ 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.
+
+ As an example, consider RFC 3325 (P-Asserted-Identity (PAI))
+ [RFC3325], an extension for the Session Initiation Protocol (SIP)
+ that allows an individual, such as a Voice over IP (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.
+
+ Note that this example ignores the fact that the recipient may infer
+ or obtain personal data from the other SIP payloads (e.g., SIP Via
+ and Contact headers, the Session Description Protocol (SDP)). The
+ implication is that PAI only attempts to address a particular threat,
+ namely the disclosure of identity (in the From header) with respect
+ to the recipient. This caveat makes the analysis of the specific
+ protocol extension easier but cannot be assumed when conducting
+ analysis of an entire architecture.
+
+
+
+
+
+
+Cooper, et al. Informational [Page 19]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+6.1.2. Pseudonymity
+
+ In the context of Internet protocols, almost all identifiers can be
+ nicknames or pseudonyms, since there is typically no requirement to
+ use personal names in protocols. However, in certain scenarios it is
+ reasonable to assume that personal names will be used (with vCard
+ [RFC6350], for example).
+
+ 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).
+
+ For Internet protocols, the following are important considerations:
+ 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.
+
+6.1.3. Identity Confidentiality
+
+ An initiator has identity confidentiality when any party other than
+ the recipient cannot sufficiently identify the initiator within the
+ anonymity set. The size of the anonymity set has a direct impact on
+ identity confidentiality, since the smaller the set is, the easier it
+ is to identify the initiator. Identity confidentiality aims to
+ provide a protection against eavesdroppers and intermediaries rather
+ than against the intended communication endpoints.
+
+ As an example, consider the network access authentication procedures
+ utilizing the Extensible Authentication Protocol (EAP) [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 Identity 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, which is encoded in the form of the Network Access
+ Identifier (NAI) as defined in RFC 4282 [RFC4282]. To address this
+ threat, as discussed in RFC 4282 [RFC4282], the username part of the
+ NAI (but not the realm part) can be hidden from these eavesdroppers
+ and intermediaries with the cryptographic support offered by EAP
+ methods. Identity confidentiality has become a recommended design
+ criteria for EAP (see [RFC4017]). The EAP method for 3rd Generation
+ Authentication and Key Agreement (EAP-AKA) [RFC4187], for example,
+ protects the EAP peer's identity against passive adversaries by
+ utilizing temporal identities. The EAP-Internet Key Exchange
+
+
+
+Cooper, et al. Informational [Page 20]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+ Protocol version 2 (EAP-IKEv2) method [RFC5106] is an example of an
+ EAP method that offers protection against active attackers with
+ regard to the individual's identity.
+
+6.1.4. Data Minimization within Identity Management
+
+ 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 AAA functionality
+ to relying parties that offer some protected resources. To
+ facilitate these functions, an identity provider will usually go
+ through a process of verifying the individual's identity and issuing
+ credentials to the individual. When an individual seeks to make use
+ of a service provided by the relying party, the relying party relies
+ on the authentication assertions provided by its identity provider.
+ Note that in more sophisticated scenarios the authentication
+ assertions are traits that demonstrate the individual's capabilities
+ and roles. The authorization responsibility may also be shared
+ between the identity provider and the relying party and does not
+ necessarily need to reside only with the identity provider.
+
+ Such systems have the ability to support a number of properties that
+ minimize data collection in different ways:
+
+ In certain use cases, relying parties do not need to know the real
+ name or date of birth of an individual (for example, when the
+ individual's age is the only attribute that needs to be
+ authenticated).
+
+ 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
+ typically requires identity management protocol support as well as
+ support by both the relying party and the identity provider.
+
+ The identity provider can be prevented from knowing which relying
+ parties an individual interacted with. This requires, at a
+ minimum, avoiding direct communication between the identity
+ provider and the relying party at the time when access to a
+ resource by the initiator is made.
+
+6.2. User Participation
+
+ As explained in Section 5.2.5, data collection and use that happen
+ "in secret", without the individual's knowledge, are 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
+
+
+
+Cooper, et al. Informational [Page 21]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+ provisions to require 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.
+ Different protocol and architectural designs can make supporting user
+ participation (for example, the ability to support a dialog box for
+ user interaction) easier or harder; for example, OAuth-based services
+ may have more natural hooks for user input than AAA services.
+
+ User participation mitigates the following threats: surveillance,
+ secondary use, disclosure, and exclusion.
+
+6.3. Security
+
+ Keeping data secure at rest and in transit is another important
+ component of privacy protection. As they are described in Section 2
+ of [RFC3552], 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. (Note that this goal also falls within data
+ minimization.)
+
+ o Inappropriate usage: Limiting how authorized users can use data.
+ (Note that this goal also falls within data minimization.)
+
+ 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).
+
+ Detection of the protocols or applications in use via traffic
+ analysis may be particularly difficult to defend against. As with
+ the anonymity of individuals, achieving "protocol anonymity" requires
+ that multiple protocols or applications exist that appear to have the
+
+
+
+Cooper, et al. Informational [Page 22]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+ same attributes -- packet sizes, content, token locations, or
+ inter-packet timing, for example. An attacker or observer will not
+ be able to use traffic analysis to identify which protocol or
+ application is in use if multiple protocols or applications are
+ indistinguishable.
+
+ Defending against the threat of traffic analysis will be possible to
+ different extents for different protocols, may depend on
+ implementation- or use-specific details, and may depend on which
+ other protocols already exist and whether they share similar traffic
+ characteristics. The defenses will also vary relative to what the
+ protocol is designed to do; for example, in some situations
+ randomizing packet sizes, timing, or token locations will reduce the
+ threat of traffic analysis, whereas in other situations (real-time
+ communications, for example) holding some or all of those factors
+ constant is a more appropriate defense. See "Guidelines for the Use
+ of Variable Bit Rate Audio with Secure RTP" [RFC6562] for an example
+ of how these kinds of trade-offs should be evaluated.
+
+ By providing proper security protection, the following threats can be
+ mitigated: surveillance, stored data compromise, misattribution,
+ secondary use, disclosure, and intrusion.
+
+7. 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 provided in this section 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. This guidance is meant to help the
+ thought process of privacy analysis; it does not provide specific
+ directions for how to write a privacy considerations section.
+
+ The framework is divided into four sections: three sections that
+ address each of the mitigation classes from Section 6, plus a general
+ section. Security is not fully elaborated, since substantial
+ guidance already exists in [RFC3552].
+
+
+
+
+
+Cooper, et al. Informational [Page 23]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+7.1. 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? What identifiers could be omitted or be made less
+ identifying while still fulfilling the protocol's goals?
+
+ 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)?
+
+ 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?
+
+ 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? Can it
+ be designed to reduce or eliminate the vulnerability? If not,
+ why not?
+
+ 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 deleting or replacing identifiers by default? Can the
+ identifiers, along with other state information, be set to
+ automatically expire?
+
+ 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?
+
+
+
+
+
+
+Cooper, et al. Informational [Page 24]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+ g. Retention. Does the protocol or its anticipated uses require
+ that the information discussed in (a) or (b) be retained by
+ recipients, intermediaries, or enablers? If so, why? Is the
+ retention expected to be persistent or temporary?
+
+7.2. 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 or
+ controls 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 that govern the
+ use of the information (contractual or otherwise) with those who
+ operate these intermediaries?
+
+ 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?
+
+7.3. Security
+
+ a. Surveillance. How do the protocol's security considerations
+ prevent surveillance, including eavesdropping and traffic
+ analysis? Does the protocol leak information that can be
+ observed through traffic analysis, such as by using a fixed token
+ at fixed offsets, or packet sizes or timing that allow observers
+ to determine characteristics of the traffic (e.g., which protocol
+ is in use or whether the traffic is part of a real-time flow)?
+
+ b. Stored data compromise. How do the protocol's security
+ considerations prevent or mitigate stored data compromise?
+
+
+
+
+
+
+
+Cooper, et al. Informational [Page 25]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+ c. Intrusion. How do the protocol's security considerations prevent
+ or mitigate intrusion, including denial-of-service attacks and
+ unsolicited communications more generally?
+
+ d. Misattribution. How do the protocol's mechanisms for identifying
+ and/or authenticating individuals prevent misattribution?
+
+7.4. 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.
+
+ b. Defaults. If the protocol can be operated in multiple modes or
+ with multiple configurable options, does the default mode or
+ option minimize the amount, identifiability, and persistence of
+ the data and identifiers exposed by the protocol? Does the
+ default mode or option maximize the opportunity for user
+ participation? Does it provide the strictest security features
+ of all the modes/options? If the answer to any of these
+ questions is no, explain why less protective defaults were
+ chosen.
+
+8. Example
+
+ The following section gives an example of the threat analysis and
+ threat mitigations 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.
+
+ A presence service, as defined in the abstract in [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 of providing users with
+ the controls to determine how their presence information would be
+ shared. The Common Profile for Presence (CPP) [RFC3859] defines a
+ set of logical operations for delivery of presence information. This
+ abstract model is applicable to multiple presence systems. The SIP
+
+
+
+Cooper, et al. Informational [Page 26]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+ for Instant Messaging and Presence Leveraging Extensions (SIMPLE)
+ presence system [RFC3856] uses CPP as its baseline architecture, and
+ the presence operations in the Extensible Messaging and Presence
+ Protocol (XMPP) have also been mapped to CPP [RFC3922].
+
+ 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 explicitly block
+ one another through a similar interface, and in some deployments it
+ is desirable to provide "polite blocking" of various kinds.
+
+ 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 conceivably 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 personal 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. Moreover, connections between the server and all
+ publishers and consumers of presence data are 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.
+
+
+
+
+Cooper, et al. Informational [Page 27]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+ Additionally, the sensitivity of presence information is not limited
+ to the disposition and capability to communicate. Capabilities 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
+ [RFC4079]. Location information thus mingles with other presence
+ information available through the system to intermediaries and to
+ authorized watchers.
+
+ 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
+ facilitate 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.
+
+ One must first ask if the trade-off of mediation for presence is
+ worthwhile. 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
+
+
+
+Cooper, et al. Informational [Page 28]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+ 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.
+
+ Some protocols that support 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. It is
+ worth noting that this would disclose the IP address of the
+ presentity to the watcher, which has its own set of risks. 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. 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 Session Traversal Utilities for NAT (STUN) and Traversal Using
+ Relays around NAT (TURN), they add complexity to the overall system.
+
+ Consequently, mediation is a difficult feature of the presence
+ architecture to remove. It is hard to minimize the data shared with
+ intermediaries, especially due to the requirement for composition.
+ 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 user participation in
+ the activities of the presence server. This work began in the
+ GEOPRIV working group, with controls on location privacy, as location
+
+
+
+Cooper, et al. Informational [Page 29]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+ of users is perceived as having especially sensitive properties.
+ With the aim of meeting the privacy requirements defined in
+ [RFC2779], a set of usage indications, such as whether retransmission
+ is allowed or when the retention period expires, have been added to
+ the PIDF-LO such that they always travel with the 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.
+
+ This approach very much follows the spirit of Creative Commons [CC],
+ namely the usage of a limited number of conditions (such as 'Share
+ Alike' [CC-SA]). Unlike Creative Commons, the GEOPRIV working group
+ did not, however, initiate work to produce legal language or 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. The GEOPRIV rules
+ can provide a means to establish accountability.
+
+ The retention and retransmission elements were envisioned as the most
+ essential examples of preference expression in sharing presence. The
+ PIDF object was designed for extensibility, and the rulesets created
+ for the 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 framework
+ (defined in [RFC4745]). This language allows one to express ways to
+ control the distribution of information as simple conditions,
+ actions, and transformation rules expressed in an XML format. Common
+ Policy itself is an abstract format that needs to be instantiated:
+ two examples can be found with the presence authorization rules
+ [RFC5025] and the Geolocation Policy [RFC6772]. The former provides
+ additional expressiveness for presence-based systems, while the
+ latter defines syntax and semantics for location-based conditions and
+ transformations.
+
+ 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 or 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. We
+ have not had great successes in the implementation space with privacy
+
+
+
+Cooper, et al. Informational [Page 30]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+ mechanisms thus far, but 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.
+
+9. Security Considerations
+
+ This document describes privacy aspects that protocol designers
+ should consider in addition to regular security analysis.
+
+10. Acknowledgements
+
+ We would like to thank Christine Runnegar for her extensive helpful
+ review comments.
+
+ 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, Lucy Lynch,
+ Trent Adams, Mark Lizar, Martin Thomson, Josh Howlett, Mischa
+ Tuffield, S. Moonesamy, Zhou Sujing, Claudia Diaz, Leif Johansson,
+ Jeff Hodges, Stephen Farrell, Steven Johnston, Cullen Jennings, Ted
+ Hardie, Dave Thaler, Klaas Wierenga, Adrian Farrel, Stephane
+ Bortzmeyer, Dave Crocker, and Hector Santos for their useful feedback
+ on this document.
+
+ 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.
+
+ Although John Morris is currently employed by the U.S. Government, he
+ participated in the development of this document in his personal
+ capacity, and the views expressed in the document may not reflect
+ those of his employer.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper, et al. Informational [Page 31]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+11. IAB Members at the Time of Approval
+
+ Bernard Aboba
+ Jari Arkko
+ Marc Blanchet
+ Ross Callon
+ Alissa Cooper
+ Spencer Dawkins
+ Joel Halpern
+ Russ Housley
+ Eliot Lear
+ Xing Li
+ Andrew Sullivan
+ Dave Thaler
+ Hannes Tschofenig
+
+12. Informative References
+
+ [CC-SA] Creative Commons, "Share Alike", 2012,
+ <http://wiki.creativecommons.org/Share_Alike>.
+
+ [CC] Creative Commons, "Creative Commons", 2012,
+ <http://creativecommons.org/>.
+
+ [CoE] Council of Europe, "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", November 2010,
+ <https://wcd.coe.int/ViewDoc.jsp?Ref=CM/Rec%282010%2913>.
+
+ [EFF] Electronic Frontier Foundation, "Panopticlick", 2013,
+ <http://panopticlick.eff.org>.
+
+ [FIPs] Gellman, B., "Fair Information Practices: A Basic
+ History", 2012,
+ <http://bobgellman.com/rg-docs/rg-FIPShistory.pdf>.
+
+ [OECD] Organisation for Economic Co-operation and Development,
+ "OECD Guidelines on the Protection of Privacy and
+ Transborder Flows of Personal Data", (adopted 1980),
+ September 2010, <http://www.oecd.org/>.
+
+ [PbD] Office of the Information and Privacy Commissioner,
+ Ontario, Canada, "Privacy by Design", 2013,
+ <http://privacybydesign.ca/>.
+
+
+
+
+
+
+Cooper, et al. Informational [Page 32]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+ [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.
+
+ [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for
+ Presence and Instant Messaging", RFC 2778, February 2000.
+
+ [RFC2779] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant
+ Messaging / Presence Protocol Requirements", RFC 2779,
+ February 2000.
+
+ [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+ A., Peterson, J., Sparks, R., Handley, M., and E.
+ Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+ June 2002.
+
+ [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.
+
+ [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
+ Levkowetz, "Extensible Authentication Protocol (EAP)",
+ RFC 3748, June 2004.
+
+ [RFC3856] Rosenberg, J., "A Presence Event Package for the Session
+ Initiation Protocol (SIP)", RFC 3856, August 2004.
+
+ [RFC3859] Peterson, J., "Common Profile for Presence (CPP)",
+ RFC 3859, August 2004.
+
+ [RFC3922] Saint-Andre, P., "Mapping the Extensible Messaging and
+ Presence Protocol (XMPP) to Common Presence and Instant
+ Messaging (CPIM)", RFC 3922, October 2004.
+
+ [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
+ Authentication Protocol (EAP) Method Requirements for
+ Wireless LANs", RFC 4017, March 2005.
+
+ [RFC4079] Peterson, J., "A Presence Architecture for the
+ Distribution of GEOPRIV Location Objects", RFC 4079,
+ July 2005.
+
+
+
+
+
+Cooper, et al. Informational [Page 33]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+ [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101,
+ June 2005.
+
+ [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
+ Protocol Method for 3rd Generation Authentication and Key
+ Agreement (EAP-AKA)", RFC 4187, January 2006.
+
+ [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
+ Network Access Identifier", RFC 4282, December 2005.
+
+ [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
+ Polk, J., and J. Rosenberg, "Common Policy: A Document
+ Format for Expressing Privacy Preferences", RFC 4745,
+ February 2007.
+
+ [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.
+
+ [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
+ "Transport Layer Security (TLS) Session Resumption without
+ Server-Side State", RFC 5077, January 2008.
+
+ [RFC5106] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y.,
+ and F. Bersani, "The Extensible Authentication Protocol-
+ Internet Key Exchange Protocol version 2 (EAP-IKEv2)
+ Method", RFC 5106, February 2008.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+ [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
+ Roberts, "Issues with IP Address Sharing", RFC 6269,
+ June 2011.
+
+ [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.
+
+ [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard,
+ "Logging Recommendations for Internet-Facing Servers",
+ BCP 162, RFC 6302, June 2011.
+
+
+
+Cooper, et al. Informational [Page 34]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+ [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
+ August 2011.
+
+ [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of
+ Variable Bit Rate Audio with Secure RTP", RFC 6562,
+ March 2012.
+
+ [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the
+ Opus Audio Codec", RFC 6716, September 2012.
+
+ [RFC6772] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J.,
+ Morris, J., and M. Thomson, "Geolocation Policy: A
+ Document Format for Expressing Privacy Preferences for
+ Location Information", RFC 6772, January 2013.
+
+ [Solove] Solove, D., "Understanding Privacy", March 2010.
+
+ [Tor] The Tor Project, Inc., "Tor", 2013,
+ <https://www.torproject.org/>.
+
+ [Westin] Kumaraguru, P. and L. Cranor, "Privacy Indexes: A Survey
+ of Westin's Studies", December 2005,
+ <http://reports-archive.adm.cs.cmu.edu/anon/isri2005/
+ CMU-ISRI-05-138.pdf>.
+
+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
+
+
+
+
+Cooper, et al. Informational [Page 35]
+
+RFC 6973 Privacy Considerations July 2013
+
+
+ Bernard Aboba
+ Skype
+
+ EMail: bernard_aboba@hotmail.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
+
+
+ Marit Hansen
+ ULD
+
+ EMail: marit.hansen@datenschutzzentrum.de
+
+
+ Rhys Smith
+ Janet
+
+ EMail: rhys.smith@ja.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper, et al. Informational [Page 36]
+