draft-ietf-6man-ipv6-address-generation-privacy-01.txt		draft-ietf-6man-ipv6-address-generation-privacy-02.txt
	Network Working Group A. Cooper		Network Working Group A. Cooper
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Informational F. Gont		Intended status: Informational F. Gont
	Expires: August 18, 2014 Huawei Technologies		Expires: April 13, 2015 Huawei Technologies
	D. Thaler		D. Thaler
	Microsoft		Microsoft
	February 14, 2014		October 10, 2014
	Privacy Considerations for IPv6 Address Generation Mechanisms		Privacy Considerations for IPv6 Address Generation Mechanisms
	draft-ietf-6man-ipv6-address-generation-privacy-01.txt		draft-ietf-6man-ipv6-address-generation-privacy-02.txt
	Abstract		Abstract
	This document discusses privacy and security considerations for		This document discusses privacy and security considerations for
	several IPv6 address generation mechanisms, both standardized and		several IPv6 address generation mechanisms, both standardized and
	non-standardized. It evaluates how different mechanisms mitigate		non-standardized. It evaluates how different mechanisms mitigate
	different threats and the trade-offs that implementors, developers,		different threats and the trade-offs that implementors, developers,
	and users face in choosing different addresses or address generation		and users face in choosing different addresses or address generation
	mechanisms.		mechanisms.
	skipping to change at page 1, line 38		skipping to change at page 1, line 38
	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 August 18, 2014.		This Internet-Draft will expire on April 13, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 3, line 24		skipping to change at page 3, line 24
	* IEEE 802 48-bit MAC or IEEE EUI-64 identifier		* IEEE 802 48-bit MAC or IEEE EUI-64 identifier
	[RFC1972][RFC2464]		[RFC1972][RFC2464]
	* Cryptographically generated [RFC3972]		* Cryptographically generated [RFC3972]
	* Temporary (also known as "privacy addresses") [RFC4941]		* Temporary (also known as "privacy addresses") [RFC4941]
	* Constant, semantically opaque (also known as random)		* Constant, semantically opaque (also known as random)
	[Microsoft]		[Microsoft]
	* Stable, semantically opaque		* Stable, semantically opaque [RFC7217]
	[I-D.ietf-6man-stable-privacy-addresses]
	o DHCPv6-based [RFC3315]		o DHCPv6-based [RFC3315]
	o Specified by transition/co-existence technologies		o Specified by transition/co-existence technologies
	* IPv4 address and port [RFC4380]		* IPv4 address and port [RFC4380]
	Deriving the IID from a globally unique IEEE identifier [RFC2462] was		Deriving the IID from a globally unique IEEE identifier [RFC2462] was
	one of the earliest mechanisms developed. A number of privacy and		one of the earliest mechanisms developed. A number of privacy and
	security issues related to the interface IDs derived from IEEE		security issues related to the interface IDs derived from IEEE
	identifiers were discovered after their standardization, and many of		identifiers were discovered after their standardization, and many of
	the mechanisms developed later aimed to mitigate some or all of these		the mechanisms developed later aimed to mitigate some or all of these
	weaknesses. This document identifies four types of threats against		weaknesses. This document identifies four types of threats against
	IEEE-identifier-based IIDs, and discusses how other existing		IEEE-identifier-based IIDs, and discusses how other existing
	techniques for generating IIDs do or do not mitigate those threats.		techniques for generating IIDs do or do not mitigate those threats.
	The discussion in this document is limited to global addresses and
	does not address link-local addresses. [Do we need to say something
	about unique-local being in or out of scope?]
	2. Terminology		2. Terminology
	This section clarifies the terminology used throughout this document.		This section clarifies the terminology used throughout this document.
	Public address:		Public address:
	An address that has been published in a directory or other public		An address that has been published in a directory or other public
	location, such as the DNS, a SIP proxy, an application-specific		location, such as the DNS, a SIP proxy, an application-specific
	DHT, or a publicly available URI. A host's public addresses are		DHT, or a publicly available URI. A host's public addresses are
	intended to be discoverable by third parties.		intended to be discoverable by third parties.
	skipping to change at page 9, line 23		skipping to change at page 9, line 23
	| Static | For address | For | Depends on | Depends on |		| Static | For address | For | Depends on | Depends on |
	| manual | lifetime | address | generation | generation |		| manual | lifetime | address | generation | generation |
	| | | lifetime | mechanism | mechanism |		| | | lifetime | mechanism | mechanism |
	| | | | | |		| | | | | |
	| Constant, | For address | For | No | No |		| Constant, | For address | For | No | No |
	| semantically | lifetime | address | | |		| semantically | lifetime | address | | |
	| opaque | | lifetime | | |		| opaque | | lifetime | | |
	| | | | | |		| | | | | |
	| CGA | For | No | No | No |		| CGA | For | No | No | No |
	| | lifetime of | | | |		| | lifetime of | | | |
	| | (public key | | | |		| | (modifier | | | |
	| | + modifier | | | |		| | block + | | | |
	| | block) | | | |		| | public key) | | | |
	| | | | | |		| | | | | |
	| Stable, | Within | No | No | No |		| Stable, | Within | No | No | No |
	| semantically | single | | | |		| semantically | single | | | |
	| opaque | network | | | |		| opaque | network | | | |
	| | | | | |		| | | | | |
	| Temporary | For temp | No | No | No |		| Temporary | For temp | No | No | No |
	| | address | | | |		| | address | | | |
	| | lifetime | | | |		| | lifetime | | | |
	| | | | | |		| | | | | |
	| DHCPv6 | For lease | No | Depends on | No |		| DHCPv6 | For lease | No | Depends on | No |
	skipping to change at page 10, line 50		skipping to change at page 10, line 50
	public key and the chosen modifier block, since it is possible to		public key and the chosen modifier block, since it is possible to
	rotate modifier blocks without generating new public keys. Because		rotate modifier blocks without generating new public keys. Because
	the cryptographic hash of the host's public key uses the subnet		the cryptographic hash of the host's public key uses the subnet
	prefix as an input, even if the host does not generate a new public		prefix as an input, even if the host does not generate a new public
	key or modifier block when it moves to a different network, its		key or modifier block when it moves to a different network, its
	location cannot be tracked via the IID. CGAs do not allow device-		location cannot be tracked via the IID. CGAs do not allow device-
	specific exploitation or address scanning attacks.		specific exploitation or address scanning attacks.
	4.5. Stable, semantically opaque IIDs		4.5. Stable, semantically opaque IIDs
	[I-D.ietf-6man-stable-privacy-addresses] specifies a mechanism that		[RFC7217] specifies a mechanism that generates a unique random IID
	generates a unique random IID for each network. A host that stays		for each network. A host that stays connected to the same network
	connected to the same network could therefore be tracked at length,		could therefore be tracked at length, whereas a mobile host's
	whereas a mobile host's activities could only be correlated for the		activities could only be correlated for the duration of each network
	duration of each network connection. Location tracking is not		connection. Location tracking is not possible with these addresses.
	possible with these addresses. They also do not allow device-		They also do not allow device-specific exploitation or address
	specific exploitation or address scanning attacks.		scanning attacks.
	4.6. Temporary IIDs		4.6. Temporary IIDs
	A host that uses only a temporary address mitigates all four threats.		A host that uses only a temporary address mitigates all four threats.
	Its activities may only be correlated for the lifetime a single		Its activities may only be correlated for the lifetime a single
	temporary address.		temporary address.
	A host that configures both an IEEE-identifier-based IID and		A host that configures both an IEEE-identifier-based IID and
	temporary addresses makes the host vulnerable to the same attacks as		temporary addresses makes the host vulnerable to the same attacks as
	if temporary addresses were not in use, although the viability of		if temporary addresses were not in use, although the viability of
	skipping to change at page 11, line 45		skipping to change at page 11, line 45
	host's addresses. However, correlation of some activities across		host's addresses. However, correlation of some activities across
	time and location tracking are both still possible because the		time and location tracking are both still possible because the
	semantically opaque IID is constant. And once an attacker has		semantically opaque IID is constant. And once an attacker has
	obtained the host's semantically opaque IID, location tracking is		obtained the host's semantically opaque IID, location tracking is
	possible on any network by probing for that IID, even if the host		possible on any network by probing for that IID, even if the host
	only uses temporary addresses on those networks. However, if the		only uses temporary addresses on those networks. However, if the
	host generates but never uses a constant, semantically opaque IID, it		host generates but never uses a constant, semantically opaque IID, it
	mitigates all four threats.		mitigates all four threats.
	When used together with temporary addresses, the stable, semantically		When used together with temporary addresses, the stable, semantically
	opaque IID generation mechanism		opaque IID generation mechanism [RFC7217] improves upon the previous
	[I-D.ietf-6man-stable-privacy-addresses] improves upon the previous
	scenario by limiting the potential for correlation to the lifetime of		scenario by limiting the potential for correlation to the lifetime of
	the stable address (which may still be lengthy for hosts that are not		the stable address (which may still be lengthy for hosts that are not
	mobile) and by eliminating the possibility for location tracking		mobile) and by eliminating the possibility for location tracking
	(since a different IID is generated for each subnet prefix). As in		(since a different IID is generated for each subnet prefix). As in
	the previous scenario, a host that configures but does not use a		the previous scenario, a host that configures but does not use a
	stable, semantically opaque address mitigates all four threats.		stable, semantically opaque address mitigates all four threats.
	4.7. DHCPv6 generation of IIDs		4.7. DHCPv6 generation of IIDs
	The security/privacy implications of DHCPv6-based addresses will		The security/privacy implications of DHCPv6-based addresses will
	skipping to change at page 13, line 9		skipping to change at page 13, line 7
	It is generally agreed that IPv6 addresses that vary over time in a		It is generally agreed that IPv6 addresses that vary over time in a
	specific network tend to increase the complexity of event logging,		specific network tend to increase the complexity of event logging,
	trouble-shooting, enforcement of access controls and quality of		trouble-shooting, enforcement of access controls and quality of
	service, etc. As a result, some organizations disable the use of		service, etc. As a result, some organizations disable the use of
	temporary addresses [RFC4941] even at the expense of reduced privacy		temporary addresses [RFC4941] even at the expense of reduced privacy
	[Broersma].		[Broersma].
	5.3. Compliance		5.3. Compliance
	Major IPv6 compliance testing suites required (and still require)		Some IPv6 compliance testing suites required (and might still
	implementations to support MAC-derived suffixes in order to be		require) implementations to support MAC-derived suffixes in order to
	approved as compliant. Implementations that fail to support MAC-		be approved as compliant. This document recommends that compliance
	derived suffixes are therefore largely not eligible to receive the		testing suites be relaxed to allow other forms of address generation
	benefits of compliance certification (e.g., use of the IPv6 logo,		that are more amenable to privacy.
	eligibility for government contracts, etc.). This document
	recommends that these be relaxed to allow other forms of address
	generation that are more amenable to privacy.
	5.4. Intellectual Property Rights (IPRs)		5.4. Intellectual Property Rights (IPRs)
	Some IPv6 addressing techniques might be covered by Intellectual		Some IPv6 addressing techniques might be covered by Intellectual
	Property rights, which might limit their implementation in different		Property rights, which might limit their implementation in different
	Operating Systems. [CGA-IPR] and [KAME-CGA] discuss the IPRs on		Operating Systems. [CGA-IPR] and [KAME-CGA] discuss the IPRs on
	CGAs.		CGAs.
	6. Security Considerations		6. Security Considerations
	This whole document concerns the privacy and security properties of		This whole document concerns the privacy and security properties of
	different IPv6 address generation mechanisms.		different IPv6 address generation mechanisms.
	7. IANA Considerations		7. IANA Considerations
	This document does not require actions by IANA.		This document does not require actions by IANA.
	8. Acknowledgements		8. Acknowledgements
	The authors would like to thank Bernard Aboba, Rich Draves, and James		The authors would like to thank Bernard Aboba, Tim Chown, Rich
	Woodyatt.		Draves, Robert Moskowitz, Erik Nordmark, and James Woodyatt for
			providing valuable comments on earlier versions of this document.
	9. Informative References		9. Informative References
	[Broersma]		[Broersma]
	Broersma, R., "IPv6 Everywhere: Living with a Fully		Broersma, R., "IPv6 Everywhere: Living with a Fully
	IPv6-enabled environment", Australian IPv6 Summit 2010,		IPv6-enabled environment", Australian IPv6 Summit 2010,
	Melbourne, VIC Australia, October 2010, October 2010,		Melbourne, VIC Australia, October 2010, October 2010,
	<http://www.ipv6.org.au/10ipv6summit/talks/		<http://www.ipv6.org.au/10ipv6summit/talks/
	Ron_Broersma.pdf>.		Ron_Broersma.pdf>.
	[CGA-IPR] IETF, "Intellectual Property Rights on RFC 3972", 2005.		[CGA-IPR] IETF, "Intellectual Property Rights on RFC 3972", 2005.
	[I-D.ietf-6man-stable-privacy-addresses]
	Gont, F., "A Method for Generating Semantically Opaque
	Interface Identifiers with IPv6 Stateless Address
	Autoconfiguration (SLAAC)", draft-ietf-6man-stable-
	privacy-addresses-17 (work in progress), January 2014.
	[I-D.ietf-opsec-ipv6-host-scanning]		[I-D.ietf-opsec-ipv6-host-scanning]
	Gont, F. and T. Chown, "Network Reconnaissance in IPv6		Gont, F. and T. Chown, "Network Reconnaissance in IPv6
	Networks", draft-ietf-opsec-ipv6-host-scanning-03 (work in		Networks", draft-ietf-opsec-ipv6-host-scanning-04 (work in
	progress), January 2014.		progress), June 2014.
	[KAME-CGA]		[KAME-CGA]
	KAME, "The KAME IPR policy and concerns of some		KAME, "The KAME IPR policy and concerns of some
	technologies which have IPR claims", 2005.		technologies which have IPR claims", 2005.
	[Microsoft]		[Microsoft]
	Microsoft, "IPv6 interface identifiers", 2013.		Microsoft, "IPv6 interface identifiers", 2013.
	[Panopticlick]		[Panopticlick]
	Electronic Frontier Foundation, "Panopticlick", 2011.		Electronic Frontier Foundation, "Panopticlick", 2011.
	skipping to change at page 15, line 34		skipping to change at page 15, line 24
	[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,		[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
	"Default Address Selection for Internet Protocol Version 6		"Default Address Selection for Internet Protocol Version 6
	(IPv6)", RFC 6724, September 2012.		(IPv6)", RFC 6724, September 2012.
	[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,		[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
	Morris, J., Hansen, M., and R. Smith, "Privacy		Morris, J., Hansen, M., and R. Smith, "Privacy
	Considerations for Internet Protocols", RFC 6973, July		Considerations for Internet Protocols", RFC 6973, July
	2013.		2013.
			[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
			Interface Identifiers with IPv6 Stateless Address
			Autoconfiguration (SLAAC)", RFC 7217, April 2014.
	Authors' Addresses		Authors' Addresses
	Alissa Cooper		Alissa Cooper
	Cisco		Cisco
	707 Tasman Drive		707 Tasman Drive
	Milpitas, CA 95035		Milpitas, CA 95035
	US		US
	Phone: +1-408-902-3950		Phone: +1-408-902-3950
	Email: alcoop@cisco.com		Email: alcoop@cisco.com
End of changes. 14 change blocks.
	39 lines changed or deleted		30 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/