idnits 2.17.00 (12 Aug 2021) /tmp/idnits36673/draft-ietf-dhc-cga-config-dhcpv6-04.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 (November 05, 2012) is 3477 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) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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: May 06, 2013 November 05, 2012 6 Configuring Cryptographically Generated Addresses (CGA) using DHCPv6 7 draft-ietf-dhc-cga-config-dhcpv6-04 9 Status of this Memo 11 This Internet-Draft is submitted 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). Note that other groups may also distribute working 16 documents as Internet-Drafts. The list of current Internet-Drafts is 17 at http://datatracker.ietf.org/drafts/current/. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 This Internet-Draft will expire on May 06, 2013. 26 Copyright Notice 28 Copyright (c) 2012 IETF Trust and the persons identified as the 29 document authors. All rights reserved. 31 This document is subject to BCP 78 and the IETF Trust's Legal 32 Provisions Relating to IETF Documents 33 (http://trustee.ietf.org/license-info) in effect on the date of 34 publication of this document. Please review these documents 35 carefully, as they describe your rights and restrictions with respect 36 to this document. Code Components extracted from this document must 37 include Simplified BSD License text as described in Section 4.e of 38 the Trust Legal Provisions and are provided without warranty as 39 described in the Simplified BSD License. 41 Abstract 43 A Cryptographically Generated Address is an IPv6 addresses binding 44 with a public/private key pair. However, the current CGA 45 specifications are lack of procedures to enable proper management of 46 the usage of CGAs. This document analyzes the parameters required for 47 the generation of CGA from network configuration and management 48 perspective. The configuration procedures of many CGA-relevant 49 parameters with existing mechanisms are described in the document. 50 Only Sec value has no suitable mechanism to be configured by network 51 admin. A new DHCPv6 option is defined accordingly. This document also 52 analyses the configuration of the parameters, which are used to 53 generate CGAs, using DHCPv6. Although the document does not define 54 new DHCPv6 option to carry these parameters for various reasons, the 55 configuration procedure is described. 57 Table of Contents 59 1. Introduction ................................................ 3 60 2. Terminology ................................................. 3 61 3. CGA Configure Process Using DHCPv6 .......................... 4 62 3.1. Configuration of the parameters required for the generation 63 of CGA ...................................................... 4 64 3.2. Host requests CGA Approved to the DHCPv6 server ........ 5 65 4. CGA Grant Option ............................................ 7 66 5. Security Considerations ..................................... 8 67 6. IANA Considerations ......................................... 8 68 7. Acknowledgments ............................................. 8 69 8. References .................................................. 8 70 8.1. Normative References ................................... 8 71 8.2. Informative References ................................. 9 72 Author's Addresses ............................................ 10 74 1. Introduction 76 Cryptographically Generated Addresses (CGA, [RFC3972]) provide means 77 to verify the ownership of IPv6 addresses without requiring any 78 security infrastructure such as a certification authority. 80 CGAs were originally designed for SeND [RFC3971] and SeND is 81 generally not used in the same environment as a Dynamic Host 82 Configure Protocol for IPv6 (DHCPv6) [RFC3315] server. However, after 83 CGA has been defined, as an independent security property, many other 84 CGA usages have been proposed and defined, such as Site Multihoming 85 by IPv6 Intermediation (SHIM6) [RFC5533], Enhanced Route Optimization 86 for Mobile IPv6 [RFC4866], also using the CGA for DHCP security 87 purpose [I-D.ietf-dhc-secure-dhcpv6], etc. The use of CGAs allows 88 identity verification in different protocols. In these scenarios, 89 CGAs may be used in DHCPv6-managed networks. 91 This document analyses the configuration of the parameters, which are 92 used to generate CGAs, from network configuration and management 93 perspective. Although the document does not define new DHCPv6 option 94 to carry these parameters for various reasons, the configuration 95 procedure is described. The procedure works with existing options or 96 future define options. 98 In current specifications, the network administration can NOT grant 99 the use of host-generated CGA addresses on request from the client, 100 or reject the CGA on the basis of a too-low sec value. In order to 101 fill this gap, a new DHCPv6 option, CGA Grant Option, is defined in 102 this document. 104 The CGA configuration procedure described in this document can work 105 with a generic address registration mechanism. However, even a 106 generic address registration mechanism was defined, the CGA-specific 107 option, CGA Grant Option, is still needed so that DHCPv6 server can 108 indicate hosts the recommended CGA Sec value. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC2119 [RFC2119]. 116 3. CGA Configure Process Using DHCPv6 118 The CGA specifications [RFC3972] define the procedure to generate a 119 CGA. However, it assumes that hosts decide by itself or have been 120 preconfigured all CGA relevant parameters. In reality, the network 121 management MAY want to assign/enforcement some parameters to hosts; 122 the network management MAY also manage the use of CGAs. 124 Among the mechanisms in which configuration parameters could be 125 pushed to the end hosts and/or CGA related information sent back to a 126 central administration, we discuss the stateful configuration 127 mechanism based on DCHPv6 in this document. Other mechanisms may also 128 provide similar functions, but out of scope. 130 In this section, configuration CGA parameters and that a DHCPv6 131 server grants the CGA usage are described in details. 133 3.1. Configuration of the parameters required for the generation of CGA 135 Each CGA is associated with a CGA Parameters data structure, which is 136 formed by all input parameters [RFC3972] except for Sec value that is 137 embedded in the CGA. The CGA associated Parameters used to generate a 138 CGA includes: 140 - a Public Key, 142 - a Subnet Prefix, 144 - a 3-bit security parameter, Sec. Additionally, it should be noted 145 that the hash algorithm to be used in the generation of the CGA is 146 also defined by the Sec value [RFC4982], 148 - any Extension Fields that could be used. 150 - Note: the modifier and the Collision Count value in the CGA 151 Parameter data structure are generated during the CGA generation 152 process. They do NOT need to be configured. 154 In a DHCPv6 managed network, a host may initiate a request for the 155 relevant CGA configuration information needed to the DHCPv6 server. 156 The server responds with the configuration information for the host. 157 The Option Request Option, defined in Section 22.7 in [RFC3315], can 158 be used for host to indicate which options the client requests from 159 the server. For response, the requested Option should be included. 160 The server MAY also initiatively push these parameters by attaching 161 these option in the response messages which are initiated for other 162 purposes. 164 - The Public/Private key pair is generated by hosts themselves and 165 considered not suitable for network transmission for security 166 reasons. The configuration of the client key pair or certificate is 167 out of scope. 169 - Currently, there are convenient mechanisms for allowing an 170 administrator to configure the subnet prefix for a host, by Router 171 Advertisement [RFC4861, RFC4862]. However, this does not suitable 172 for the DHCP-managed network. To propagate the prefix through DHCP 173 interactions, DHCPv6 Prefix Delegation Option [RFC3633] MAY be 174 used. However, this option was designed to assign prefix block for 175 routers. A new Prefix Assignment Option MAY need to be defined. 176 Since alternative approach is existing and there are debates 177 whether a new Prefix Assignment Option MAY is necessary, this 178 document does not define it. 180 - Although the network management MAY want to enforce or configure 181 a Sec value to the hosts, it is considered as a very dangerous 182 action. A malicious fake server may send out a high Sec value to 183 attack clients giving the fact that generation a CGA with a high 184 Sec value is very computational intensive. Another risk is that a 185 malicious server could propagate a Sec value providing less 186 protection than intended by the network administrator, facilitating 187 a brute force attack against the hash, or the selection of the 188 weakest hash algorithm available for CGA definition. A 189 recommendation Sec value is considered as confusion information. 190 The receiving host is lack for information to make choose whether 191 generates a CGA according to the recommendation or not. Therefore, 192 the document does not define a DHCPv6 option to propagate the Sec 193 value. 195 - Although there is an optional Extension Fields in CGA Parameter 196 data structure, there is NO any defined extension fields. If in the 197 future, new Extension Fields in CGA Parameter data structure are 198 defined, future specification may define correspondent DHCPv6 199 options to carry these parameters. 201 Upon reception of the CGA relevant parameters from DHCPv6 server, the 202 end hosts SHOULD generate addresses compliant with the received 203 parameters. If the parameters change, the end hosts SHOULD generate 204 new addresses compliant with the parameters propagated. 206 3.2. Host requests CGA Approved to the DHCPv6 server 208 A CGA address is generated by the associated key pair owner, normally 209 an end host. However, in a DHCPv6-managed network, hosts should use 210 IPv6 global addresses only from a DHCPv6 server. The process 211 described below allows a host, also DHCPv6 client, uses self- 212 generated CGAs in a DHCPv6-managed environment, by requesting the 213 granting from a DHCPv6 server. 215 The client sends a CGA, which is generated by itself, to a DHCPv6 216 server, and requests the DHCP server to determine whether the 217 generated CGA satisfies the requirements of the network 218 configuration, wherein the network configuration comprises a CGA 219 security level set by the DHCP; and generates a new CGA if the 220 generated CGA does not satisfy the requirements of the network 221 configuration. 223 - Client initiation behavior 225 In details, a DHCPv6 client SHOULD send a DHCPv6 Request message 226 to initiate the CGA granting process. 228 This DHCPv6 Request message MUST include an Option Request option 229 [RFC3315], which requests the CGA Grant Option, defined in 230 Section 4 in this document, to indicate the DHCPv6 server 231 responses with the address granting decision. 233 The client MUST include one or more IA Options, either IA_NA or 234 IA_TA, in the Request message. Each IA Option MUST includes one 235 or more IA Address Options. CGAs are carried in the IA Address 236 Options. 238 - Server behavior 240 Upon reception of the Request message, the DHCPv6 server SHOULD 241 verify whether the client's CGAs satisfy the CGA-related 242 configuration parameters of the network. The DHCPv6 server then 243 send an acknowledgement, a Reply message, to the client to either 244 grant the use of the CGA or decline the requested CGA. The 245 CGA_Grant field SHOULD be set following the rule, defined in 246 Section 4 in this document. When the requested CGA is declined, 247 the DHCPv6 server MAY also recommend a Sec value to the client 248 using the CGA Grant option in the DHCPv6 Reply message. 250 In the meantime, the DHCPv6 server MAY log the requested CGA 251 addresses. This information MAY later be used by other network 252 functions, such as ACL. 254 - Client receiving behavior 256 Upon reception of the acknowledgement from server, the client can 257 legally use the granted CGAs. The client SHOULD silently drop any 258 message that has the CGA_Grant field set any other value, but F0x, 259 or 00x~07x. If the server declines the requested CGA, the client 260 MAY generate a new CGA with the recommended Sec value. If the 261 server replies with CGA-relevant parameters, the client MAY 262 generate a new CGA accordingly. 264 4. CGA Grant Option 266 DHCPv6 CGA Grant Option is used to indicate the DHCPv6 client whether 267 the requested address is granted or not. In the decline case, a 268 recommended Sec value MAY be sent, too. 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | OPTION_ADDR_GRANT | option-len | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | CGA Grant | 276 +-+-+-+-+-+-+-+-+ 278 option-code 280 OPTION_ADDR_GRANT (TBA1). 282 option-len 284 1. 286 CGA_Grant 288 In the DHCPv6 reply message, the CGA_Grant field sets F0x to 289 indicate that the requested CGA is granted; it sets 00x to 290 indicate that the requested Address is declined without any 291 recommended Sec value. It sets 01x~07x to indicate that 292 requested Address is declined and the recommended Sec value 293 (value from 1~7). 295 Note: On receiving the CGA Grant Option with reject information and a 296 recommended Sec value, the client MAY generate a new CGA with the 297 recommended Sec value. If choosing not use the recommended Sec value, 298 the client MAY take the risk that it is not able to use full network 299 capabilities. The network may consider the hosts that use CGAs with 300 lower Sec values as unsecure users and decline some or all network 301 services. 303 5. Security Considerations 305 The mechanisms based on DHCPv6 are all vulnerable to attacks to the 306 DHCP client. Proper use of DHCPv6 autoconfiguration facilities 307 [RFC3315], such as AUTH option or Secure DHCP 308 [I-D.ietf-dhc-secure-dhcpv6] can prevent these threats, provided that 309 a configuration token is known to both the client and the server. 311 IF a DHCPv6 server rejected a client CGA based on a certain Sec 312 value, it SHOULD NOT suggest a new Sec value either equal or lower 313 than the Sec value that has been rejected. 315 Note that, as expected, it is not possible to provide secure 316 configuration of CGA without a previous configuration of security 317 information at the client (either a trust anchor, or a DHCPv6 318 configuration token, etc.). However, considering that the values of 319 these elements could be shared by the hosts in the network segment, 320 these security elements can be configured more easily in the end 321 hosts than its addresses. 323 6. IANA Considerations 325 This document defines two new DHCPv6 [RFC3315] options, which must be 326 assigned Option Type values within the option numbering space for 327 DHCPv6 messages: 329 The DHCPv6 CGA Grant Option, OPTION_ADDR_GRANT (TBA1), described in 330 Section 4. 332 7. Acknowledgments 334 The authors would like to thank Marcelo Bagnulo Braun and Alberto 335 Garcia-Martinez for been involved in the early requirement 336 identification. Valuable comments from Bernie Volz, Ted Lemon, John 337 Jason Brzozowski, Dujuan Gu and other DHC WG members are appreciated. 339 8. References 341 8.1. Normative References 343 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 344 Requirement Levels", RFC2119, March 1997. 346 [RFC3315] R. Droms, Ed., "Dynamic Host Configure Protocol for IPv6", 347 RFC3315, July 2003. 349 [RFC3633] O. Troan and R. Droms, "IPv6 Prefix Options for Dynamic 350 Host Configuration Protocol (DHCP) version 6", RFC 3633, 351 December 2003. 353 [RFC3971] J. Arkko, J. Kempf, B. Zill and P. Nikander, "SEcure 354 Neighbor Discovery (SEND) ", RFC 3971, March 2005. 356 [RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972, 357 March 2005. 359 [RFC4861] T. Narten, et al., "Neighbor Discovery for IP version 6 360 (IPv6)", RFC 4861, September 2007. 362 [RFC4862] S. Thomson, T. Narten and T. Jinmei, "IPv6 Stateless 363 Address Autoconfiguration", RFC4862, September 2007. 365 [RFC4866] J. Arkko, C. Vogt and W. Haddad, "Enhanced Route 366 Optimization for Mobile IPv6", RFC4866, May 2007. 368 [RFC4982] M. Bagnulo, "Support for Multiple Hash Algorithms in 369 Cryptographically Generated Addresses (CGAs) ", RFC4982, 370 July 2007. 372 [RFC5533] E. Nordmark and M. Bagnulo, "Shim6: Level 3 Multihoming 373 Shim Protocol for IPv6" FRC 5533, June 2009. 375 8.2. Informative References 377 [I-D.ietf-dhc-secure-dhcpv6] 378 S. Jiang and S. Shen, "Secure DHCPv6 Using CGAs", draft- 379 ietf-dhc-secure-dhcpv6 (work in progress), Septerber, 2012. 381 Author's Addresses 383 Sheng Jiang 384 Huawei Technologies Co., Ltd 385 Q14 Huawei Campus, 156 BeiQi Road, 386 ZhongGuan Cun, Hai-Dian District, Beijing 100085 387 P.R. China 388 Email: jiangsheng@huawei.com 390 Sam(Zhongqi) Xia 391 Huawei Technologies Co., Ltd 392 Q14 Huawei Campus, 156 BeiQi Road, 393 ZhongGuan Cun, Hai-Dian District, Beijing 100085 394 P.R. China 395 Email: xiazhongqi@huawei.com