Network Working Group                                           B. Aboba
Internet-Draft                                     Microsoft Corporation
Intended status: Informational                                 J. Morris
Expires: April 21, 2011                                              CDT
                                                             J. Peterson
                                                           NeuStar, Inc.
                                                           H. Tschofenig
                                                  Nokia Siemens Networks
                                                        October 18, 2010

             Privacy Considerations for Internet Protocols


   This document aims to make protocol designers aware of the privacy-
   related design choices and offers guidance for writing privacy
   considerations in IETF documents.  Similiar to other design aspects
   the IETF influence on the actual deployment is limited.  We discuss
   these limitations but are convinced that protocol architects have
   indeed a role to play in a privacy friendly design by making more
   conscious decision, and by documenting those.

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 21, 2011.

Copyright Notice

   Copyright (c) 2010 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

Aboba, et al.            Expires April 21, 2011                 [Page 1]

Internet-Draft           Privacy Considerations             October 2010

   ( 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.  Historical Background  . . . . . . . . . . . . . . . . . . . .  5
   3.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   4.  Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . 13
   5.  Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   6.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     6.1.  Presence . . . . . . . . . . . . . . . . . . . . . . . . . 16
     6.2.  AAA for Network Access . . . . . . . . . . . . . . . . . . 18
     6.3.  SIP for Internet Telephony . . . . . . . . . . . . . . . . 20
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 24
     10.2. Informative References . . . . . . . . . . . . . . . . . . 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28

Aboba, et al.            Expires April 21, 2011                 [Page 2]

Internet-Draft           Privacy Considerations             October 2010

1.  Introduction

   The IETF is known for its contributions to the design of the Internet
   and the specifications IETF participants produce belong to different
   categories, such as technical specification, best current practice
   descriptions, and architectural documentations.  While these
   documents do not mandate a specific type of implementation they are
   often, if not always, impacted by different architectural design
   decisions.  These decision decisions are influenced by technical
   aspects, expectations about deployment incentives of the involved
   entities, operational considerations, security frameworks, etc.

   This document aims to make protocol designers aware of the privacy-
   related design choices and offers guidance for writing privacy
   considerations in IETF documents.  Similiar to other design aspects
   there is only a certain degree of influence a protocol designer
   working in a standards developing organization has on the final
   deployment outcome.  We discuss these limitations in Section 3.
   Nevertheless, we believe that the IETF community overall has indeed a
   role to play in making specifications more privacy friendly: Being
   aware of how design decisions impact privacy, by reflecting them in
   the protocol design, and by documenting the chosen design choices and
   potential challenges when deploying a single protocol or an entire
   suite of protcols.

   From the activities in the industry one can observe three schools of
   thought in the work on privacy, namely

   Privacy by Technology:  This approach builds on the observation that
      considering privacy in the design of a protocol as a technical
      mechanism.  One approach is to approach a specific application
      problem by sharing fewer data items with other parties (i.e. data
      minimization).  Limiting data sharing also avoids the need for
      evaluation on how consent is obtained, to define policies around
      how to protect data, etc.  The main idea therefore is that
      different architectural designs lead to different results with
      respect to privacy.

      Examples in the area of location privacy can be found in
      [EFF-Privacy].  These solution approaches often make heavy use of
      cryptographic techniques, such as threshold cryptography and
      secret sharing schemes.

   Privacy by Policy:  With this approach it is assumed that privacy
      protection happens to a large degree a matter of getting the
      consent of the user in the form of privacy policies.  Hence,
      protection of the customers privacy is therefore largely a
      responsibility of the company collecting, processing, and storing

Aboba, et al.            Expires April 21, 2011                 [Page 3]

Internet-Draft           Privacy Considerations             October 2010

      personal data.  Notice and choice are offered to the customer and
      backed-up by an appropriate legal framework.

      An example in the area of location-based services is a recent
      publication by CTIA [CTIA].

   Policy/Technology Hybrid:  This approach presents a middle-ground
      where some privacy enhancing features can be provided by
      technology, and made transparent to those who implement (via
      explicit recommendations for implementation, configuration and
      deployment best current practices or implicitly by raising
      awareness via a discussion about privacy in technical
      specifications) but other aspects can only be provided and
      enforced by the parties who decide about the deployment.  For
      deployments often a certain expectation about the existence of an
      appropriate legal framework is required.

   The authors believe that the policy/technology hybrid approach is the
   most practical one and therefore suggest it to be the leading
   paradigm in privacy investigations within the IETF.

   This document is structured as follows: First, we provide a brief
   introduction to the privacy history in Section 2.  In Section 3 we
   illustrate what is in scope of the IETF work and where the
   responsibility of the IETF ends.  In Section 4 we discuss the main
   threat model for privacy investigations.  In Section 5 we propose
   guidelines for investing privacy within IETF specifications and in
   Section VII we discuss privacy characteristics of a few IETF
   protocols and explain what privacy features have been provided until

Aboba, et al.            Expires April 21, 2011                 [Page 4]

Internet-Draft           Privacy Considerations             October 2010

2.  Historical Background

   The "right to be let alone" is a phrase coined by Warren and Brandeis
   in their seminal Harvard Law Review article on privacy [Warren].
   They were the first scholars to recognize that a right to privacy had
   evolved in the 19th century to embrace not only physical privacy but
   also a potential "injury of the feelings", which could, for example,
   result from the public disclosure of embarrassing private facts.

   In 1967 Westin [Westin] described privacy as a "personal adjustment
   process" in which individuals balance "the desire for privacy with
   the desire for disclosure and communication" in the context of social
   norms and their environment.  Privacy thus requires that an
   individual has a means to exercise selective control of access to the
   self and is aware of the potential consequences of exercising that
   control [Altman].

   Efforts to define and analyze the privacy concept evolved
   considerably in the 20th century.  In 1975, Altman conceptualized
   privacy as a "boundary regulation process whereby people optimize
   their accessibility along a spectrum of 'openness' and 'closedness'
   depending on context" [Altman].  "Privacy is the claim of
   individuals, groups, or institutions to determine for themselves
   when, how, and to what extent information about them is communicated
   to others.  Viewed in terms of the relation of the individual to
   social participation, privacy is the voluntary and temporary
   withdrawal of a person from the general society through physical or
   psychological means, either in a state of solitude or small-group
   intimacy or, when among larger groups, in a condition of anonymity or
   reserve."  [Westin].

   Note: Altman and Westin were referring to nonelectronic environments,
   where privacy intrusion was typically based on fresh information,
   referring to one particular person only, and stemming from traceable
   human sources.  The scope of possible privacy breaches was therefore
   rather limited.  Today, in contrast, details about an individual's
   activities are typically stored over a longer period of time,
   collected from many different sources, and information about almost
   every activity in life is available electronically.

   In 1980, the Organization for Economic Co-operation and Development
   (OECD) published eight Guidelines on the Protection of Privacy and
   Trans-Border Flows of Personal Data [OECD], which are often referred
   to as Fair Information Practices (FIPs).  Fair information practices
   include the following principles:

Aboba, et al.            Expires April 21, 2011                 [Page 5]

Internet-Draft           Privacy Considerations             October 2010

   Notice and Consent:  Before the collection of data, the data subject
      should be provided: notice of what information is being collected
      and for what purpose and an opportunity to choose whether to
      accept the data collection and use.  In Europe, data collection
      cannot proceed unless data subject has unambiguously given his
      consent (with exceptions).

   Collection Limitation:  Data should be collected for specified,
      explicit and legitimate purposes.  The data collected should be
      adequate, relevant and not excessive in relation to the purposes
      for which they are collected.

   Use/Disclosure Limitation:  Data should be used only for the purpose
      for which it was collected and should not be used or disclosed in
      any way incompatible with those purposes.

   Retention Limitation:  Data should be kept in a form that permits
      identification of the data subject no longer than is necessary for
      the purposes for which the data were collected.

   Accuracy:  The party collecting and storing data is obligated to
      ensure its accuracy and, where necessary, keep it up to date;
      every reasonable step must be taken to ensure that data which are
      inaccurate or incomplete are corrected or deleted.

   Access:  A data subject should have access to data about himself, in
      order to verify its accuracy and to determine how it is being

   Security:  Those holding data about others must take steps to protect
      its confidentiality.

   The OECD guidelines and also recent onces, like the Madrid resolution
   [Madrid] or the Granada Charter of Privacy in a Digital World
   [Granada], provide a useful understanding of how to provide privacy
   protection but these guidelines quite naturally stay on a higher
   level.  As such, they do not aim to evaluate the tradeoffs in
   addressing privacy protection in the different stages of the
   development process, as illustrated in Figure 1.

   US regulatory and self-regulatory efforts supported by the Federal
   Trade Commission (FTC) have focused on a subset of these principles,

Aboba, et al.            Expires April 21, 2011                 [Page 6]

Internet-Draft           Privacy Considerations             October 2010

   namely to notice, choice, access, and security rather than minimizing
   data collection or use limitation.  Hence, they are sometimes labeled
   as the "notice and choice" approach to privacy.  From a practical
   point of view it became evident that companies are reluctant to stop
   collecting and using data but individuals expect to remain in control
   about its usage.  Today, the effectiveness to deal with privacy
   violations using the "notice and choice" approach is heavily
   criticized [limits].

   Among these considers (although often implicit) are assumptions on
   how information is exchanged between different parties and for
   certain protocols this information may help to identify entities, and
   potentially humans behind them.  Without doubt the information
   exchanged is not always equal.  The terms 'personal data' [DPD95] and
   Personally Identifiable Information (PII) [SP800-122] have become
   common language in the vocabulary of privacy experts.  It seems
   therefore understandable that regulators around the globe have
   focused on the type of data being exchanged and have provided laws
   according to the level of sensitivity.  Medical data is treated
   differently in many juristictions than blog comments.  For an initial
   investigation it is intuitive and helpful to determine whether
   specific protocol or application may be privacy sensitive.  The ever
   increasing ability for parties on the Internet to collect, aggregate,
   and to reason about information collected from a wide range of
   sources requires to apply further thinking about potential other
   privacy sensitive items.  The recent example of browser
   fingerprinting [browser-fingerprinting] shows how many information
   items combined can lead to a privacy threat.

   The following list contains examples of information that may be
   considered personal data:

   o  Name

   o  Address information

   o  Phone numbers, email addresses, SIP/XMPP URIs, other identifiers

   o  IP and MAC addresses or other host-specific persistent identifiers
      that consistently links to a particular person or small, well-
      defined group of people

   o  Information identifying personally owned property, such as vehicle
      registration number

   Data minimization means that first of all, the possibility to collect
   personal data about others should be minimized.  Next, within the
   remaining possibilities, collecting personal data should be

Aboba, et al.            Expires April 21, 2011                 [Page 7]

Internet-Draft           Privacy Considerations             October 2010

   minimized.  Finally, the time how long collected personal data is
   stored should be minimized.

   As stated in [I-D.hansen-privacy-terminology], "If we exclude
   providing misinformation (inaccurate or erroneous information,
   provided usually without conscious effort at misleading, deceiving,
   or persuading one way or another) or disinformation (deliberately
   false or distorted information given out in order to mislead or
   deceive), data minimization is the only generic strategy to enable
   anonymity, since all correct personal data help to identify.".

   Early papers from the 1980ies about privacy by data minimization
   already deal with anonymity, unlinkability, unobservability, and
   pseudonymity.  [I-D.hansen-privacy-terminology] provides a
   compilation of terms.

Aboba, et al.            Expires April 21, 2011                 [Page 8]

Internet-Draft           Privacy Considerations             October 2010

3.  Scope

   The IETF at large produces specifications that typically fall into
   the following categories:

   o  Process specifications (e.g.  WG shepherding guidelines described
      in RFC 4858 [RFC4858]) These documents aim to document and to
      improve the work style within the IETF.

   o  Building blocks (e.g. cryptographic algorithms, MIME types
      registrations).  These specifications are meant to be used with
      other protocols one or several communication paradigms.

   o  Architectural descriptions (for example, on IP-based emergency
      services [I-D.ietf-ecrit-framework], Internet Mail [RFC5598])

   o  Best current practices (e.g.  Guidance for Authentication,
      Authorization, and Accounting (AAA) Key Management [RFC4962])

   o  Policy statements (e.g.  IETF Policy on Wiretapping [RFC2804])

   Often, the architectural description is compiled some time after the
   deployment has long been ongoing and therefore those who implement
   and those who deploy have to make their own determination of which
   protocols they would like to glue together to a complete system.
   This type of work style has the advantage that protocol designers are
   encouraged to write their specifications in a flexible way so that
   they can be used in multiple contexts with different deployment
   scenarios without a huge amount of interdependency between the
   components.  [Tussle] highlights the importance of such an approach
   and [I-D.morris-policy-cons] offers a more detailed discussion.

   This work style has an important consequence for the scope of privacy
   work in the IETF, namely

   o  the standardization work focuses on those parts where
      interoperability is really essentially rather than describing a
      specific instantiation of an architecture and therefore leaving a
      lot of choices for deployments.

   o  application internal functionality, such as API, and details about
      databases are outside the scope of the IETF

   o  regulatory requirements of different juristictions are not part of
      the IETF work either.

   Here is an example that aims to illustrate the boundaries of the IETF
   work: Imagine a social networking site that allows user registration,

Aboba, et al.            Expires April 21, 2011                 [Page 9]

Internet-Draft           Privacy Considerations             October 2010

   requires user authentication prior to usage, and offers its
   functionality for Web browser users via HTTP, real-time messaging
   functionality via XMPP, and email notifications.  Additionally,
   support for data sharing with other Internet service providers is
   provided by OAuth.

   While HTTP, XMPP, Email, and OAuth are IETF specifications they only
   define how the protocol behavior on the wire looks like.  They
   certainly have an architectural spirit that has enormous impact on
   the protocol mechanisms and the set of specifications that are
   required.  However, IETF specifications would not go into details of
   how the user has to register, what type of data he has to provide to
   this social networking site, how long transaction data is kept, how
   requirements for lawful intercept are met, how authorization policies
   are designed to let users know more about data they share with other
   Internet services, how the user's data is secured against authorized
   access, whether the HTTP communication exchange between the browser
   and the social networking site is using TLS or not, what data is
   uploaded by the user, how the privacy policy of the social networking
   site should look like, etc.

   Another example is the usage of HTTP for the Web. HTTP is published
   in RFC 2616 and was designed to allow the exchange of arbitrary data.
   An analysis of potential privacy problems would consider what type of
   data is exchanged, how this data is stored and processed.  Hence, the
   analysis for a static webpage by a company would different than the
   usage of HTTP for exchanging health records.  A protocol designer
   working on HTTP extensions (such as WebDAV) it would therefore be
   difficult to describe all possible privacy considersations given that
   the space of possible usage is essentially unlimited.

Aboba, et al.            Expires April 21, 2011                [Page 10]

Internet-Draft           Privacy Considerations             October 2010

   |Blocks  |       |
   +--------+       |
             |            |----+
             |Architecture|    |
             +------------+    |
                           |Design|        |
                           +------+        |
                                   |              |------+
                                   |Implementation|      |
                                   +--------------+      |
                                                   |          |

                       Figure 1: Development Process

   Figure 1 shows a typical development process.  IETF work often starts
   with identifying building blocks that ccan then be used in different
   architectural variants useful for a wide range of usage scenarios.
   Before implementation activities start a software architecture needs
   to evaluable which components to integrate, how to provide proper
   performance characteristics, etc.  Finally, the implemented work
   needs to be deployed.  Privacy considerations play a role along the
   entire process.

      To pick an example from the security field consider the NIST
      Framework for Designing Cryptographic Key Management Systems
      [SP800-130], NIST SP 800-130.  SP 800-130 provides a number of
      recommendations that can be addressed largely during the system
      design phase as well as in the implementation phase of product
      development.  The cryptographic building blocks and the underlying
      architecture is assumed to be sound.  Even with well-design
      cryptographic components there are plenty of possibilities to
      introduce security vulnerabilities in the later stage of the
      development cycle.

   Similiar to the work on security the impact of work in standards
   developing organizations is limited.  Neverthelesss, discussing
   potential privacy problems and considering privacy in the design of
   an IETF protocol can offer system architects and those deploying
   systems additional insights.  The rest of this document is focused on

Aboba, et al.            Expires April 21, 2011                [Page 11]

Internet-Draft           Privacy Considerations             October 2010

   illustrating how protocol designers can consider privacy in their
   design decisions, as they do factors like security, congestion
   control, scalability, operations and management, etc.

Aboba, et al.            Expires April 21, 2011                [Page 12]

Internet-Draft           Privacy Considerations             October 2010

4.  Threat Model

   To consider privacy in protocol design it useful to think about the
   overall communication architecture and what the different actors
   could do.  This analysis is similar to a threat analysis found in
   security consideration sections of IETF documents.  See also RFC 4101
   [RFC4101] for an illustration on how to write protocol models.  In
   Figure 2 we show a communication model found in many of today's
   protocols where a sender wants to establish communication with some
   recipient and thereby uses some form of intermediary (referred as
   relay in Figure 2.  In some cases this intermediary stays in the
   communication path for the entire duration of the communication and
   sometimes it is only used for communication establishment, for either
   inbound or outbound communication.  In rare cases they may even be a
   series of relays that are traversed.

                                      |           |
                                     >| Recipient |
                                    / |           |
                                  ,'  +-----------+
   +--------+        )-------(  ,'    +-----------+
   |        |        |       | -      |           |
   | Sender |<------>|Relay  |<------>| Recipient |
   |        |        |       |`.      |           |
   +--------+        )-------(  \     +-----------+
       ^                         `.   +-----------+
       :                           \  |           |
       :                            `>| Recipient |
       ..............................>|           |


   <....> End-to-End Communication
   <----> Hop-by-Hop Communication

           Figure 2: Example Instantiation of involved Entities

   We can distinguish between three types of adversaries:

   Eavesdropper:  RFC 4949 describes the act of 'eavesdropping' as

         "Passive wiretapping done secretly, i.e., without the knowledge
         of the originator or the intended recipients of the

Aboba, et al.            Expires April 21, 2011                [Page 13]

Internet-Draft           Privacy Considerations             October 2010

      Eavesdropping is often considered by IETF protocols in the context
      of a security analysis to deal with a range of attacks by offering
      confidentiality protection.

      RFC 3552 provides guidance on how to write security considerations
      for IETF documents and already demands the confidentiality
      security services to be considered.  While IETF protocols offer
      guidance on how to secure communication against eavesdroppers
      deployments sometimes choose not to enable its usage.

   Middleman:  Many protocols developed today show a more complex
      communication pattern than just client and server communication,
      as motivated in Figure 2.  Store-and-forward protocols are
      examples where entities participate in the message delivery even
      though they are not the final recipients.  Often, these
      intermediaries only need to see a small amount of information
      necessary for message routing and security and/or protocol
      mechanisms should ensure that end-to-end information is made
      inaccessible for these entities.  Unfortunately, the difficulty to
      deploy end-to-end security proceduces, the additional messaging,
      the computational overhead, and other business / legal
      requirements often slow down or prevent the deployment of these
      end-to-end security mechanisms giving these intermediaries more
      exposure to communication patters and communication payloads than

   Recipient:  It may seem strange to put the recipient as an adversary
      in this list since the entire purpose of the communication
      interaction is to provide information to it.  However, the degree
      of familiarity and the type of information that needs to be shared
      with such an entity may vary from context to context and also
      between application scenarios.  Often enough, the sender has no
      strong familiarity with the other communication endpoint.  While
      it seems to be advisable to utilize access control before
      disclosing information with such an entity reality in Internet
      communication is not so simple.  As such, a sender may still want
      to limit the amount of information disclosed to the recipient some
      mutual understanding of how this data is treated my need to be
      created, e.g. how long it is kept (retention), whether re-
      distribution is permitted.

Aboba, et al.            Expires April 21, 2011                [Page 14]

Internet-Draft           Privacy Considerations             October 2010

5.  Guidelines

   A pre-condition for reasoning about the impact of a protocol or an
   architecture is to look at the high level protocol model, as
   described in [RFC4101].  This step helps to identify actors and their
   relationship.  The protocol specification (or the set of
   specifications then allows a deep dive into the data that is

   The answers to these questions provide insight into the potential
   privacy impact:

   1.  What entities collect and use data?

       1.a:  How many entities collect and use data?

             Note that this question aims to raise the question of what
             is possible for various entities to inspect (or potentially
             modify).  In architectures with intermediaries, the
             question can be stated as "What data is exposed to
             intermediaries that they do not need to know to do their

       1.b:  For each entity, what type of entity is it?

          +  The first-party site or application

          +  Other sites or applications whose data collection and use
             is in some way controlled by the first party

          +  Third parties that may use the data they collect for other

   2.  For each entity, think about the relationship between the entity
       and the user.

       2.a:  What is the user's familiarity or degree of relationship
          with the entity in other contexts?

       2.b:  What is the user's reasonable expectation of the entity's

   3.  What data about the user is likely needed to be collected?

   4.  What is the identification level of the data? (identified,
       pseudonymous, anonymous, see [I-D.hansen-privacy-terminology])

Aboba, et al.            Expires April 21, 2011                [Page 15]

Internet-Draft           Privacy Considerations             October 2010

6.  Example

   This section allows us to illustrate how privacy was deal within
   certain IETF protocols.  We will start the description with AAA for
   network access and expand it to other protocols in a future version
   of this draft.

6.1.  Presence

   A presence service, as defined in the abstract in RFC 2778 [RFC2778],
   allows users of a communications service to monitor one another's
   availability and disposition in order to make de- cisions about
   communicating.  Presence information is highly dynamic, and generally
   characterizes whether a user is online or offline, busy or idle, away
   from communications devices or nearby, and the like.  Necessarily,
   this information has certain privacy implications, and from the start
   the IETF approached this work with the aim to provide users with the
   controls to determine how their presence information would be shared.
   The Common Profile for Presence (CPP) [RFC3859] defines a set of
   logical operations for delivery of presence information.  This
   abstract model is applicable to multiple presence systems.  The SIP-
   based SIMPLE presence system [RFC3261] uses CPP as its baseline
   architecture, and the presence operations in the Extensible Messaging
   and Presence Protocol (XMPP) have also been mapped to CPP [RFC3922].

   SIMPLE [RFC3261], the application of the Session Initiation Protocol
   (SIP) to instant messaging and presence, has native support for
   subscriptions and notifications (with its event framework [RFC3265])
   and has added an event package [RFC3856] for pres- ence in order to
   satisfy the requirements of CPP.  Other event packages were defined
   later to allow additional information to be exchanged.  With the help
   of the PUBLISH method [RFC3903]. clients are able to install presence
   information on a server, so that the server can apply access-control
   policies before sharing presence information with other entities.
   The integration of an explicit authorization mechanism into the
   presence architecture has been a major improvement in terms of
   involving the end users in the decision making pro- cess 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

   One important extension for presence was to enable the support for
   location sharing.  With the desire to standardize protocols for
   systems sharing geolocation IETF work 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

Aboba, et al.            Expires April 21, 2011                [Page 16]

Internet-Draft           Privacy Considerations             October 2010

   clear that the system would 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 RFC
   4079 [RFC4079].

   While presence systems exerted influence on location pri- vacy, the
   location privacy work also influenced ongoing IETF work on presence
   by triggering the standardization of a general access control policy
   language called the Common Policy (defined in RFC 4745 [RFC4745])
   framework.  This language allows one to express ways to control the
   distribution of information as simple conditions, actions, and
   transformations rules expressed in an XML format.  Common Policy
   itself is an abstract format which needs to be instantiated: two
   examples can be found with the Presence Authorization Rules [RFC5025]
   and the Geolocation Policy [I-D.ietf-geopriv-policy].  The former
   provides additional expressiveness for presence based systems, while
   the latter defines syntax and semantic for location based conditions
   and transformations.

   As a component of the prior work on the presence architecture, a
   format for presence information, called Presence Information Data
   Format (PIDF), had been developed.  For the purposes of conveying
   location information an extension was developed, the PIDF Location
   Object (PIDF-LO).  With the aim to meet the privacy requirements
   defined in RFC 2779 [RFC2779] a set of usage indications (such as
   whether retransmission is allowed or when the retention period
   expires) in the form of the following policies have been added that
   always travel with location information itself.  We believe that the
   standardization of these meta-rules that travel with location
   information has been a unique contribution to privacy on the
   Internet, recognizing the need for users to express their preferences
   when information travels through the Internet, from website to
   website.  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 nor to de- sign 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.

   While these retention and retransmission meta-data elements could
   have been devised to accompany information elements in other IETF
   protocols, the decision was made to introduce these elements for

Aboba, et al.            Expires April 21, 2011                [Page 17]

Internet-Draft           Privacy Considerations             October 2010

   geolocation initially because of the sensitivity of location

   The GEOPRIV working group had decided to clarify the architecture to
   make it more accessible to those outside the IETF, and also provides
   a more generic description applicable beyond the context of presence.
   [I-D.ietf-geopriv-arch] shows the work-in-progress writeup.

6.2.  AAA for Network Access

   On a high-level, AAA for network access uses the communication model
   shown in Figure 3.  When an end host requests access to the network
   it has to interact with a Network Access Server (NAS) using some
   front-end protocol (often at the link layer, such as IEEE 802.1X).
   When asked by the NAS, the end host presents a Network Access
   Identifier (NAI), an email alike identifier that consists of a
   username and a domain part.  This NAI is then used to discover the
   AAA server authorized for the users' domain and an initial access
   request is forwarded to it.  To deal with various security,
   accounting and fraud prevention aspects an end-to-end authentication
   procedure, run between the end host (the peer) and a separate
   component within the AAA server (the server) is executed using the
   Extensible Authentication Protocol (EAP).  After a successful
   authentication protocol exchange the user may get authorized to
   access the network and keying material is provided to the NAS to
   enable link layer security over the air interface.

   From a privacy point of view, the entities participating in this eco-
   system are the user, an end host, the NAS, a range of different
   intermediaries, and the AAA server.  The user will most likely have
   some form of contractual relationship with the entity operating the
   AAA server since credential provisioning had to happen someone but,
   in certain deployments like coffee shops, this is not guaranteed.  In
   many deployment during this initial registration process the
   subscriber is provided with credentials after showing some form of
   identification information (e.g. a passport) and consequently the NAI
   together with credentials can be used to linked to a specific
   subscriber, often a single person.

   The username part of the NAI is data provided by the end host
   provides during network access authentication that intermediaries do
   not need to fulfill their role in AAA message routing.  Hiding the
   user's identity is, as discussed in RFC 4282 [RFC4282], possible only
   when NAIs are used together with a separate authentication method
   that can transfer the username in a secure manner.  Such EAP methods
   have been designed and requirements for offering such functionality
   have have become recommended design criteria, see [RFC4017].

Aboba, et al.            Expires April 21, 2011                [Page 18]

Internet-Draft           Privacy Considerations             October 2010

   More than just identity information is exchanged during the network
   access authentication is exchanged.  The NAS provides information
   about the user's point of attachment towards the AAA server and the
   AAA server in response provides data related to the authorization
   decision back.  While the need to exchange data is motivated by the
   service usage itself there are still a number of questions that could
   be asked, such as

   o  What mechanisms can be utilized to offer users ways to authorize
      sharing of information (considering that the ability for protocol
      interaction is limited without sucessful network access

   o  What are the best current practices for a privacy-sensitive
      operation of intermediaries?  Since end hosts are not interacting
      with intermediaries explicitly and users have no relationship with
      those who operate them it is quite likely their practices are less
      widely known.

   o  Are there alternative approaches to trust establishment between
      the NAS and the AAA server so that the involvement of
      intermediaries can be limited or avoided?

Aboba, et al.            Expires April 21, 2011                [Page 19]

Internet-Draft           Privacy Considerations             October 2010

                                   |  AAA Server  |
                                     * EAP      | RADIUS/
                                     *          | Diameter
                                ///                \\\
                              //     AAA Proxies,     \\   ***
                             |       Relays, and        |  back-
                             |       Redirect Agents    |  end
                              \\                      //   ***
                                \\\                ///
                                     * EAP      | RADIUS/
                                     *          | Diameter
     +----------+  Data            +-v----------v-- +
     |          |<---------------->|                |
     | End Host |  EAP/EAP Method  | Network Access |
     |          |<****************>| Server         |
     +----------+                  +--------------- +
                 *** front-end ***

    <****>: End-to-end exchange
    <---->: Hop-by-hop exchange

           Figure 3: Network Access Authentication Architecture

6.3.  SIP for Internet Telephony

   [Editor's Note: Jon/Bernard to add a little bit of text here.]

Aboba, et al.            Expires April 21, 2011                [Page 20]

Internet-Draft           Privacy Considerations             October 2010

7.  Security Considerations

   This document describes aspects a protocol designer would considered
   in the area of privacy in addition to the regular security analysis.

Aboba, et al.            Expires April 21, 2011                [Page 21]

Internet-Draft           Privacy Considerations             October 2010

8.  IANA Considerations

   This document does not require actions by IANA.

Aboba, et al.            Expires April 21, 2011                [Page 22]

Internet-Draft           Privacy Considerations             October 2010

9.  Acknowledgements

   Add your name here.

Aboba, et al.            Expires April 21, 2011                [Page 23]

Internet-Draft           Privacy Considerations             October 2010

10.  References

10.1.  Normative References

              Pfitzmann, A., Hansen, M., and H. Tschofenig, "Terminology
              for Talking about Privacy by Data Minimization: Anonymity,
              Unlinkability, Undetectability, Unobservability,
              Pseudonymity, and Identity Management",
              draft-hansen-privacy-terminology-01 (work in progress),
              August 2010.

   [OECD]     Organization for Economic Co-operation and Development,
              "OECD Guidelines on the Protection of Privacy and
              Transborder Flows of Personal Data", available at
              (September 2010) ,

10.2.  Informative References

   [Altman]   Altman, I., "The Environment and Social Behavior: Privacy,
              Personal Space, Territory, Crowding", Brooks/Cole , 1975.

   [CC]       "Creative Commons", June 2010.

   [CC-SA]    "Creative Commons - Licenses", June 2010.

   [CTIA]     CTIA, "Best Practices and Guidelines for Location-Based
              Services",  , March 2010.

   [DPD95]    European Commission, "Directive 95/46/EC of the European
              Parliament and of the Council of 24 October 1995 on the
              protection of individuals with regard to the processing of
              personal data and on the free movement of such data",
              Official Journal L 281 , 23/11/1995 P. 0031 - 0050,
              November 2005.

              Blumberg, A. and P. Eckersley, "On Locational Privacy, and
              How to Avoid Losing it Forever", August 2009.

   [Granada]  International Working Group on Data Protection in
              Telecommunications, "The Granada Charter of Privacy in a
              Digital World, Granada (Spain)", April 2010.

              Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,

Aboba, et al.            Expires April 21, 2011                [Page 24]

Internet-Draft           Privacy Considerations             October 2010

              "Framework for Emergency Calling using Internet
              Multimedia", draft-ietf-ecrit-framework-11 (work in
              progress), July 2010.

              Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
              Tschofenig, H., and H. Schulzrinne, "An Architecture for
              Location and Location Privacy in Internet Applications",
              draft-ietf-geopriv-arch-03 (work in progress),
              October 2010.

              Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
              and J. Polk, "Geolocation Policy: A Document Format for
              Expressing Privacy Preferences for Location Information",
              draft-ietf-geopriv-policy-21 (work in progress),
              January 2010.

              Morris, J., Aboba, B., Peterson, J., and H. Tschofenig,
              "Public Policy Considerations for Internet Protocols",
              draft-morris-policy-cons-00 (work in progress),
              October 2010.

   [Madrid]   Data Protection Authorities and Privacy Regulators, "The
              Madrid Resolution, International Standards on the
              Protection of Personal Data and Privacy", Conference of
              Data Protection and Privacy Commissioners , 31st
              International Meeting, November 2009.

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

   [RFC2804]  IAB and IESG, "IETF Policy on Wiretapping", RFC 2804,
              May 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.

   [RFC3265]  Roach, A., "Session Initiation Protocol (SIP)-Specific
              Event Notification", RFC 3265, June 2002.

Aboba, et al.            Expires April 21, 2011                [Page 25]

Internet-Draft           Privacy Considerations             October 2010

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

   [RFC3903]  Niemi, A., "Session Initiation Protocol (SIP) Extension
              for Event State Publication", RFC 3903, October 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.

   [RFC4101]  Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101,
              June 2005.

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

   [RFC4858]  Levkowetz, H., Meyer, D., Eggert, L., and A. Mankin,
              "Document Shepherding from Working Group Last Call to
              Publication", RFC 4858, May 2007.

   [RFC4962]  Housley, R. and B. Aboba, "Guidance for Authentication,
              Authorization, and Accounting (AAA) Key Management",
              BCP 132, RFC 4962, July 2007.

   [RFC5025]  Rosenberg, J., "Presence Authorization Rules", RFC 5025,
              December 2007.

   [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598,
              July 2009.

              McCallister, E., Grance, T., and K. Scarfone, "Guide to

Aboba, et al.            Expires April 21, 2011                [Page 26]

Internet-Draft           Privacy Considerations             October 2010

              Protecting the Confidentiality of Personally Identifiable
              Information (PII)", NIST Special Publication (SP) , 800-
              122, April 2010.

              Barker, E., Branstad, D., Chokhani, S., and M. Smid,
              "DRAFT: A Framework for Designing Cryptographic Key
              Management Systems", NIST Special Publication (SP) , 800-
              130, June 2010.

   [Tussle]   Clark, D., Wroslawski, J., Sollins, K., and R. Braden,
              "Tussle in Cyberspace: Defining Tomorrow's Internet", In
              Proc. ACM SIGCOMM ,

   [Warren]   Warren, D. and L. Brandeis, "The Right to Privacy",
              Harvard Law Rev. , vol. 45, 1890.

   [Westin]   Westin, A., "Privacy and Freedom", Atheneum, New York ,

              Eckersley, P., "How Unique Is Your Browser?", Springer
              Lecture Notes in Computer Science , Privacy Enhancing
              Technologies Symposium (PETS 2010), 2010.

   [limits]   Cate, F., "The Limits of Notice and Choice", IEEE Computer
              Society , IEEE Security and Privacy, pg. 59-62,
              November 2005.

Aboba, et al.            Expires April 21, 2011                [Page 27]

Internet-Draft           Privacy Considerations             October 2010

Authors' Addresses

   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052


   John B. Morris, Jr.
   Center for Democracy and Technology
   1634 I Street NW, Suite 1100
   Washington, DC  20006


   Jon Peterson
   NeuStar, Inc.
   1800 Sutter St Suite 570
   Concord, CA  94520


   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600

   Phone: +358 (50) 4871445

Aboba, et al.            Expires April 21, 2011                [Page 28]