--- 1/draft-ietf-6man-stable-privacy-addresses-10.txt 2013-08-08 16:14:25.160574951 -0700 +++ 2/draft-ietf-6man-stable-privacy-addresses-11.txt 2013-08-08 16:14:25.200575925 -0700 @@ -1,19 +1,19 @@ IPv6 maintenance Working Group (6man) F. Gont Internet-Draft SI6 Networks / UTN-FRH -Intended status: Standards Track June 12, 2013 -Expires: December 14, 2013 +Intended status: Standards Track August 8, 2013 +Expires: February 9, 2014 A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC) - draft-ietf-6man-stable-privacy-addresses-10 + draft-ietf-6man-stable-privacy-addresses-11 Abstract This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware address (e.g., using IEEE identifiers), such that the benefits of @@ -30,73 +30,56 @@ 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 December 14, 2013. + This Internet-Draft will expire on February 9, 2014. Copyright Notice Copyright (c) 2013 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Design goals . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3. Algorithm specification . . . . . . . . . . . . . . . . . . . 8 - 4. Resolving Duplicate Address Detection (DAD) conflicts . . . . 13 - 5. Specified Constants . . . . . . . . . . . . . . . . . . . . . 14 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 - Appendix A. Possible sources for the Net_Iface parameter . . . . 22 - A.1. Interface Index . . . . . . . . . . . . . . . . . . . . . 22 - A.2. Interface Name . . . . . . . . . . . . . . . . . . . . . . 22 - A.3. Link-layer Addresses . . . . . . . . . . . . . . . . . . . 22 - A.4. Logical Network Service Identity . . . . . . . . . . . . . 23 - Appendix B. Security/privacy issues with traditional SLAAC - addresses . . . . . . . . . . . . . . . . . . . . . . 24 - B.1. Correlation of node activities within the same network . . 24 - B.2. Correlation of node activities across networks (host - tracking) . . . . . . . . . . . . . . . . . . . . . . . . 24 - B.3. Address-scanning attacks . . . . . . . . . . . . . . . . . 25 - B.4. Exploitation of device-specific information . . . . . . . 25 - Appendix C. Privacy issues still present when temporary - addresses are employed . . . . . . . . . . . . . . . 26 - C.1. Host tracking . . . . . . . . . . . . . . . . . . . . . . 26 - C.1.1. Tracking hosts across networks #1 . . . . . . . . . . 26 - C.1.2. Tracking hosts across networks #2 . . . . . . . . . . 27 - C.1.3. Revealing the identity of devices performing - server-like functions . . . . . . . . . . . . . . . . 27 - C.2. Address-scanning attacks . . . . . . . . . . . . . . . . . 27 - C.3. Information Leakage . . . . . . . . . . . . . . . . . . . 28 - C.4. Correlation of node activities within a network . . . . . 28 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 3. Algorithm specification . . . . . . . . . . . . . . . . . . . 9 + 4. Resolving Duplicate Address Detection (DAD) conflicts . . . . 14 + 5. Specified Constants . . . . . . . . . . . . . . . . . . . . . 15 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 + Appendix A. Possible sources for the Net_Iface parameter . . . . 23 + A.1. Interface Index . . . . . . . . . . . . . . . . . . . . . 23 + A.2. Interface Name . . . . . . . . . . . . . . . . . . . . . . 23 + A.3. Link-layer Addresses . . . . . . . . . . . . . . . . . . . 23 + A.4. Logical Network Service Identity . . . . . . . . . . . . . 24 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction [RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for IPv6 [RFC2460], which typically results in hosts configuring one or more "stable" addresses composed of a network prefix advertised by a local router, and an Interface Identifier (IID) that typically embeds a hardware address (e.g., using IEEE identifiers) [RFC4291]. Cryptographically Generated Addresses (CGAs) [RFC3972] are yet @@ -129,23 +112,24 @@ o embedding the underlying link-layer address in the Interface Identifier leaks device-specific information that could be leveraged to launch device-specific attacks. o embedding the underlying link-layer address in the Interface Identifier means that replacement of the underlying interface hardware will result in a change of the IPv6 address(es) assigned to that interface. - Appendix B provides additional details regarding how these - vulnerabilities could be exploited, and the extent to which the - method discussed in this document mitigates them. + [I-D.cooper-6man-ipv6-address-generation-privacy] provides additional + details regarding how these vulnerabilities could be exploited, and + the extent to which the method discussed in this document mitigates + them. The "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" [RFC4941] (henceforth referred to as "temporary addresses") were introduced to complicate the task of eavesdroppers and other information collectors (e.g. IPv6 addresses in web server logs or email headers, etc.) to correlate the activities of a node, and basically result in temporary (and random) Interface Identifiers. These temporary addresses are generated in addition to the traditional IPv6 addresses based on IEEE identifiers, with the "temporary addresses" being employed for "outgoing communications", @@ -170,22 +154,22 @@ attacks, and that at the very least do not reveal the node's identity when roaming from one network to another -- without complicating the operation of the corresponding networks. However, even with "temporary addresses" in place, a number of issues remain to be mitigated. Namely, o since "temporary addresses" [RFC4941] do not eliminate the use of fixed identifiers for server-like functions, they only partially mitigate host-tracking and activity correlation across networks - (see Appendix C.1 for some example attacks that are still possible - with temporary addresses). + (see [I-D.cooper-6man-ipv6-address-generation-privacy] for some + example attacks that are still possible with temporary addresses). o since "temporary addresses" [RFC4941] do not replace the traditional SLAAC addresses, an attacker can still leverage patterns in those addresses to greatly reduce the search space for "alive" nodes [Gont-DEEPSEC2011] [CPNI-IPv6] [I-D.ietf-opsec-ipv6-host-scanning]. Hence, there is a motivation to improve the properties of "stable" addresses regardless of whether temporary addresses are employed or not. @@ -281,38 +265,39 @@ identifiers (as specified in [RFC2464]). It is meant to be employed for all of the stable (i.e. non-temporary) IPv6 addresses configured with SLAAC for a given interface, including global, link-local, and unique-local IPv6 addresses. We note that of use of the algorithm specified in this document is (to a large extent) orthogonal to the use of "temporary addresses" [RFC4941]. When employed along with "temporary addresses", the method specified in this document will mitigate address-scanning attacks and correlation of node activities across networks (see - Appendix C and [IAB-PRIVACY]). On the other hand, hosts that do not - implement/use "temporary addresses" but employ the method specified - in this document would, at the very least, mitigate the host-tracking - and address scanning issues discussed in the previous section. + [I-D.cooper-6man-ipv6-address-generation-privacy] and [IAB-PRIVACY]). + On the other hand, hosts that do not implement/use "temporary + addresses" but employ the method specified in this document would, at + the very least, mitigate the host-tracking and address scanning + issues discussed in the previous section. 3. Algorithm specification IPv6 implementations conforming to this specification MUST generate Interface Identifiers using the algorithm specified in this section in replacement of any other algorithms used for generating "stable" - addresses (such as those specified in [RFC2464]). However, - implementations conforming to this specification MAY employ the - algorithm specified in [RFC4941] to generate temporary addresses in - addition to the addresses generated with the algorithm specified in - this document. The method specified in this document MUST be - employed for generating the Interface Identifiers for all the stable - addresses of a given interface, including IPv6 global, link-local, - and unique-local addresses. + addresses with SLAAC (such as those specified in [RFC2464]). + However, implementations conforming to this specification MAY employ + the algorithm specified in [RFC4941] to generate temporary addresses + in addition to the addresses generated with the algorithm specified + in this document. The method specified in this document MUST be + employed for generating the Interface Identifiers with SLAAC for all + the stable addresses of a given interface, including IPv6 global, + link-local, and unique-local addresses. This means that this document does not formally obsolete or deprecate any of the existing algorithms to generate Interface Identifiers (e.g. such as that specified in [RFC2464]). However, those IPv6 implementations that employ this specification MUST generate all of their "stable" addresses as specified in this document. Implementations conforming to this specification SHOULD provide the means for a system administrator to enable or disable the use of this @@ -557,21 +542,22 @@ Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), as an alternative to e.g. Interface Identifiers that embed IEEE identifiers (such as those specified in [RFC2464]). When compared to such identifiers, the identifiers specified in this document have a number of advantages: o They prevent trivial host-tracking, since when a host moves from one network to another the network prefix used for autoconfiguration and/or the Network ID (e.g., IEEE 802.11 SSID) will typically change, and hence the resulting Interface - Identifier will also change (see Appendix C.1). + Identifier will also change (see + [I-D.cooper-6man-ipv6-address-generation-privacy]). o They mitigate address-scanning techniques which leverage predictable Interface Identifiers (e.g., known Organizationally Unique Identifiers) [I-D.ietf-opsec-ipv6-host-scanning]. o They may result in IPv6 addresses that are independent of the underlying hardware (i.e. the resulting IPv6 addresses do not change if a network interface card is replaced) if an appropriate source for Net_Iface (Section 3) is employed. @@ -617,22 +603,23 @@ Interface Identifiers such as those specified in [RFC2464], but is not meant as an alternative to temporary Interface Identifiers (such as those specified in [RFC4941]). Clearly, temporary addresses may help to mitigate the correlation of activities of a node within the same network, and may also reduce the attack exposure window (since temporary addresses are short-lived when compared to the addresses generated with the method specified in this document). We note that implementation of this algorithm would still benefit those hosts employing "temporary addresses", since it would mitigate host- tracking vectors still present when such addresses are used (see - Appendix C.1), and would also mitigate address-scanning techniques - that leverage patterns in IPv6 addresses that embed IEEE identifiers. + [I-D.cooper-6man-ipv6-address-generation-privacy]), and would also + mitigate address-scanning techniques that leverage patterns in IPv6 + addresses that embed IEEE identifiers. Finally, we note that the method described in this document addresses some of the privacy concerns arising from the use of IPv6 addresses that embed IEEE identifiers, without the use of temporary addresses, thus possibly offering an interesting trade-off for those scenarios in which the use of temporary addresses is not feasible. 8. Acknowledgements The algorithm specified in this document has been inspired by Steven @@ -710,29 +697,35 @@ 9.2. Informative References [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996. [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998. [I-D.ietf-opsec-ipv6-host-scanning] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 - Networks", draft-ietf-opsec-ipv6-host-scanning-01 (work in - progress), April 2013. + Networks", draft-ietf-opsec-ipv6-host-scanning-02 (work in + progress), July 2013. [I-D.ietf-v6ops-ra-guard-implementation] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", draft-ietf-v6ops-ra-guard-implementation-07 (work in progress), November 2012. + [I-D.cooper-6man-ipv6-address-generation-privacy] + Cooper, A., Gont, F., and D. Thaler, "Privacy + Considerations for IPv6 Address Generation Mechanisms", + draft-cooper-6man-ipv6-address-generation-privacy-00 (work + in progress), July 2013. + [HDMoore] HD Moore, "The Wild West", Louisville, Kentucky, U.S.A. September 25-29, 2012, . [Gont-DEEPSEC2011] Gont, "Results of a Security Assessment of the Internet Protocol version 6 (IPv6)", DEEPSEC 2011 Conference, Vienna, Austria, November 2011, . @@ -815,229 +808,20 @@ change upon replacement of the underlying network interface card). A.4. Logical Network Service Identity Host operating systems with a conception of logical network service identity, distinct from network interface identity or index, may keep a Universally Unique Identifier (UUID) [RFC4122] or similar identifier with the stability properties appropriate for use as the Net_Iface parameter. -Appendix B. Security/privacy issues with traditional SLAAC addresses - - This section provides additional details regarding security/privacy - issues arising from traditional SLAAC addresses- Namely, it provides - additional details regarding how those issues could be exploited, and - the extent to which the method specified in this document mitigates - such issues. - -B.1. Correlation of node activities within the same network - - Since traditional SLAAC addresses employ Interface Identifiers that - are constant within the same network, such identifiers can be - leveraged to correlate the activities of a node within the same - network. One sample scenario is that in which a client repeatedly - connects to a server over a period of time, and hence, based on the - stable Interface Identifier, the server can correlate all - communication instances as being initiated by the same node. - - The method specified in this document does not mitigate this attack - vector, since it produces Interface Identifiers that are constant - within a given network. - - This attack vector could only be mitigated by employing "temporary - addresses" [RFC4941]. However, as noted in Appendix C.4, in - scenarios in which there is a reduced number of nodes in a given - network, mitigation of this vector might be difficult (if at all - possible) -- even with "temporary addresses" [RFC4941] in place. - -B.2. Correlation of node activities across networks (host tracking) - - Since traditional SLAAC addresses employ Interface Identifiers that - are constant across networks, such identifiers can be leveraged to - correlate the activities of a node across networks. - - A passive version of this attack would be that in which a client - repeatedly connects to an attacker-operated server over a period of - time, and hence, based on the client's stable Interface Identifier, - the server can correlate all communication instances as being - initiated by the same node. - - An attacker could also launch an active version of this attack. For - example, let us assume that the attacker knows the Interface - Identifier employed by the target node (e.g., the target and the - attacker were simultaneously connected to the same subnetwork at some - point in time). If the attacker knows the possible networks the - target might connect to, he could probe whether there is an address - with the target's Interface Identifier in each of those networks. If - such address is found to be "alive", then the attacker could infer - that the target node has connected to the corresponding network. - - This vector is discussed in detail in Appendix C.1.2. - - Since the method specified in this document results in Interface - Identifiers that are not constant across networks, both the passive - and active versions of this attack vector are mitigated. - -B.3. Address-scanning attacks - - Since traditional SLAAC addresses typically embed the underlying - link-layer address, the aforementioned addresses follow specific - patterns that can be leveraged to reduce the search space when - performing IPv6 address-scanning attacks (this is discussed in detail - in [I-D.ietf-opsec-ipv6-host-scanning]). The method specified in - this document produces random (but table within each subnet) - Interface Identifiers, thus mitigating this attack vector. - -B.4. Exploitation of device-specific information - - Since traditional SLAAC addresses typically embed the underlying - link-layer address, the aforementioned addresses leaks device- - specific information that might be leveraged to launch device- - specific attacks. For example, an attacker with knowledge about a - specific vulnerability in devices manufactured by some vendor might - easily identify potential targets by looking at the Interface - Identifier of a list of IPv6 addresses. The method specified in this - document produces random (but table within each subnet) Interface - Identifiers, thus mitigating this attack vector. - -Appendix C. Privacy issues still present when temporary addresses are - employed - - It is not unusual for people to assume or expect that all the - security/privacy implications of traditional SLAAC addresses are - mitigated when "temporary addresses" [RFC4941] are employed. - However, as noted in Section 1 of this document and [IAB-PRIVACY], - since temporary addresses are employed in addition to (rather than in - replacement of) traditional SLAAC addresses, many of the security/ - privacy implications of traditional SLAAC addresses are not mitigated - by the use of temporary addresses. - - This section discusses a (non-exhaustive) number of scenarios in - which host security/privacy is still negatively affected as a result - of employing Interface Identifiers that are constant across networks - (e.g., those resulting from embedding IEEE identifiers), even when - temporary addresses [RFC4941] are employed. It aims to clarify the - motivation of employing the method specified in this document in - replacement of the traditional SLAAC addresses even when privacy/ - temporary addresses [RFC4941] are employed. - -C.1. Host tracking - - This section describes two attack scenarios which illustrate that - host-tracking may still be possible when privacy/temporary addresses - [RFC4941] are employed. These examples should remind us that one - should not disclose more than it is really needed for achieving a - specific goal (and an Interface Identifier that is constant across - different networks does exactly that: it discloses more information - than is needed for providing a stable address). - -C.1.1. Tracking hosts across networks #1 - - A host configures its stable addresses with the constant Interface - Identifier, and runs any application that needs to perform a server- - like function (e.g. a peer-to-peer application). As a result of - that, an attacker/user participating in the same application (e.g., - P2P) would learn the constant Interface Identifier used by the host - for that network interface. - - Some time later, the same host moves to a completely different - network, and employs the same P2P application. The attacker now - interacts with the same host again, and hence can learn its newly- - configured stable address. Since the Interface Identifier is the - same as the one used before, the attacker can infer that it is - communicating with the same device as before. - -C.1.2. Tracking hosts across networks #2 - - Once an attacker learns the constant Interface Identifier employed by - the victim host for its stable address, the attacker is able to - "probe" a network for the presence of such host at any given network. - - See Appendix C.1.1 for just one example of how an attacker could - learn such value. Other examples include being able to share the - same network segment at some point in time (e.g. a conference - network or any public network), etc. - - For example, if an attacker learns that in one network the victim - used the Interface Identifier 1111:2222:3333:4444 for its stable - addresses, then he could subsequently probe for the presence of such - device in the network 2011:db8::/64 by sending a probe packet (ICMPv6 - Echo Request, or any other probe packet) to the address 2001:db8:: - 1111:2222:3333:4444. - -C.1.3. Revealing the identity of devices performing server-like - functions - - Some devices, such as storage devices, may typically perform server- - like functions and may be usually moved from one network to another. - Such devices are likely to simply disable (or not even implement) - privacy/temporary addresses [RFC4941]. If the aforementioned devices - employ Interface Identifiers that are constant across networks, it - would be trivial for an attacker to tell whether the same device is - being used across networks by simply looking at the Interface - Identifier. Clearly, performing server-like functions should not - imply that a device discloses its identity (i.e., that the attacker - can tell whether it is the same device providing some function in two - different networks, at two different points in time). - - The scheme proposed in this document prevents such information - leakage by causing nodes to generate different Interface Identifiers - when moving from one network to another, thus mitigating this kind of - privacy attack. - -C.2. Address-scanning attacks - - While it is usually assumed that IPv6 address-scanning attacks are - unfeasible, an attacker can leverage address patterns in IPv6 - addresses to greatly reduce the search space - [I-D.ietf-opsec-ipv6-host-scanning] [Gont-BRUCON2012]. Addresses - that embed IEEE identifiers result in one of such patterns that could - be leveraged to reduce the search space when other nodes employ the - same IEEE OUI (Organizationally Unique Identifier). - - As noted earlier in this document, temporary addresses [RFC4941] do - not replace/eliminate the use of IPv6 addresses that embed IEEE - identifiers (they are employed in addition to those), and hence hosts - implementing [RFC4941] would still be vulnerable to address-scanning - attacks. The method specified in this document is meant as an - alternative to addresses that embed IEEE identifiers, and hence - eliminates such patterns (thus mitigating the aforementioned address- - scanning attacks). - -C.3. Information Leakage - - IPv6 addresses embedding 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 - device/software-specific vulnerabilities knowledge to quickly find - possible targets. Since temporary addresses do not replace the - traditional SLAAC addresses that typically embed IEEE identifiers, - employing temporary addresses does not eliminate this possible - information leakage. - -C.4. Correlation of node activities within a network - - In scenarios in which the number of nodes connected to a subnetwork - is small, preventing the correlation of the activities of those nodes - within such network might be difficult (if at all possible) to - achieve, even with temporary addresses [RFC4941] in place. As a - trivial example, consider a scenario where there is a single node (or - a reduced number of nodes) connected to a specific network. An - attacker could detect new addresses in use at that network along with - addresses that are no longer in use, and infer which addresses are - being employed by which hosts. This task is made particularly easier - by the fact that use of "temporary addresses" can be easily inferred - (since they follow different patterns from that of traditional SLAAC - addresses), and since they are re-generated periodically (i.e., after - a specific amount of time has elapsed). - Author's Address Fernando Gont SI6 Networks / UTN-FRH Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina Phone: +54 11 4650 8472 Email: fgont@si6networks.com