idnits 2.17.1 draft-ietf-dhc-secure-dhcpv6-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 30, 2011) is 4494 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 informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: July 1, 2012 CNNIC 5 December 30, 2011 7 Secure DHCPv6 Using CGAs 8 draft-ietf-dhc-secure-dhcpv6-04.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 July 1, 2012. 32 Copyright Notice 34 Copyright (c) 2011 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 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified 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 ................................................ 15 76 10.1. Normative References ................................. 15 77 10.2. Informative References ............................... 15 78 Author's Addresses ............................................ 16 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. 156 Secondly, a DHCPv6 server sends a reconfigure key to the client in 157 the initial exchange of DHCPv6 messages for future use, in this case 158 security is not guaranteed because this key is transmitted in 159 plaintext. In either way, the security of key itself is in question 160 mark. 162 Communication between a server and a relay agent, and communication 163 between relay agents, can be secured through the use of IPSec, as 164 described in section 21.1 in [RFC3315]. However, IPSec is quite 165 complicated. A simpler security mechanism may have better deploy 166 ability. Furthermore, the manual configuration and static keys are 167 potential issue makers. Relay agents MAY require other security 168 mechanisms besides IPSec. 170 4. Secure DHCPv6 Overview 172 To solve the abovementioned security issues, we introduce CGAs into 173 DHCPv6. CGAs are introduced in [RFC3972]. "CGAs are IPv6 addresses 174 for which the interface identifier is generated by computing a 175 cryptographic one-way hash function from a public key and auxiliary 176 parameters. The binding between the public key and the address can be 177 verified by re-computing the hash value and by comparing the hash 178 with the interface identifier. Messages sent from an IPv6 address can 179 be protected by attaching the public key and auxiliary parameters and 180 by signing the message with the corresponding private key. The 181 protection works without a certification authority or any security 182 infrastructure." 184 In this document, a CGA option with an address ownership proof 185 mechanism and a signature option with a corresponding verification 186 mechanism are introduced. A DHCPv6 message (from either a server, a 187 relay agent or a client) with a CGA as source address, can carry the 188 CGA Parameters data structure and a digital signature. The receiver 189 of this DHCPv6 message can verify both the CGA and signature, then 190 process the payload of the DHCPv6 message only if the validation is 191 successful. 193 With them, the receiver of a DHCP message can verify the sender 194 address of the DHCP message, which improves communication security of 195 DHCP messages. By using the signature option, the verification of 196 data integrity and replay protections can also be achieved without 197 the authentication option. 199 This documentation focuses on using CGAs to secure the DHCPv6 200 protocol. It assumes the sender, which uses CGAs, has self-generated 201 or been configured CGAs. The CGA configuration in the DHCPv6 network 202 is out of scope and specified in 203 [I-D.draft-ietf-dhc-cga-config-dhcpv6]. 205 In the relay scenarios, because relay agent restructures the DHCPv6 206 messages, a receiver would not find the sender's source CGA address 207 in the DHCPv6 message header. In the client-relay-server scenarios, 208 "the relay agent copies the source address from the header of the IP 209 datagram in which the message was received to the peer-address field 210 of the Relay-forward message" [RFC3315]. The receiver, a DHCPv6 211 server, can find the sender's source CGA address in the peer-address 212 field for CGA verification. In the server-relay-client scenarios, a 213 DHCP server knows a client is behind relay(s) if it receives a Relay- 214 forward DHCPv6 message. Then it will reply a Relay-reply message with 215 the server's source CGA address being carried in the server DUID, 216 which is in the payload. In this way, the receiver, a DHCPv6 client 217 can get the server's source CGA address for CGA verification. The 218 server DUID is also protected by CGA. 220 4.1. New Components 222 The components of the solution specified in this document are as 223 follows: 225 - CGAs are used to make sure that the sender of a DHCPv6 message 226 is the "owner" of the claimed address. A public-private key 227 pair has been generated by a node itself before it can claim an 228 address. A new DHCPv6 option, the CGA Parameter Option, is used 229 to carry the public key and associated 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 through the address ownership proof 234 mechanism, by using CGAs. 236 - Server Address type of DUID is used to carry server's source 237 address in the relay scenarios. The receiver gets the server's 238 source CGA address for CGA verification. 240 4.2. Support for algorithm agility 242 Hash functions are the fundamental of security mechanisms, including 243 CGAs in this document. "...they have two security properties: to be 244 one way and collision free." "The recent attacks have demonstrated 245 that one of those security properties is not true." [RFC4270] 247 Following the approach recommended by [RFC4270] and [NewHash], our 248 analysis shows none of these attacks are currently doable. However, 249 these attacks indicate the possibility of future real-world attacks. 250 Therefore, we have to take into account that future attacks will be 251 improved and provide a support for multiple hash algorithms. Our 252 mechanisms, in this document, support not only hash algorithm agility 253 but also signature algorithm agility. 255 The support for hash agility within CGAs has been defined in 256 [RFC4982]. The usage of CGAs in this document SHOULD also obey 257 [RFC4982], too. 259 5. Extensions for Secure DHCPv6 261 This section extends DHCPv6. Two new options and a new DUID type have 262 been defined. The new options MUST be supported, if the node has been 263 configured to use Secure DHCPv6. The new DUID type MUST be supported 264 in the relay scenarios. 266 5.1. CGA Parameter Option 268 The CGA option allows the verification of the sender's CGAs. The 269 format of the CGA option is described as follows: 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | OPTION_CGA_PARAMETER | option-len | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | | 277 . . 278 . CGA Parameters (variable length) . 279 . . 280 | | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 option-code OPTION_CGA_PARAMETER (TBA1). 285 option-len Length of CGA Parameters in octets. 287 CGA Parameters A variable-length field containing the CGA 288 Parameters data structure described in Section 4 289 of [RFC3972]. This specification requires that 290 the public key found from the CGA Parameters 291 field in the CGA option MUST be that referred by 292 the Key Hash field in the Signature option. 293 Packets received with two different keys MUST be 294 silently discarded. Note that a future extension 295 MAY provide a mechanism allowing the owner of an 296 address and the signer to be different parties. 298 5.2. Signature Option 300 The Signature option allows public key-based signatures to be 301 attached to a DHCPv6 message. The Signature option COULD be any place 302 within the DHCPv6 message. It protects all the DHCPv6 header and 303 options before it. Any options after the Signature option can be 304 processed, but it should be noticed that they are not protected by 305 this Signature option. The format of the Signature option is 306 described as follows: 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | OPTION_SIGNATURE | option-len | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | HA-id | SA-id | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | HA-id-KH | Reserved | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Timestamp (64-bit) | 318 | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | | 321 | Key Hash (128-bit) | 322 | | 323 | | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | | 326 . Signature (variable length) . 327 . . 328 . . 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 option-code OPTION_SIGNATURE (TBA2). 333 option-len 32 + Length of signature field in octets. 335 HA-id Hash Algorithm id. The hash algorithm is used 336 for computing the signature result. RSA 337 signature [RSA] with SHA-1 [sha-1] is adopted. 338 In order to provide hash algorithm agility, SHA- 339 1 is assigned an initial value 0x0000 in this 340 document. 342 SA-id Signature Algorithm id. The signature algorithm 343 is used for computing the signature result. RSA 344 signature with RSASSA-PKCS1-v1_5 algorithm is 345 adopted. In order to provide algorithm agility, 346 RSASSA_PKCS1-v1_5 is assigned an initial value 347 0x0000 in this document. 349 HA-id-KH Hash Algorithm id for Key Hash. Hash algorithm 350 used for producing the Key Hash field in the 351 Signature option. SHA-1 is adopted. In order to 352 provide hash algorithm agility, SHA-1 is 353 assigned an initial value 0x0000 in this 354 document. 356 Reserved A 16-bit field reserved for future use. The 357 value MUST be initialized to zero by the sender, 358 and MUST be ignored by the receiver. 360 Timestamp The current time of day (NTP-format timestamp 361 [RFC5905], a 64-bit unsigned fixed-point number, 362 in seconds relative to 0h on 1 January 1900.). 363 It can reduce the danger of replay attacks. 365 Key Hash A 128-bit field containing the most significant 366 (leftmost) 128 bits of a SHA-1 hash of the 367 public key used for constructing the signature. 368 The SHA-1 hash is taken over the presentation 369 used in the Public Key field of the CGA 370 Parameters data structure carried in the CGA 371 option. Its purpose is to associate the 372 signature to a particular key known by the 373 receiver. Such a key can either be stored in the 374 certificate cache of the receiver or be received 375 in the CGA option in the same message. 377 Signature A variable-length field containing a digital 378 signature. The signature value is computed with 379 the hash algorithm and the signature algorithm, 380 as described in HA-id and SA-id. The signature 381 constructed by using the sender's private key 382 over the following sequence of octets: 384 1. The 128-bit CGA Message Type tag value for 385 Secure DHCPv6, 0x81be a1eb 0021 ce7e caa9 4090 386 0665 d2e0 02c2. (The tag value has been 387 generated randomly by the editor of this 388 specification.). 390 2. The 128-bit Source IPv6 Address. 392 3. The 128-bit Destination IPv6 Address. 394 4. The DHCPv6 message header. 396 5. All DHCPv6 options except for the Signature 397 option and the Authentication Option. 399 6. The content between the option-len field and 400 the signature field in this Signature option, in 401 the format described above. 403 5.3. DUID-SA Type 405 Server Address Type DUID (DUID-SA) allows IP address of DHCPv6 406 servers can be carried in DHCPv6 message payload. 408 The following diagram illustrates the format of a DUID-SA: 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | TBA3 | Reserved | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | | 415 | Server Address (128-bit) | 416 | | 417 | | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Type-code DUID-SA Type (TBA3) 422 Reserved A 16-bit field reserved for future use. The 423 value MUST be initialized to zero by the sender, 424 and MUST be ignored by the receiver. 426 Server Address The 128-bit IPv6 address of the DHCPv6 server. 428 In the secure DHCPv6 solution, the Server Address field of DUID-SA, 429 which is the IPv6 address of the DHCPv6 server, MUST be a CGA. 431 In the secure DHCPv6 solution, all the payloads, including DUID-SA, 432 are protected by signature option by the definition of section 5.1 433 and 5.2. 435 6. Processing Rules and Behaviors 437 6.1. Processing Rules of Sender 439 A DHCPv6 node, which could be a server, relay agent or client, can be 440 configured to send Secure DHCPv6 messages only if CGAs have been 441 configured on it. 443 The node MUST record the following configuration information: 445 CGA parameters Any information required to construct CGAs, as 446 described in [RFC3972]. 448 Keypair A public-private key pair. The public key used 449 for constructing the signature MUST be the same 450 in CGA parameters. 452 CGA flag A flag that indicates whether CGA is used or 453 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 Using CGA as source addresses of DHCPv6 servers, relays or, also in 548 DHCPv6 message exchanging provides the source address ownership 549 verification and data integrity protection. 551 Without other pre-configured security mechanism, like pre-notified 552 DHCPv6 server address, using host-based CGA by DHCPv6 servers could 553 not prevent attacks claiming to be a DHCPv6 server. Furthermore, CGAs 554 of DHCPv6 servers may be pre-notified to hosts. Then, hosts may 555 decline the DHCPv6 messages from other servers, which may be fake 556 servers. But in this case the address will be fixed. It may increase 557 the vulnerability to, e.g., brute force attacks. The pre-notification 558 operation also needs to be protected, which is out of scope. 560 DHCPv6 nodes without CGAs or the DHCPv6 messages that use unspecific 561 addresses cannot be protected. 563 Downgrade attacks cannot be avoided if nodes are configured to accept 564 both secured and unsecured messages. A future specification MAY 565 provide a mechanism on how to treat unsecured DHCPv6 messages. One 566 simple solution MAY be that Secure DHCPv6 is mandated on all servers, 567 reply agents and clients if a certain link has been deployed Secure 568 DHCPv6. 570 As stated in CGA definition [RFC3972], link-local CGAs are more 571 vulnerable because the same prefix is used by all IPv6 nodes. 572 Therefore, when link-local CGAs are used by the DHCPv6 clients, it is 573 recommended to use a slightly higher Sec value. When higher Sec 574 values are used, the relative advantage of attacking link-local 575 addresses becomes insignificant. 577 Impacts of collision attacks on current uses of CGAs are analyzed in 578 [RFC4982]. The basic idea behind collision attacks, as described in 579 Section 4 of [RFC4270], is on the non-repudiation feature of hash 580 algorithms. However, CGAs do not provide non-repudiation features. 581 Therefore, as [RFC4982] points out CGA-based protocols, including 582 Secure DHCPv6 defined in this document, are not affected by collision 583 attacks on hash functions. 585 [RFC6273] has analyzed possible threats to the hash algorithms used 586 in SEND. Since the Secure DHCPv6 defined in this document uses the 587 same hash algorithms in similar way like SEND (except that Secure 588 DHCPv6 has not used PKIX Certificate), analysis results could be 589 applied as well: current attacks on hash functions do not constitute 590 any practical threat to the digital signatures used in the RSA 591 signature in Secure. Attacks on CGAs, as described in [RFC4982], will 592 compromise the security of Secure DHCPv6 and they need to be 593 addressed by encoding the hash algorithm information into the CGA as 594 specified in [RFC4982]. 596 8. IANA Considerations 598 This document defines two new DHCPv6 [RFC3315] options, which MUST be 599 assigned Option Type values within the option numbering space for 600 DHCPv6 messages: 602 The CGA Parameter Option (TBA1), described in Section 5.1. 604 The Signature Option (TBA2), described in Section 5.2. 606 This document defines a new DHCPv6 DUID, which MUST be assigned DUID 607 Type values within the DHCPv6 DUID Type numbering space: 609 The DUID-SA (TBA3), described in Section 5.3. 611 This document defines three new registries that have been created and 612 are maintained by IANA. Initial values for these registries are given 613 below. Future assignments are to be made through Standards Action 614 [RFC5226]. Assignments for each registry consist of a name, a value 615 and a RFC number where the registry is defined. 617 Hash Algorithm id (HA-id). The values in this name space are 16-bit 618 unsigned integers. The following initial values are assigned for HA- 619 id in this document: 621 Name | Value | RFCs 622 -------------------+---------+------------ 623 SHA-1 | 0x0000 | this document 625 Signature Algorithm id (SA-id). The values in this name space are 16- 626 bit unsigned integers. The following initial values are assigned for 627 SA-id in this document: 629 Name | Value | RFCs 630 -------------------+---------+------------ 631 SHA-1 | 0x0000 | this document 633 Hash Algorithm id for Key Hash (HA-id-KH). The values in this name 634 space are 16-bit unsigned integers. The following initial values are 635 assigned for HA-id-KH in this document: 637 Name | Value | RFCs 638 -------------------+---------+------------ 639 RSASSA-PKCS1-v1_5 | 0x0000 | this document 641 This document defines a new 128-bit value under the CGA Message Type 642 [RFC3972] namespace, 0x81be a1eb 0021 ce7e caa9 4090 0665 d2e0 02c2. 644 9. Acknowledgments 646 The authors would like to thank Bernie Volz, Ted Lemon, Ralph Dorms, 647 Jari Arkko, Sean Turner and other members of the IETF DHC & CSI 648 working groups for their valuable comments. 650 10. References 652 10.1. Normative References 654 [RFC3315] R. Droms, et al., "Dynamic Host Configure Protocol for 655 IPv6", RFC3315, July 2003. 657 [RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972, 658 March 2005. 660 [RFC4982] M. Bagnulo, J. Arkko, "Support for Multiple Hash Algorithms 661 in Cryptographically Generated Addresses (CGAs)", RFC4982, 662 July 2007. 664 [RFC5905] D. Mills, J. Martin, Ed., J. Burbank and W. Kasch, "Network 665 Time Protocol Version 4: Protocol and Algorithms 666 Specification", RFC 5905, June 2010. 668 10.2. Informative References 670 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 671 Requirement Levels", c, March 1997. 673 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 674 Hashes in Internet Protocols", RFC 4270, November 2005. 676 [RFC5226] T. Narten and H. Alvestrand, "Guidelines for Writing an 677 IANA Considerations Section in RFCs", RFC 5226, May 2008. 679 [RFC6273] A. Kukec, S. Krishnan and S. Jiang "The Secure Neighbor 680 Discovery (SEND) Hash Threat Analysis", RFC 6274, June 681 2011. 683 [NewHash] S.Bellovin and E. Rescorla, "Deploying a New Hash 684 Algorithm", November 2005. 686 [I-D.draft-ietf-dhc-cga-config-dhcpv6] 687 S. Jiang and S. Xia, "Configuring Cryptographically 688 Generated Addresses (CGA) using DHCPv6", draft-ietf-dhc- 689 cga-config-dhcpv6, working in progress, October 2011. 691 [I-D.draft-ietf-csi-dhcpv6-cga-ps] 692 S. Jiang, S. Shen and T. Chown, "DHCPv6 and CGA 693 Interaction: Problem Statement", draft-ietf-csi-dhcpv6- 694 cga-ps, work in progress, May 2011. 696 [RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1", 697 PKCS 1, November 2002. 699 [sha-1] National Institute of Standards and Technology, "Secure 700 Hash Standard", FIBS PUB 180-1, April 1995, 701 http://www.itl.nist.gov/fipspubs/fip180-1.htm. 703 Author's Addresses 705 Sheng Jiang 706 Huawei Technologies Co., Ltd 707 Q14, Huawei Campus 708 No.156 Beiqing Road 709 Hai-Dian District, Beijing 100095 710 P.R. China 711 EMail: jiangsheng@huawei.com 713 Sean Shen 714 CNNIC 715 4, South 4th Street, Zhongguancun 716 Beijing 100190 717 P.R. China 718 EMail: shenshuo@cnnic.cn