idnits 2.17.1 draft-ietf-dhc-secure-dhcpv6-07.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 (September 14, 2012) is 4214 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: Proposed Standard Sean Shen 4 Update: RFC3315 CNNIC 5 Expires: March 17, 2013 September 14, 2012 7 Secure DHCPv6 Using CGAs 8 draft-ietf-dhc-secure-dhcpv6-07.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 March 17, 2013. 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 attacks. This document 53 analyzes the security issues of DHCPv6 and specifies a Secure DHCPv6 54 mechanism 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. Signature Option for Relay-Reply Message ............... 9 68 5.4. DUID-SA Type .......................................... 10 69 6. Processing Rules and Behaviors ............................. 11 70 6.1. Processing Rules of Sender ............................ 11 71 6.2. Processing Rules of Receiver .......................... 12 72 6.3. Processing Rules of Relay Agent ....................... 13 73 7. Security Considerations .................................... 14 74 8. IANA Considerations ........................................ 16 75 9. Acknowledgments ............................................ 17 76 10. References ................................................ 17 77 10.1. Normative References ................................. 17 78 10.2. Informative References ............................... 17 80 1. Introduction 82 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6 [RFC3315]) 83 enables DHCPv6 servers to pass configuration parameters. It offers 84 configuration flexibility. If not secured, DHCPv6 is vulnerable to 85 various attacks, particularly spoofing attacks. 87 This document analyzes the security issues of DHCPv6 in details. This 88 document provides mechanisms for improving the security of DHCPv6: 90 - the address of a DHCPv6 message sender, which can be a DHCPv6 91 server, a relay agent or a client, can be verified by a 92 receiver. 94 - The integrity of DHCPv6 messages can be checked by the receiver 95 of the message. 97 The security mechanisms specified in this document is based on 98 Cryptographically Generated Addresses (CGA [RFC3972]). 100 Secure DHCPv6 is applicable in environments where physical security 101 on the link is not assured (such as over wireless) and attacks on 102 DHCPv6 are a concern. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. Security Overview of DHCPv6 112 DHCPv6 is a client/server protocol that provides managed 113 configuration of devices. It enables DHCPv6 server to automatically 114 configure relevant network parameters on clients. In the basic DHCPv6 115 specification [RFC3315], security of DHCPv6 message can be improved 116 in a few aspects. 118 a) In the basic DHCPv6 specifications, the DHCPv6 server uses a 119 "regular" IPv6 address for itself. It is possible for a malicious 120 attacker to use a fake address to spoof or launch an attack. See 121 Section 23, "Security Considerations" of [RFC3315] for more 122 details. 124 CGA-based security mechanism can provide proof of ownership of 125 source addresses, which prevents such attacks. 127 b) The basic DHCPv6 specifications can optionally authenticate the 128 origin of messages and validate the integrity of messages using an 129 authentication option with a symmetric key pair. [RFC3315] relies 130 on pre-established secret keys. For any kind of meaningful 131 security, each DHCPv6 client would need to be configured with its 132 own secret key; [RFC3315] provides no mechanism for doing this. 134 For the key of the hash function, there are two key management 135 mechanisms. Firstly, the key management is out of band, usually 136 manual, i.e. operators set up key database for both server and 137 client before running DHCPv6. Usually multiple keys are deployed 138 one a time and key id is used to specify which key is used. 140 Manual key distribution runs counter to the goal of minimizing the 141 configuration data needed at each host. [RFC3315] provides an 142 additional mechanism for preventing off-network timing attacks 143 using the Reconfigure message: the Reconfigure Key authentication 144 method. However, this method provides no message integrity or 145 source integrity check. This key is transmitted in plaintext. 147 Comparing to this, the CGA-based security mechanism only require a 148 key pair on the sender. The key management mechanism is very 149 simple. 151 c) Communication between a server and a relay agent, and 152 communication between relay agents, can be secured through the use 153 of IPsec, as described in section 21.1 in [RFC3315]. However, 154 IPsec is quite complicated. A simpler security mechanism, which 155 can be easier to deploy, is desirable. 157 4. Secure DHCPv6 Overview 159 To solve the abovementioned security issues, we introduce the use of 160 CGAs into DHCPv6. CGAs are introduced in [RFC3972]. By combining CGAs 161 with signatures based on the CGA-associated key pair, address 162 ownership can be verified and messages protected, "without a 163 certification authority or any security infrastructure." [RFC3972] 165 This document introduces a Secure DHCPv6 mechanism that uses CGAs to 166 secure the DHCPv6 protocol. It assumes: the secured DHCPv6 message 167 sender already has a CGA and its corresponding CGA parameters; and 168 the receiver has already been have the CGAs of the sender, which may 169 be pre-configured or recorded from previous communications; in the 170 server-relay and relay-server scenarios, the receiver has also been 171 pre-configured the associated CGA parameters of the sender. 173 In this document, we introduce a CGA option with a mechanism for 174 proving address ownership and two signature options with a 175 corresponding verification mechanism. A DHCPv6 message (from a 176 server, a relay agent or a client), with a CGA as source address and 177 carry a digital signature, can be verified by the receiver for both 178 the CGA and signature, then process the payload of the DHCPv6 message 179 only if the validation is successful. 181 This improves communication security of DHCPv6 messages. The 182 authentication options can also be used for replay protection. 184 Because the sender can be a DHCPv6 server, a relay agent or a client, 185 the end-to-end security protection can be from DHCPv6 servers to 186 relay agents or clients, or from clients to DHCPv6 servers. Relay 187 agents MAY add its own Secure DHCPv6 options in Relay-Forward 188 messages when transmitting client messages to the server. 190 4.1. New Components 192 The components of the solution specified in this document are as 193 follows: 195 - CGAs are used to make sure that the sender of a DHCPv6 message 196 is the "owner" of the claimed address. A public-private key 197 pair has been generated by a node itself before it can claim an 198 address. A new DHCPv6 option, the CGA Parameter Option, is used 199 to carry the public key and associated parameters. 201 - Signatures signed by private key protect the integrity of the 202 DHCPv6 messages and authenticate the identity of their sender. 204 - Server Address type of DUID is used to carry server's source 205 address in the server-relay-client scenarios. The receiver gets 206 the server's source CGA address for CGA verification. 208 4.2. Support for algorithm agility 210 Hash functions are the fundamental security mechanism, including CGAs 211 in this document. "...they have two security properties: to be one 212 way and collision free." "The recent attacks have demonstrated that 213 one of those security properties is not true." [RFC4270] It is 214 theoretically possible to perform collision attacks against the 215 "collision-free" property. 217 Following the approach recommended by [RFC4270] and [NewHash], recent 218 analysis shows none of these attacks are currently possible, 219 according to [RFC6273]. "The broken security property will not affect 220 the overall security of many specific Internet protocols, the 221 conservative security approach is to change hash algorithms." 222 [RFC4270] 224 However, these attacks indicate the possibility of future real-world 225 attacks. Therefore, we have to take into account that attacks will 226 improved in the future, and provide a support for multiple hash 227 algorithms. Our mechanism, in this document, supports not only hash 228 algorithm agility but also signature algorithm agility. 230 Support for hash agility within CGAs has been defined in [RFC4982]. 231 The usage of CGAs in this document SHOULD also obey [RFC4982], too. 233 The support for algorithm agility in this document is mainly a 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. Three new options and a new DUID type 242 have been defined. The new options MUST be supported in the Secure 243 DHCPv6 message exchange. The new DUID type MUST be supported in 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 the entire 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 | | Padding | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 option-code OPTION_SIGNATURE (TBA2). 311 option-len 32 + Length of Signature field and Padding field 312 in octets. 314 HA-id Hash Algorithm id. The hash algorithm is used 315 for computing the signature result. This design 316 is adopted in order to provide hash algorithm 317 agility. The value is from the Hash Algorithm 318 for Secure DHCPv6 registry in IANA. The initial 319 values are assigned for SHA-1 is 0x0001. 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 signature 324 algorithm agility. The value is from the 325 Signature Algorithm for Secure DHCPv6 registry 326 in IANA. The initial values are assigned for 327 RSASSA-PKCS1-v1_5 is 0x0001. 329 HA-id-KH Hash Algorithm id for Key Hash. Hash algorithm 330 used for producing the Key Hash field in the 331 Signature option. This design is adopted in 332 order to provide hash algorithm agility. The 333 value is from the Hash Algorithm for Secure 334 DHCPv6 registry in IANA. The initial values are 335 assigned for SHA-1 is 0x0001. 337 Reserved A 16-bit field reserved for future use. The 338 value MUST be initialized to zero by the sender, 339 and MUST be ignored by the receiver. 341 Timestamp The current time of day (NTP-format timestamp 342 [RFC5905], a 64-bit unsigned fixed-point number, 343 in seconds relative to 0h on 1 January 1900.). 344 It can reduce the danger of replay attacks. 346 Key Hash A 128-bit field containing the most significant 347 (leftmost) 128 bits of the hash value of the 348 public key used for constructing the signature. 349 The hash algorithm is indicated in the HA-id-KH 350 field. The field is taken over the presentation 351 used in the Public Key field of the CGA 352 Parameters data structure carried in the CGA 353 option. Its purpose is to associate the 354 signature to a particular key known by the 355 receiver. Such a key can either be stored in the 356 certificate cache of the receiver or be received 357 in the CGA option in the same message. 359 Signature A variable-length field containing a digital 360 signature. The signature value is computed with 361 the hash algorithm and the signature algorithm, 362 as described in HA-id and SA-id. The signature 363 constructed by using the sender's private key 364 protects the following sequence of octets: 366 1. The 128-bit CGA Message Type tag value for 367 Secure DHCPv6, 0x81be a1eb 0021 ce7e caa9 4090 368 0665 d2e0 02c2. 370 2. The 128-bit Source IPv6 Address. 372 3. The 128-bit Destination IPv6 Address. 374 4. The DHCPv6 message header. 376 5. All DHCPv6 options except for the Signature 377 option and the Authentication Option. 379 6. The content between the option-len field and 380 the signature field in this Signature option, in 381 the format described above. 383 Padding This variable-length field contains padding, as 384 many bits long as remain after the end of the 385 signature. This padding is only needed if the 386 length of signature is not a multiple of 8 387 bits. 389 Note: a Relay-Reply message is constructed by a DHCPv6 server in 390 segments. The server first constructs the server message for client, 391 which includes a Signature Option that covers the server message. In 392 the signed data, the destination address is the address of the 393 client. It then constructs the Relay-Reply message by encapsulating 394 the server message into a Relay Message Option. If there is 395 additional option for relay, the server MUST include a Signature 396 Option for Relay-Reply Message, defined below, which covers the 397 entire Relay-Reply message. In the signed data, the destination 398 address is the address of the target relay agent. 400 5.3. Signature Option for Relay-Reply Message 402 In the server-relay-client scenario, the Relay-Reply message may be 403 carried two signatures: one covers the server message for client, one 404 covers the entire relay-reply message. In order to save the double 405 transmission of 32 byte duplicated data, which include HA-id, SA-id, 406 SA-id-HK, Timestamp and Key Hash, another signature option is 407 designed for Relay-Reply message only. On the receiver - the relay 408 agent, these data can be obtained from the Signature Option within 409 the Relay Message option. The format of the Signature Option for 410 Relay-Reply message is described as follows: 412 0 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | OPTION_SIGNATURE_RRM | option-len | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | | 418 . Signature (variable length) . 419 . . 420 . +-+-+-+-+-+ 421 | | Padding | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 option-code OPTION_SIGNATURE_RRM (TBA3). 426 option-len Length of Signature field and Padding field in 427 octets. 429 Signature The same with Section 5.3. 431 Padding The same with Section 5.3. 433 5.4. DUID-SA Type 435 Server Address Type DUID (DUID-SA) allows IPv6 address of DHCPv6 436 servers can be carried in DHCPv6 message payload. 438 The following diagram illustrates the format of a DUID-SA: 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | TBA3 | | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 444 | | 445 | Server Address (128-bit) | 446 | | 447 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 Type-code DUID-SA Type (TBA4) 453 Server Address The 128-bit IPv6 address of the DHCPv6 server. 455 The Server Address field of DUID-SA, which is the IPv6 address of the 456 DHCPv6 server, MUST be a CGA in the Secure DHCPv6. 458 In the server-relay-client scenarios, a DHCPv6 server knows a client 459 is behind relay(s) if it receives a Relay-forward DHCPv6 message. 460 Then it will reply a Relay-reply message. Within the payload of 461 Replay-reply message, the server's source CGA address is carried in 462 the Server Address Type DUID that is encapsulated in a Relay Message 463 option. In this way, the receiver, a DHCPv6 client can get the 464 server's source CGA address for CGA verification. 466 All the payloads, including DUID-SA, are protected by signature 467 option by the definition of section 5.1 and 5.2. 469 If there is DUID-SA in the server message and its address is 470 different from the source address of IP packet, the client MUST use 471 the address in DUID-SA for CGA verification. 473 6. Processing Rules and Behaviors 475 6.1. Processing Rules of Sender 477 The sender of a Secure DHCPv6 message could be a DHCPv6 server, a 478 DHCPv6 relay agent or a DHCPv6 client. 480 The node MUST have the following information in order to create 481 Secure DHCPv6 messages: 483 CGA parameters Any information required to construct CGAs, as 484 described in [RFC3972]. 486 Keypair A public-private key pair. The public key used 487 for constructing the signature MUST be the same 488 in CGA parameters. 490 CGA flag A flag that indicates whether CGA is used or 491 not. 493 To support Secure DHCPv6, the Secure DHCPv6 enabled sender MUST 494 construct the DHCPv6 message following the rules defined 495 in [RFC3315]. The sender MUST use a CGA, which be constructed as 496 specified in Section 4 of [RFC3972], as the source address, unless 497 they are sent with the unspecified source address. 499 A Secure DHCPv6 message MUST contain both the CGA option and the 500 Signature option, except for the Relay-forward and Relay-reply 501 Messages. If a relay agent adds its own options in Relay-forward 502 message, it MUST contain the Signature option. If it does not any add 503 new options it MUST NOT add either the CGA option or the Signature 504 option into Relay-forward message. If a server adds addition options 505 for relay agents in Relay-reply message, it MUST contain the 506 Signature Option for Relay-Reply Message. If it does not add any 507 addition options, it MUST NOT add the CGA option, the Signature 508 option, or the Signature Option for Relay-Reply Message into the 509 Relay-reply message. 511 The CGA option is constructed according to the rules presented in 512 Section 5.1 and in [RFC3972]. The public key in the field is the one 513 associated with the CGA, which is also the source address in the 514 message header. 516 The Signature option MUST be constructed as explained in Section 5.2. 517 It protects the message header and the message payload and all DHCPv6 518 options (including the CGA option) except for the Signature option 519 itself and the Authentication Option. The Signature Option for 520 Relay-Reply Message MUST be constructed as explained in Section 5.3. 522 When constructing a Relay-reply message, a DHCPv6 server MUST include 523 an OPTION_SERVERID [RFC3315] and put its CGA in the Server Address 524 field of the DUID in the OPTION_SERVERID in the Relay Message Option. 525 By applying this rule, the CGA of the DHCPv6 server will not be lost 526 when the relay agents decapsulate the Relay-reply messages, so that 527 the client can verify CGA address and signature. 529 6.2. Processing Rules of Receiver 531 When receiving a DHCPv6 message (except for Relay-Forward and 532 Relay-Reply messages), a Secure DHCPv6 enabled receiver SHOULD 533 discard the DHCPv6 message if either the CGA option or the Signature 534 option is absent. If both options are absent, the receiver MAY fall 535 back the unsecure DHCPv6 model. 537 The receiving node MUST verify the source CGA address of the DHCPv6 538 message by using the public key of the DHCPv6 message sender, CGA 539 Parameters and the algorithm described in Section 5 of [RFC3972]. The 540 inputs to the algorithm are the source address, as used in IPv6 541 header, and the CGA Parameters field. In the relay scenarios, a 542 DHCPv6 server obtains the CGA of a client from the peer address field 543 in the Relay-forward message. A DHCPv6 client obtains the CGA of a 544 server from the Server Address field of the DUID in the 545 OPTION_SERVERID. 547 If the CGA verification is successful, the recipient proceeds with a 548 more time-consuming cryptographic check of the signature. Note that 549 even if the CGA verification succeeds, no claims about the validity 550 of the use can be made until the signature has been checked. 552 The receiving node MUST verify the Signature option as follows: the 553 Key Hash field MUST indicate the use of a known public key, the one 554 learned from a preceding CGA option in the same message. The 555 signature field verification MUST show that the signature has been 556 calculated as specified in Section 5.2. 558 Only the messages that get through both CGA and signature 559 verifications are accepted as secured DHCPv6 messages and continue to 560 be handled for their contained DHCPv6 options as defined 561 in [RFC3315]. Messages that do not pass all the above tests MUST be 562 discarded or treated as unsecure messages. 564 The receiver MAY record the verified CGA for future authentications. 566 Furthermore, the node that supports the verification of the Secure 567 DHCPv6 messages MAY record the following information: 569 Minbits The minimum acceptable key length for public 570 keys used in the generation of CGAs. An upper 571 limit MAY also be set for the amount of 572 computation needed when verifying packets that 573 use these security associations. The appropriate 574 lengths SHOULD be set according to the signature 575 algorithm and also following prudent 576 cryptographic practice. For example, minimum 577 length 1024 and upper limit 2048 may be used for 578 RSA [RSA]. 580 A Relay-forward message without any addition option to Relay Message 581 option or a Relay-forward message with both addition options and the 582 Signature option is accepted for a Secure DHCPv6 enabled server. 583 Otherwise, the message SHOULD be discarded or treated as unsecure 584 message. If Signature option is presented in the Relay-forward 585 message, the CGA verification and signature verification are needed. 586 The server obtains the CGA parameters of the relay agents from 587 pre-configured data. The server MUST also verify the CGA and 588 signature for the encapsulated client DHCPv6 message in the Relay 589 Message Option. The client CGA address is obtained from the 590 peer-address field in the Relay-forward message. 592 A Relay-reply message without any addition option to Relay Message 593 option or a Relay-reply message with both addition options and the 594 Signature Option for Relay-Reply message is accepted for a Secure 595 DHCPv6 enabled server. Otherwise, the message SHOULD be discarded or 596 treated as unsecure message. If the Signature Option for Relay-Reply 597 message is presented in the Relay-reply message, the CGA verification 598 and signature verification are needed. The relay agents obtain the 599 CGA parameters of the server from pre-configured data. It obtains 600 HA-id, SA-id, SA-id-HK, Timestamp and Key Hash from Signature option 601 encapsulated in the Relay Message option. 603 6.3. Processing Rules of Relay Agent 605 To support Secure DHCPv6, relay agents MUST follow the same 606 processing rules defined in [RFC3315]. 608 In the client-relay-server scenario, the relay agent MAY verify the 609 CGA and signature as a receiver before relaying the client message 610 further, following verification procedure define in Section 6.2. In 611 the case of failure, it MUST discard the DHCPv6 message. However, 612 this does not save the load of the DHCPv6 server. The server still 613 MUST verify the CGA and signature by itself in order to prevent the 614 attack between the relay agent and server. 616 In the server-relay-client scenario, if the Signature Option for 617 Relay-Reply message is presented, the relay agent MUST verify the CGA 618 and signature before relaying the server message further, following 619 verification procedure define in Section 6.2. In the case of failure, 620 it MUST discard the DHCPv6 message. 622 In the relay scenarios, because relay agents restructure the DHCPv6 623 messages, a downstream receiver would not find the sender's source 624 CGA address in the DHCPv6 message header. 626 In the client-relay-server scenarios, "The relay agent copies the 627 source address from the IP datagram in which the message was received 628 from the client into the peer-address field in the Relay-forward 629 message" [RFC3315]. Therefore, the CGA of a client will not be lost 630 during the relay processing from the client to the server. The 631 receiver, a DHCPv6 server, can find the sender's source CGA address 632 in the peer-address field for CGA verification. 634 During the relay processing from the server to the client, when the 635 relay agent constructs the IPv6 header for the server message, the 636 source IPv6 address is the relay's IPv6 address, rather than the 637 server's IPv6 address. In order to make the CGA of the DHCPv6 server 638 reach the client, DUID-SA, described in Section 5.4, MUST be used. 639 Defined in [RFC6422], "the implicit requirement that relay agents not 640 modify the content of encapsulation payloads as they are relayed back 641 toward clients", A relay agent will not change the OPTION_SERVERID 642 when processing Relay-reply message from a DHCPv6 server, so that the 643 CGA of the DHCPv6 server will not be lost when the Relay-reply 644 message is decapsulated in the relay agent. The relay agent MAY also 645 verify the CGA and signature for the encapsulated DHCPv6 message in 646 the Relay Message Option. This can be helpful if the DHCPv6 response 647 traverses a separate administrative domain, or if the relay agent is 648 in a separate administrative domain. However, this is not necessary 649 because the DHCPv6 client validation will catch any modification to 650 the response. 652 7. Security Considerations 654 This document provides new security features to the DHCPv6 protocol. 656 Using CGA as source addresses with its verification mechanism in 657 DHCPv6 message exchanging provides the source address ownership 658 verification and data integrity protection. 660 The Secure DHCPv6 mechanism is based on the pre-condition that the 661 receiver knows the CGA of senders. For example, to prevent DHCPv6 662 server spoofing, the clients should be pre-configured with the DHCPv6 663 server CGA. The clients may decline the DHCPv6 messages from unknown 664 servers, which may be fake servers; or may prefer DHCPv6 messages 665 from known servers over unsigned messages or messages from unknown 666 servers. The pre-configuration operation also needs to be protected, 667 which is out of scope. 669 In the relay-server and server-relay authentication scenarios, the 670 Secure DHCPv6 mechanism is based on the pre-condition that the 671 receiver has been pre-configured with sender's CGAs and associated 672 CGA parameters. The pre-configuration operation also needs to be 673 protected, which is out of scope. 675 CGA-based signatures cannot be used to authenticate a transaction if 676 the CGA key isn't pre-configured in the DHCPv6 client that needs to 677 authenticate the transaction. However, such a DHCPv6 client can make 678 a leap of faith when it first encounters a new CGA. If the DHCPv6 679 server that used that CGA is in fact legitimate, then all future 680 communication with that DHCPv6 server can be protected by caching the 681 CGA and the associated public key. This does not provide complete 682 security, but it limits the opportunity to mount an attack on a 683 specific DHCPv6 client to the first time it communicates with a new 684 DHCPv6 server. 686 DHCPv6 nodes without CGAs or the DHCPv6 messages that use unspecific 687 addresses cannot be protected. 689 Downgrade attacks cannot be avoided if nodes are configured to accept 690 both secured and unsecured messages. A future specification may 691 provide a mechanism on how to treat unsecured DHCPv6 messages. 693 As stated in CGA definition [RFC3972], link-local CGAs are more 694 vulnerable because the same prefix is used by all IPv6 nodes. 695 Therefore, when link-local CGAs are used by the DHCPv6 clients, it is 696 recommended to use a slightly higher Sec value, for example Sec=1 for 697 now. When higher Sec values are used, the relative advantage of 698 attacking link-local addresses becomes insignificant. 700 Impacts of collision attacks on current uses of CGAs are analyzed in 701 [RFC4982]. The basic idea behind collision attacks, as described in 702 Section 4 of [RFC4270], is on the non-repudiation feature of hash 703 algorithms. However, CGAs do not provide non-repudiation features. 704 Therefore, as [RFC4982] points out CGA-based protocols, including 705 Secure DHCPv6 defined in this document, are not affected by collision 706 attacks on hash functions. 708 [RFC6273] has analyzed possible threats to the hash algorithms used 709 in SEND. Since the Secure DHCPv6 defined in this document uses the 710 same hash algorithms in similar way to SEND (except that Secure 711 DHCPv6 has not used PKIX Certificate), analysis results could be 712 applied as well: current attacks on hash functions do not constitute 713 any practical threat to the digital signatures used in the signature 714 algorithm in the Secure DHCPv6. Attacks on CGAs, as described in 715 [RFC4982], will compromise the security of Secure DHCPv6 and they 716 need to be addressed by encoding the hash algorithm information into 717 the CGA as specified in [RFC4982]. 719 8. IANA Considerations 721 This document defines two new DHCPv6 [RFC3315] options, which MUST be 722 assigned Option Type values within the option numbering space for 723 DHCPv6 messages: 725 The CGA Parameter Option (TBA1), described in Section 5.1. 727 The Signature Option (TBA2), described in Section 5.2. 729 The Signature Option for Relay-Reply Message (TBA3), described in 730 Section 5.3. 732 This document defines a new DHCPv6 DUID, which MUST be assigned DUID 733 Type values within the DHCPv6 DUID Type numbering space: 735 The DUID-SA (TBA4), described in Section 5.4. 737 This document defines two new registries that have been created and 738 are maintained by IANA. Initial values for these registries are given 739 below. Future assignments are to be made through Standards Action 740 [RFC5226]. Assignments for each registry consist of a name, a value 741 and a RFC number where the registry is defined. 743 Hash Algorithm for Secure DHCPv6. The values in this name space are 744 16-bit unsigned integers. The following initial values are assigned 745 for Hash Algorithm for Secure DHCPv6 in this document: 747 Name | Value | RFCs 748 -------------------+---------+------------ 749 Reserved | 0x0000 | this document 750 SHA-1 | 0x0001 | this document 751 SHA-256 | 0x0002 | this document 753 Signature Algorithm for Secure DHCPv6. The values in this name space 754 are 16-bit unsigned integers. The following initial values are 755 assigned for Signature Algorithm for Secure DHCPv6 in this document: 757 Name | Value | RFCs 758 -------------------+---------+------------ 759 Reserved | 0x0000 | this document 760 RSASSA-PKCS1-v1_5 | 0x0001 | this document 762 This document defines a new 128-bit value under the CGA Message Type 763 [RFC3972] namespace, 0x81be a1eb 0021 ce7e caa9 4090 0665 d2e0 02c2. 764 (The tag value has been generated randomly by the editor of this 765 specification. It may replaced by any IANA-allocated value when the 766 specification is published.) 768 9. Acknowledgments 770 The authors would like to thank Bernie Volz, Ted Lemon, Ralph Dorms, 771 Jari Arkko, Sean Turner, Stephen Kent, Thomas Huth, David Schumacher 772 and other members of the IETF DHC and CSI working groups for their 773 valuable comments. 775 10. References 777 10.1. Normative References 779 [RFC3315] R. Droms, et al., "Dynamic Host Configure Protocol for 780 IPv6", RFC3315, July 2003. 782 [RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972, 783 March 2005. 785 [RFC4982] M. Bagnulo, J. Arkko, "Support for Multiple Hash Algorithms 786 in Cryptographically Generated Addresses (CGAs)", RFC4982, 787 July 2007. 789 [RFC5905] D. Mills, J. Martin, Ed., J. Burbank and W. Kasch, "Network 790 Time Protocol Version 4: Protocol and Algorithms 791 Specification", RFC 5905, June 2010. 793 [RFC6422] T. Lemon, and Q. Wu, "Relay-Supplied DHCP Options", RFC 794 6422, December 2011. 796 10.2. Informative References 798 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 799 Requirement Levels", c, March 1997. 801 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 802 Hashes in Internet Protocols", RFC 4270, November 2005. 804 [RFC5226] T. Narten and H. Alvestrand, "Guidelines for Writing an 805 IANA Considerations Section in RFCs", RFC 5226, May 2008. 807 [RFC6273] A. Kukec, S. Krishnan and S. Jiang "The Secure Neighbor 808 Discovery (SEND) Hash Threat Analysis", RFC 6274, June 809 2011. 811 [NewHash] S.Bellovin and E. Rescorla, "Deploying a New Hash 812 Algorithm", November 2005. 814 [RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1", 815 PKCS 1, November 2002. 817 [sha-1] National Institute of Standards and Technology, "Secure 818 Hash Standard", FIBS PUB 180-1, April 1995, 819 http://www.itl.nist.gov/fipspubs/fip180-1.htm. 821 Author's Addresses 823 Sheng Jiang 824 Huawei Technologies Co., Ltd 825 Q14, Huawei Campus 826 No.156 Beiqing Road 827 Hai-Dian District, Beijing 100095 828 P.R. China 829 EMail: jiangsheng@huawei.com 831 Sean Shen 832 CNNIC 833 4, South 4th Street, Zhongguancun 834 Beijing 100190 835 P.R. China 836 EMail: shenshuo@cnnic.cn