idnits 2.17.1 draft-ietf-dhc-secure-dhcpv6-05.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 (March 7, 2012) is 4426 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 Update: RFC3315 CNNIC 5 Expires: September 15, 2012 March 7, 2012 7 Secure DHCPv6 Using CGAs 8 draft-ietf-dhc-secure-dhcpv6-05.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 September 15, 2012. 32 Copyright Notice 34 Copyright (c) 2012 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 DHCPv6 servers to pass configuration parameters. It offers 51 configuration flexibility. If not secured, DHCPv6 is vulnerable to 52 various attacks, particularly spoofing attack. This document analyzes 53 the security issues of DHCPv6 and specifies a Secure DHCPv6 mechanism 54 based on 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 .......................... 5 64 5. Extensions 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 .............................. 9 69 6.1. Processing Rules of Sender ............................. 9 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 ........................................ 13 74 9. Acknowledgments ............................................ 14 75 10. References ................................................ 14 76 10.1. Normative References ................................. 14 77 10.2. Informative References ............................... 14 79 1. Introduction 81 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6 [RFC3315]) 82 enables DHCPv6 servers to pass configuration parameters. It offers 83 configuration flexibility. If not secured, DHCPv6 is vulnerable to 84 various attacks, particularly spoofing attack. 86 This document analyzes the security issues of DHCPv6 in details. This 87 document is aiming to provide mechanisms for improving the security 88 of DHCPv6, thus the address of a DHCPv6 message sender, which can be 89 a DHCPv6 server, a relay agent or a client, is able to be verified by 90 a receiver. It improves communication security of DHCPv6 interaction. 91 The security mechanisms specified in this document is mainly based on 92 the Cryptographically Generated Addresses (CGA [RFC3972]). 94 Secure DHCPv6 is applicable in environments where physical security 95 on the link is not assured (such as over wireless) and attacks on 96 DHCPv6 are a concern. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 3. Security Overview of DHCPv6 106 DHCPv6 is a client/server protocol that provides managed 107 configuration of devices. It enables DHCPv6 server to auto-configure 108 relevant network parameters on clients through the DHCPv6 message 109 exchanging mechanisms. In the basic DHCPv6 specifications [RFC3315], 110 security of DHCPv6 message can be improved in a few aspects. 112 a) In the basic DHCPv6 specifications, the DHCPv6 server uses a 113 "regular" IPv6 address for itself. It is possible for a malicious 114 attacker to use a fake address to spoof or launch an attack. See 115 Section 23, "Security Considerations" of [RFC3315] for more 116 details. 118 Furthermore, if DHCPv6 servers play the role of updating DNS and 119 other directory services, attackers may spoof DHCPv6 servers to 120 register incorrect information in those services. 122 CGA-based security mechanism can provide source address ownership 123 proofing, which prevents such attacks. 125 b) The basic DHCPv6 specifications achieve message origin 126 authentication and message integrity via an authentication option 127 with a symmetric key pair. For the key of the hash function, there 128 are two key management mechanisms. Firstly, the key management is 129 out of band, usually manual, i.e. operators set up key database 130 for both server and client before running DHCPv6. Usually multiple 131 keys are deployed once a time and key id is used to specify which 132 key is used. Manual key distribution runs counter to the goal of 133 minimizing the configuration data needed at each host. Secondly, a 134 DHCPv6 server sends a reconfigure key to the client in the initial 135 exchange of DHCPv6 messages for future use, in this case security 136 is not guaranteed because this key is transmitted in plaintext. 138 Comparing to this, CGA-based security mechanism does not request 139 any key management mechanisms. 141 c) Communication between a server and a relay agent, and 142 communication between relay agents, can be secured through the use 143 of IPsec, as described in section 21.1 in [RFC3315]. However, 144 IPsec is quite complicated. A simpler security mechanism may have 145 better deploy ability. 147 4. Secure DHCPv6 Overview 149 To solve the abovementioned security issues, we introduce CGAs into 150 DHCPv6. CGAs are introduced in [RFC3972]. "CGAs are IPv6 addresses 151 for which the interface identifier is generated by computing a 152 cryptographic one-way hash function from a public key and auxiliary 153 parameters. The binding between the public key and the address can be 154 verified by re-computing the hash value and by comparing the hash 155 with the interface identifier. Messages sent from an IPv6 address can 156 be protected by attaching the public key and auxiliary parameters and 157 by signing the message with the corresponding private key. The 158 protection works without a certification authority or any security 159 infrastructure." 161 This documentation introduces a Secure DHCPv6 mechanism that uses 162 CGAs to secure the DHCPv6 protocol. It assumes the secured DHCPv6 163 message sender has already haven CGAs and their correspondent CGA 164 parameters; and the receiver has already been given the CGAs of the 165 sender. 167 In this document, a CGA option with an address ownership proof 168 mechanism and a signature option with a corresponding verification 169 mechanism are introduced. A DHCPv6 message (from either a server, a 170 relay agent or a client) with a CGA as source address, can carry the 171 CGA Parameters data structure and a digital signature. The receiver 172 of this DHCPv6 message, who has already known the CGA of the sender, 173 can verify both the CGA and signature, then process the payload of 174 the DHCPv6 message only if the validation is successful. 176 can verify both the CGA and signature, then process the payload of 177 the DHCPv6 message only if the validation is successful. 179 With them, the receiver of a DHCPv6 message can verify the sender 180 address of the DHCPv6 message, which improves communication security 181 of DHCPv6 messages. The verification of data integrity and replay 182 protections can also be achieved without the authentication option. 184 The sender can be a DHCPv6 server, a relay agent or a client. So, the 185 end-to-end security protection can be from DHCPv6 servers to relay 186 agents or clients, or from clients to relay agent or DHCPv6 servers. 187 Relay agents MAY add its own Secure DHCPv6 options, too. 189 4.1. New Components 191 The components of the solution specified in this document are as 192 follows: 194 - CGAs are used to make sure that the sender of a DHCPv6 message 195 is the "owner" of the claimed address. A public-private key 196 pair has been generated by a node itself before it can claim an 197 address. A new DHCPv6 option, the CGA Parameter Option, is used 198 to carry the public key and associated parameters. 200 - Public key signatures protect the integrity of the DHCPv6 201 messages and authenticate the identity of their sender. 203 - Server Address type of DUID is used to carry server's source 204 address in the relay scenarios. The receiver gets the server's 205 source CGA address for CGA verification. 207 4.2. Support for algorithm agility 209 Hash functions are the fundamental of security mechanisms, including 210 CGAs in this document. "...they have two security properties: to be 211 one way and collision free." "The recent attacks have demonstrated 212 that one of those security properties is not true." [RFC4270] It is 213 theoretically possible to perform collision attack Attacks against 214 the "collision-free" property. 216 Following the approach recommended by [RFC4270] and [NewHash], recent 217 analysis shows none of these attacks are currently doable [RFC6273]. 218 "The broken security property will not affect the overall security of 219 many specific Internet protocols, the conservative security approach 220 is to change hash algorithms." [RFC4270] 222 However, these attacks indicate the possibility of future real-world 223 attacks. Therefore, we have to take into account that future attacks 224 will be improved and provide a support for multiple hash algorithms. 226 Our mechanisms, in this document, support not only hash algorithm 227 agility but also signature algorithm agility. 229 The support for hash agility within CGAs has been defined in 230 [RFC4982]. The usage of CGAs in this document SHOULD also obey 231 [RFC4982], too. 233 The support for algorithm agility in this document is mainly 234 unilateral notification model from a sender to a receiver. If the 235 receiver cannot support the algorithm provided by the sender, it 236 takes the risk itself. Senders in a same network do not have to 237 upgrade to a new algorithm simultaneously. 239 5. Extensions for Secure DHCPv6 241 This section extends DHCPv6. Two new options and a new DUID type have 242 been defined. The new options MUST be supported in the Secure DHCPv6 243 message exchanging. The new DUID type MUST be supported in the relay 244 scenarios. 246 5.1. CGA Parameter Option 248 The CGA option allows the verification of the sender's CGAs. The 249 format of the CGA option is described as follows: 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | OPTION_CGA_PARAMETER | option-len | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | | 257 . . 258 . CGA Parameters (variable length) . 259 . . 260 | | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 option-code OPTION_CGA_PARAMETER (TBA1). 265 option-len Length of CGA Parameters in octets. 267 CGA Parameters A variable-length field containing the CGA 268 Parameters data structure described in Section 4 269 of [RFC3972]. This specification requires that 270 the public key found from the CGA Parameters 271 field in the CGA option MUST be that referred by 272 the Key Hash field in the Signature option. 273 Packets received with two different keys MUST be 274 silently discarded. 276 5.2. Signature Option 278 The Signature option allows public key-based signatures to be 279 attached to a DHCPv6 message. The Signature option could be any place 280 within the DHCPv6 message. It protects all the DHCPv6 header and 281 options, particularly including the CGA option, except for the 282 Signature option and the Authentication Option. The format of the 283 Signature option is described as follows: 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | OPTION_SIGNATURE | option-len | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | HA-id | SA-id | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | HA-id-KH | Reserved | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Timestamp (64-bit) | 295 | | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | | 298 | Key Hash (128-bit) | 299 | | 300 | | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | | 303 . Signature (variable length) . 304 . . 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | | 307 . Padding . 308 . . 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 option-code OPTION_SIGNATURE (TBA2). 313 option-len 32 + Length of Signature field and Padding field 314 in octets. 316 HA-id Hash Algorithm id. The hash algorithm is used 317 for computing the signature result. This design 318 is adopted in order to provide hash algorithm 319 agility. 321 SA-id Signature Algorithm id. The signature algorithm 322 is used for computing the signature result. This 323 design is adopted in order to provide hash 324 algorithm agility. 326 HA-id-KH Hash Algorithm id for Key Hash. Hash algorithm 327 used for producing the Key Hash field in the 328 Signature option. This design is adopted in 329 order to provide hash algorithm agility. 331 Reserved A 16-bit field reserved for future use. The 332 value MUST be initialized to zero by the sender, 333 and MUST be ignored by the receiver. 335 Timestamp The current time of day (NTP-format timestamp 336 [RFC5905], a 64-bit unsigned fixed-point number, 337 in seconds relative to 0h on 1 January 1900.). 338 It can reduce the danger of replay attacks. 340 Key Hash A 128-bit field containing the most significant 341 (leftmost) 128 bits of the hash value of the 342 public key used for constructing the signature. 343 The hash algorithm is indicated in the HA-id-KH 344 field. The field is taken over the presentation 345 used in the Public Key field of the CGA 346 Parameters data structure carried in the CGA 347 option. Its purpose is to associate the 348 signature to a particular key known by the 349 receiver. Such a key can either be stored in the 350 certificate cache of the receiver or be received 351 in the CGA option in the same message. 353 Signature A variable-length field containing a digital 354 signature. The signature value is computed with 355 the hash algorithm and the signature algorithm, 356 as described in HA-id and SA-id. The signature 357 constructed by using the sender's private key 358 protects the following sequence of octets: 360 1. The 128-bit CGA Message Type tag value for 361 Secure DHCPv6, 0x81be a1eb 0021 ce7e caa9 4090 362 0665 d2e0 02c2. 364 2. The 128-bit Source IPv6 Address. 366 3. The 128-bit Destination IPv6 Address. 368 4. The DHCPv6 message header. 370 5. All DHCPv6 options except for the Signature 371 option and the Authentication Option. 373 6. The content between the option-len field and 374 the signature field in this Signature option, in 375 the format described above. 377 Padding This variable-length field contains padding, as 378 many bytes long as remain after the end of the 379 signature. 381 5.3. DUID-SA Type 383 Server Address Type DUID (DUID-SA) allows IP address of DHCPv6 384 servers can be carried in DHCPv6 message payload. 386 The following diagram illustrates the format of a DUID-SA: 388 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 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | TBA3 | Reserved | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | | 393 | Server Address (128-bit) | 394 | | 395 | | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 Type-code DUID-SA Type (TBA3) 400 Reserved A 16-bit field reserved for future use. The 401 value MUST be initialized to zero by the sender, 402 and MUST be ignored by the receiver. 404 Server Address The 128-bit IPv6 address of the DHCPv6 server. 406 The Server Address field of DUID-SA, which is the IPv6 address of the 407 DHCPv6 server, MUST be a CGA. 409 In the server-relay-client scenarios, a DHCPv6 server knows a client 410 is behind relay(s) if it receives a Relay-forward DHCPv6 message. 411 Then it will reply a Relay-reply message with the server's source CGA 412 address being carried in the Server Address Type DUID, which is in 413 the payload. In this way, the receiver, a DHCPv6 client can get the 414 server's source CGA address for CGA verification. 416 All the payloads, including DUID-SA, are protected by signature 417 option by the definition of section 5.1 and 5.2. 419 6. Processing Rules and Behaviors 421 6.1. Processing Rules of Sender 423 The sender of a Secure DHCPv6 message could be a DHCPv6 server, a 424 DHCPv6 relay agent or a DHCPv6 client. 426 The node MUST have the following information in order to create 427 Secure DHCPv6 messages: 429 CGA parameters Any information required to construct CGAs, as 430 described in [RFC3972]. 432 Keypair A public-private key pair. The public key used 433 for constructing the signature MUST be the same 434 in CGA parameters. 436 CGA flag A flag that indicates whether CGA is used or 437 not. 439 To support Secure DHCPv6, the Secure DHCPv6 enabled sender MUST 440 construct the DHCPv6 message following the rules defined 441 in [RFC3315]. The sender MUST use a CGA, which be constructed as 442 specified in Section 4 of [RFC3972], as the source address, unless 443 they are sent with the unspecified source address. 445 A Secure DHCPv6 message MUST contains both the CGA option and the 446 Signature option. 448 The CGA option is constructed according to the rules presented in 449 Section 5.1 and in [RFC3972]. The public key in the field is the one 450 associated with the CGA, which is also the source address in the 451 message header. 453 The Signature option MUST be constructed as explained in Section 5.2. 454 It protects all DHCPv6 options (including the CGA option) except for 455 the Signature option itself and the Authentication Option, the 456 message header and the message payload 458 When constructing a Relay-reply message, a DHCPv6 server MUST include 459 an OPTION_SERVERID [RFC3315] and put its CGA in the Server Address 460 field of the DUID in the OPTION_SERVERID. By applying this rule, the 461 CGA of the DHCPv6 server will not be lost when the Relay-reply 462 message passes relay agents so that the client can verify CGA address 463 and signature. 465 6.2. Processing Rules of Receiver 467 By receiving a DHCPv6 message, a Secure DHCPv6 enabled receiver MUST 468 discard the DHCPv6 message if either the CGA option or the Signature 469 option absents. 471 The receiving node MUST verify the source CGA address of the DHCPv6 472 message by using the public key of the DHCPv6 message sender, CGA 473 Parameters and the algorithm described in Section 5 of [RFC3972]. The 474 inputs to the algorithm are the source address, as used in IP header, 475 and the CGA Parameters field. In the relay scenarios, a DHCPv6 server 476 obtains the CGA of a client from the peer address field in the Relay- 477 forward message. A DHCPv6 client obtains the CGA of a server from the 478 Server Address field of the DUID in the OPTION_SERVERID. 480 If the CGA verification is successful, the recipient proceeds with a 481 more time-consuming cryptographic check of the signature. Note that 482 even if the CGA verification succeeds, no claims about the validity 483 of the use can be made until the signature has been checked. 485 The receiving node MUST verify the Signature option as follows: the 486 Key Hash field MUST indicate the use of a known public key, the one 487 learned from a preceding CGA option in the same message. The 488 signature field verification MUST show that the signature has been 489 calculated as specified in Section 5.2. 491 Only the messages that get through both CGA and signature 492 verifications are accepted as secured DHCPv6 messages and continue to 493 be handled for their contained DHCPv6 options as defined 494 in [RFC3315]. Messages that do not pass all the above tests MUST be 495 discarded. 497 Furthermore, the node that supports the verification of the Secure 498 DHCPv6 messages MAY record the following information: 500 Minbits The minimum acceptable key length for public 501 keys used in the generation of CGAs. An upper 502 limit MAY also be set for the amount of 503 computation needed when verifying packets that 504 use these security associations. The appropriate 505 lengths SHOULD be set according to the signature 506 algorithm and also following prudent 507 cryptographic practice. For example, minimum 508 length 1024 and upper limit 2048 may be used for 509 RSA [RSA]. 511 6.3. Processing Rules of Relay Agent 513 To support Secure DHCPv6, Relay Agents MUST follow the same 514 processing rules defined in [RFC3315]. 516 A relay agent MAY verify the CGA and signature as a receiver before 517 relay the DHCPv6 message further, following verification procedure 518 define in Section 6.2. In the case of failure, it MUST discard the 519 DHCPv6 message. 521 In the relay scenarios, because relay agent restructures the DHCPv6 522 messages, a downstream receiver would not find the sender's source 523 CGA address in the DHCPv6 message header. 525 In the client-relay-server scenarios, "The relay agent copies the 526 source address from the IP datagram in which the message was received 527 from the client into the peer-address field in the Relay-forward 528 message" [RFC3315]. Therefore, the CGA of a client will not be lost 529 during the relay processing from the client to the server. The 530 receiver, a DHCPv6 server, can find the sender's source CGA address 531 in the peer-address field for CGA verification. 533 During the relay processing from the server to the client, when the 534 relay agent constructs the Relay-reply message the server's IP 535 address is replaced by the relay's IP address. In order to make the 536 CGA of the DHCPv6 server reach the client, DUID-SA, described in 537 Section 5.3, MUST be used. A relay will not change the 538 OPTION_SERVERID when processing Relay-reply message from a DHCPv6 539 server, so that the CGA of the DHCPv6 server will not be lost when 540 the Relay-reply message passes the Relay Agent. 542 Relay agents MAY also added its own CGA option and signature option 543 in the Relay-forward or Relay-reply messages. By receiving such 544 messages, the downstream receiver MUST verify CGA and signature from 545 the relay agent, and CGA and signature from the original sender. 547 7. Security Considerations 549 This document provides new security features to the DHCPv6 protocol. 551 Using CGA as source addresses of DHCPv6 servers, relays or, also in 552 DHCPv6 message exchanging provides the source address ownership 553 verification and data integrity protection. 555 The Secure DHCPv6 mechanism is based on the precondition that the 556 receiver has known the CGA of senders. For example, to prevent DHCPv6 557 server spoofing, the clients should be pre-notified the DHCPv6 server 558 CGA. The clients may decline the DHCPv6 messages from other servers, 559 which may be fake servers. The pre-notification operation also needs 560 to be protected, which is out of scope. 562 DHCPv6 nodes without CGAs or the DHCPv6 messages that use unspecific 563 addresses cannot be protected. 565 Downgrade attacks cannot be avoided if nodes are configured to accept 566 both secured and unsecured messages. A future specification may 567 provide a mechanism on how to treat unsecured DHCPv6 messages. One 568 simple solution may be that Secure DHCPv6 is mandated on all servers, 569 relay agents and clients on a certain link. 571 As stated in CGA definition [RFC3972], link-local CGAs are more 572 vulnerable because the same prefix is used by all IPv6 nodes. 573 Therefore, when link-local CGAs are used by the DHCPv6 clients, it is 574 recommended to use a slightly higher Sec value, for example Sec=1 for 575 now. When higher Sec values are used, the relative advantage of 576 attacking link-local addresses becomes insignificant. 578 Impacts of collision attacks on current uses of CGAs are analyzed in 579 [RFC4982]. The basic idea behind collision attacks, as described in 580 Section 4 of [RFC4270], is on the non-repudiation feature of hash 581 algorithms. However, CGAs do not provide non-repudiation features. 582 Therefore, as [RFC4982] points out CGA-based protocols, including 583 Secure DHCPv6 defined in this document, are not affected by collision 584 attacks on hash functions. 586 [RFC6273] has analyzed possible threats to the hash algorithms used 587 in SEND. Since the Secure DHCPv6 defined in this document uses the 588 same hash algorithms in similar way like SEND (except that Secure 589 DHCPv6 has not used PKIX Certificate), analysis results could be 590 applied as well: current attacks on hash functions do not constitute 591 any practical threat to the digital signatures used in the signature 592 algorithm in the Secure DHCPv6. Attacks on CGAs, as described in 593 [RFC4982], will compromise the security of Secure DHCPv6 and they 594 need to be addressed by encoding the hash algorithm information into 595 the CGA as specified in [RFC4982]. 597 8. IANA Considerations 599 This document defines two new DHCPv6 [RFC3315] options, which MUST be 600 assigned Option Type values within the option numbering space for 601 DHCPv6 messages: 603 The CGA Parameter Option (TBA1), described in Section 5.1. 605 The Signature Option (TBA2), described in Section 5.2. 607 This document defines a new DHCPv6 DUID, which MUST be assigned DUID 608 Type values within the DHCPv6 DUID Type numbering space: 610 The DUID-SA (TBA3), described in Section 5.3. 612 This document defines three new registries that have been created and 613 are maintained by IANA. Initial values for these registries are given 614 below. Future assignments are to be made through Standards Action 615 [RFC5226]. Assignments for each registry consist of a name, a value 616 and a RFC number where the registry is defined. 618 Hash Algorithm id (HA-id). The values in this name space are 16-bit 619 unsigned integers. The following initial values are assigned for HA- 620 id in this document: 622 Name | Value | RFCs 623 -------------------+---------+------------ 624 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 RSASSA-PKCS1-v1_5 | 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 SHA-1 | 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. 643 (The tag value has been generated randomly by the editor of this 644 specification. It may replaced by any IANA-allocated value when the 645 specification is published.) 647 9. Acknowledgments 649 The authors would like to thank Bernie Volz, Ted Lemon, Ralph Dorms, 650 Jari Arkko, Sean Turner, Stephen Kent and other members of the IETF 651 DHC & CSI working groups for their valuable comments. 653 10. References 655 10.1. Normative References 657 [RFC3315] R. Droms, et al., "Dynamic Host Configure Protocol for 658 IPv6", RFC3315, July 2003. 660 [RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972, 661 March 2005. 663 [RFC4982] M. Bagnulo, J. Arkko, "Support for Multiple Hash Algorithms 664 in Cryptographically Generated Addresses (CGAs)", RFC4982, 665 July 2007. 667 [RFC5905] D. Mills, J. Martin, Ed., J. Burbank and W. Kasch, "Network 668 Time Protocol Version 4: Protocol and Algorithms 669 Specification", RFC 5905, June 2010. 671 10.2. Informative References 673 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 674 Requirement Levels", c, March 1997. 676 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 677 Hashes in Internet Protocols", RFC 4270, November 2005. 679 [RFC5226] T. Narten and H. Alvestrand, "Guidelines for Writing an 680 IANA Considerations Section in RFCs", RFC 5226, May 2008. 682 [RFC6273] A. Kukec, S. Krishnan and S. Jiang "The Secure Neighbor 683 Discovery (SEND) Hash Threat Analysis", RFC 6274, June 684 2011. 686 [NewHash] S.Bellovin and E. Rescorla, "Deploying a New Hash 687 Algorithm", November 2005. 689 [RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1", 690 PKCS 1, November 2002. 692 [sha-1] National Institute of Standards and Technology, "Secure 693 Hash Standard", FIBS PUB 180-1, April 1995, 694 http://www.itl.nist.gov/fipspubs/fip180-1.htm. 696 Author's Addresses 698 Sheng Jiang 699 Huawei Technologies Co., Ltd 700 Q14, Huawei Campus 701 No.156 Beiqing Road 702 Hai-Dian District, Beijing 100095 703 P.R. China 704 EMail: jiangsheng@huawei.com 706 Sean Shen 707 CNNIC 708 4, South 4th Street, Zhongguancun 709 Beijing 100190 710 P.R. China 711 EMail: shenshuo@cnnic.cn