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