idnits 2.17.1 draft-ietf-dhc-secure-dhcpv6-02.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 (December 21, 2010) is 4846 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 642, 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: June 18, 2011 CNNIC 5 December 21, 2010 7 Secure DHCPv6 Using CGAs 8 draft-ietf-dhc-secure-dhcpv6-02.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 June 18, 2011. 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..........................................10 68 6. Processing Rules and Behaviors..............................10 69 6.1. Processing Rules of Sender.............................10 70 6.2. Processing Rules of Receiver...........................11 71 6.3. Processing Rules of Relay Agent........................12 72 7. Security Considerations.....................................12 73 8. IANA Considerations........................................13 74 9. Acknowledgments............................................14 75 10. References................................................14 76 10.1. Normative References..................................14 77 10.2. Informative References................................14 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. A DHCPv6 message (from either a server, 186 relay agent or client) with a CGA as source address, can carry the 187 CGA Parameters data structure and a digital signature. The receiver 188 of this DHCPv6 message can verify both the CGA and signature, then 189 process the payload of the DHCPv6 message only if the validation is 190 successful. 192 With them, the receiver of a DHCP message can verify the sender 193 address of the DHCP message, which improves communication security of 194 DHCP messages. By using the signature option, the verification of 195 data integrity and replay protections can also be achieved without 196 the authentication option. 198 This documentation focuses on using CGAs to secure the DHCPv6 199 protocol. It assumes the sender, which uses CGAs, has self-generated 200 or been configured CGAs. The CGA configuration in the DHCPv6 network 201 is out of scope and specified in [I-D.draft-jiang-dhc-cga-config- 202 dhcpv6]. 204 In the relay scenarios, because relay agent restructures the DHCPv6 205 messages, a receiver would not find the sender's source CGA address 206 in the DHCPv6 message header. In the client-relay-server scenarios, 207 "the relay agent copies the source address from the header of the IP 208 datagram in which the message was received to the peer-address field 209 of the Relay-forward message" [RFC3315]. The receiver, a DHCPv6 210 server, can find the sender's source CGA address in the peer-address 211 field for CGA verification. In the server-relay-client scenarios, a 212 DHCP server knows a client is behind relay(s) if it receives a Relay- 213 forward DHCPv6 message. Then it will reply a Relay-reply message with 214 the server's source CGA address being carried in the server DUID, 215 which is in the payload. In this way, the receiver, a DHCPv6 client 216 can get the server's source CGA address for CGA verification. The 217 server DUID is also protected by CGA. 219 4.1. New Components 221 The components of the solution specified in this document are as 222 follows: 224 - CGAs are used to make sure that the sender of a DHCPv6 message 225 is the "owner" of the claimed address. A public-private key 226 pair has been generated by a node itself or configured before 227 it can claim an address. A new DHCPv6 option, the CGA Parameter 228 Option, is used to carry the public key and associated 229 parameters. 231 - Public key signatures protect the integrity of the messages and 232 authenticate the identity of their sender. The authority of a 233 public key is established either with the authorization 234 delegation process, by using certificates, or through the 235 address ownership proof mechanism, by using CGAs, or with both. 237 - Server Address type of DUID is used to carry server's source 238 address in the relay scenarios. The receiver gets the server's 239 source CGA address for CGA verification. 241 4.2. Support for algorithm agility 243 Hash functions are the fundamental of security mechanisms, including 244 CGAs in this document. "...they have two security properties: to be 245 one way and collision free." "The recent attacks have demonstrated 246 that one of those security properties is not true." [RFC4270] 248 Following the approach recommended by [RFC4270] and [NewHash], our 249 analysis shows none of these attacks are currently doable. However, 250 these attacks indicate the possibility of future real-world attacks. 251 Therefore, we have to take into account that future attacks will be 252 improved and provide a support for multiple hash algorithms. Our 253 mechanisms, in this document, support not only hash algorithm agility 254 but also signature algorithm agility. 256 The support for hash agility within CGAs has been defined in 257 [RFC4982]. The usage of CGAs in this document SHOULD also obey 258 [RFC4982], too. 260 5. Extension for Secure DHCPv6 262 This section extends DHCPv6. Two new options and a new DUID type have 263 been defined. The new options MUST be supported, if the node has been 264 configured to use Secure DHCPv6. The new DUID type MUST be supported 265 in the relay scenarios. 267 5.1. CGA Parameter Option 269 The CGA option allows the verification of the sender's CGAs. The 270 format of the CGA option is described as follows: 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | OPTION_CGA_PARAMETER | option-len | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | | 278 . . 279 . CGA Parameters (variable length) . 280 . . 281 | | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 option-code OPTION_CGA_PARAMETER (TBA1). 286 option-len Length of CGA Parameters in octets. 288 CGA Parameters A variable-length field containing the CGA 289 Parameters data structure described in Section 4 290 of [RFC3972]. This specification requires that 291 the public key found from the CGA Parameters 292 field in the CGA option MUST be that referred by 293 the Key Hash field in the Signature option. 294 Packets received with two different keys MUST be 295 silently discarded. Note that a future extension 296 MAY provide a mechanism allowing the owner of an 297 address and the signer to be different parties. 299 5.2. Signature Option 301 The Signature option allows public key-based signatures to be 302 attached to a DHCPv6 message. The Signature option COULD be any place 303 within the DHCPv6 message. It protects all the DHCPv6 header and 304 options before it. Any options after the Signature option can be 305 processed, but it should be noticed that they are not protected by 306 this Signature option. The format of the Signature option is 307 described as follows: 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | OPTION_SIGNATURE | option-len | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | HA-id | SA-id | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | HA-id-KH | Reserved | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Timestamp (64-bit) | 319 | | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | | 322 | Key Hash (128-bit) | 323 | | 324 | | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | | 327 . Signature (variable length) . 328 . . 329 . . 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 option-code OPTION_SIGNATURE (TBA2). 334 option-len 32 + Length of signature field in octets. 336 HA-id Hash Algorithm id. The hash algorithm is used 337 for computing the signature result. RSA 338 signature [RSA] with SHA-1 [sha-1] is adopted. 339 In order to provide hash algorithm agility, SHA- 340 1 is assigned an initial value 0x0000 in this 341 document. 343 SA-id Signature Algorithm id. The signature algorithm 344 is used for computing the signature result. RSA 345 signature with RSASSA-PKCS1-v1_5 algorithm is 346 adopted. In order to provide algorithm agility, 347 RSASSA_PKCS1-v1_5 is assigned an initial value 348 0x0000 in this document. 350 HA-id-KH Hash Algorithm id for Key Hash. Hash algorithm 351 used for producing the Key Hash field in the 352 Signature option. SHA-1 is adopted. In order to 353 provide hash algorithm agility, SHA-1 is 354 assigned an initial value 0x0000 in this 355 document. 357 Reserved A 16-bit field reserved for future use. The 358 value MUST be initialized to zero by the sender, 359 and MUST be ignored by the receiver. 361 Timestamp The current time of day (NTP-format timestamp 362 [RFC1305], a 64-bit unsigned fixed-point number, 363 in seconds relative to 0h on 1 January 1900.). 364 It can reduce the danger of replay attacks. 366 Key Hash A 128-bit field containing the most significant 367 (leftmost) 128 bits of a SHA-1 hash of the 368 public key used for constructing the signature. 369 The SHA-1 hash is taken over the presentation 370 used in the Public Key field of the CGA 371 Parameters data structure carried in the CGA 372 option. Its purpose is to associate the 373 signature to a particular key known by the 374 receiver. Such a key can either be stored in the 375 certificate cache of the receiver or be received 376 in the CGA option in the same message. 378 Signature A variable-length field containing a digital 379 signature. The signature value is computed with 380 the hash algorithm and the signature algorithm, 381 as described in HA-id and SA-id. The signature 382 constructed by using the sender's private key 383 over the following sequence of octets: 385 1. The 128-bit CGA Message Type tag value for 386 Secure DHCPv6, 0x81be a1eb 0021 ce7e caa9 4090 387 0665 d2e0 02c2. (The tag value has been 388 generated randomly by the editor of this 389 specification.). 391 2. The 128-bit Source IPv6 Address. 393 3. The 128-bit Destination IPv6 Address. 395 4. The DHCPv6 message header. 397 5. All DHCPv6 options except for the Signature 398 option and the Authentication Option. 400 6. The content between the option-len field and 401 the signature field in this Signature option, in 402 the format described above. 404 5.3. DUID-SA Type 406 Server Address Type DUID (DUID-SA) allows IP address of DHCPv6 407 servers can be carried in DHCPv6 message payload. 409 The following diagram illustrates the format of a DUID-SA: 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | TBA3 | Reserved | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | | 416 | Server Address (128-bit) | 417 | | 418 | | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Type-code DUID-SA Type (TBA3) 423 Reserved A 16-bit field reserved for future use. The 424 value MUST be initialized to zero by the sender, 425 and MUST be ignored by the receiver. 427 Server Address The 128-bit IPv6 address of the DHCPv6 server. 429 In the secure DHCPv6 solution, the Server Address field of DUID-SA, 430 which is the IPv6 address of the DHCPv6 server, MUST be a CGA. 432 In the secure DHCPv6 solution, all the payloads, including DUID-SA, 433 are protected by signature option by the definition of section 5.1 434 and 5.2. 436 6. Processing Rules and Behaviors 438 6.1. Processing Rules of Sender 440 A DHCPv6 node, which could be a server, relay agent or client, can be 441 configured to send Secure DHCPv6 messages only if CGAs have been 442 configured on it. 444 The node MUST record the following configuration information: 446 CGA parameters Any information required to construct CGAs, as 447 described in [RFC3972]. 449 Keypair A public-private key pair. The public key used 450 for constructing the signature MUST be the same 451 in CGA parameters. 453 CGA flag A flag that indicates whether CGA is used or not. 455 If a node has been configured to use Secure DHCPv6, the node MUST 456 send a DHCPv6 message using a CGA, which be constructed as specified 457 in Section 4 of [RFC3972], as the source address unless they are sent 458 with the unspecified source address. This DHCPv6 message MUST be 459 signed by the private key of the sender. In the message, both the CGA 460 option and the Signature option MUST be present. The CGA Parameter 461 field in the CGA option is filled according to the rules presented 462 above and in [RFC3972]. The public key in the field is taken from the 463 configuration used to generate the CGA, typically from a data 464 structure associated with the source address. The Signature option 465 MUST be constructed as explained in Section 5.2 and be the last 466 DHCPv6 option. 468 In relay scenario, a DHCPv6 server MUST include an OPTION_SERVERID 469 [RFC3315] in Relay-reply message and put its CGA in the Server 470 Address field of the DUID in the OPTION_SERVERID. The CGA of DHCPv6 471 server will not lose during relaying so that the client can verify 472 CGA address and signature. 474 6.2. Processing Rules of Receiver 476 The node that supports the verification of the Secure DHCPv6 messages 477 MUST record the following configuration information: 479 Minbits The minimum acceptable key length for public 480 keys used in the generation of CGAs. The default 481 SHOULD be 1024 bits. Implementations MAY also 482 set an upper limit for the amount of computation 483 needed when verifying packets that use these 484 security associations. Any implementation SHOULD 485 follow prudent cryptographic practice in 486 determining the appropriate key lengths. 488 On a node that has been configured to use Secure DHCPv6, DHCPv6 489 message without either the CGA option or the Signature option MUST be 490 treated as unsecured. Note the Secure DHCPv6 nodes MAY simply discard 491 the unsecured messages. 493 The receiving node MUST verify the source CGA address of the DHCPv6 494 message by using the public key of the DHCPv6 message sender, CGA 495 Parameters and the algorithm described in Section 5 of [RFC3972]. The 496 inputs to the algorithm are the source address, as used in IP header, 497 and the CGA Parameters field. 499 If the CGA verification is successful, the recipient proceeds with a 500 more time-consuming cryptographic check of the signature. Note that 501 even if the CGA verification succeeds, no claims about the validity 502 of the use can be made until the signature has been checked. 504 The processing on the receiving node also includes the verification 505 on signed data by using the public key of the DHCPv6 message sender. 506 The receiving node MUST verify the Signature option as follows: the 507 Key Hash field MUST indicate the use of a known public key, either 508 one learned from a preceding CGA option in the same message, or one 509 known by other means. The signature field verification MUST show that 510 the signature has been calculated as specified in the previous 511 section. 513 Only the messages that get through both CGA and signature 514 verifications are accepted as secured DHCPv6 messages and continue to 515 be handled for their contained DHCPv6 options. 517 Messages that do not pass all the above tests MUST be silently 518 discarded if the host has been configured to accept only secured 519 DHCPv6 messages. The messages MAY be accepted if the host has been 520 configured to accept both secured and unsecured messages but MUST be 521 treated as an unsecured message. The receiver MAY also otherwise 522 silently discard packets. 524 In the relay scenarios, a DHCPv6 server obtains the CGA of a client 525 from the peer address field in the Relay-forward message. A DHCPv6 526 client obtains the CGA of a server from the Server Address field of 527 the DUID in the OPTION_SERVERID. 529 6.3. Processing Rules of Relay Agent 531 To support secure DHCPv6, Relay Agents follow the same processing 532 rules defined in [RFC3315]. 534 By current definition: "The relay agent copies the source address 535 from the IP datagram in which the message was received from the 536 client into the peer-address field in the Relay-forward message". The 537 CGA of a client will not lose during relaying. 539 A relay will not change the OPTION_SERVERID when processing Relay- 540 reply message from a DHCPv6 server, CGA of the DHCPv6 server will not 541 lose. 543 7. Security Considerations 545 This document provides new security features to the DHCPv6 protocol. 547 DHCPv6 nodes without CGAs or the DHCPv6 messages that use unspecific 548 addresses cannot be protected. 550 Downgrade attacks cannot be avoided if nodes are configured to accept 551 both secured and unsecured messages. A future specification MAY 552 provide a mechanism on how to treat unsecured DHCPv6 messages. One 553 simple solution MAY be that Secure DHCPv6 is mandated on all servers, 554 reply agents and clients if a certain link has been deployed Secure 555 DHCPv6. 557 8. IANA Considerations 559 This document defines two new DHCPv6 [RFC3315] options, which MUST be 560 assigned Option Type values within the option numbering space for 561 DHCPv6 messages: 563 The CGA Parameter Option (TBA1), described in Section 5.1. 565 The Signature Option (TBA2), described in Section 5.2. 567 This document defines a new DHCPv6 DUID, which MUST be assigned DUID 568 Type values within the DHCPv6 DUID Type numbering space: 570 The DUID-SA (TBA3), described in Section 5.3. 572 This document defines three new registries that have been created and 573 are maintained by IANA. Initial values for these registries are given 574 below. Future assignments are to be made through Standards Action 575 [RFC5226]. Assignments for each registry consist of a name, a value 576 and a RFC number where the registry is defined. 578 Hash Algorithm id (HA-id). The values in this name space are 16-bit 579 unsigned integers. The following initial values are assigned for HA- 580 id in this document: 582 Name | Value | RFCs 583 -------------------+---------+------------ 584 SHA-1 | 0x0000 | this document 586 Signature Algorithm id (SA-id). The values in this name space are 16- 587 bit unsigned integers. The following initial values are assigned for 588 SA-id in this document: 590 Name | Value | RFCs 591 -------------------+---------+------------ 592 SHA-1 | 0x0000 | this document 594 Hash Algorithm id for Key Hash (HA-id-KH). The values in this name 595 space are 16-bit unsigned integers. The following initial values are 596 assigned for HA-id-KH in this document: 598 Name | Value | RFCs 599 -------------------+---------+------------ 600 RSASSA-PKCS1-v1_5 | 0x0000 | this document 602 This document defines a new 128-bit value under the CGA Message Type 603 [RFC3972] namespace, 0x81be a1eb 0021 ce7e caa9 4090 0665 d2e0 02c2. 605 9. Acknowledgments 607 The authors would like to thank Bernie Volz, Ted Lemon, Ralph Dorms 608 and other members of the IETF DHC & CSI working groups for their 609 valuable comments. 611 10. References 613 10.1. Normative References 615 [RFC1305] D. Mills, "Network Time Protocol (Version 3) Specification, 616 Implementation and Analysis", RFC1305, March, 1992. 618 [RFC3315] R. Droms, et al., "Dynamic Host Configure Protocol for 619 IPv6", RFC3315, July 2003. 621 [RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972, 622 March 2005. 624 [RFC4982] M. Bagnulo, J. Arkko, "Support for Multiple Hash Algorithms 625 in Cryptographically Generated Addresses (CGAs)", RFC4982, 626 July 2007. 628 10.2. Informative References 630 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 631 Requirement Levels", RFC2119, March 1997. 633 [RFC4270] P. Hoffman and B. Schneier, "Attacks on Cryptographic 634 Hashed in Internet Protocols", RFC 4270, November 2005. 636 [RFC5226] T. Narten and H. Alvestrand, "Guidelines for Writing an 637 IANA Considerations Section in RFCs", RFC 5226, May 2008. 639 [NewHash] S.Bellovin and E. Rescorla, "Deploying a New Hash 640 Algorithm", November 2005. 642 [I-D.draft-jiang-dhc-cga-config-dhcpv6] 643 S. Jiang and S. Xia, "Configuring Cryptographically 644 Generated Addresses (CGA) using DHCPv6", draft-jiang-dhc- 645 cga-config-dhcpv6, working in progress, February 2010. 647 [I-D.draft-ietf-csi-dhcpv6-cga-ps] 648 S. Jiang, S. Shen and T. Chown, "DHCPv6 and CGA Interaction: 649 Problem Statement", draft-ietf-csi-dhcpv6-cga-ps, work in 650 progress, October 2010 652 [RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1", 653 PKCS 1, November 2002. 655 [sha-1] National Institute of Standards and Technology, "Secure 656 Hash Standard", FIBS PUB 180-1, April 1995, 657 http://www.itl.nist.gov/fipspubs/fip180-1.htm. 659 Author's Addresses 661 Sheng Jiang 662 Huawei Technologies Co., Ltd 663 Huawei Building, No.3 Xinxi Rd., 664 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 665 P.R. China 666 Email: shengjiang@huawei.com 668 Sean Shen 669 CNNIC 670 4, South 4th Street, Zhongguancun 671 Beijing 100190 672 P.R. China 673 Email: shenshuo@cnnic.cn