--- 1/draft-ietf-6man-ipv6-address-generation-privacy-04.txt 2015-04-27 12:14:52.923191188 -0700 +++ 2/draft-ietf-6man-ipv6-address-generation-privacy-05.txt 2015-04-27 12:14:52.959192066 -0700 @@ -1,21 +1,21 @@ Network Working Group A. Cooper Internet-Draft Cisco Intended status: Informational F. Gont -Expires: August 27, 2015 Huawei Technologies +Expires: October 29, 2015 Huawei Technologies D. Thaler Microsoft - February 23, 2015 + April 27, 2015 Privacy Considerations for IPv6 Address Generation Mechanisms - draft-ietf-6man-ipv6-address-generation-privacy-04.txt + draft-ietf-6man-ipv6-address-generation-privacy-05.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 27, 2015. + This Internet-Draft will expire on October 29, 2015. Copyright Notice Copyright (c) 2015 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 @@ -52,41 +52,41 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Weaknesses in IEEE-identifier-based IIDs . . . . . . . . . . 4 3.1. Correlation of activities over time . . . . . . . . . . . 5 3.2. Location tracking . . . . . . . . . . . . . . . . . . . . 6 3.3. Address scanning . . . . . . . . . . . . . . . . . . . . 6 - 3.4. Device-specific vulnerability exploitation . . . . . . . 7 + 3.4. Device-specific vulnerability exploitation . . . . . . . 6 4. Privacy and security properties of address generation mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. IEEE-identifier-based IIDs . . . . . . . . . . . . . . . 9 4.2. Static, manually configured IIDs . . . . . . . . . . . . 10 4.3. Constant, semantically opaque IIDs . . . . . . . . . . . 10 4.4. Cryptographically generated IIDs . . . . . . . . . . . . 10 4.5. Stable, semantically opaque IIDs . . . . . . . . . . . . 10 4.6. Temporary IIDs . . . . . . . . . . . . . . . . . . . . . 11 4.7. DHCPv6 generation of IIDs . . . . . . . . . . . . . . . . 12 4.8. Transition/co-existence technologies . . . . . . . . . . 12 - 5. Miscellaneous Issues with IPv6 addressing . . . . . . . . . . 12 - 5.1. Network Operation . . . . . . . . . . . . . . . . . . . . 12 + 5. Miscellaneous Issues with IPv6 addressing . . . . . . . . . . 13 + 5.1. Network Operation . . . . . . . . . . . . . . . . . . . . 13 5.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . 13 5.3. Intellectual Property Rights (IPRs) . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 - 9.2. Informative References . . . . . . . . . . . . . . . . . 15 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 + 9.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction IPv6 was designed to improve upon IPv4 in many respects, and mechanisms for address assignment were one such area for improvement. In addition to static address assignment and DHCP, stateless autoconfiguration was developed as a less intensive, fate-shared means of performing address assignment. With stateless autoconfiguration, routers advertise on-link prefixes and hosts @@ -121,94 +121,93 @@ [Microsoft] * 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 + Deriving the IID from a globally unique IEEE identifier [RFC1971] was one of the earliest mechanisms developed. A number of privacy and security issues related to the IIDs 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. 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. Stable address: - An address that does not vary over time within the same network. + An address that does not vary over time within the same IPv6 link. Note that [RFC4941] refers to these as "public" addresses, but "stable" is used here for reasons explained in Section 4. Temporary address: - An address that varies over time within the same network. + An address that varies over time within the same IPv6 link. Constant IID: An IPv6 Interface Identifier that is globally stable. That is, the Interface ID will remain constant even if the node moves from - one network to another. + one IPv6 link to another. Stable IID: An IPv6 Interface Identifier that is stable within some specified context. For example, an Interface ID can be globally stable - (constant), or could be stable per network (meaning that the + (constant), or could be stable per IPv6 link (meaning that the Interface ID will remain unchanged as long as a the node stays on - the same network, but may change when the node moves from one - network to another). + the same IPv6 link, but may change when the node moves from one + IPv6 link to another). Temporary IID: An IPv6 Interface Identifier that varies over time. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. These words take their normative meanings only when they are presented in ALL UPPERCASE. 3. Weaknesses in IEEE-identifier-based IIDs There are a number of privacy and security implications that exist for hosts that use IEEE-identifier-based IIDs. This section discusses four generic attack types: correlation of activities over time, location tracking, address scanning, and device-specific vulnerability exploitation. The first three of these rely on the attacker first gaining knowledge of the target host's IID. This can be achieved by a number of different attackers: the operator of a server to which the host connects, such as a web server or a peer-to- - peer server; an entity that connects to the same network as the + peer server; an entity that connects to the same IPv6 link as the target (such as a conference network or any public network); or an entity that is on-path to the destinations with which the host communicates, such as a network operator. 3.1. Correlation of activities over time As with other identifiers, an IPv6 address can be used to correlate the activities of a host for at least as long as the lifetime of the address. The correlation made possible by IEEE-identifier-based IIDs - is of particular concern because MAC addresses are much more - permanent than, say, DHCP leases. MAC addresses tend to last roughly - the lifetime of a device's network interface, allowing correlation on - the order of years, compared to days for DHCP. + is of particular concern since they last roughly for the lifetime of + a device's network interface, allowing correlation on the order of + years. As [RFC4941] explains, "[t]he use of a non-changing interface identifier to form addresses is a specific instance of the more general case where a constant identifier is reused over an extended period of time and in multiple independent activities. Anytime the same identifier is used in multiple contexts, it becomes possible for that identifier to be used to correlate seemingly unrelated activity. ... The use of a constant identifier within an address is of @@ -241,53 +240,53 @@ address via DHCPv4 can be tracked as described above. However, the widespread use of both NAT and DHCPv4 implementations that assign the same host a different address upon lease expiration mitigates this threat in the IPv4 case as compared to the IEEE identifier case in IPv6. 3.2. Location tracking Because the IPv6 address structure is divided between a topological portion and an interface identifier portion, an interface identifier - that remains constant when a host connects to different networks (as - an IEEE-identifier-based IID does) provides a way for observers to - track the movements of that host. In a passive attack on a mobile + that remains constant when a host connects to different IPv6 links + (as an IEEE-identifier-based IID does) provides a way for observers + to track the movements of that host. In a passive attack on a mobile host, a server that receives connections from the same host over time would be able to determine the host's movements as its prefix changes. Active attacks are also possible. An attacker that first learns the - host's interface identifier by being connected to the same network - segment, running a server that the host connects to, or being on-path - to the host's communications could subsequently probe other networks - for the presence of the same interface identifier by sending a probe - packet (ICMPv6 Echo Request, or any other probe packet). Even if the - host does not respond, the first hop router will usually respond with - an ICMP Address Unreachable when the host is not present, and be - silent when the host is present. + host's interface identifier by being connected to the same IPv6 link, + running a server that the host connects to, or being on-path to the + host's communications could subsequently probe other networks for the + presence of the same interface identifier by sending a probe packet + (ICMPv6 Echo Request, or any other probe packet). Even if the host + does not respond, the first hop router will usually respond with an + ICMP Destination Unreachable/Address Unreachable (type 1, code 3) + when the host is not present, and be silent when the host is present. Location tracking based on IP address is generally not possible in IPv4 since hosts get assigned wholly new addresses when they change networks. 3.3. Address scanning The structure of IEEE-based identifiers used for address generation can be leveraged by an attacker to reduce the target search space [I-D.ietf-opsec-ipv6-host-scanning]. The 24-bit Organizationally Unique Identifier (OUI) of MAC addresses, together with the fixed value (0xff, 0xfe) used to form a Modified EUI-64 Interface Identifier, greatly help to reduce the search space, making it easier for an attacker to scan for individual addresses using widely-known popular OUIs. This erases much of the protection against address - scanning that the larger IPv6 address space was supposed to provide - as compared to IPv4. + scanning that the larger IPv6 address space could provide as compared + to IPv4. 3.4. Device-specific vulnerability exploitation IPv6 addresses that embed IEEE identifiers leak information about the device (Network Interface Card vendor, or even Operating System and/ or software type), which could be leveraged by an attacker with knowledge of device/software-specific vulnerabilities to quickly find possible targets. Attackers can exploit vulnerabilities in hosts whose IIDs they have previously obtained, or scan an address space to find potential targets. @@ -302,21 +301,21 @@ addresses using different mechanisms and may use any or all of them. [RFC3041] (later obsoleted by [RFC4941]) sought to address some of the problems described in Section 3 by defining "temporary addresses" for outbound connections. Temporary addresses are meant to supplement the other addresses that a device might use, not to replace them. They use IIDs that are randomly generated and change daily by default. The idea was for temporary addresses to be used for outgoing connections (e.g., web browsing) while maintaining the ability to use a stable address when more address stability is - desired (e.g., in DNS advertisements). + desired (e.g., for IPv6 addresses published in the DNS). [RFC3484] originally specified that stable addresses be used for outbound connections unless an application explicitly prefers temporary addresses. The default preference for stable addresses was established to avoid applications potentially failing due to the short lifetime of temporary addresses or the possibility of a reverse look-up failure or error. However, [RFC3484] allowed that "implementations for which privacy considerations outweigh these application compatibility concerns MAY reverse the sense of this rule" and instead prefer by default temporary addresses rather than @@ -382,22 +381,22 @@ | semantically | lifetime | address | | | | opaque | | lifetime | | | | | | | | | | CGA | For | No | No | No | | | lifetime of | | | | | | (modifier | | | | | | block + | | | | | | public key) | | | | | | | | | | | Stable, | Within | No | No | No | - | semantically | single | | | | - | opaque | network | | | | + | semantically | single IPv6 | | | | + | opaque | link | | | | | | | | | | | Temporary | For temp | No | No | No | | | address | | | | | | lifetime | | | | | | | | | | | DHCPv6 | For lease | No | Depends on | No | | | lifetime | | generation | | | | | | mechanism | | +--------------+-------------+----------+-------------+-------------+ @@ -429,72 +428,72 @@ are generated. 4.3. Constant, semantically opaque IIDs Although a mechanism to generate a constant, semantically opaque IID has not been standardized, it has been in wide use for many years on at least one platform (Windows). Windows uses the [RFC4941] random generation mechanism in lieu of generating an IEEE-identifier-based IID. This mitigates the device-specific exploitation and address scanning attacks, but still allows correlation and location tracking - because the IID is constant across networks and time. + because the IID is constant across IPv6 links and time. 4.4. Cryptographically generated IIDs Cryptographically generated addresses (CGAs) [RFC3972] bind a hash of the host's public key to an IPv6 address in the SEcure Neighbor Discovery (SEND) [RFC3971] protocol. CGAs may be regenerated for each subnet prefix, but this is not required given that they are computationally expensive to generate. A host using a CGA can be correlated for as long as the lifetime of the combination of the 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 + key or modifier block when it moves to a different IPv6 link, 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 [RFC7217] specifies an algorithm that generates, for each network - interface, a unique random IID per network. The aforementioned + interface, a unique random IID per IPv6 link. The aforementioned algorithm is employed not only for global unicast addresses, but also for unique local unicast addresses and link-local unicast addresses, since these addresses may leak out via application protocols (e.g., IPv6 addresses embedded in email headers). - A host that stays connected to the same network could therefore be + A host that stays connected to the same IPv6 link 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 some of them depends on how the host uses each address. An attacker can correlate all of the host's activities for which it uses its IEEE-identifier-based IID. Once an attacker has obtained the IEEE- identifier-based IID, location tracking becomes possible on other - networks even if the host only makes use of temporary addresses on - those other networks; the attacker can actively probe the other - networks for the presence of the IEEE-identifier-based IID. Device- - specific vulnerabilities can still be exploited. Address scanning is - also still possible because the IEEE-identifier-based address can be - probed. + IPv6 links even if the host only makes use of temporary addresses on + those other IPv6 links; the attacker can actively probe the other + IPv6 links for the presence of the IEEE-identifier-based IID. + Device-specific vulnerabilities can still be exploited. Address + scanning is also still possible because the IEEE-identifier-based + address can be probed. If the host instead generates a constant, semantically opaque IID to use in a stable address for server-like connections together with temporary addresses for outbound connections (as is the default in Windows), it sees some improvements over the previous scenario. The address scanning and device-specific exploitation attacks are no longer possible because the OUI is no longer embedded in any of the 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 @@ -509,27 +508,34 @@ 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 - typically depend on the specific DHCPv6 server software being - employed. We note that recent releases of most popular DHCPv6 server - software typically lease random addresses with a similar lease time - as that of IPv4. Thus, these addresses can be considered to be - "stable, semantically opaque". + typically depend on whether the client requests an IA_NA (Identity + Association for Non-temporary Addresses) or an IA_TA ( Identity + Association for Temporary Addresses) [RFC3315] and the specific + DHCPv6 server software being employed. + + DHCPv6 temporary addresses have the same properties as SLAAC + temporary addresses Section 4.6 [RFC4941]. On the other hand, the + properties of DHCPv6 non-temporary addresses typically depend on the + specific DHCPv6 server software being employed. Recent releases of + most popular DHCPv6 server software typically lease random addresses + with a similar lease time as that of IPv4. Thus, these addresses can + be considered to be "stable, semantically opaque". [I-D.ietf-dhc-stable-privacy-addresses] specifies an algorithm that - can be employed by DHCP servers to generate "stable, semantically + can be employed by DHCPv6 servers to generate "stable, semantically opaque" addresses. On the other hand, some DHCPv6 software leases sequential addresses (typically low-byte addresses). These addresses can be considered to be stable addresses. The drawback of this address generation scheme compared to "stable, semantically opaque" addresses is that, since they follow specific patterns, they enable IPv6 address scans. 4.8. Transition/co-existence technologies @@ -544,108 +550,87 @@ NATs is not randomized). For this reason, popular implementations (e.g., Windows), began deviating from the standard by including 12 random bits in place of zero bits. This modification was later standardized in [RFC5991]. 5. Miscellaneous Issues with IPv6 addressing 5.1. Network Operation It is generally agreed that IPv6 addresses that vary over time in a - specific network tend to increase the complexity of event logging, + specific IPv6 link 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.2. Compliance 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. + require) implementations to support IEEE-identifier-based IIDS 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.3. 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, Brian Carpenter, Tim - Chown, Lorenzo Colitti, Rich Draves, Robert Moskowitz, Erik Nordmark, - and James Woodyatt for providing valuable comments on earlier - versions of this document. + Chown, Lorenzo Colitti, Rich Draves, Robert Hinden, Robert Moskowitz, + Erik Nordmark, Mark Smith, Ole Troan, and James Woodyatt for + providing valuable comments on earlier versions of this document. 9. References - 9.1. Normative References - [RFC1972] Crawford, M., "A Method for the Transmission of IPv6 - Packets over Ethernet Networks", RFC 1972, August 1996. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 2462, December 1998. - [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998. - [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for - Stateless Address Autoconfiguration in IPv6", RFC 3041, - January 2001. - - [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third - Generation Partnership Project (3GPP) Standards", RFC - 3314, September 2002. - [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. - [RFC3484] Draves, R., "Default Address Selection for Internet - Protocol version 6 (IPv6)", RFC 3484, February 2003. - [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. [RFC5991] Thaler, D., Krishnan, S., and J. Hoagland, "Teredo Security Updates", RFC 5991, September 2010. - [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, - April 2011. - [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012. [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, February 2014. [RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, April 2014. @@ -658,42 +643,62 @@ Melbourne, VIC Australia, October 2010, October 2010, . [CGA-IPR] IETF, "Intellectual Property Rights on RFC 3972", 2005. [I-D.ietf-dhc-stable-privacy-addresses] Gont, F. and W. Will, "A Method for Generating Semantically Opaque Interface Identifiers with Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", draft- - ietf-dhc-stable-privacy-addresses-01 (work in progress), - February 2015. + ietf-dhc-stable-privacy-addresses-02 (work in progress), + April 2015. [I-D.ietf-opsec-ipv6-host-scanning] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", draft-ietf-opsec-ipv6-host-scanning-06 (work in progress), February 2015. [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, . + [RFC1971] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 1971, August 1996. + + [RFC1972] Crawford, M., "A Method for the Transmission of IPv6 + Packets over Ethernet Networks", RFC 1972, August 1996. + + [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for + Stateless Address Autoconfiguration in IPv6", RFC 3041, + January 2001. + + [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third + Generation Partnership Project (3GPP) Standards", RFC + 3314, September 2002. + + [RFC3484] Draves, R., "Default Address Selection for Internet + Protocol version 6 (IPv6)", RFC 3484, February 2003. + + [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, + April 2011. + [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. [RFC7421] Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit Boundary in IPv6 Addressing", RFC 7421, January 2015. Authors' Addresses