--- 1/draft-ietf-6man-stable-privacy-addresses-00.txt 2012-10-08 02:14:16.809600376 +0200 +++ 2/draft-ietf-6man-stable-privacy-addresses-01.txt 2012-10-08 02:14:16.837646677 +0200 @@ -1,19 +1,19 @@ IPv6 maintenance Working Group (6man) F. Gont -Internet-Draft UK CPNI -Intended status: Standards Track May 18, 2012 -Expires: November 19, 2012 +Internet-Draft SI6 Networks / UTN-FRH +Intended status: Standards Track October 8, 2012 +Expires: April 11, 2013 A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC) - draft-ietf-6man-stable-privacy-addresses-00 + draft-ietf-6man-stable-privacy-addresses-01 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. The aforementioned method is meant to be an alternative to generating Interface Identifiers based on IEEE identifiers, such that the benefits of stable addresses can be @@ -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 November 19, 2012. + This Internet-Draft will expire on April 11, 2013. Copyright Notice Copyright (c) 2012 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 @@ -59,40 +59,40 @@ 4. Resolving Duplicate Address Detection (DAD) conflicts . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 Appendix A. Privacy issues still present with RFC 4941 . . . . . 15 A.1. Host tracking . . . . . . . . . . . . . . . . . . . . . . 15 A.1.1. Tracking hosts across networks #1 . . . . . . . . . . 15 - A.1.2. Tracking hosts across networks #2 . . . . . . . . . . 16 - A.1.3. Revealing the identity of a devices performing + A.1.2. Tracking hosts across networks #2 . . . . . . . . . . 15 + A.1.3. Revealing the identity of devices performing server-like functions . . . . . . . . . . . . . . . . 16 - A.2. Host scanning-attacks . . . . . . . . . . . . . . . . . . 16 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 + A.2. Address scanning attacks . . . . . . . . . . . . . . . . . 16 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction [RFC4862] specifies the 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]. Generally, static addresses are thought to simplify network - management, since they simplify ACLs and logging. However, since - IEEE identifiers are typically globally unique, the resulting IPv6 - addresses can be leveraged to track and correlate the activity of a - node over time and across multiple subnets and networks, thus - negatively affecting the privacy of users. + management, since they simplify Access Control Lists (ACLs) and + logging. However, since IEEE identifiers are typically globally + unique, the resulting IPv6 addresses can be leveraged to track and + correlate the activity of a node over time and across multiple + subnets and networks, thus negatively affecting the privacy of users. The "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" [RFC4941] were introduced to complicate the task of eavesdroppers and other information collectors to correlate the activities of a node, and basically result in temporary (and random) Interface Identifiers that are typically more difficult to leverage than those based on IEEE identifiers. When privacy extensions are enabled, "privacy addresses" are employed for "outgoing communications", while the traditional IPv6 addresses based on IEEE identifiers are still used for "server" functions (i.e., receiving @@ -241,62 +241,55 @@ Prefix: The prefix to be used for SLAAC, as learned from an ICMPv6 Router Advertisement message. Interface_Index: The interface index [RFC3493] [RFC3542] corresponding to this network interface. Network_ID: Some network specific data that identifies the subnet to which - this interface is attached. For example the IEEE 802.11 SSID - corresponding to the network to which this interface is - associated. This parameter is OPTIONAL. + this interface is attached. For example the IEEE 802.11 + Service Set Identifier (SSID) corresponding to the network to + which this interface is associated. This parameter is + OPTIONAL. DAD_Counter: A counter that is employed to resolve Duplicate Address Detection (DAD) conflicts. It MUST be initialized to 0, and incremented by 1 for each new tentative address that is configured as a result of a DAD conflict. See Section 4 for additional details. secret_key: A secret key that is not known by the attacker. The secret - key MUST be initialized at system installation time to the - concatenation of a pseudo-random number (see [RFC4086] for - randomness requirements for security) and the machine's serial - number. If the machine's serial number is not available, a - value of 0 should be used for it. An implementation MAY - provide the means for the user to change the secret key. + key MUST be initialized at system installation time to a + pseudo-random number (see [RFC4086] for randomness + requirements for security). An implementation MAY provide the + means for the user to change the secret key. 2. The Interface Identifier is finally obtained by taking the leftmost 64 bits of the RID value computed in the previous step, and and setting bit 6 (the leftmost bit is numbered 0) to zero. This creates an interface identifier with the universal/local bit indicating local significance only. Note that the result of F() in the algorithm above is no more secure than the secret key. If an attacker is aware of the PRF that is being used by the victim (which we should expect), and the attacker can obtain enough material (i.e. addresses configured by the victim), the attacker may simply search the entire secret-key space to find matches. To protect against this, the secret key should be of a reasonable length. Key lengths of at least 128 bits should be - adequate. The secret key is initialized at installation time to the - concatenation of a pseudo-random number and the machine's serial - number. This allows this mechanism to be enabled/used automatically, - without user intervention. - - The machine's serial number is concatenated to the pseudo-random - number, such that the entropy of the key is increased (since at - installation time the entropy of the Pseudo-Random Number - Generator might be reduced). + adequate. The secret key is initialized at system installation time + to a pseudo-random number, thus allowing this mechanism to be + enabled/used automatically, without user intervention. Including the SLAAC prefix in the PRF computation causes the Interface ID to vary across networks that employ different prefixes, thus mitigating host-tracking attacks and any other attacks that benefit from predictable Interface IDs (such as host scanning). Including the optional Network_ID parameter when computing the RID value above would cause the algorithm to produce a different Interface Identifier when connecting to different networks, even when configuring addresses belonging to the same prefix. This means that @@ -388,23 +381,24 @@ Finally, we note that the method described in this document may mitigate most 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. 7. Acknowledgements The author would like to thank (in alphabetical order) Karl Auer, - Steven Bellovin, Dominik Elsbroek, Bob Hinden, Christian Huitema, Ray - Hunter, Jong-Hyouk Lee, and Michael Richardson, for providing - valuable comments on earlier versions of this document. + Steven Bellovin, Matthias Bethke, Dominik Elsbroek, Bob Hinden, + Christian Huitema, Ray Hunter, Jong-Hyouk Lee, and Michael + Richardson, for providing valuable comments on earlier versions of + this document. This document is based on the technical report "Security Assessment of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] authored by Fernando Gont on behalf of the UK Centre for the Protection of National Infrastructure (CPNI). Fernando Gont would like to thank CPNI (http://www.cpni.gov.uk) for their continued support. 8. References @@ -439,131 +433,141 @@ Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003. [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003. [RFC4620] Crawford, M. and B. Haberman, "IPv6 Node Information Queries", RFC 4620, August 2006. + [I-D.gont-opsec-ipv6-host-scanning] + Gont, F., "Network Reconnaissance in IPv6 Networks", + draft-gont-opsec-ipv6-host-scanning-01 (work in progress), + July 2012. + [Gont-DEEPSEC2011] Gont, "Results of a Security Assessment of the Internet Protocol version 6 (IPv6)", DEEPSEC 2011 Conference, Vienna, Austria, November 2011, . + [Gont-BRUCON2012] + Gont, "Recent Advances in IPv6 Security", BRUCON 2012 + Conference, Ghent, Belgium, September 2012, . + [Broersma] Broersma, R., "IPv6 Everywhere: Living with a Fully IPv6- enabled environment", Australian IPv6 Summit 2010, Melbourne, VIC Australia, October 2010, . [CPNI-IPv6] Gont, F., "Security Assessment of the Internet Protocol version 6 (IPv6)", UK Centre for the Protection of National Infrastructure, (available on request). Appendix A. Privacy issues still present with RFC 4941 - This aims to clarify the motivation of using the method specified in - this document even when privacy/temporary addresses are employed. It - has been incorporated in the document to clarify a number of - questions that arose during the presentation of this document at IETF - 83 (Paris). This entire section might be removed prior to - publication of this document as an RFC. + This section aims to clarify the motivation of using the method + specified in this document even when privacy/temporary addresses + [RFC4941] are employed. It discusses a (non-exaustive) number of + scenarios in which host privacy is still sacrificed even when + privacy/temporary addresses [RFC4941] are employed, as a result of + employing interface identifiers that are constant across networks + (e.g., those resulting from embedding IEEE identifiers). A.1. Host tracking - Some 6man participants questioned the inclusion of the SLAAC prefix - in PRF function, and noted that the ID of "stable" addresses need not - change across networks, since privacy/temporary addresses already - mitigate host tracking. This section describes one possible attack - scenario that illustrates that host-tracking may still be possible - when privacy/temporary addresses are employed. + This section describes one possible attack scenario that illustrates + that host-tracking may still be possible when privacy/temporary + addresses [RFC4941] are employed. A.1.1. Tracking hosts across networks #1 - A host configures the stable addresses without including the Prefix - in the F() (the PRF). The aforementioned host now 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 - Interface-ID used for the stable address. + A host configures its stable addresses with the constant + Interface-ID, 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-ID used by the host + for that network interface. Some time later, the same host moves to a completely different - network, and uses the same P2P application, probably even with a - different user. The attacker now interacts with the same host again, - and hence can learn the "new" stable address. Since the interface ID - is the same as the one used before, the attacker can infer that it is - communicating with the same device as before. - - Had the host included the Prefix when computing the Interface-ID - (with the hash function F()) as RECOMMENDED in this document, the - Interface-ID would have been different, and this privacy attack would - not have been possible. + network, and employs the same P2P application, probably even with a + different username. The attacker now interacts with the same host + again, and hence can learn its newly-configured stable address. + Since the interface ID is the same as the one used before, the + attacker can infer that it is communicating with the same device as + before. This is just *one* possible attack scenario, which should remind us that one should not disclose more than it is really needed for achieving a specific goal (and an Interface-ID that is constant across different networks does exactly that: it discloses more information than is needed for providing a stable address). A.1.2. Tracking hosts across networks #2 - Once an attacker learns the fixed Interface-ID employed by the victim - host for its stable address, the attacker is able to "probe" a + Once an attacker learns the constant Interface-ID 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 A.1.1 for just one example of how an attacker could - learn such prefix. Other examples include being able to share the - same network segment at some point in time (think about sharing a - conference network with 1000+ peers), etc. + 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 prefix 1111:2222:3333:4444 for its stable addresses, then we - could subsequently probe for the presence of such device in the - network 2011:db8::/64 by sending a probe packet (ICMPv6 Echo Request, - or your favourite probe packet) to the address 2001:db8::1111:2222: - 3333:4444. + used the Interface-ID 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. -A.1.3. Revealing the identity of a devices performing server-like +A.1.3. Revealing the identity of devices performing server-like functions - Some devices may typically perform server-like functions and may be - usually moved from one network to another (e.g., from storage devices - to printers). Such devices are likely to simply disable (or not even - implement) privacy/temporary addresses [RFC4941]. If the + Some devices, such as storage devices or printers, 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-IDs 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 ID. Clearly, performing server-like 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. + Interface ID. 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-IDs when moving to one network to another, thus mitigating this kind of privacy attack. -A.2. Host scanning-attacks +A.2. Address scanning attacks - While it is usually assumed that host-scanning attacks are - unfeasible, an attack can leverage patterns in IPv6 address - generation to greatly reduce the search space. + While it is usually assumed that address-scanning attacks are + unfeasible, an attacker could leverage patterns in IPv6 addresses to + greatly reduce the search space [I-D.gont-opsec-ipv6-host-scanning] + [Gont-BRUCON2012]. As noted earlier in this document, privacy/temporary addresses do not eliminate the use of IPv6 addresses that embed IEEE identifiers, and - hence such hosts would still be vulnerable to host-scanning attacks - unless they eliminate the patterns introduced by embedding IEEE - identifiers in the Interface-ID. The method specified in this - document would mitigate the aforementioned host-scanning attacks. + hence such hosts would still be vulnerable to address-scanning + attacks. The method specified in this document eliminates such + patterns and would thus mitigate the aforementioned address-scanning + attacks. Author's Address Fernando Gont - UK CPNI + SI6 Networks / UTN-FRH + Evaristo Carriego 2644 + Haedo, Provincia de Buenos Aires 1706 + Argentina + Phone: +54 11 4650 8472 Email: fgont@si6networks.com - URI: http://www.cpni.gov.uk + URI: http://www.si6networks.com