[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-hansen-privacy-terminology) 00 01 draft-iab-privacy-considerations

Network Working Group                                          M. Hansen
Internet-Draft                                                  ULD Kiel
Intended status: Informational                             H. Tschofenig
Expires: September 13, 2012                       Nokia Siemens Networks
                                                                R. Smith
                                                               JANET(UK)
                                                               A. Cooper
                                                                     CDT
                                                          March 12, 2012


                    Privacy Terminology and Concepts
                  draft-iab-privacy-terminology-01.txt

Abstract

   Privacy is a concept that has been debated and argued throughout the
   last few millennia.  Its most striking feature is the difficulty that
   disparate parties encounter when they attempt to precisely define it.
   In order to discuss privacy in a meaningful way, a tightly defined
   context is necessary.  The specific context of privacy used within
   this document is that of personal data in Internet protocols.
   Personal data is any information relating to a data subject, where a
   data subject is an identified natural person or a natural person who
   can be identified, directly or indirectly.

   A lot of work within the IETF involves defining protocols that can
   potentially transport (either explicitly or implicitly) personal
   data.  This document aims to establish a consistent lexicon around
   privacy for IETF contributors to use when discussing privacy
   considerations within their work.

   Note: This document is discussed at
   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



Hansen, et al.         Expires September 13, 2012               [Page 1]

Internet-Draft      Privacy Terminology and Concepts          March 2012


   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
   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.  Basic Terms  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Identifiability  . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Anonymity  . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Pseudonymity . . . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Identity Confidentiality . . . . . . . . . . . . . . . . .  8
     3.4.  Identity Management  . . . . . . . . . . . . . . . . . . .  8
   4.  Unlinkability  . . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Undetectability  . . . . . . . . . . . . . . . . . . . . . . . 11
   6.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     10.2. Informative References . . . . . . . . . . . . . . . . . . 16














Hansen, et al.         Expires September 13, 2012               [Page 2]

Internet-Draft      Privacy Terminology and Concepts          March 2012


1.  Introduction

   Privacy is a concept that has been debated and argued throughout the
   last few millennia by all manner of people, including philosophers,
   psychologists, lawyers, and more recently, computer scientists.  Its
   most striking feature is the difficulty that disparate parties
   encounter when they attempt to precisely define it.  Each individual,
   group, and culture has its own views and preconceptions about
   privacy, some of which are mutually complimentary and some of which
   diverge.  However, it is generally (but not unanimously) agreed that
   the protection of privacy is "A Good Thing."  People often do not
   realize how they value privacy until they lose it.

   In order to discuss privacy in a meaningful way, a tightly defined
   context is necessary.  The specific context of privacy used within
   this document is that of "personal data" in Internet protocols.
   Personal data is any information relating to a data subject, where a
   data subject is an identified natural person or a natural person who
   can be identified, directly or indirectly.

   A lot of work within the IETF involves defining protocols that can
   potentially transport personal data.  Protocols are therefore capable
   of enabling both privacy protections and privacy breaches.  Protocol
   architects often do not assume a specific relationship between the
   identifiers and data elements communicated in protocols and the
   humans using the software running the protocols.  However, a protocol
   may facilitate the identification of a natural person depending on
   how protocol identifiers and other state are created and
   communicated.

   One commonly held privacy objective is that of data minimization --
   eliminating the potential for personal data to be collected.  Often,
   however, the collection of personal data cannot not be prevented
   entirely, in which case the goal is to minimize the amount of
   personal data that can be collected for a given purpose and to offer
   ways to control the dissemination of personal data.  This document
   focuses on introducing terms used to describe privacy properties that
   support data minimization.

   Other techniques have been proposed and implemented that aim to
   enhance privacy by providing misinformation (inaccurate or erroneous
   information, provided usually without conscious effort to mislead or
   deceive) or disinformation (deliberately false or distorted
   information provided in order to mislead or deceive).  These
   techniques are out of scope for this document.

   This document aims to establish a basic lexicon around privacy so
   that IETF contributors who wish to discuss privacy considerations



Hansen, et al.         Expires September 13, 2012               [Page 3]

Internet-Draft      Privacy Terminology and Concepts          March 2012


   within their work (see [I-D.iab-privacy-considerations]) can do so
   using terminology consistent across areas.  Note that it does not
   attempt to define all aspects of privacy terminology, rather it
   discusses terms describing the most common ideas and concepts.















































Hansen, et al.         Expires September 13, 2012               [Page 4]

Internet-Draft      Privacy Terminology and Concepts          March 2012


