< draft-morris-privacy-considerations-00.txt		draft-morris-privacy-considerations-01.txt >
	Network Working Group B. Aboba		Network Working Group B. Aboba
	Internet-Draft Microsoft Corporation		Internet-Draft Microsoft Corporation
	Intended status: Informational J. Morris		Intended status: Informational J. Morris
	Expires: April 21, 2011 CDT		Expires: April 28, 2011 CDT
	J. Peterson		J. Peterson
	NeuStar, Inc.		NeuStar, Inc.
	H. Tschofenig		H. Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	October 18, 2010		October 25, 2010
	Privacy Considerations for Internet Protocols		Privacy Considerations for Internet Protocols
	draft-morris-privacy-considerations-00.txt		draft-morris-privacy-considerations-01.txt
	Abstract		Abstract
	This document aims to make protocol designers aware of the privacy-		This document aims to make protocol designers aware of privacy-
	related design choices and offers guidance for writing privacy		related design choices and offers guidance for developing privacy
	considerations in IETF documents. Similiar to other design aspects		considerations for IETF documents. While specifications cannot
	the IETF influence on the actual deployment is limited. We discuss		police the implementation community, nonetheless protocol architects
	these limitations but are convinced that protocol architects have		must play in the improvement of privacy, both by making a conscious
	indeed a role to play in a privacy friendly design by making more		decision to design for privacy, and by documenting privacy risks in
	conscious decision, and by documenting those.		protocol designs.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 21, 2011.		This Internet-Draft will expire on April 28, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 22 ¶		skipping to change at page 2, line 22 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Historical Background . . . . . . . . . . . . . . . . . . . . 5		2. Historical Background . . . . . . . . . . . . . . . . . . . . 5
	3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9		3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . 13		4. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 15		5. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 16		6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	6.1. Presence . . . . . . . . . . . . . . . . . . . . . . . . . 16		6.1. Presence . . . . . . . . . . . . . . . . . . . . . . . . . 16
	6.2. AAA for Network Access . . . . . . . . . . . . . . . . . . 18		6.2. AAA for Network Access . . . . . . . . . . . . . . . . . . 18
	6.3. SIP for Internet Telephony . . . . . . . . . . . . . . . . 20
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 21		7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 24		10.1. Normative References . . . . . . . . . . . . . . . . . . . 24
	10.2. Informative References . . . . . . . . . . . . . . . . . . 24		10.2. Informative References . . . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
	1. Introduction		1. Introduction
	The IETF is known for its contributions to the design of the Internet		The IETF produces specifications that aim to make the Internet
	and the specifications IETF participants produce belong to different		better. Those specifications fall into a number of different
	categories, such as technical specification, best current practice		categories, including protocol specifications, best current practice
	descriptions, and architectural documentations. While these		descriptions, and architectural documentations. While IETF documents
	documents do not mandate a specific type of implementation they are		are typically implementation-agnostic, they are often, if not always,
	often, if not always, impacted by different architectural design		impacted by fundamental architectural design decisions. These
	decisions. These decision decisions are influenced by technical		decision decisions in turn hinge on technical aspects, predictions
	aspects, expectations about deployment incentives of the involved		about deployment incentives, operational considerations, legal
	entities, operational considerations, security frameworks, etc.		concerns, security frameworks, and so on.
	This document aims to make protocol designers aware of the privacy-		This document aims to make protocol designers aware of privacy-
	related design choices and offers guidance for writing privacy		related design choices and offers guidance for developing privacy
	considerations in IETF documents. Similiar to other design aspects		considerations for IETF documents. While specifications cannot
	there is only a certain degree of influence a protocol designer		police the implementation community, nonetheless protocol architects
	working in a standards developing organization has on the final		must play in the improvement of privacy, both by making a conscious
	deployment outcome. We discuss these limitations in Section 3.		decision to design for privacy, and by documenting privacy risks in
	Nevertheless, we believe that the IETF community overall has indeed a		protocol designs. While discuss the limitations of standards
	role to play in making specifications more privacy friendly: Being		activities in Section 3, we maintain that the IETF community in its
	aware of how design decisions impact privacy, by reflecting them in		mandate to "make the Internet better" has a role to play in making
	the protocol design, and by documenting the chosen design choices and		its specifications, and the Internet, more privacy friendly. This
	potential challenges when deploying a single protocol or an entire		must spring from awareness of how design decisions impact privacy,
	suite of protcols.		and must be reflected in both protocol design and in the
			documentation of potential privacy challenges in the deployment a
			single protocol or an entire suite of protocols.
	From the activities in the industry one can observe three schools of		From the activities in the industry, one can observe three schools of
	thought in the work on privacy, namely		thought in the work on privacy, namely
	Privacy by Technology: This approach builds on the observation that		Privacy by Technology:
	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		This approach considers the assurance of privacy in the design of
	[EFF-Privacy]. These solution approaches often make heavy use of		a protocol as a technical problem. For example, the design of a
			specific application may heighten privacy by sharing fewer data
			items with other parties (i.e. data minimization). Limiting data
			sharing also avoids the need for evaluation on how data-related
			consent is obtained, to define policies around how to protect
			data, etc. Ultimately, different architectural designs will lead
			to different results with respect to privacy.
			Examples in this area of location privacy can be found in
			[EFF-Privacy]. These solution often make heavy use of
	cryptographic techniques, such as threshold cryptography and		cryptographic techniques, such as threshold cryptography and
	secret sharing schemes.		secret sharing schemes.
	Privacy by Policy: With this approach it is assumed that privacy		Privacy by Policy:
	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
	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		In this approach, privacy protection happens through establishing
	publication by CTIA [CTIA].		the consent of the user to a set of privacy policies. Hence,
			protection of the user privacy is largely the responsibility of
			the company collecting, processing, and storing personal data.
			Notices and choices are offered to the customer and backed-up by
			an appropriate legal framework.
	Policy/Technology Hybrid: This approach presents a middle-ground		An example of this approach for the privacy of location-based
	where some privacy enhancing features can be provided by		services is the recent publication by CTIA [CTIA].
	technology, and made transparent to those who implement (via
	explicit recommendations for implementation, configuration and		Policy/Technology Hybrid:
	deployment best current practices or implicitly by raising
	awareness via a discussion about privacy in technical		This approach targets a middle-ground where some privacy-enhancing
			features can be provided by technology, and made attractive to
			implementers (via explicit best current practices for
			implementation, configuration and deployment, or by raising
			awareness implicitly via a discussion about privacy in technical
	specifications) but other aspects can only be provided and		specifications) but other aspects can only be provided and
	enforced by the parties who decide about the deployment. For		enforced by the parties who control the deployment. Deployments
	deployments often a certain expectation about the existence of an		often base their decisions on the existence of a plausible legal
	appropriate legal framework is required.		framework.
	The authors believe that the policy/technology hybrid approach is the		The authors believe that the policy/technology hybrid approach is the
	most practical one and therefore suggest it to be the leading		most practical one, and therefore propose that privacy consideration
	paradigm in privacy investigations within the IETF.		within the IETF follow its principles.
	This document is structured as follows: First, we provide a brief		This remainder of this document is structured as follows: First, we
	introduction to the privacy history in Section 2. In Section 3 we		provide a brief introduction to the concept of privacy in Section 2.
	illustrate what is in scope of the IETF work and where the		In Section 3, we illustrate what is in scope of the IETF and where
	responsibility of the IETF ends. In Section 4 we discuss the main		the responsibility of the IETF ends. In Section 4, we discuss the
	threat model for privacy investigations. In Section 5 we propose		main threat model for privacy considerations. In Section 5, we
	guidelines for investing privacy within IETF specifications and in		propose guidelines for documenting privacy within IETF
	Section VII we discuss privacy characteristics of a few IETF		specifications, and in Section 6 we examine the privacy
	protocols and explain what privacy features have been provided until		characteristics of a few exemplary IETF protocols and explain what
	now.		privacy features have been provided to date.
	2. Historical Background		2. Historical Background
	The "right to be let alone" is a phrase coined by Warren and Brandeis		The "right to be let alone" is a phrase coined by Warren and Brandeis
	in their seminal Harvard Law Review article on privacy [Warren].		in their seminal Harvard Law Review article on privacy [Warren].
	They were the first scholars to recognize that a right to privacy had		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		evolved in the 19th century to embrace not only physical privacy but
	also a potential "injury of the feelings", which could, for example,		also a potential "injury of the feelings", which could, for example,
	result from the public disclosure of embarrassing private facts.		result from the public disclosure of embarrassing private facts.
	skipping to change at page 20, line 32 ¶		skipping to change at page 21, line 5 ¶
	| |<****************>| Server |		| |<****************>| Server |
	+----------+ +--------------- +		+----------+ +--------------- +
	*** front-end ***		*** front-end ***
	Legend:		Legend:
	<****>: End-to-end exchange		<****>: End-to-end exchange
	<---->: Hop-by-hop exchange		<---->: Hop-by-hop exchange
	Figure 3: Network Access Authentication Architecture		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.]
	7. Security Considerations		7. Security Considerations
	This document describes aspects a protocol designer would considered		This document describes aspects a protocol designer would considered
	in the area of privacy in addition to the regular security analysis.		in the area of privacy in addition to the regular security analysis.
	8. IANA Considerations		8. IANA Considerations
	This document does not require actions by IANA.		This document does not require actions by IANA.
	9. Acknowledgements		9. Acknowledgements
End of changes. 18 change blocks.
	78 lines changed or deleted		78 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/