idnits 2.17.1 draft-ietf-dhc-secure-dhcpv6-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 3 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 (April 12, 2010) is 5128 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) == Unused Reference: 'I-D.draft-jiang-dhc-cga-config-dhcpv6' is defined on line 628, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DHC Working Group Sheng Jiang 2 Internet Draft Huawei Technologies Co., Ltd 3 Intended status: Standards Track Sean Shen 4 Expires: October 12, 2010 CNNIC 5 April 12, 2010 7 Secure DHCPv6 Using CGAs 8 draft-ietf-dhc-secure-dhcpv6-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on October 12, 2010. 32 Copyright Notice 34 Copyright (c) 2010 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents carefully, 41 as they describe your rights and restrictions with respect to this 42 document. Code Components extracted from this document must include 43 Simplified BSD License text as described in Section 4.e of the Trust 44 Legal Provisions and are provided without warranty as described in 45 the BSD License. 47 Abstract 49 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables 50 DHCP servers to pass configuration parameters. It offers 51 configuration flexibility. If not secured, DHCPv6 is vulnerable to 52 various attacks, particularly fake attack. This document analyzes the 53 security issues of DHCPv6 and specifies security mechanisms, mainly 54 using CGAs. 56 Table of Contents 58 1. Introduction.................................................3 59 2. Terminology..................................................3 60 3. Security Overview of DHCPv6..................................3 61 4. Secure DHCPv6 Overview.......................................4 62 4.1. New Components..........................................5 63 4.2. Support for algorithm agility...........................6 64 5. Extension for Secure DHCPv6..................................6 65 5.1. CGA Parameter Option....................................6 66 5.2. Signature Option........................................7 67 5.3. DUID-SA Type............................................9 68 6. Processing Rules and Behaviors..............................10 69 6.1. Processing Rules of Sender.............................10 70 6.2. Processing Rules of Receiver...........................10 71 6.3. Processing Rules of Relay Agent........................11 72 7. Security Considerations.....................................12 73 8. IANA Considerations.........................................12 74 9. Acknowledgments.............................................13 75 10. References.................................................13 76 10.1. Normative References..................................13 77 10.2. Informative References................................13 78 Author's Addresses.............................................15 80 1. Introduction 82 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6 [RFC3315]) 83 enables DHCP servers to pass configuration parameters. It offers 84 configuration flexibility. If not secured, DHCPv6 is vulnerable to 85 various attacks, particularly fake attack. 87 The requirements of using CGA to secure DHCPv6 have been introduced 88 in [I-D.draft-ietf-csi-dhcpv6-cga-ps]. This document analyzes the 89 security issues of DHCPv6 in more details. This document is aiming to 90 provide mechanisms for improving the security of DHCPv6, thus the 91 address of a DHCP message sender, which can be a DHCP server, a reply 92 agent or a client, is able to be verified by a receiver. It improves 93 communication security of DHCPv6 interaction. The security mechanisms 94 specified in this document is mainly based on the Cryptographically 95 Generated Addresses (CGA [RFC3972]). 97 Secure DHCPv6 is applicable in environments where physical security 98 on the link is not assured (such as over wireless) or where available 99 security mechanisms are not sufficient, and attacks on DHCPv6 are a 100 concern. 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]. 108 3. Security Overview of DHCPv6 110 DHCPv6 is a client/server protocol that provides managed and stateful 111 configuration of devices. It enables DHCPv6 server to auto-configure 112 relevant network parameters on clients through the DHCPv6 message 113 exchanging mechanisms. In the basic DHCPv6 specifications [RFC3315], 114 security of DHCPv6 message can be improved in a few aspects. 116 In the basic DHCPv6 specifications, regular IPv6 addresses are used. 117 It is possible for a malicious attacker to use a fake address to 118 spoof or launch an attack. 120 "One attack specific to a DHCP client is the establishment of a 121 malicious server with the intent of providing incorrect configuration 122 information to the client. The motivation for doing so may be to 123 mount a 'man in the middle' attack that causes the client to 124 communicate with a malicious server instead of a valid server for 125 some service such as DNS or NTP. The malicious server may also mount 126 a denial of service attack through mis-configuration of the client 127 that causes all network communication from the client to fail." 128 [RFC3315] 130 "A DHCP client may also be subject to attack through the receipt of a 131 Reconfigure message from a malicious server that causes the client to 132 obtain incorrect configuration information from that server." 133 [RFC3315] 135 Fake servers can also provide clients with partially correct 136 information that allows the attacker to route traffic through certain 137 host where critical information can be collected. This becomes 138 important to detect and prevent when encrypted traffic is allowed to 139 pass through firewalls. Clients can be configured with bogus data, so 140 that they will assume that the network is down. 142 Once servers start updating DNS and other directory services, 143 attackers may spoof DHCP servers to register incorrect information in 144 those services. 146 Another possible attack is that attackers may be able to gain 147 unauthorized access to some resources, such as network access. 149 The basic DHCPv6 specifications achieve message origin authentication 150 and message integrity via an authentication option with a symmetric 151 key pair. For the key of the hash function, there are two key 152 management mechanisms. Firstly, the key management is out of band, 153 usually manual, i.e. operators set up key database for both server 154 and client before running DHCPv6. Usually multiple keys are deployed 155 once a time and key id is used to specify which key is used. Secondly, 156 a DHCPv6 server sends a reconfigure key to the client in the initial 157 exchange of DHCPv6 messages for future use, in this case security is 158 not guaranteed because this key is transmitted in plaintext. In 159 either way, the security of key itself is in question mark. 161 Communication between a server and a relay agent, and communication 162 between relay agents, can be secured through the use of IPSec, as 163 described in section 21.1 in [RFC3315]. However, IPSec is quite 164 complicated. A simpler security mechanism may have better deploy 165 ability. Furthermore, the manual configuration and static keys are 166 potential issue makers. Relay agents MAY require other security 167 mechanisms besides IPSec. 169 4. Secure DHCPv6 Overview 171 To solve the abovementioned security issues, we introduce CGAs into 172 DHCPv6. CGAs are introduced in [RFC3972]. "CGAs are IPv6 addresses 173 for which the interface identifier is generated by computing a 174 cryptographic one-way hash function from a public key and auxiliary 175 parameters. The binding between the public key and the address can be 176 verified by re-computing the hash value and by comparing the hash 177 with the interface identifier. Messages sent from an IPv6 address can 178 be protected by attaching the public key and auxiliary parameters and 179 by signing the message with the corresponding private key. The 180 protection works without a certification authority or any security 181 infrastructure." 183 In this document, a CGA option with an address ownership proof 184 mechanism and a signature option with a corresponding verification 185 mechanism are introduced. With them, the receiver of a DHCP message 186 can verify the sender address of the DHCP message, which improves 187 communication security of DHCP messages. By using the signature 188 option, the verification of data integrity and replay protections can 189 also be achieved without the authentication option. 191 This documentation focuses on using CGAs to secure the DHCPv6 192 protocol. It assumes the sender, which uses CGAs, has self-generated 193 or been configured CGAs. The CGA configuration in the DHCPv6 network 194 is out of scope and specified in [I-D.draft-jiang-dhc-cga-config- 195 dhcpv6]. 197 In the relay scenarios, because relay agent restructures the DHCPv6 198 messages, a receiver would not find the sender's source CGA address 199 in the DHCPv6 message header. In the client-relay-server scenarios, 200 "the relay agent copies the source address from the header of the IP 201 datagram in which the message was received to the peer-address field 202 of the Relay-forward message" [RFC3315]. The receiver, a DHCPv6 203 server, can find the sender's source CGA address in the peer-address 204 field for CGA verification. In the server-relay-client scenarios, a 205 DHCP server knows a client is behind relay(s) if it receives a Relay- 206 forward DHCPv6 message. Then it will reply a Relay-reply message with 207 the server's source CGA address being carried in the server DUID, 208 which is in the payload. In this way, the receiver, a DHCPv6 client 209 can get the server's source CGA address for CGA verification. The 210 server DUID is also protected by CGA. 212 4.1. New Components 214 The components of the solution specified in this document are as 215 follows: 217 - CGAs are used to make sure that the sender of a DHCPv6 message 218 is the "owner" of the claimed address. A public-private key 219 pair has been generated by a node itself or configured before 220 it can claim an address. A new DHCPv6 option, the CGA Parameter 221 Option, is used to carry the public key and associated 222 parameters. 224 - Public key signatures protect the integrity of the messages and 225 authenticate the identity of their sender. The authority of a 226 public key is established either with the authorization 227 delegation process, by using certificates, or through the 228 address ownership proof mechanism, by using CGAs, or with both. 230 - Server Address type of DUID is used to carry server's source 231 address in the relay scenarios. The receiver gets the server's 232 source CGA address for CGA verification. 234 4.2. Support for algorithm agility 236 Hash functions are the fundamental of security mechanisms, including 237 CGAs in this document. "...they have two security properties: to be 238 one way and collision free." "The recent attacks have demonstrated 239 that one of those security properties is not true." [RFC4270] 241 Following the approach recommended by [RFC4270] and [NewHash], our 242 analysis shows none of these attacks are currently doable. However, 243 these attacks indicate the possibility of future real-world attacks. 244 Therefore, we have to take into account that future attacks will be 245 improved and provide a support for multiple hash algorithms. Our 246 mechanisms, in this document, support not only hash algorithm agility 247 but also signature algorithm agility. 249 The support for hash agility within CGAs has been defined in 250 [RFC4982]. The usage of CGAs in this document SHOULD also obey 251 [RFC4982], too. 253 5. Extension for Secure DHCPv6 255 This section extends DHCPv6. Two new options and a new DUID type have 256 been defined. The new options MUST be supported, if the node has been 257 configured to use Secure DHCPv6. The new DUID type MUST be supported 258 in the relay scenarios. 260 5.1. CGA Parameter Option 262 The CGA option allows the verification of the sender's CGAs. The 263 format of the CGA option is described as follows: 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | OPTION_CGA_PARAMETER | option-len | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | | 271 . . 272 . CGA Parameters (variable length) . 273 . . 274 | | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 option-code OPTION_CGA_PARAMETER (TBA1). 278 option-len Length of CGA Parameters in octets. 280 CGA Parameters A variable-length field containing the CGA 281 Parameters data structure described in Section 4 282 of [RFC3972]. This specification requires that 283 the public key found from the CGA Parameters 284 field in the CGA option MUST be that referred by 285 the Key Hash field in the Signature option. 286 Packets received with two different keys MUST be 287 silently discarded. Note that a future extension 288 MAY provide a mechanism allowing the owner of an 289 address and the signer to be different parties. 291 5.2. Signature Option 293 The Signature option allows public key-based signatures to be 294 attached to a DHCPv6 message. The Signature option COULD be any place 295 within the DHCPv6 message. It protects all the DHCPv6 header and 296 options before it. Any options after the Signature option can be 297 processed, but it should be noticed that they are not protected by 298 this Signature option. The format of the Signature option is 299 described as follows: 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | OPTION_SIGNATURE | option-len | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | HA-id | SA-id | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | HA-id-KH | Reserved | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Timestamp (64-bit) | 311 | | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | | 314 | Key Hash (128-bit) | 315 | | 316 | | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | | 319 . Signature (variable length) . 320 . . 321 . . 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 option-code OPTION_SIGNATURE (TBA2). 326 option-len 32 + Length of signature field in octets. 328 HA-id Hash Algorithm id. The hash algorithm is used 329 for computing the signature result. RSA 330 signature [RSA] with SHA-1 [sha-1] is adopted. 331 In order to provide hash algorithm agility, SHA- 332 1 is assigned an initial value 0x0000 in this 333 document. 335 SA-id Signature Algorithm id. The signature algorithm 336 is used for computing the signature result. RSA 337 signature with RSASSA-PKCS1-v1_5 algorithm is 338 adopted. In order to provide algorithm agility, 339 RSASSA_PKCS1-v1_5 is assigned an initial value 340 0x0000 in this document. 342 HA-id-KH Hash Algorithm id for Key Hash. Hash algorithm 343 used for producing the Key Hash field in the 344 Signature option. SHA-1 is adopted. In order to 345 provide hash algorithm agility, SHA-1 is 346 assigned an initial value 0x0000 in this 347 document. 349 Reserved A 16-bit field reserved for future use. The 350 value MUST be initialized to zero by the sender, 351 and MUST be ignored by the receiver. 353 Timestamp The current time of day (NTP-format timestamp 354 [RFC1305], a 64-bit unsigned fixed-point number, 355 in seconds relative to 0h on 1 January 1900.). 356 It can reduce the danger of replay attacks. 358 Key Hash A 128-bit field containing the most significant 359 (leftmost) 128 bits of a SHA-1 hash of the 360 public key used for constructing the signature. 361 The SHA-1 hash is taken over the presentation 362 used in the Public Key field of the CGA 363 Parameters data structure carried in the CGA 364 option. Its purpose is to associate the 365 signature to a particular key known by the 366 receiver. Such a key can either be stored in the 367 certificate cache of the receiver or be received 368 in the CGA option in the same message. 370 Signature A variable-length field containing a digital 371 signature. The signature value is computed with 372 the hash algorithm and the signature algorithm, 373 as described in HA-id and SA-id. The signature 374 constructed by using the sender's private key 375 over the following sequence of octets: 377 1. The 128-bit CGA Message Type tag value for 378 Secure DHCPv6, 0x81be a1eb 0021 ce7e caa9 4090 379 0665 d2e0 02c2. (The tag value has been 380 generated randomly by the editor of this 381 specification.). 383 2. The 128-bit Source IPv6 Address. 385 3. The 128-bit Destination IPv6 Address. 387 4. The DHCPv6 message header. 389 5. All DHCPv6 options except for the Signature 390 option and the Authentication Option. 392 6. The content between the option-len field and 393 the signature field in this Signature option, in 394 the format described above. 396 5.3. DUID-SA Type 398 Server Address Type DUID (DUID-SA) allows IP address of DHCPv6 399 servers can be carried in DHCPv6 message payload. 401 The following diagram illustrates the format of a DUID-SA: 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | TBA3 | Reserved | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | | 408 | Server Address (128-bit) | 409 | | 410 | | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 Type-code DUID-SA Type (TBA3) 415 Reserved A 16-bit field reserved for future use. The 416 value MUST be initialized to zero by the sender, 417 and MUST be ignored by the receiver. 419 Server Address The 128-bit IPv6 address of the DHCPv6 server. 421 In the secure DHCPv6 solution, the Server Address field of DUID-SA, 422 which is the IPv6 address of the DHCPv6 server, MUST be a CGA. 424 In the secure DHCPv6 solution, all the payloads, including DUID-SA, 425 are protected by signature option by the definition of section 5.1 426 and 5.2. 428 6. Processing Rules and Behaviors 430 6.1. Processing Rules of Sender 432 A DHCPv6 node, which could be a server, relay agent or client, can be 433 configured to send Secure DHCPv6 messages only if CGAs have been 434 configured on it. 436 The node MUST record the following configuration information: 438 CGA parameters Any information required to construct CGAs, as 439 described in [RFC3972]. 441 Keypair A public-private key pair. The public key used 442 for constructing the signature MUST be the same 443 in CGA parameters. 445 CGA flag A flag that indicates whether CGA is used or not. 447 If a node has been configured to use Secure DHCPv6, the node MUST 448 send a message using a CGA, which be constructed as specified in 449 Section 4 of [RFC3972], as the source address unless they are sent 450 with the unspecified source address. In the message, both the CGA 451 option and the Signature option MUST be present in all DHCPv6 452 messages. The CGA Parameter field in the CGA option is filled 453 according to the rules presented above and in [RFC3972]. The public 454 key in the field is taken from the configuration used to generate the 455 CGA, typically from a data structure associated with the source 456 address. The Signature option MUST be constructed as explained in 457 Section 5.2 and be the last DHCPv6 option. 459 In relay scenario, a DHCPv6 server MUST include an OPTION_SERVERID 460 [RFC3315] in Relay-reply message and put its CGA in the Server 461 Address field of the DUID in the OPTION_SERVERID. The CGA of DHCPv6 462 server will not lose during relaying so that the client can verify 463 CGA address and signature. 465 6.2. Processing Rules of Receiver 467 The node that supports the verification of the Secure DHCPv6 messages 468 MUST record the following configuration information: 470 Minbits The minimum acceptable key length for public 471 keys used in the generation of CGAs. The default 472 SHOULD be 1024 bits. Implementations MAY also 473 set an upper limit for the amount of computation 474 needed when verifying packets that use these 475 security associations. Any implementation SHOULD 476 follow prudent cryptographic practice in 477 determining the appropriate key lengths. 479 On a node that has been configured to use Secure DHCPv6, DHCPv6 480 message without either the CGA option or the Signature option MUST be 481 treated as unsecured. Note the Secure DHCPv6 nodes MAY simply discard 482 the unsecured messages. 484 The receiving node MUST verify the source address of the packet by 485 using the algorithm described in Section 5 of [RFC3972]. The inputs 486 to the algorithm are the source address, as used in IP header, and 487 the CGA Parameters field. 489 If the CGA verification is successful, the recipient proceeds with a 490 more time-consuming cryptographic check of the signature. Note that 491 even if the CGA verification succeeds, no claims about the validity 492 of the use can be made until the signature has been checked. 494 The receiving node MUST verify the Signature option as follows: the 495 Key Hash field MUST indicate the use of a known public key, either 496 one learned from a preceding CGA option in the same message, or one 497 known by other means. The signature field verification MUST show that 498 the signature has been calculated as specified in the previous 499 section. 501 Only the messages that get through both CGA and signature 502 verifications are accepted as secured DHCPv6 messages and continue to 503 be handled for their contained DHCPv6 options. 505 Messages that do not pass all the above tests MUST be silently 506 discarded if the host has been configured to accept only secured 507 DHCPv6 messages. The messages MAY be accepted if the host has been 508 configured to accept both secured and unsecured messages but MUST be 509 treated as an unsecured message. The receiver MAY also otherwise 510 silently discard packets. 512 In the relay scenarios, a DHCPv6 server obtains the CGA of a client 513 from the peer address field in the Relay-forward message. A DHCPv6 514 client obtains the CGA of a server from the Server Address field of 515 the DUID in the OPTION_SERVERID. 517 6.3. Processing Rules of Relay Agent 519 To support secure DHCPv6, Relay Agents follow the same processing 520 rules defined in [RFC3315]. 522 By current definition: "The relay agent copies the source address 523 from the IP datagram in which the message was received from the 524 client into the peer-address field in the Relay-forward message". The 525 CGA of a client will not lose during relaying. 527 A relay will not change the OPTION_SERVERID when processing Relay- 528 reply message from a DHCPv6 server, CGA of the DHCPv6 server will not 529 lose. 531 7. Security Considerations 533 This document provides new security features to the DHCPv6 protocol. 535 DHCPv6 nodes without CGAs or the DHCPv6 messages that use unspecific 536 addresses cannot be protected. 538 Downgrade attacks cannot be avoided if nodes are configured to accept 539 both secured and unsecured messages. A future specification MAY 540 provide a mechanism on how to treat unsecured DHCPv6 messages. One 541 simple solution MAY be that Secure DHCPv6 is mandated on all servers, 542 reply agents and clients if a certain link has been deployed Secure 543 DHCPv6. 545 8. IANA Considerations 547 This document defines two new DHCPv6 [RFC3315] options, which MUST be 548 assigned Option Type values within the option numbering space for 549 DHCPv6 messages: 551 The CGA Parameter Option (TBA1), described in Section 5.1. 553 The Signature Option (TBA2), described in Section 5.2. 555 This document defines a new DHCPv6 DUID, which MUST be assigned DUID 556 Type values within the DHCPv6 DUID Type numbering space: 558 The DUID-SA (TBA3), described in Section 5.3. 560 This document defines three new registries that have been created and 561 are maintained by IANA. Initial values for these registries are given 562 below. Future assignments are to be made through Standards Action 563 [RFC5226]. Assignments for each registry consist of a name, a value 564 and a RFC number where the registry is defined. 566 Hash Algorithm id (HA-id). The values in this name space are 16-bit 567 unsigned integers. The following initial values are assigned for HA- 568 id in this document: 570 Name | Value | RFCs 571 -------------------+---------+------------ 572 SHA-1 | 0x0000 | this document 573 Signature Algorithm id (SA-id). The values in this name space are 16- 574 bit unsigned integers. The following initial values are assigned for 575 SA-id in this document: 577 Name | Value | RFCs 578 -------------------+---------+------------ 579 SHA-1 | 0x0000 | this document 581 Hash Algorithm id for Key Hash (HA-id-KH). The values in this name 582 space are 16-bit unsigned integers. The following initial values are 583 assigned for HA-id-KH in this document: 585 Name | Value | RFCs 586 -------------------+---------+------------ 587 RSASSA-PKCS1-v1_5 | 0x0000 | this document 589 This document defines a new 128-bit value under the CGA Message Type 590 [RFC3972] namespace, 0x81be a1eb 0021 ce7e caa9 4090 0665 d2e0 02c2. 592 9. Acknowledgments 594 The authors would like to thank Bernie Volz and other members of the 595 IETF DHC & CSI working groups for their valuable comments. 597 10. References 599 10.1. Normative References 601 [RFC1305] D. Mills, "Network Time Protocol (Version 3) Specification, 602 Implementation and Analysis", RFC1305, March, 1992. 604 [RFC3315] R. Droms, et al., "Dynamic Host Configure Protocol for 605 IPv6", RFC3315, July 2003. 607 [RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972, 608 March 2005. 610 [RFC4982] M. Bagnulo, J. Arkko, "Support for Multiple Hash Algorithms 611 in Cryptographically Generated Addresses (CGAs)", RFC4982, 612 July 2007. 614 10.2. Informative References 616 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 617 Requirement Levels", RFC2119, March 1997. 619 [RFC4270] P. Hoffman and B. Schneier, "Attacks on Cryptographic 620 Hashed in Internet Protocols", RFC 4270, November 2005. 622 [RFC5226] T. Narten and H. Alvestrand, "Guidelines for Writing an 623 IANA Considerations Section in RFCs", RFC 5226, May 2008. 625 [NewHash] S.Bellovin and E. Rescorla, "Deploying a New Hash 626 Algorithm", November 2005. 628 [I-D.draft-jiang-dhc-cga-config-dhcpv6] 629 S. Jiang and S. Xia, "Configuring Cryptographically 630 Generated Addresses (CGA) using DHCPv6", draft-jiang-dhc- 631 cga-config-dhcpv6, working in progress, February 2010. 633 [I-D.draft-ietf-csi-dhcpv6-cga-ps] 634 S. Jiang, S. Shen and T. Chown, "DHCPv6 and CGA Interaction: 635 Problem Statement", draft-ietf-csi-dhcpv6-cga-ps, work in 636 progress, December 2009. 638 [RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1", 639 PKCS 1, November 2002. 641 [sha-1] National Institute of Standards and Technology, "Secure 642 Hash Standard", FIBS PUB 180-1, April 1995, 643 http://www.itl.nist.gov/fipspubs/fip180-1.htm. 645 Author's Addresses 647 Sheng Jiang 648 Huawei Technologies Co., Ltd 649 KuiKe Building, No.9 Xinxi Rd., 650 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 651 P.R. China 652 Email: shengjiang@huawei.com 654 Sean Shen 655 CNNIC 656 4, South 4th Street, Zhongguancun 657 Beijing 100190 658 P.R. China 659 Email: shenshuo@cnnic.cn