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

This html diff was produced by rfcdiff 1.39p1. The latest version is available from http://tools.ietf.org/tools/rfcdiff/