idnits 2.17.1 draft-ietf-dhc-cga-config-dhcpv6-03.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 (October 10, 2012) is 4215 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: April 11, 2013 October 10, 2012 6 Configuring Cryptographically Generated Addresses (CGA) using DHCPv6 7 draft-ietf-dhc-cga-config-dhcpv6-03 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 April 11, 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 defines the process using DHCPv6 to 47 manage CGAs in detail. A new DHCPv6 option is defined accordingly. 48 This document also analyses the configuration of the parameters, 49 which are used to generate CGAs, using DHCPv6. Although the document 50 does not define new DHCPv6 option to carry these parameters for 51 various reasons, the configuration procedure is described. 53 Table of Contents 55 1. Introduction ................................................ 3 56 2. Terminology ................................................. 3 57 3. CGA Configure Process Using DHCPv6 .......................... 4 58 3.1. Configuration of the parameters required for the generation 59 of CGA ...................................................... 4 60 3.2. Host requests CGA Approved to the DHCPv6 server ........ 5 61 4. CGA Grant Option ............................................ 7 62 5. Security Considerations ..................................... 8 63 6. IANA Considerations ......................................... 8 64 7. Acknowledgments ............................................. 8 65 8. References .................................................. 8 66 8.1. Normative References ................................... 8 67 8.2. Informative References ................................. 9 68 Author's Addresses ............................................ 10 70 1. Introduction 72 Cryptographically Generated Addresses (CGA, [RFC3972]) provide means 73 to verify the ownership of IPv6 addresses without requiring any 74 security infrastructure such as a certification authority. 76 CGAs were originally designed for SeND [RFC3971] and SeND is 77 generally not used in the same environment as a Dynamic Host 78 Configure Protocol for IPv6 (DHCPv6) [RFC3315] server. However, after 79 CGA has been defined, as an independent security property, many other 80 CGA usages have been proposed and defined, such as Site Multihoming 81 by IPv6 Intermediation (SHIM6) [RFC5533], Enhanced Route Optimization 82 for Mobile IPv6 [RFC4866], also using the CGA for DHCP security 83 purpose [I-D.ietf-dhc-secure-dhcpv6], etc. The use of CGAs allows 84 identity verification in different protocols. In these scenarios, 85 CGAs may be used in DHCPv6-managed networks. 87 As [I-D.ietf-csi-dhcpv6-cga-ps] analyses, in the current 88 specifications, there is a lack of procedures to enable proper 89 management of the usage of CGAs. Particularly, in a DHCPv6-managed 90 network, a new DHCPv6 option is missed, therefore, the DHCPv6 server 91 can NOT grant the use of host-generated CGA addresses on request from 92 the client, or reject the CGA on the basis of a too-low sec value. In 93 order to fill this gap, a new DHCPv6 option, CGA Grant Option, is 94 defined in this document. 96 This document also analyses the configuration of the parameters, 97 which are used to generate CGAs, using DHCPv6. Although the document 98 does not define new DHCPv6 option to carry these parameters for 99 various reasons, the configuration procedure is described. The 100 procedure works with existing options or future define options. 102 The CGA configuration procedure described in this document can work 103 with a generic address registration mechanism, which discussed in 104 IETF DHC Working Group, but have not been defined yet. However, even 105 a generic address registration mechanism was defined, the CGA- 106 specific option, CGA Grant Option, is still needed so that DHCP 107 server can indicate hosts the recommended CGA Sec value. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC2119 [RFC2119]. 115 3. CGA Configure Process Using DHCPv6 117 The CGA specifications [RFC3972] define the procedure to generate a 118 CGA. However, it assumes that hosts decide by itself or have been 119 preconfigured all CGA relevant parameters. In reality, the network 120 management MAY want to assign/enforcement some parameters to hosts; 121 the network management MAY also manage the use of CGAs. 123 Among the mechanisms in which configuration parameters could be 124 pushed to the end hosts and/or CGA related information sent back to a 125 central administration, we discuss the stateful configuration 126 mechanism based on DCHPv6 in this document. Other mechanisms may also 127 provide similar functions, but out of scope. 129 In this section, configuration CGA parameters and that a DHCPv6 130 server grants the CGA usage are described in details. 132 3.1. Configuration of the parameters required for the generation of CGA 134 Each CGA is associated with a CGA Parameters data structure, which is 135 formed by all input parameters [RFC3972] except for Sec value that is 136 embedded in the CGA. The CGA associated Parameters used to generate a 137 CGA includes: 139 - a Public Key, 141 - a Subnet Prefix, 143 - a 3-bit security parameter, Sec. Additionally, it should be noted 144 that the hash algorithm to be used in the generation of the CGA is 145 also defined by the Sec value [RFC4982], 147 - any Extension Fields that could be used. 149 - Note: the modifier and the Collision Count value in the CGA 150 Parameter data structure are generated during the CGA generation 151 process. They do NOT need to be configured. 153 In a DHCPv6 managed network, a host may initiate a request for the 154 relevant CGA configuration information needed to the DHCPv6 server. 155 The server responds with the configuration information for the host. 156 The Option Request Option, defined in Section 22.7 in [RFC3315], can 157 be used for host to indicate which options the client requests from 158 the server. For response, the requested Option should be included. 159 The server MAY also initiatively push these parameters by attaching 160 these option in the response messages which are initiated for other 161 purposes. 163 - The Public/Private key pair is generated by hosts themselves and 164 considered not suitable for network transmission for security 165 reasons. The configuration of the client key pair or certificate is 166 out of scope. 168 - Currently, there are convenient mechanisms for allowing an 169 administrator to configure the subnet prefix for a host, by Router 170 Advertisement [RFC4861, RFC4862]. However, this does not suitable 171 for the DHCP-managed network. To propagate the prefix through DHCP 172 interactions, DHCPv6 Prefix Delegation Option [RFC3633] MAY be 173 used. However, this option was designed to assign prefix block for 174 routers. A new Prefix Assignment Option MAY need to be defined. 175 Since alternative approach is existing and there are debates 176 whether a new Prefix Assignment Option MAY is necessary, this 177 document does not define it. 179 - Although the network management MAY want to enforce or configure 180 a Sec value to the hosts, it is considered as a very dangerous 181 action. A malicious fake server may send out a high Sec value to 182 attack clients giving the fact that generation a CGA with a high 183 Sec value is very computational intensive 184 [I-D.ietf-csi-dhcpv6-cga-ps]. Another risk is that a malicious 185 server could propagate a Sec value providing less protection than 186 intended by the network administrator, facilitating a brute force 187 attack against the hash, or the selection of the weakest hash 188 algorithm available for CGA definition. A recommendation Sec value 189 is considered as confusion information. The receiving host is lack 190 for information to make choose whether generates a CGA according to 191 the recommendation or not. Therefore, the document does not define 192 a DHCPv6 option to propagate the Sec value. 194 - Although there is an optional Extension Fields in CGA Parameter 195 data structure, there is NO any defined extension fields. If in the 196 future, new Extension Fields in CGA Parameter data structure are 197 defined, future specification may define correspondent DHCPv6 198 options to carry these parameters. 200 Upon reception of the CGA relevant parameters from DHCPv6 server, the 201 end hosts SHOULD generate addresses compliant with the received 202 parameters. If the parameters change, the end hosts SHOULD generate 203 new addresses compliant with the parameters propagated. 205 3.2. Host requests CGA Approved to the DHCPv6 server 207 A CGA address is generated by the associated key pair owner, normally 208 an end host. However, in a DHCPv6-managed network, hosts should use 209 IPv6 global addresses only from a DHCPv6 server. The process 210 described below allows a host, also DHCPv6 client, uses self- 211 generated CGAs in a DHCPv6-managed environment, by requesting the 212 granting from a DHCPv6 server. 214 The client sends a CGA, which is generated by itself, to a DHCPv6 215 server, and requests the DHCP server to determine whether the 216 generated CGA satisfies the requirements of the network 217 configuration, wherein the network configuration comprises a CGA 218 security level set by the DHCP; and generates a new CGA if the 219 generated CGA does not satisfy the requirements of the network 220 configuration. 222 Client initiation behavior 224 In details, a DHCPv6 client SHOULD send a DHCPv6 Request message to 225 initiate the CGA granting process. 227 This DHCPv6 Request message MUST include an Option Request option, 228 which requests the CGA Grant Option, defined in Section 4 in this 229 document, to indicate the DHCPv6 server responses with the address 230 granting decision. 232 The client MUST include one or more IA Options, either IA_NA or 233 IA_TA, in the Request message. Each IA Option MUST includes one or 234 more IA Address Options. CGAs are carried in the IA Address Options. 236 Server behavior 238 Upon reception of the Request message, the DHCPv6 server SHOULD 239 verify whether the client's CGAs satisfy the CGA-related 240 configuration parameters of the network. The DHCPv6 server SHOULD NOT 241 handle the Request which the CGA_Grant field is not all 1(FFx). The 242 DHCPv6 server then send an acknowledgement, a Reply message, to the 243 client to either grant the use of the CGA or decline the requested 244 CGA. The CGA_Grant field SHOULD be set following the rule, defined in 245 Section 4 in this document. When the requested CGA is declined, the 246 DHCPv6 server MAY also recommend a Sec value to the client using the 247 CGA Grant option in the DHCPv6 Reply message. 249 In the meantime, the DHCPv6 server MAY log the requested CGA 250 addresses. This information MAY later be used by other network 251 functions, such as ACL. 253 Client receiving behavior 255 Upon reception of the acknowledgement from server, the client can 256 legally use the granted CGAs. The client SHOULD silently drop any 257 message that has the CGA_Grant field set any other value, but F0x, or 258 00x~07x. If the server declines the requested CGA, the client MAY 259 generate a new CGA with the recommended Sec value. If the server 260 replies with CGA-relevant parameters, the client MAY generate a new 261 CGA accordingly. 263 4. CGA Grant Option 265 DHCPv6 CGA Grant Option is used to indicate the DHCPv6 client whether 266 the requested address is granted or not. In the decline case, a 267 recommended Sec value MAY be sent, too. 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | OPTION_ADDR_GRANT | option-len | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | CGA Grant | 275 +-+-+-+-+-+-+-+-+ 277 option-code 279 OPTION_ADDR_GRANT (TBA1). 281 option-len 283 1. 285 CGA_Grant 287 The CGA_Grant field sets all 1 (FFx) when a client requests 288 granting from server in the DHCPv6 Request message. 290 In the DHCPv6 reply message, the CGA_Grant field sets F0x to 291 indicate that the requested CGA is granted; it sets 00x to 292 indicate that the requested Address is declined without any 293 recommended Sec value. It sets 01x~07x to indicate that 294 requested Address is declined and the recommended Sec value 295 (value from 1~7). 297 Note: On receiving the CGA Grant Option with reject information and a 298 recommended Sec value, the client MAY generate a new CGA with the 299 recommended Sec value. . If choosing not use the recommended Sec 300 value, the client MAY take the risk that it is not able to use full 301 network capabilities. The network may consider the hosts that use 302 CGAs with lower Sec values as unsecure users and decline some or all 303 network services. 305 5. Security Considerations 307 The mechanisms based on DHCPv6 are all vulnerable to attacks to the 308 DHCP client. Proper use of DHCPv6 autoconfiguration facilities 309 [RFC3315], such as AUTH option or Secure DHCP 310 [I-D.ietf-dhc-secure-dhcpv6] can prevent these threats, provided that 311 a configuration token is known to both the client and the server. 313 IF a DHCPv6 server rejected a client CGA based on a certain Sec 314 value, it SHOULD NOT suggest a new Sec value either equal or lower 315 than the Sec value that has been rejected. 317 Note that, as expected, it is not possible to provide secure 318 configuration of CGA without a previous configuration of security 319 information at the client (either a trust anchor, or a DHCPv6 320 configuration token, etc.). However, considering that the values of 321 these elements could be shared by the hosts in the network segment, 322 these security elements can be configured more easily in the end 323 hosts than its addresses. 325 6. IANA Considerations 327 This document defines two new DHCPv6 [RFC3315] options, which must be 328 assigned Option Type values within the option numbering space for 329 DHCPv6 messages: 331 The DHCPv6 CGA Grant Option, OPTION_ADDR_GRANT (TBA1), described in 332 Section 4. 334 7. Acknowledgments 336 The authors would like to thank Marcelo Bagnulo Braun and Alberto 337 Garcia-Martinez for been involved in the early requirement 338 identification. Valuable comments from Bernie Volz, Ted Lemon, John 339 Jason Brzozowski, Dujuan Gu and other DHC WG members are appreciated. 341 8. References 343 8.1. Normative References 345 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 346 Requirement Levels", RFC2119, March 1997. 348 [RFC3315] R. Droms, Ed., "Dynamic Host Configure Protocol for IPv6", 349 RFC3315, July 2003. 351 [RFC3633] O. Troan and R. Droms, "IPv6 Prefix Options for Dynamic 352 Host Configuration Protocol (DHCP) version 6", RFC 3633, 353 December 2003. 355 [RFC3971] J. Arkko, J. Kempf, B. Zill and P. Nikander, "SEcure 356 Neighbor Discovery (SEND) ", RFC 3971, March 2005. 358 [RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972, 359 March 2005. 361 [RFC4861] T. Narten, et al., "Neighbor Discovery for IP version 6 362 (IPv6)", RFC 4861, September 2007. 364 [RFC4862] S. Thomson, T. Narten and T. Jinmei, "IPv6 Stateless 365 Address Autoconfiguration", RFC4862, September 2007. 367 [RFC4866] J. Arkko, C. Vogt and W. Haddad, "Enhanced Route 368 Optimization for Mobile IPv6", RFC4866, May 2007. 370 [RFC4982] M. Bagnulo, "Support for Multiple Hash Algorithms in 371 Cryptographically Generated Addresses (CGAs) ", RFC4982, 372 July 2007. 374 [RFC5533] E. Nordmark and M. Bagnulo, "Shim6: Level 3 Multihoming 375 Shim Protocol for IPv6" FRC 5533, June 2009. 377 8.2. Informative References 379 [I-D.ietf-csi-dhcpv6-cga-ps] 380 S. Jiang, S. Shen and T. Chown, "DHCPv6 and CGA 381 Interaction: Problem Statement", draft-ietf-csi-dhcpv6-cga- 382 ps (work in progress), February, 2012. 384 [I-D.ietf-dhc-secure-dhcpv6] 385 S. Jiang and S. Shen, "Secure DHCPv6 Using CGAs", draft- 386 ietf-dhc-secure-dhcpv6 (work in progress), Septerber, 2012. 388 Author's Addresses 390 Sheng Jiang 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: jiangsheng@huawei.com 397 Sam(Zhongqi) Xia 398 Huawei Technologies Co., Ltd 399 Q14 Huawei Campus, 156 BeiQi Road, 400 ZhongGuan Cun, Hai-Dian District, Beijing 100085 401 P.R. China 402 Email: xiazhongqi@huawei.com