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/