idnits 2.17.1 draft-jiang-csi-cga-config-dhcpv6-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2009) is 5294 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-09) exists of draft-ietf-csi-dhcpv6-cga-ps-00 == Outdated reference: A later version (-03) exists of draft-jiang-dhc-secure-dhcpv6-02 == Outdated reference: A later version (-04) exists of draft-xia-dhc-host-gen-id-02 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Sheng Jiang 2 Internet Draft Sam(Zhongqi) Xia 3 Intended status: Standards Track Huawei Technologies Co., Ltd 4 Expires: April 25, 2010 October 26, 2009 6 Configuring Cryptographically Generated Addresses (CGA) using DHCPv6 7 draft-jiang-csi-cga-config-dhcpv6-01.txt 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 This Internet-Draft will expire on April 25, 2010. 31 Copyright Notice 33 Copyright (c) 2009 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents in effect on the date of 38 publication of this document (http://trustee.ietf.org/license-info). 39 Please review these documents carefully, as they describe your rights 40 and restrictions with respect to this document. 42 Abstract 44 A Cryptographically Generated Address (CGA) is an IPv6 addresses 45 binding with a public/private key pair. However, the current CGA 46 specifications are lack of procedures to enable proper management of 47 CGA generation. Administrators should be able to configure parameters 48 used to generate CGA. The Dynamic Host Configuration Protocol for 49 IPv6 (DHCPv6), which enables network management to dynamically 50 configure hosts, can be used in the CGA configuration. Furthermore, 51 CGA generation consumes large computation power. This computational 52 burden can be delegated to the DHCPv6 server. A new DHCPv6 options 53 are also defined in this document to enable hosts delegate CGA 54 generation to a DHCPv6 server. 56 Table of Contents 58 1. Introduction..................................................3 59 2. Terminology...................................................3 60 3. Requirements..................................................4 61 3.1. Configuration of the parameters required for the generation 62 of CGA........................................................4 63 3.2. Offloading the large computational burden................5 64 4. DHCPv6 Approach...............................................5 65 4.1. Node requests CGA-related configuration parameters to the 66 DHCPv6 server.................................................6 67 4.2. Node requests CGA generation to the DHCPv6 server........6 68 5. New CGA-related DHCPv6 Options................................6 69 5.1. DHCPv6 CGA Sec Option....................................6 70 5.2. DHCPv6 CGA Generation Request Option.....................7 71 6. Security Considerations.......................................8 72 7. IANA Considerations...........................................9 73 8. Acknowledgments...............................................9 74 9. References....................................................9 75 9.1. Normative References.....................................9 76 9.2. Informative References..................................10 77 Author's Addresses..............................................11 79 1. Introduction 81 Cryptographically Generated Addresses (CGA, [RFC3972]) provide means 82 to verify the ownership of IPv6 addresses without requiring any 83 security infrastructure such as a certification authority. The use 84 of CGAs allows identity verification in different protocols, such as 85 SEure Neighbor Discovery (SEND, [RFC3971]), Enhanced Route 86 Optimization for MIPv6 [RFC4866] or Site Multihoming by IPv6 87 Intermediation (SHIM6 [RFC5533]). 89 However, as [PS-DC] analyses, in the current specifications, there is 90 a lack of procedures to enable proper management of CGA generation, 91 in particular, in the configuration of the parameters that define the 92 security properties of the addresses. Administrators should be able 93 to configure parameters used to generate CGA. The Dynamic Host 94 Configuration Protocol for IPv6 (DHCPv6), which enables network 95 management to dynamically configure hosts, can be used in the CGA 96 configuration. For example, DHCPv6 server should be able to assign 97 subnet prefix or other relevant parameters to CGA address owner. In 98 some scenarios, the administrator may further want to enforce some 99 parameters, particularly, the demanded security related parameters 100 such as SEC value. 102 Additionally, CGA generation is computational consumption. It can be 103 a heavy burden for end-user devices, particular slow or battery- 104 dependant devices. Currently, there are no means to delegate the 105 computation of the modifier, a CPU intensive operation, to faster or 106 non battery-dependant resources. It is possible that the whole or 107 part of CGA generation procedure is delegated to the DHCPv6 server. 109 This draft analyses the requirements raised by CGA configuration and 110 computational delegation for CGA generation. This draft provides 111 solutions for CGA configuration and delegated CGA generation. Two 112 existing DHCPv6 options are re-used. Two new DHCPv6 options are also 113 defined in this document. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC2119 [RFC2119]. 121 3. Requirements 123 The CGA specifications [RFC3972] define the procedure to generate a 124 CGA. However, these procedures do not allow the enforcement of a 125 given configuration to a group of hosts. It does also not consider 126 the delegation of CPU-intensive operations to other nodes. In this 127 section, we analyze the scenarios in which these operations are 128 required. 130 3.1. Configuration of the parameters required for the generation 131 of CGA 133 The CGA associated Parameters used to generate a CGA includes several 134 parameters [RFC3972]: 136 - a Public Key, 138 - a Subnet Prefix, 140 - a 3-bit security parameter Sec. Additionally, it should be noted 141 that the hash algorithm to be used in the generation of the CGA is 142 also defined by the Sec value [RFC4982], 144 - a modifier that is selected so that the result of a hash to 145 comply with the requirements introduced by the value of a security 146 parameter Sec in order to provide protection against brute-force 147 attacks, 149 - a Collision Count value, increased each time the address 150 generated results in a collision in the subnet considered, 152 - any Extension Fields that could be used. 154 Currently, there are convenient mechanisms for allowing an 155 administrator to configure the subnet prefix for a host, by Router 156 Advertisement [RFC4862]. But other parameters used for generating the 157 CGA could not be configured by the administrator. 159 It would be useful if these parameters could also be configured by 160 the administrator. For instance, the administrator can determine, 161 according to the type of infrastructure and the security needs, the 162 Sec value that should be used by the hosts to generate the CGA. When 163 appropriate, the Extension Fields could also be mandated by the 164 administrator. 166 Upon reception of this information, the end hosts SHOULD generate 167 addresses compliant with the received parameters. If the parameters 168 change, the end hosts SHOULD generate new addresses compliant with 169 the parameters propagated. 171 3.2. Offloading the large computational burden 173 An important case to consider is the large computational consumption 174 of the generation of the modifier field. The modifier is a 128 175 unsigned integer that is selected so that the Hash2 operation defined 176 in RFC 3972 results in the required number of leftmost 0 bits. The 177 higher the number of bits required being 0, the more secure a CGA is 178 against brute-force attacks. However, high number of bits also 179 results in additional computational cost for the generation process, 180 cost that could be deemed excessive in certain environments, such as 181 mobile terminals with low computing power. 183 As an example, consider a Sec value equals 2, requesting the leftmost 184 32 bits of a SHA-1 Hash2 to be zero. For assuring this, a system has 185 to generate in mean 2^32 different modifiers, and perform the Hash2 186 operation to check the bits required to be 0. An estimation of the 187 CPU power required to do this can be obtained as following: openSSL 188 can perform in an Intel Core2-6300 on an Asus p5b-w motherboard close 189 to 0.87 million of SHA-1 operations on 16 byte blocks per second. 190 Since the input data of Hash2 operation is larger than 16 bytes, this 191 value is an upper bound for the number of hash operations that can be 192 performed for generating the modifier. Checking 2^32 different 193 modifiers requires around 5000 seconds. The high number of required 194 operations can represent a problem for end hosts (i.e. mobile devices) 195 with much lower computing power than considered in the example, 196 and/or with restrictions in battery resources. 198 For these cases, a mechanism for delegating the computation of the 199 modifier should be provided. It is also possible that the whole CGA 200 generation procedure is delegated. 202 4. DHCPv6 Approach 204 Among the mechanisms in which configuration parameters could be 205 pushed to the end hosts and/or CGA related information sent back to a 206 central administration, we discuss the stateful configuration 207 mechanism based on DCHPv6 in this document. Other mechanisms may also 208 provide similar functions, but out of scope. 210 DHCPv6 can be extended to: 212 - propagate to the end hosts the values of the parameters required 213 to configure CGAs, 214 - receive requests for generating a CGA according to a given 215 security configuration, and returning the result to the end host. 217 4.1. Node requests CGA-related configuration parameters to the 218 DHCPv6 server 220 A node may initiate a request for the relevant CGA configuration 221 information needed to the DHCPv6 server. The server responds with the 222 configuration information for the node. The Option Request Option, 223 defined in Section 22.7 in [RFC3315], can be used for node to 224 indicate which options the client requests from the server. To 225 propagate the CHA-related parameters, the Identity Association for 226 Prefix Assignment Option defined in [HGID] and a new CGA-Sec Option 227 defined in Section 5.1 can be used. Of course, a node can also use 228 the sub-prefix received through Router Advertisement message 229 [RFC4861]. Future specification may define more options to carry CGA- 230 related configuration parameters. 232 After receiving the configuration information, the node SHOULD 233 generate a CGA based on its public key and the configuration 234 information. The configuration of the client key pair or certificate 235 is out of scope. 237 4.2. Node requests CGA generation to the DHCPv6 server 239 A node may initiate a request for the computation of the modifier or 240 the CGA address for a certain security configuration to the DHCPv6 241 server. The node includes the values selected for the CGA associated 242 parameters, such as its public key, the value of the Sec parameter, 243 etc. The server either computes by itself, or redirects the 244 computation to other node using a mechanism that is out of the scope 245 of this document. Once the server generates or obtains the CGA, it 246 responds to the node with the resulting address and the CGA 247 Parameters Data Structure using the CGA Generation Request Option 248 defined in Section 5.2. 250 5. New CGA-related DHCPv6 Options 252 5.1. DHCPv6 CGA Sec Option 254 DHCPv6 CGA Sec Option is used to carry a Sec value, the parameters 255 associated with CGA generation on a client. After receiving the CGA 256 Sec Option, the client SHOULD generate a CGA using a Sec value that 257 is not lower than the option indicated. 259 0 1 2 3 260 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | OPTION_CGA_SEC | option-len | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | CGA SEC | 265 +-+-+-+-+-+-+-+-+ 267 option-code OPTION_CGA_SEC (TBA). 269 option-len 1. 271 CGA SEC a digit between 0 and 7, the SEC level. 273 5.2. DHCPv6 CGA Generation Request Option 275 DHCPv6 CGA Generation Request Option is sent by a client to request a 276 DHCPv6 server to generate a CGA address. After a DHCPv6 server 277 receives CGA-relevant parameters sent by the client, it generates a 278 CGA address based on these parameters and its own configuration. It 279 then replies the CGA address and associated CGA Parameters data 280 structure back to the client. 282 0 1 2 3 283 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | OPTION_CGA_GR | option-len | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | CGA SEC | Reserved | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Subnet Prefix (64-bit) | 290 | | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | | 293 ~ Public Key (variable length) ~ 294 | | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | | 297 ~ Extension Fields (optional, variable length,) ~ 298 | | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 option-code OPTION_CGA_GR (TBA). 303 option-len 16 + Length of public key field in octets. 305 CGA SEC a digit between 0 and 7, the SEC level require 306 by the client. 308 Reserved A 24-bit field reserved for future use. The 309 value MUST be initialized to zero by the sender, 310 and MUST be ignored by the receiver. 312 Subnet Prefix An IPv6 prefix provided by the client, used for 313 CGA generation. If set all 0, DHCPv6 server will 314 use its own configured IPv6 subnet prefix. 316 Public Key This is a variable-length field contain the 317 public key of the client. This public key will 318 be used for CGA generation. 320 Extension Fields This is an optional variable-length field that 321 is not used in the current specification. Future 322 versions of this specification may use this 323 field for additional data items that need to be 324 included in the CGA Parameters data structure. 325 Implementations MUST ignore the value of any 326 unrecognized extension fields. 328 DHCPv6 server MAY use IA-NA or IA TA option with a CGA Parameter Data 329 Structure IA sub-option to return the CGA address and associated CGA 330 Parameters data structure back to the client. 332 DHCPv6 server MAY generate only a modifier and associated CGA 333 Parameters data structure if it can not perform duplicate address 334 detection, as per [RFC3971]. 336 6. Security Considerations 338 The mechanisms based on DHCPv6 are all vulnerable to DOS attacks to 339 the server, such as request for large number of CGA generations. 340 Proper use of DHCPv6 autoconfiguration facilities [RFC3315], such as 341 AUTH option or Secure DHCP [SDHCP] can prevent these threats, 342 provided that a configuration token is known to both the client and 343 the server. 345 Note that, as expected, it is not possible to provide secure 346 configuration of CGA without a previous configuration of security 347 information at the client (either a trust anchor, a DHCPv6 348 configuration token...). However, considering that the values of 349 these elements could be shared by the nodes in the network segment, 350 these security elements can be configured more easily in the end 351 nodes than its addresses. 353 Regarding to the configuration of the Sec parameter, one risk is that 354 a malicious node could propagate a Sec value providing less 355 protection than intended by the network administrator, facilitating a 356 brute force attack against the hash, or the selection of the weakest 357 hash algorithm available for CGA definition. However, even in the 358 worst case, if the hash algorithm cannot be inverted, the expected 359 number of iterations required for a brute force attack is O(2^59) in 360 order to find a CGA Parameters data structure that matches a given 361 CGA. Another risk is the use of a Sec, higher than intended by the 362 administrator, which would require a large number of resources of the 363 client to compute the modifier, requiring a long time before the 364 device can communicate. This can be considered a kind of DOS attack. 365 A variation of this attack is the propagation of different Sec values. 366 This kind of attack may be prevented by server authentication. 368 An attacker could send malicious CGA Generation Requests in order to 369 exhaust the server resources, since the CPU cost for the server can 370 be high, especially considering that the attacker could select a Sec 371 value requiring the highest number of computations for the server. 372 This kind of attack may be prevented by host-based authentication. 374 7. IANA Considerations 376 This document defines two new DHCPv6 [RFC3315] options, which must be 377 assigned Option Type values within the option numbering space for 378 DHCPv6 messages: 380 The DHCPv6 CGA Sec Option (TBA1), described in Section 5.1. 382 The DHCPv6 CGA Generation Request Option (TBA2), described in Section 383 5.2. 385 8. Acknowledgments 387 The authors would like to thank Marcelo Bagnulo Braun and Alberto 388 Garcia-Martinez from Universidad Carlos III de Madrid for been 389 involved in the early requirement identification. 391 9. References 393 9.1. Normative References 395 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 396 Requirement Levels", RFC2119, March 1997. 398 [RFC3315] R. Droms, Ed., "Dynamic Host Configure Protocol for IPv6", 399 RFC3315, July 2003. 401 [RFC3971] J. Arkko, J. Kempf, B. Zill, P. Nikander, "SEcure Neighbor 402 Discovery (SEND) ", RFC 3971, March 2005. 404 [RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972, 405 March 2005. 407 [RFC4861] T. Narten, et al., "Neighbor Discovery for IP version 6 408 (IPv6)", RFC 4861, September 2007. 410 [RFC4862] S. Thomson, T. Narten, T. Jinmei, "IPv6 Stateless Address 411 Autoconfiguration", RFC4862, September 2007. 413 [RFC4866] J. Arkko, C. Vogt, W. Haddad, "Enhanced Route Optimization 414 for Mobile IPv6", RFC4866, May 2007. 416 [RFC4982] M. Bagnulo, "Support for Multiple Hash Algorithms in 417 Cryptographically Generated Addresses (CGAs) ", RFC4982, 418 July 2007. 420 [RFC5533] E. Nordmark and M. Bagnulo "Shim6: Level 3 Multihoming Shim 421 Protocol for IPv6" FRC 5533, June 2009 423 9.2. Informative References 425 [PS-DC] S. Jiang, "DHCPv6 and CGA Interaction: Problem Statement", 426 draft-ietf-csi-dhcpv6-cga-ps-00.txt (work in progress), 427 October, 2009. 429 [SDHCP] S. Jiang, "Secure DHCPv6 Using CGAs", draft-jiang-dhc- 430 secure-dhcpv6-02.txt (work in progress), July 2009. 432 [HGID] F. Xia, B. Sarikaya, S. Jiang, "Usage of Host Generating 433 Interface Identifier in DHCPv6", draft-xia-dhc-host-gen-id- 434 02.txt (work in progress), October 2009. 436 Author's Addresses 438 Sheng Jiang 439 Huawei Technologies Co., Ltd 440 KuiKe Building, No.9 Xinxi Rd., 441 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 442 P.R. China 443 Email: shengjiang@huawei.com 445 Sam(Zhongqi) Xia 446 Huawei Technologies Co., Ltd 447 KuiKe Building, No.9 Xinxi Rd., 448 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 449 P.R. China 450 Email: xiazhongqi@huawei.com