idnits 2.17.1 draft-jiang-dhc-cga-config-dhcpv6-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 (November 19, 2010) is 4907 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 30, 2011 November 19, 2010 6 Configuring Cryptographically Generated Addresses (CGA) using DHCPv6 7 draft-jiang-dhc-cga-config-dhcpv6-02.txt 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 30, 2011. 26 Copyright Notice 28 Copyright (c) 2010 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...........................3 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......................................7 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 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC2119 [RFC2119]. 108 3. CGA Configure Process Using DHCPv6 110 The CGA specifications [RFC3972] define the procedure to generate a 111 CGA. However, it assumes that hosts decide by itself or have been 112 preconfigured all CGA relevant parameters. In reality, the network 113 management MAY want to assign/enforcement some parameters to hosts; 114 the network management MAY also manage the use of CGAs. 116 Among the mechanisms in which configuration parameters could be 117 pushed to the end hosts and/or CGA related information sent back to a 118 central administration, we discuss the stateful configuration 119 mechanism based on DCHPv6 in this document. Other mechanisms may also 120 provide similar functions, but out of scope. 122 In this section, configuration CGA parameters and that a DHCPv6 123 server grants the CGA usage are described in details. 125 3.1. Configuration of the parameters required for the generation of CGA 127 Each CGA is associated with a CGA Parameters data structure, which is 128 formed by all input parameters [RFC3972] except for Sec value that is 129 embedded in the CGA. The CGA associated Parameters used to generate a 130 CGA includes: 132 - a Public Key, 134 - a Subnet Prefix, 136 - a 3-bit security parameter, Sec. Additionally, it should be noted 137 that the hash algorithm to be used in the generation of the CGA is 138 also defined by the Sec value [RFC4982], 140 - any Extension Fields that could be used. 142 - Note: the modifier and the Collision Count value in the CGA 143 Parameter data structure are generated during the CGA generation 144 process. They do NOT need to be configured. 146 In a DHCPv6 managed network, a host may initiate a request for the 147 relevant CGA configuration information needed to the DHCPv6 server. 148 The server responds with the configuration information for the host. 149 The Option Request Option, defined in Section 22.7 in [RFC3315], can 150 be used for host to indicate which options the client requests from 151 the server. For response, the requested Option should be included. 152 The server MAY also initiatively push these parameters by attaching 153 these option in the response messages which are initiated for other 154 purposes. 156 - The Public/Private key pair is generated by hosts themselves and 157 considered not suitable for network transmission for security 158 reasons. The configuration of the client key pair or certificate is 159 out of scope. 161 - Currently, there are convenient mechanisms for allowing an 162 administrator to configure the subnet prefix for a host, by Router 163 Advertisement [RFC4861, RFC4862]. However, this does not suitable 164 for the DHCP-managed network. To propagate the prefix through DHCP 165 interactions, DHCPv6 Prefix Delegation Option [RFC3633] MAY be 166 used. However, this option was designed to assign prefix block for 167 routers. A new Prefix Assignment Option MAY need to be defined. 168 Since alternative approach is existing and there are debates 169 whether a new Prefix Assignment Option MAY is necessary, this 170 document does not define it. 172 - Although the network management MAY want to enforce or configure 173 a Sec value to the hosts, it is considered as a very dangerous 174 action. A malicious fake server may send out a high Sec value to 175 attack clients giving the fact that generation a CGA with a high 176 Sec value is very computational intensive [I-D.ietf-csi-dhcpv6-cga- 177 ps]. Another risk is that a malicious server could propagate a Sec 178 value providing less protection than intended by the network 179 administrator, facilitating a brute force attack against the hash, 180 or the selection of the weakest hash algorithm available for CGA 181 definition. A recommendation Sec value is considered as confusion 182 information. The receiving host is lack for information to make 183 choose whether generates a CGA according to the recommendation or 184 not. Therefore, the document does not define a DHCPv6 option to 185 propagate the Sec value. 187 - Although there is an optional Extension Fields in CGA Parameter 188 data structure, there is NO any defined extension fields. If in the 189 future, new Extension Fields in CGA Parameter data structure are 190 defined, future specification may define correspondent DHCPv6 191 options to carry these parameters. 193 Upon reception of the CGA relevant parameters from DHCPv6 server, the 194 end hosts SHOULD generate addresses compliant with the received 195 parameters. If the parameters change, the end hosts SHOULD generate 196 new addresses compliant with the parameters propagated. 198 3.2. Host requests CGA Approved to the DHCPv6 server 200 A CGA address is generated by the associated key pair owner, normally 201 an end host. However, in a DHCPv6-managed network, hosts should use 202 IPv6 global addresses only from a DHCPv6 server. The process 203 described below allows a host, also DHCPv6 client, uses self- 204 generated CGAs in a DHCPv6-managed environment, by requesting the 205 granting from a DHCPv6 server. 207 The client sends a CGA, which is generated by itself, to a DHCPv6 208 server, and requests the DHCP server to determine whether the 209 generated CGA satisfies the requirements of the network 210 configuration, wherein the network configuration comprises a CGA 211 security level set by the DHCP; and generates a new CGA if the 212 generated CGA does not satisfy the requirements of the network 213 configuration. 215 Client initiation behavior 217 In details, a DHCPv6 client SHOULD send a DHCPv6 Request message to 218 initiate the CGA granting process. 220 This DHCPv6 Request message MUST include an Option Request option, 221 which requests the CGA Grant Option, defined in Section 4 in this 222 document, to indicate the DHCPv6 server responses with the address 223 granting decision. The CGA_Grant field in the embedded CGA Grant 224 Option should be set all 1 (FFx). 226 The client MUST include one or more IA Options, either IA_NA or IA 227 _TA, in the Request message. Each IA Option MUST include one or more 228 IA Address Options. CGAs are carried in the IA Address Options. 230 Server behavior 232 Upon reception of the Request message, the DHCPv6 server SHOULD 233 verify whether the client's CGAs satisfy the CGA-related 234 configuration parameters of the network. The DHCPv6 server SHOULD NOT 235 handle the Request which the CGA Grant field is not all 1(FFx). The 236 DHCPv6 server then send an acknowledgement, a Reply message, to the 237 client to either grant the use of the CGA or decline the requested 238 CGA. The CGA_Grant field SHOULD be set following the rule, defined in 239 Section 4 in this document. When the requested CGA is declined, the 240 DHCPv6 server MAY also recommend a Sec value to the client a using 241 the CGA Grant option. 243 In the meantime, the DHCPv6 server MAY log the requested CGA 244 addresses. This information MAY later be used by other network 245 functions, such as ACL. 247 Client receiving behavior 249 Upon reception of the acknowledgement from server, the client can 250 legally use the granted CGAs. The client SHOULD silently drop any 251 message that has the CGA Grant field set any other value, but F0x, 252 00x~07x. If the server declines the requested CGA, the client MUST 253 generate a new CGA. If the server replies with CGA-relevant 254 parameters, the client MAY generate a new CGA accordingly. 256 4. CGA Grant Option 258 DHCPv6 CGA Grant Option is used to indicate the DHCPv6 client whether 259 the requested address is granted or not. In the decline case, a 260 recommended Sec value MAY be sent, too. 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | OPTION_ADDR_GRANT | option-len | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | CGA Grant | 268 +-+-+-+-+-+-+-+-+ 270 option-code 272 OPTION_ADDR_GRANT (TBA1). 274 option-len 276 1. 278 CGA Grant 280 The CGA_Grant field sets all 1 (FFx) when a client requests 281 granting from server. It sets F0x to indicate that the 282 requested CGA is granted; it sets 00x to indicate that the 283 requested Address is declined without any recommended Sec 284 value. It sets 01x~07x to indicate that requested Address is 285 declined and the recommended Sec value (value from 1~7). 287 Note: On receiving the CGA Grant Option with reject information and 288 recommended Sec value, the client MAY generate a new CGA with the 289 recommended Sec value. If choosing not use the recommended Sec 290 value, the client MAY take the risk that it is not able to use full 291 network capabilities. 293 5. Security Considerations 295 The mechanisms based on DHCPv6 are all vulnerable to attacks to the 296 DHCP client. Proper use of DHCPv6 autoconfiguration facilities 297 [RFC3315], such as AUTH option or Secure DHCP [I-D.ietf-dhc-secure- 298 dhcpv6] can prevent these threats, provided that a configuration 299 token is known to both the client and the server. 301 Note that, as expected, it is not possible to provide secure 302 configuration of CGA without a previous configuration of security 303 information at the client (either a trust anchor, a DHCPv6 304 configuration token...). However, considering that the values of 305 these elements could be shared by the hosts in the network segment, 306 these security elements can be configured more easily in the end 307 hosts than its addresses. 309 6. IANA Considerations 311 This document defines two new DHCPv6 [RFC3315] options, which must be 312 assigned Option Type values within the option numbering space for 313 DHCPv6 messages: 315 The DHCPv6 CGA Grant Option (TBA1), described in Section 4. 317 7. Acknowledgments 319 The authors would like to thank Marcelo Bagnulo Braun and Alberto 320 Garcia-Martinez from Universidad Carlos III de Madrid for been 321 involved in the early requirement identification. Valuable comments 322 from Bernie Volz, Ted Lemon, John Jason Brzozowski and Dujuan Gu, 323 Huawei are appreciated. 325 8. Change Log [RFC Editor please remove] 327 draft-jiang-dhc-cga-config-dhcpv6-02, remove Sec option according to 328 IETF 79 discussion, 2010-11-19. 330 draft-jiang-dhc-cga-config-dhcpv6-01, remove CGA generation 331 delegation according to IETF 77 and mail list discussion, 2010-08-24. 333 draft-jiang-dhc-cga-config-dhcpv6-00, original version, 2010-02-03. 335 9. References 337 9.1. Normative References 339 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 340 Requirement Levels", RFC2119, March 1997. 342 [RFC3315] R. Droms, Ed., "Dynamic Host Configure Protocol for IPv6", 343 RFC3315, July 2003. 345 [RFC3633] O. Troan and R. Droms, "IPv6 Prefix Options for Dynamic 346 Host Configuration Protocol (DHCP) version 6", RFC 3633, 347 December 2003. 349 [RFC3971] J. Arkko, J. Kempf, B. Zill and P. Nikander, "SEcure 350 Neighbor Discovery (SEND) ", RFC 3971, March 2005. 352 [RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972, 353 March 2005. 355 [RFC4861] T. Narten, et al., "Neighbor Discovery for IP version 6 356 (IPv6)", RFC 4861, September 2007. 358 [RFC4862] S. Thomson, T. Narten and T. Jinmei, "IPv6 Stateless 359 Address Autoconfiguration", RFC4862, September 2007. 361 [RFC4866] J. Arkko, C. Vogt and W. Haddad, "Enhanced Route 362 Optimization for Mobile IPv6", RFC4866, May 2007. 364 [RFC4982] M. Bagnulo, "Support for Multiple Hash Algorithms in 365 Cryptographically Generated Addresses (CGAs) ", RFC4982, 366 July 2007. 368 [RFC5533] E. Nordmark and M. Bagnulo, "Shim6: Level 3 Multihoming 369 Shim Protocol for IPv6" FRC 5533, June 2009. 371 9.2. Informative References 373 [I-D.ietf-csi-dhcpv6-cga-ps] 374 S. Jiang, S. Shen and T. Chown, "DHCPv6 and CGA 375 Interaction: Problem Statement", draft-ietf-csi-dhcpv6-cga- 376 ps (work in progress), October, 2010. 378 [I-D.ietf-dhc-secure-dhcpv6] 379 S. Jiang and S. Shen, "Secure DHCPv6 Using CGAs", draft- 380 ietf-dhc-secure-dhcpv6 (work in progress), June 2010. 382 Author's Addresses 384 Sheng Jiang 385 Huawei Technologies Co., Ltd 386 Huawei Building, No.3 Xinxi Rd., 387 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 388 P.R. China 389 Email: shengjiang@huawei.com 391 Sam(Zhongqi) Xia 392 Huawei Technologies Co., Ltd 393 Huawei Building, No.3 Xinxi Rd., 394 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 395 P.R. China 396 Email: xiazhongqi@huawei.com