2.  Basic Terms

   Personal data:  Any information relating to a data subject.

   Data subject:  An identified natural person or a natural person who
      can be identified, directly or indirectly.

   Item of Interest (IOI):  Any data item that an observer or attacker
      might be interested in.  This includes attributes, identifiers,
      communication actions (such as sending data to or receiving data
      from certain communication partners), etc.

   Initiator:  The protocol entity that starts a communication
      interaction with a recipient.  The term "initiator" is used rather
      than "sender" to highlight the fact that many protocols use
      bidirectional communication where both ends send and receive data

   Recipient:  A protocol entity that recieves communications from an
      initiator.

   Attacker:  An entity that intentionally works against some protection
      goal.  It is assumed that an attacker uses all information
      available to infer information about its items of interest.

   Observer:  A protocol 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.  These entities are not generally considered as
      "attackers" in the security sense, but they are still capable of
      privacy invasion.





















Hansen, et al.         Expires September 13, 2012               [Page 5]

Internet-Draft      Privacy Terminology and Concepts          March 2012


3.  Identifiability

   Identity:  Any subset of a data subject's attributes that identifies
      the data subject within a given context.  Data subjects usually
      have multiple identities for use in different contexts.

   Identifier:  A data object that represents a specific identity of a
      protocol entity or data subject.  See [RFC4949].

   Identifiability:  The extent to which a data subject is identifiable.

   Identification:  The linking of information to a particular data
      subject to infer the subject's identity.

   The following sub-sections define terms related to different ways of
   reducing identifiability.

3.1.  Anonymity

   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).

   Anonymity:  The state of being anonymous.

   To enable anonymity of a data subject, there must exist a set of data
   subjects with potentially the same attributes, i.e., to the attacker
   or the observer these data subjects must appear indistinguishable
   from each other.  The set of all such data subjects 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 data subjects that may initiate
   communications.  Conversely, a recipient may be anonymous only within
   a set of potential receipients -- its receipient 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 a
   data subject, such as a VoIP caller, to instruct an intermediary that
   he or she trusts not to populate the SIP From header field with the
   subject's authenticated and verified identity.  The recipient of the
   call, as well as any other entity outside of the data subject's trust
   domain, would therefore only learn that the SIP message (typically a
   SIP INVITE) was sent with a header field 'From: "Anonymous"



Hansen, et al.         Expires September 13, 2012               [Page 6]

Internet-Draft      Privacy Terminology and Concepts          March 2012


   <sip:anonymous@anonymous.invalid>' rather than the subject's address-
   of-record, which is typically thought of as the "public address" of
   the user (the data subject).  When PAI is used, the data subject
   becomes anonymous within the initiator anonymity set that is
   populated by every data subject making use of that specific
   intermediary.

   Note: This example ignores the fact that other personal data may be
   inferred from the other SIP protocol payloads.  This caveat makes the
   analysis of the specific protocol extension easier but cannot be
   assumed when conducting analysis of an entire architecture.

