idnits 2.17.1 draft-gont-dhcpv6-stable-privacy-addresses-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 28, 2016) is 2858 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 346, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 351, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 360, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration (dhc) F. Gont 3 Internet-Draft SI6 Networks / UTN-FRH 4 Intended status: Informational W. Liu 5 Expires: December 30, 2016 Huawei Technologies 6 June 28, 2016 8 A Method for Generating Semantically Opaque Interface Identifiers with 9 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 10 draft-gont-dhcpv6-stable-privacy-addresses-02 12 Abstract 14 This document describes a method for selecting IPv6 Interface 15 Identifiers that can be employed by Dynamic Host Configuration 16 Protocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 17 addresses to DHCPv6 clients. This method is a DHCPv6 server side 18 algorithm, that does not require any updates to the existing DHCPv6 19 specifications. The aforementioned method results in stable 20 addresses within each subnet, even in the presence of multiple DHCPv6 21 servers or DHCPv6 server reinstallments. It is a DHCPv6-variant of 22 the method specified in RFC 7217 for IPv6 Stateless Address 23 Autoconfiguration. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 30, 2016. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Applicability and Design Goals . . . . . . . . . . . . . . . 3 61 3. Method Specification . . . . . . . . . . . . . . . . . . . . 4 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 7.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 The benefits of stable IPv6 addresses are discussed in [RFC7721]. 73 Providing address stability across server re-installations or when a 74 database of previous DHCPv6 address leases is unavailable is of use 75 not only when a DHCPv6 server must be re-installed or the address- 76 lease database becomes corrupted, but is also of use when 77 implementation constraints (e.g., a DHCPv6 server implementation on 78 an embedded device) make it impossible for a DHCPv6 server 79 implementation to maintain a database of previous DHCPv6 address 80 leases. Additionally, [RFC7031] describes scenarios where multiple 81 DHCPv6 servers are required to run in such a way as to provide 82 increased availability in case of server failure. 84 This document describes a method for selecting IPv6 Interface 85 Identifiers that can be employed by Dynamic Host Configuration 86 Protocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 87 addresses to DHCPv6 clients (i.e., to be employed with IA_NA 88 options). This method is a DHCPv6 server side algorithm, that does 89 not require any updates to the existing DHCPv6 specifications. The 90 aforementioned method has the following properties: 92 o The resulting IPv6 addresses remain stable within each subnet for 93 the same network interface of the same client, even when different 94 DHCPv6 servers (implementing this specification) are employed. 96 o Predicting the IPv6 addresses that will be generated by the method 97 specified in this document, even with knowledge of the IPv6 98 addresses generated for other nodes within the same network, 99 becomes very difficult. 101 The method specified in this document achieves the aforementioned 102 properties by means of a calculated technique as opposed to e.g. 103 state-sharing among DHCPv6 servers. This approach has been already 104 suggested in [RFC7031]. We note that the method described in this 105 document is essentially a DHCPv6-version of the "Method for 106 Generating Semantically Opaque Interface Identifiers with IPv6 107 Stateless Address Autoconfiguration (SLAAC)" specified in [RFC7217]. 109 2. Applicability and Design Goals 111 This document simply describes one possible approach for selecting 112 IPv6 Interface Identifiers to be employed by Dynamic Host 113 Configuration Protocol for IPv6 (DHCPv6) servers when leasing non- 114 temporary IPv6 addresses to DHCPv6 clients, with the following 115 properties: 117 o The resulting IPv6 addresses remain stable within each subnet for 118 the same network interface of the same client. 120 o The resulting IPv6 addresses cannot be predicted by an attacker 121 without knowledge of a secret key. 123 o The resulting IPv6 addresses remain stable across DHCPv6 server 124 re-installations, or even a database of previous DHCPv6 address 125 leases is not available. 127 o The resulting IPv6 addresses remain stable when different DHCPv6 128 servers (implementing this specification) are employed on the same 129 network. 131 We note that the algorithm specified in this document employs a 132 (lightweight) calculated technique (as opposed to e.g. state-sharing 133 among DHCPv6 servers) to achieve address stability in scenarios where 134 multiple DHCPv6 servers are required to run in such a way as to 135 provide increased availability, without the need of an additional 136 protocol to synchronize the lease databases of DHCPv6 servers. 138 Finally, we note that the algorithm in this document is only meant to 139 mitigate IPv6 address-based location tracking, device-specific 140 vulnerability exploitation, and host scanning (please see [RFC7721]). 141 The are a number of ways in which DHCPv6 affects user privacy, which 142 the algorithm speficied in this document does not mitigate (and does 143 not intend to). Please see [RFC7844] for a comprehensive discussion 144 of how DHCPv6 may affect user privacy. 146 3. Method Specification 148 Implementations should provide the means for a system administrator 149 to enable or disable the use of this algorithm for generating IPv6 150 addresses. 152 A DHCPv6 server implementing this specification must select the IPv6 153 addresses to be leased with the following algorithm: 155 1. Compute a random (but stable) identifier with the expression: 157 RID = F(Prefix | Client_DUID | IAID | Counter | secret_key) 159 Where: 161 RID: 162 Random (but stable) Identifier 164 F(): 165 A pseudorandom function (PRF) that must not be computable from 166 the outside (without knowledge of the secret key). F() must 167 also be difficult to reverse, such that it resists attempts to 168 obtain the secret key, even when given samples of the output 169 of F() and knowledge or control of the other input parameters. 170 F() should produce an output of at least 64 bits. F() could 171 be implemented as a cryptographic hash of the concatenation of 172 each of the function parameters. The default algorithm to be 173 employed for F() should be SHA-256 [FIPS-SHS]. An 174 implementation may provide the means for selecting other 175 algorithms. Note: MD5 [RFC1321] is considered unacceptable 176 for F() [RFC6151]. 178 Prefix: 179 The prefix employed for the local subnet, as a 128-bit 180 unsigned integer in network byte order (with the unused bits 181 set to 0). If multiple servers operate on the same network to 182 provide increased availability, all such DHCPv6 servers must 183 be configured with the same Prefix. It is the administrator's 184 responsibility that the aforementioned requirement is met. 186 |: 187 An operator representing "concatenation". 189 Client_DUID: 191 The DUID value contained in the Client Identifier option 192 received in the DHCPv6 client message. The DUID can be 193 treated as an array of 8-bit unsigned integers. 195 IAID: 196 The IAID value contained in the IA_NA option received in the 197 client message. It must be interpreted as a 32-bit unsigned 198 integer in network byte order. 200 secret_key: 201 A secret key configured by the DHCPv6 server administrator, 202 which must not be known by the attacker. It must be encoded 203 as an array of 8-bit unsigned integers. An implementation of 204 this specification must provide an interface for viewing and 205 changing the secret key. All DHCPv6 servers leasing addresses 206 from the same address range must employ the same secret key. 208 Counter: 209 A 32-bit unsigned integer in network byte order, that is 210 employed to resolve address conflicts. It must be initialized 211 to 0. 213 2. A candidate IPv6 address (IPV6_ADDR) to be leased is obtained by 214 concatenating as many bits as necessary from the RID value 215 computed in the previous step (starting from the least 216 significant bit) to the Prefix employed in the equation above as 217 follows: 219 IPV6_ADDR = IPV6_ADDR_LOW + 220 RID % (IPV6_ADDR_HI - IPV6_ADDR_LOW + 1) 222 where: 224 IPV6_ADDR: 225 The candidate IPv6 address to be leased. 227 IPV6_ADDR_HI: 228 An IPv6 address specifying the upper boundary of the IPv6 229 address pool from which the DHCPv6 server leases IPv6 230 addresses. If an address range is not explicitly selected, 231 IPV6_ADDR_HI must be set to the IPv6 address from Prefix (see 232 the expression above) that has all of the bits of the 233 Interface Identifier set to 1. 235 IPV6_ADDR_LOW: 236 An IPv6 address specifying the lower boundary of the IPv6 237 address pool from which the DHCPv6 server leases IPv6 238 addresses. If an address range is not explicitly selected, 239 IPV6_ADDR_LOW must be set to the IPv6 address from Prefix (see 240 the expression above) that has all of the bits of the 241 Interface Identifier set to 0. 243 3. The Interface Identifier of the selected IPv6 address must be 244 compared against the reserved IPv6 Interface Identifiers 245 [RFC5453] [IANA-RESERVED-IID]. In the event that an unacceptable 246 identifier has been generated, the Counter variable should be 247 incremented by 1, and a new IPv6 address should be computed with 248 the updated Counter value. 250 4. If the resulting address is not available (e.g., there is a 251 conflicting binding), the server should increment the Counter 252 variable, and a new Interface ID and IPv6 address should be 253 computed with the updated Counter value. 255 This document requires that SHA-256 be the default function to be 256 used for F(), such that, all other configuration parameters being the 257 same, different implementations of this specification result in the 258 same IPv6 addresses. 260 Including the Prefix in the PRF computation causes the Interface 261 Identifier to be different for each address from a different prefix 262 assigned to the same client. This mitigates the correlation of 263 activities of multi-homed nodes (since each of the corresponding 264 addresses will employ a different Interface ID), host-tracking (since 265 the network prefix will change as the node moves from one network to 266 another), and any other attacks that benefit from predictable 267 Interface Identifiers [RFC7721]. 269 As required by [RFC3315], an IAID is associated with each of the 270 client's network interfaces, and is consistent across restarts of the 271 DHCPv6 client. 273 The Counter parameter provides the means to intentionally cause this 274 algorithm to produce different IPv6 addresses (all other parameters 275 being the same). This can be of use to resolve address conflicts 276 (e.g. the resulting address having a conflicting binding). 278 Note that the result of F() in the algorithm above is no more secure 279 than the secret key. If an attacker is aware of the PRF that is 280 being used by the DHCPv6 server (which we should expect), and the 281 attacker can obtain enough material (i.e. addresses generated by the 282 DHCPv6 server), the attacker may simply search the entire secret-key 283 space to find matches. To protect against this, the secret key 284 should be of at least 128 bits. Key lengths of at least 128 bits 285 should be adequate. 287 Providing a mechanism to display and change the secret_key is crucial 288 for having different DHCPv6 servers produce the same IPv6 addresses, 289 and for causing a replacement system to generate the same IPv6 290 addresses as the system being replaced. We note that since the 291 privacy of the scheme specified in this document relies on the 292 secrecy of the secret_key parameter, implementations should constrain 293 access to the secret_key parameter to the extent practicable (e.g., 294 require superuser privileges to access it). Furthermore, in order to 295 prevent leakages of the secret_key parameter, it should not be used 296 for any other purposes than being a parameter to the scheme specified 297 in this document. 299 We note that all of the bits in the resulting Interface IDs are 300 treated as "opaque" bits [RFC7136]. For example, the universal/local 301 bit of Modified EUI-64 format identifiers is treated as any other bit 302 of such identifier. 304 4. IANA Considerations 306 There are no IANA registries within this document. The RFC-Editor 307 can remove this section before publication of this document as an 308 RFC. 310 5. Security Considerations 312 The method specified in this document results in IPv6 Interface 313 Identifiers (and hence IPv6 addresses) that do not follow any 314 specific pattern. Thus, attacks that rely on predictable Interface 315 IDs (such as [RFC7707]) are mitigated. 317 The method specified in this document neither mitigates nor 318 exacerbates the security considerations for DHCPv6 discussed in 319 [RFC3315], and does not mitigate a range of other privacy 320 implications associated with DHCPv6. Please read [RFC7844] for a 321 comprehensive assessment of the privacy implications of DHCPv6. 323 Finally, we note that an attacker that is able to attach to each of 324 the links to which the victim attaches would still be able to 325 correlate the activities of the victim across networks. 327 6. Acknowledgements 329 This document is based on [RFC7217], authored by Fernando Gont. 331 The authors would like to thank Marc Blanchet, Stephane Bortzmeyer, 332 Tatuya Jinmei, Andre Kostur, Tomek Mrugalski, Hosnieh Rafiee, Jim 333 Schaad, Jean-Francois Tremblay, Tina Tsou, and Bernie Volz, for 334 providing valuable comments on earlier versions of this documents. 336 The authors would like to thank Ted Lemon, who kindly answered some 337 DHCPv6-related questions. 339 Finally, the authors would like to thank Nevil Brownlee for his 340 guidance while pursuing this document. 342 7. References 344 7.1. Normative References 346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, 348 DOI 10.17487/RFC2119, March 1997, 349 . 351 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 352 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 353 December 1998, . 355 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 356 C., and M. Carney, "Dynamic Host Configuration Protocol 357 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 358 2003, . 360 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 361 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 362 2006, . 364 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", 365 RFC 5453, DOI 10.17487/RFC5453, February 2009, 366 . 368 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 369 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 370 February 2014, . 372 7.2. Informative References 374 [FIPS-SHS] 375 FIPS, , "Secure Hash Standard (SHS)", Federal Information 376 Processing Standards Publication 180-4, March 2012, 377 . 380 [IANA-RESERVED-IID] 381 Reserved IPv6 Interface Identifiers, , 382 "http://www.iana.org/assignments/ipv6-interface-ids/ 383 ipv6-interface-ids.xml". 385 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 386 DOI 10.17487/RFC1321, April 1992, 387 . 389 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 390 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 391 RFC 6151, DOI 10.17487/RFC6151, March 2011, 392 . 394 [RFC7031] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover 395 Requirements", RFC 7031, DOI 10.17487/RFC7031, September 396 2013, . 398 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 399 Interface Identifiers with IPv6 Stateless Address 400 Autoconfiguration (SLAAC)", RFC 7217, 401 DOI 10.17487/RFC7217, April 2014, 402 . 404 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 405 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 406 . 408 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 409 Considerations for IPv6 Address Generation Mechanisms", 410 RFC 7721, DOI 10.17487/RFC7721, March 2016, 411 . 413 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 414 Profiles for DHCP Clients", RFC 7844, 415 DOI 10.17487/RFC7844, May 2016, 416 . 418 Authors' Addresses 420 Fernando Gont 421 SI6 Networks / UTN-FRH 422 Evaristo Carriego 2644 423 Haedo, Provincia de Buenos Aires 1706 424 Argentina 426 Phone: +54 11 4650 8472 427 Email: fgont@si6networks.com 428 URI: http://www.si6networks.com 429 Will(Shucheng) Liu 430 Huawei Technologies 431 Bantian, Longgang District 432 Shenzhen 518129 433 P.R. China 435 Email: liushucheng@huawei.com