3.2.  Pseudonymity

   Pseudonym:  An identifier of a subject other than one of the
      subject's real names.

   Real name:  The opposite of a pseudonym.  For example, a natural
      person may possess the names that appear on his or her birth
      certificate or on other official identity documents issued by the
      state.  A natural person's real name typically comprises his or
      her given names and a family name.  A data subject may have
      multiple real names over a lifetime, including legal names.  Note
      that from a technological perspective it cannot always be
      determined whether an identifier of a data subject is a pseudonym
      or a real name.

   Pseudonymous:  A property of a data subject in which the subject is
      identified by a pseudonym.

   Pseudonymity:  The state of being pseudonymous.

   In the context of IETF protocols almost all identifiers are
   pseudonyms since there is typically no requirement to use real names
   in protocols.  However, in certain scenarios it is reasonable to
   assume that real names will be used (with vCard [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 it is important whether protocols allow
   pseudonyms to be changed without human interaction, the default
   length of pseudonym lifetimes, to whom pseudonyms are exposed, how
   data subjects are able to control disclosure, how often pseudonyms



Hansen, et al.         Expires September 13, 2012               [Page 7]

Internet-Draft      Privacy Terminology and Concepts          March 2012


   can be changed, and the consequences of changing them.  These aspects
   are described in [I-D.iab-privacy-considerations].

3.3.  Identity Confidentiality

   Identity confidentiality:  A property of a data subject wherein any
      party other than the recipient cannot sufficiently identify the
      data subject within the anonymity set.  In comparison to anonymity
      and pseudonymity, identity confidentiality is concerned with
      eavesdroppers and intermediaries.

   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 Responses are sent in
   cleartext, eavesdroppers and intermediaries along the communication
   path between the EAP peer and the EAP server can snoop on the
   identity.  To address this treat, as discussed in RFC 4282 [RFC4282],
   the user's identity can be hidden against these observers with the
   cryptography support by EAP methods.  Identity confidentiality has
   become a recommended design criteria for EAP (see [RFC4017]).  EAP-
   AKA [RFC4187], for example, protects the EAP peer's identity against
   passive adversaries by utilizing temporal identities.  EAP-IKEv2
   [RFC5106] is an example of an EAP method that offers protection
   against active observers with regard to the data subject's identity.

3.4.  Identity Management

   Identity Provider (IdP):  An entity (usually an organization) that
      has a relationship with a data subject and is responsible for
      providing authentication and authorization information to relying
      parties (see below).  To facilitate the provision of
      authentication and authorization, an IdP will usually go through a
      process of verifying the data subject's identity and issuing the
      subject a set of credentials.  Each function that the IdP performs
      -- identity verification, credential issuing, providing
      authentication assertions, providing authorization assertions, and
      so forth -- may be performed by separate entities, but for the
      purposes of this document, it is assumed that a single entity is
      performing all of them.

   Relying Party (RP):  An entity that relies on authentication and
      authorization of a data subject provided by an identity provider,
      typically to process a transaction or grant access to information
      or a system.





Hansen, et al.         Expires September 13, 2012               [Page 8]

Internet-Draft      Privacy Terminology and Concepts          March 2012


4.  Unlinkability

   Unlinkability:  Within a particular set of information, a state in
      which an observer or attacker cannot distinguish whether two items
      of interest are related or not (with a high enough degree of
      probability to be useful to the observer or attacker).

   Unlinkability of two or more messages may depend on whether their
   content is protected against the observer or attacker.  In the cases
   where this is not true, messages may only be unlinkable if it is
   assumed that the observer or attacker is not able to infer
   information about the initiator or receipient from the message
   content itself.  It is worth noting that even if the content itself
   does not betray linkable information explicitly, deep semantic
   analysis of a message sequence can often detect certain
   characteristics that link them together, including similarities in
   structure, style, use of particular words or phrases, consistent
   appearance of certain grammatical errors, and so forth.

   There are several items of terminology highly related to
   unlinkability:

   Correlation:  The combination of various pieces of information about
      a data subject.  For example, if an observer or attacker concludes
      that a data subject plays a specific computer game, reads a
      specific news article on a website, and uploads specific videos,
      then the data subject's activities have been correlated, even if
      the observer or attacker is unable to identify the specific data
      subject.

   Relationship anonymity:  When an initiator and receipient (or each
      recipient in the case of multicast) are unlinkable.  The classical
      MIX-net [Chau81] without dummy traffic is one implementation with
      this property: the observer sees who sends and receives messages
      and when they are sent and received, but it cannot figure out who
      is sending messages to whom.

   Unlinkable protocol interaction:  When one protocol interaction is
      not linkable to another protocol interaction of the same protocol.

      An example of a protocol that does not provide this property is
      Transport Layer Security (TLS) session resumption [RFC5246] or the
      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



Hansen, et al.         Expires September 13, 2012               [Page 9]

Internet-Draft      Privacy Terminology and Concepts          March 2012


      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 is exchanged in clear
      (which is the case with data exchange in the initial handshake
      messages).

   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.  For example, the Panopticlick project by the Electronic
      Frontier Foundation uses parameters an HTTP-based Web browser
      shares with sites it visits to determine the uniqueness of the
      browser [panopticlick].

































Hansen, et al.         Expires September 13, 2012              [Page 10]

Internet-Draft      Privacy Terminology and Concepts          March 2012


5.  Undetectability

   Undetectability:  The state in which an observer or attacker cannot
      sufficiently distinguish whether an item of interest exists or
      not.

   In contrast to anonymity and unlinkability, where the IOI is
   protected indirectly through protection of the IOI's relationship to
   a subject or other IOI, undetectability means the IOI is directly
   protected.  For example, undetectability is as a desirable property
   of steganographic systems.

   If we consider the case where an IOI is a message, then
   undetectability means that the message is not sufficiently
   discernible from other messages (from, e.g., random noise).

   Achieving anonymity, unlinkability, and undetectability may enable
   extreme data minimization.  Unfortunately, this would also prevent a
   certain class of useful two-way communication scenarios.  Therefore,
   for many applications, a certain amount of linkability and
   detectability is usually accepted while attempting to retain
   unlinkability between the data subject and his or her transactions.
   This is achieved through the use of appropriate kinds of pseudonymous
   identifiers.  These identifiers are then often used to refer to
   established state or are used for access control purposes, see
   [I-D.iab-identifier-comparison].

























Hansen, et al.         Expires September 13, 2012              [Page 11]

Internet-Draft      Privacy Terminology and Concepts          March 2012


6.  Example

   [To be provided in a future version once the guidance is settled.]
















































Hansen, et al.         Expires September 13, 2012              [Page 12]

Internet-Draft      Privacy Terminology and Concepts          March 2012


7.  Acknowledgments

   Parts of this document utilizes content from [anon_terminology],
   which had a long history starting in 2000 and whose quality was
   improved due to the feedback from a number of people.  The authors
   would like to thank Andreas Pfitzmann for his work on an earlier
   draft version of this document.

   Within the IETF a number of persons had provided their feedback to
   this document.  We would like to thank Scott Brim, Marc Linsner,
   Bryan McLaughlin, Nick Mathewson, Eric Rescorla, Scott Bradner, Nat
   Sakimura, Bjoern Hoehrmann, David Singer, Dean Willis, Christine
   Runnegar, Lucy Lynch, Trend Adams, Mark Lizar, Martin Thomson, Josh
   Howlett, Mischa Tuffield, S. Moonesamy, Ted Hardie, Zhou Sujing,
   Claudia Diaz, Leif Johansson, and Klaas Wierenga.




































Hansen, et al.         Expires September 13, 2012              [Page 13]

Internet-Draft      Privacy Terminology and Concepts          March 2012


8.  Security Considerations

   This document introduces terminology for talking about privacy within
   IETF specifications.  Since privacy protection often relies on
   security mechanisms then this document is also related to security in
   its broader context.













































Hansen, et al.         Expires September 13, 2012              [Page 14]

Internet-Draft      Privacy Terminology and Concepts          March 2012


9.  IANA Considerations

   This document does not require actions by IANA.
















































Hansen, et al.         Expires September 13, 2012              [Page 15]

Internet-Draft      Privacy Terminology and Concepts          March 2012


10.  References

10.1.  Normative References

   [I-D.iab-privacy-considerations]  Cooper, A., Tschofenig, H., Aboba,
                                     B., Peterson, J., and J. Morris,
                                     "Privacy Considerations for
                                     Internet Protocols",
                                     draft-iab-privacy-considerations-01
                                     (work in progress), October 2011.

   [id]                              "Identifier - Wikipedia",
                                     Wikipedia , URL: http://
                                     en.wikipedia.org/wiki/Identifier,
                                     Dec 2011.

10.2.  Informative References

   [Chau81]                          Chaum, D., "Untraceable Electronic
                                     Mail, Return Addresses, and Digital
                                     Pseudonyms", Communications of the
                                     ACM , 24/2, 84-88, 1981.

   [I-D.iab-identifier-comparison]   Thaler, D., "Issues in Identifier
                                     Comparison for Security Purposes",
                                     draft-iab-identifier-comparison-00
                                     (work in progress), July 2011.

   [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.

   [RFC3748]                         Aboba, B., Blunk, L., Vollbrecht,
                                     J., Carlson, J., and H. Levkowetz,
                                     "Extensible Authentication Protocol
                                     (EAP)", RFC 3748, June 2004.

   [RFC4017]                         Stanley, D., Walker, J., and B.
                                     Aboba, "Extensible Authentication
                                     Protocol (EAP) Method Requirements
                                     for Wireless LANs", RFC 4017,
                                     March 2005.

   [RFC4187]                         Arkko, J. and H. Haverinen,
                                     "Extensible Authentication Protocol



Hansen, et al.         Expires September 13, 2012              [Page 16]

Internet-Draft      Privacy Terminology and Concepts          March 2012


                                     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.

   [RFC4949]                         Shirey, R., "Internet Security
                                     Glossary, Version 2", RFC 4949,
                                     August 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.

   [RFC6265]                         Barth, A., "HTTP State Management
                                     Mechanism", RFC 6265, April 2011.

   [RFC6350]                         Perreault, S., "vCard Format
                                     Specification", RFC 6350,
                                     August 2011.

   [anon_terminology]                Pfitzmann, A. and M. Hansen, "A
                                     terminology for talking about
                                     privacy by data minimization:
                                     Anonymity, Unlinkability,
                                     Undetectability, Unobservability,
                                     Pseudonymity, and Identity
                                     Management", URL: http://
                                     dud.inf.tu-dresden.de/literatur/
                                     Anon_Terminology_v0.34.pdf ,



Hansen, et al.         Expires September 13, 2012              [Page 17]

Internet-Draft      Privacy Terminology and Concepts          March 2012


                                     version 034, 2010.

   [panopticlick]                    Eckersley, P., "How Unique Is Your
                                     Web Browser?", Electronig Frontier
                                     Foundation , URL: https://
                                     panopticlick.eff.org/
                                     browser-uniqueness.pdf, 2009.












































Hansen, et al.         Expires September 13, 2012              [Page 18]

Internet-Draft      Privacy Terminology and Concepts          March 2012


Authors' Addresses

   Marit Hansen
   ULD Kiel

   EMail: marit.hansen@datenschutzzentrum.de


   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


   Rhys Smith
   JANET(UK)

   EMail: rhys.smith@ja.net


   Alissa Cooper
   CDT

   EMail: acooper@cdt.org






















Hansen, et al.         Expires September 13, 2012              [Page 19]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/