idnits 2.17.1 draft-ietf-dhc-sedhcpv6-00.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 (November 21, 2013) is 3808 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 normative reference: RFC 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group S. Jiang 3 Internet-Draft Huawei Technologies Co., Ltd 4 Intended status: Standards Track S. Shen 5 Expires: May 25, 2014 CNNIC 6 November 21, 2013 8 Secure DHCPv6 with Public Key 9 draft-ietf-dhc-sedhcpv6-00 11 Abstract 13 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables 14 DHCPv6 servers to pass configuration parameters. It offers 15 configuration flexibility. If not secured, DHCPv6 is vulnerable to 16 various attacks, particularly spoofing attacks. This document 17 analyzes the security issues of DHCPv6 and specifies a Secure DHCPv6 18 mechanism for communication between DHCPv6 client and server. This 19 mechanism is based on public/private key pairs. The authority of the 20 sender may depend on either pre-configuration mechanism or Public Key 21 Infrastructure. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 25, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language and Terminology . . . . . . . . . . . . 3 59 3. Security Overview of DHCPv6 . . . . . . . . . . . . . . . . . 3 60 4. Secure DHCPv6 Overview . . . . . . . . . . . . . . . . . . . 4 61 4.1. New Components . . . . . . . . . . . . . . . . . . . . . 5 62 4.2. Support for algorithm agility . . . . . . . . . . . . . . 5 63 5. Extensions for Secure DHCPv6 . . . . . . . . . . . . . . . . 5 64 5.1. Public Key Option . . . . . . . . . . . . . . . . . . . . 6 65 5.2. Certificate Option . . . . . . . . . . . . . . . . . . . 6 66 5.3. Signature Option . . . . . . . . . . . . . . . . . . . . 7 67 6. Processing Rules and Behaviors . . . . . . . . . . . . . . . 8 68 6.1. Processing Rules of Sender . . . . . . . . . . . . . . . 8 69 6.2. Processing Rules of Recipient . . . . . . . . . . . . . . 9 70 6.3. Processing Rules of Relay Agent . . . . . . . . . . . . . 10 71 6.4. Timestamp Check . . . . . . . . . . . . . . . . . . . . . 10 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 75 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 14 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 78 11.2. Informative References . . . . . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6, [RFC3315]) 84 enables DHCPv6 servers to pass configuration parameters. It offers 85 configuration flexibility. If not secured, DHCPv6 is vulnerable to 86 various attacks, particularly spoofing attacks. 88 This document analyzes the security issues of DHCPv6 in details. 89 This document provides mechanisms for improving the security of 90 DHCPv6 between client and server: 92 o the identity of a DHCPv6 message sender, which can be a DHCPv6 93 server or a client, can be verified by a recipient. 95 o the integrity of DHCPv6 messages can be checked by the recipient 96 of the message. 98 Note: this secure mechanism in this document does not protect the 99 relay-relevant options, either added by a relay agent toward a server 100 or added by a server toward a relay agent, are considered less 101 vulnerable, because they are only transported within operator 102 networks. Communication between a server and a relay agent, and 103 communication between relay agents, may be secured through the use of 104 IPsec, as described in section 21.1 in [RFC3315]. 106 The security mechanisms specified in this document is based on self- 107 generated public/private key pairs. It also integrates timestamps 108 for anti-replay. The authentication procedure defined in this 109 document may depend on either deployed Public Key Infrastructure 110 (PKI, [RFC5280]) or pre-configured sender's public key. However, the 111 deployment of PKI or pre-configuration is out of the scope. 113 Secure DHCPv6 is applicable in environments where physical security 114 on the link is not assured (such as over wireless) and attacks on 115 DHCPv6 are a concern. 117 2. Requirements Language and Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in 122 [RFC2119] when they appear in ALL CAPS. When these words are not in 123 ALL CAPS (such as "should" or "Should"), they have their usual 124 English meanings, and are not to be interpreted as [RFC2119] key 125 words. 127 3. Security Overview of DHCPv6 129 DHCPv6 is a client/server protocol that provides managed 130 configuration of devices. It enables DHCPv6 server to automatically 131 configure relevant network parameters on clients. In the basic 132 DHCPv6 specification [RFC3315], security of DHCPv6 message can be 133 improved. 135 The basic DHCPv6 specifications can optionally authenticate the 136 origin of messages and validate the integrity of messages using an 137 authentication option with a symmetric key pair. [RFC3315] relies 138 on pre-established secret keys. For any kind of meaningful 139 security, each DHCPv6 client would need to be configured with its 140 own secret key; [RFC3315] provides no mechanism for doing this. 142 For the key of the hash function, there are two key management 143 mechanisms. Firstly, the key management is done out of band, 144 usually through some manual process. For example, operators can 145 set up a key database for both servers and clients which the 146 client obtains a key before running DHCPv6. 148 Manual key distribution runs counter to the goal of minimizing the 149 configuration data needed at each host. [RFC3315] provides an 150 additional mechanism for preventing off-network timing attacks 151 using the Reconfigure message: the Reconfigure Key authentication 152 method. However, this method provides no message integrity or 153 source integrity check. This key is transmitted in plaintext. 155 In comparison, the public/private key security mechanism allows 156 the keys to be generated by the sender, and allows the public key 157 database on the recipient to be populated opportunistically or 158 manually, depending on the degree of confidence desired in a 159 specific application. PKI security mechanism is simpler in the 160 local key management respect. 162 4. Secure DHCPv6 Overview 164 To solve the above mentioned security issues, this document 165 introduces the use of public/private key pair mechanism into DHCPv6, 166 also with timestamp. The authority of the sender may depend on 167 either pre-configuration mechanism or PKI. By combining with the 168 signatures, sender identity can be verified and messages protected. 170 This document introduces a Secure DHCPv6 mechanism that uses a public 171 /private key pair to secure the DHCPv6 protocol. It has two modes; 172 in both modes, the sender has a public/private key pair. In the 173 first mode, the public key of the sender is pre-shared with the 174 recipient, either opportunistically or through a manual process. In 175 the second mode, the sender has a certificate for its public key, 176 signed by a Certificate Authority that is trusted by the recipient. 177 It is possible for the same public key to be used with different 178 recipients in both modes. 180 In this document, we introduce a public key option, a certificate 181 option and a signature options with a corresponding verification 182 mechanism. Timestamp is integrated into signature options. A DHCPv6 183 message (from a server or a client), with either a public key or 184 certificate option, and carrying a digital signature, can be verified 185 by the recipient for both the timestamp and authentication, then 186 process the payload of the DHCPv6 message only if the validation is 187 successful. Because the sender can be a DHCPv6 server or a client, 188 the end-to-end security protection can be from DHCPv6 servers to or 189 clients, or from clients to DHCPv6 servers. 191 This improves communication security of DHCPv6 messages. The 192 authentication options [RFC3315] may also be used for replay 193 protection. 195 4.1. New Components 197 The components of the solution specified in this document are as 198 follows: 200 o The node generates a public/private key pair. A DHCPv6 option is 201 defined that carries the public key. 203 The node may also obtain a certificate from a Certificate 204 Authority that can be used to establish the trustworthiness of the 205 node. A second option is defined to carry the certificate. 206 Because the certificate contains the public key, there is never a 207 need to send both options at the same time. 209 o A signature generated using the private key that protects the 210 integrity of the DHCPv6 messages and authenticates the identity of 211 the sender. 213 o A timestamp, to detect and prevent packet replay. The secure 214 DHCPv6 nodes need to meet some accuracy requirements and be synced 215 to global time, while the timestamp checking mechanism allows a 216 configurable time value for clock drift. 218 4.2. Support for algorithm agility 220 Hash functions are used to provide message integrity checks. In 221 order to provide a means of addressing problems that may emerge in 222 the future with existing hash algorithms, as recommended in 223 [RFC4270], this document provides a mechanism for negotiating the use 224 of more secure hashes in the future. 226 In addition to hash algorithm agility, this document also provides a 227 mechanism for signature algorithm agility. 229 The support for algorithm agility in this document is mainly a 230 unilateral notification mechanism from sender to recipient. If the 231 recipient does not support the algorithm used by the sender, it 232 cannot authenticate the message. Senders in a same administrative 233 domain are not required to upgrade to a new algorithm simultaneously. 235 5. Extensions for Secure DHCPv6 236 This section extends DHCPv6. Three new options have been defined. 237 The new options MUST be supported in the Secure DHCPv6 message 238 exchange. 240 5.1. Public Key Option 242 The Public Key option carries the public key of the sender. The 243 format of the Public Key option is described as follows: 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | OPTION_Public_Key | option-len | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | | 251 . Public Key (variable length) . 252 . . 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 option-code OPTION_PK_PARAMETER (TBA1). 257 option-len Length of public key in octets. 259 Public Key A variable-length field containing public key. The 260 key MUST be represented as a lower-case hexadecimal 261 string with the most significant octet of the key 262 first. 264 5.2. Certificate Option 266 The Certificate option carries the certificate of the sender. The 267 format of the Certificate option is described as follows: 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | OPTION_Certificate | option-len | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | | 275 . Certificate (variable length) . 276 . . 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 option-code OPTION_CERT_PARAMETER (TBA2). 281 option-len Length of certificate in octets. 283 Certificate A variable-length field containing certificate. The 284 encoding of certificate and certificate data MUST 285 be in format as defined in Section 3.6, [RFC5996]. 287 5.3. Signature Option 289 The Signature option allows public key-based signatures to be 290 attached to a DHCPv6 message. The Signature option could be any 291 place within the DHCPv6 message. It protects the entire DHCPv6 292 header and options, except for the Authentication Option. The format 293 of the Signature option is described as follows: 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | OPTION_SIGNATURE | option-len | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | HA-id | SA-id | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Timestamp (64-bit) | 303 | | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | | 306 . Signature (variable length) . 307 . . 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 option-code OPTION_SIGNATURE (TBA3). 312 option-len 12 + Length of Signature field in octets. 314 HA-id Hash Algorithm id. The hash algorithm is used for 315 computing the signature result. This design is 316 adopted in order to provide hash algorithm agility. 317 The value is from the Hash Algorithm for Secure 318 DHCPv6 registry in IANA. The initial values are 319 assigned for SHA-1 is 0x0001. 321 SA-id Signature Algorithm id. The signature algorithm is 322 used for computing the signature result. This 323 design is adopted in order to provide signature 324 algorithm agility. The value is from the Signature 325 Algorithm for Secure DHCPv6 registry in IANA. The 326 initial values are assigned for RSASSA-PKCS1-v1_5 327 is 0x0001. 329 Timestamp The current time of day (NTP-format timestamp 330 [RFC5905] in UTC (Coordinated Universal Time), a 331 64-bit unsigned fixed-point number, in seconds 332 relative to 0h on 1 January 1900.). It can reduce 333 the danger of replay attacks. 335 Signature A variable-length field containing a digital 336 signature. The signature value is computed with 337 the hash algorithm and the signature algorithm, 338 as described in HA-id and SA-id. The signature 339 constructed by using the sender's private key 340 protects the following sequence of octets: 342 1. The DHCPv6 message header. 344 2. All DHCPv6 options including the Signature 345 option (fill the signature field with zeroes) 346 except for the Authentication Option. 348 The signature filed MUST be padded, with all 0, to 349 the next octet boundary if its size is not an even 350 multiple of 8 bits. The padding length depends on 351 the signature algorithm, which is indicated in the 352 SA-id field. 354 Note: if both signature and authentication option are presented, 355 signature option does not protect authentication option. It is 356 because both needs to apply hash algorithm to whole message, so there 357 must be a clear order and there could be only one last-created 358 option. In order to avoid update RFC3315 because of changing auth 359 option, the authors chose not include authentication option in the 360 signature. 362 6. Processing Rules and Behaviors 364 6.1. Processing Rules of Sender 366 The sender of a Secure DHCPv6 message could be a DHCPv6 server or a 367 DHCPv6 client. 369 The node must have a public/private key pair in order to create 370 Secure DHCPv6 messages. The node may have a certificate which is 371 signed by a CA trusted by both sender and recipient. 373 To support Secure DHCPv6, the Secure DHCPv6 enabled sender MUST 374 construct the DHCPv6 message following the rules defined in 375 [RFC3315]. 377 A Secure DHCPv6 message, except for Relay-forward and Relay-reply 378 messages, MUST contain either a the Public Key or Certificate option, 379 which MUST contructed as explained in Section 5.1 or Section 5.2. 381 A Secure DHCPv6 message, except for Relay-forward and Relay-reply 382 messages, MUST contain the Signature option, which MUST be 383 constructed as explained in Section 5.3. It protects the message 384 header and the message payload and all DHCPv6 options except for the 385 Signature option itself and the Authentication Option. Within the 386 Signature option the Timestamp field SHOULD be set to the current 387 time, according to sender's real time clock. 389 A Relay-forward and relay-reply message MUST NOT contain any Public 390 Key or Certificate option or Signature Option. 392 6.2. Processing Rules of Recipient 394 When receiving a DHCPv6 message, except for Relay-Forward and Relay- 395 Reply messages, a Secure DHCPv6 enabled recipient SHOULD discard the 396 DHCPv6 message if the Signature option is absent, or both the Public 397 Key and Certificate option is absent, or both the Public Key and 398 Certificate option are presented. If all three options are absent, 399 the recipient MAY fall back the unsecure DHCPv6 model. 401 The recipient SHOULD first check the authority of this sender. If 402 the sender uses a public key, the recipient SHOULD validate it by 403 finding a match public key from the local trust public key list, 404 which is pre-configured or recorded from previous communications. A 405 local trust public key list is a data table maintained by the 406 recipient. It restores public keys from all trustworthy senders. A 407 fast search index may be created for this data table. If the sender 408 uses certificate, the recipient SHOULD validate the sender's 409 certificate following the rules defined in [RFC5280]. An 410 implementation may then create a local trust certificate record. 412 The recipient may choose to further process the message from a sender 413 for which no authorization information exists. By recording the key 414 that was used by the sender, when the first time it is seen, the 415 recipient can make a leap of faith that the sender is trustworthy. 416 If no evidence to the contrary surfaces, the recipient can then 417 validate the sender as trustworthy when it subsequently sees the same 418 key used to sign messages from the same server. 420 At this point, the recipient has either recognized the authorization 421 of the sender, or decided to attempt a leap of faith. The recipient 422 MUST now authenticate the sender by verifying the Signature and 423 checking timestamp. The order of two procedures is left as an 424 implementation decision. It is RECOMMENDED to check timestamp first, 425 because signature verification is much more computationally 426 expensive. 428 The signature field verification MUST show that the signature has 429 been calculated as specified in Section 5.3. Only the messages that 430 get through both the signature verifications and timestamp check are 431 accepted as secured DHCPv6 messages and continue to be handled for 432 their contained DHCPv6 options as defined in [RFC3315]. Messages 433 that do not pass the above tests MUST be discarded or treated as 434 unsecure messages. 436 The recipient MAY record the verified public key or certificate for 437 future authentications. 439 Furthermore, the node that supports the verification of the Secure 440 DHCPv6 messages MAY record the following information: 442 Minbits The minimum acceptable key length for public keys. An upper 443 limit MAY also be set for the amount of computation needed when 444 verifying packets that use these security associations. The 445 appropriate lengths SHOULD be set according to the signature 446 algorithm and also following prudent cryptographic practice. For 447 example, minimum length 1024 and upper limit 2048 may be used for 448 RSA [RSA]. 450 A Relay-forward or Relay-reply message with any Public Key, 451 Certificate or the Signature option is invilad. The message SHOULD 452 be discarded silently. 454 6.3. Processing Rules of Relay Agent 456 To support Secure DHCPv6, relay agents just need to follow the same 457 processing rules defined in [RFC3315]. There is nothing more the 458 relay agents have to do, either verify the messages from client or 459 server, or add any secure DHCPv6 options. Actually, be definition in 460 this document, relay agents MUST NOT add any secure DHCPv6 options. 462 6.4. Timestamp Check 464 Recipients SHOULD be configured with an allowed timestamp Delta 465 value, a "fuzz factor" for comparisons, and an allowed clock drift 466 parameter. The recommended default value for the allowed Delta is 467 300 seconds (5 minutes); for fuzz factor 1 second; and for clock 468 drift, 0.01 second. 470 Note: the Timestamp mechanism is based on the assumption that 471 communication peers have rough synchronized clocks, with certain 472 allowed clock drift. So, accurate clock is not necessary. If one 473 has a clock too far from the current time, the timestamp mechanism 474 would not work. 476 To facilitate timestamp checking, each recipient SHOULD store the 477 following information for each sender, from which at least one 478 accepted secure DHCPv6 message is successfully verified (for both 479 timestamp check and signature verification): 481 o The receive time of the last received and accepted DHCPv6 message. 482 This is called RDlast. 484 o The time stamp in the last received and accepted DHCPv6 message. 485 This is called TSlast. 487 An verified (for both timestamp check and signature verification) 488 secure DHCPv6 message initiates the update of the above variables in 489 the recipient's record. 491 Recipients MUST check the Timestamp field as follows: 493 o When a message is received from a new peer (i.e., one that is not 494 stored in the cache), the received timestamp, TSnew, is checked, 495 and the message is accepted if the timestamp is recent enough to 496 the reception time of the packet, RDnew: 498 -Delta < (RDnew - TSnew) < +Delta 500 After the signature verification also successes, the RDnew and 501 TSnew values SHOULD be stored in the cache as RDlast and TSlast. 503 o When a message is received from a known peer (i.e., one that 504 already has an entry in the cache), the timestamp is checked 505 against the previously received Secure DHCPv6 message: 507 TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz 509 If this inequality does not hold, the recipient SHOULD silently 510 discard the message. If, on the other hand, the inequality holds, 511 the recipient SHOULD process the message. 513 Moreover, if the above inequality holds and TSnew > TSlast, the 514 recipient SHOULD update RDlast and TSlast after the signature 515 verification also successes. Otherwise, the recipient MUST NOT 516 update RDlast or TSlast. 518 An implementation MAY use some mechanism such as a timestamp cache to 519 strengthen resistance to replay attacks. When there is a very large 520 number of nodes on the same link, or when a cache filling attack is 521 in progress, it is possible that the cache holding the most recent 522 timestamp per sender will become full. In this case, the node MUST 523 remove some entries from the cache or refuse some new requested 524 entries. The specific policy as to which entries are preferred over 525 others is left as an implementation decision. 527 7. Security Considerations 529 This document provides new security features to the DHCPv6 protocol. 531 Using public key based security mechanism and its verification 532 mechanism in DHCPv6 message exchanging provides the authentication 533 and data integrity protection. Timestamp mechanism provides anti- 534 replay function. 536 The Secure DHCPv6 mechanism is based on the pre-condition that the 537 recipient knows the public key of senders or the sender's certificate 538 can be verified through a trust CA. It prevents DHCPv6 server 539 spoofing. The clients may decline the DHCPv6 messages from unknown/ 540 unverified servers, which may be fake servers; or may prefer DHCPv6 541 messages from known/verified servers over unsigned messages or 542 messages from unknown/unverified servers. The pre-configuration 543 operation also needs to be protected, which is out of scope. The 544 deployment of PKI is also out of scope. 546 However, when a DHCPv6 client first encounters a new public key or 547 new unverified certificate, it can make a leap of faith. If the 548 DHCPv6 server that used that public key or certificate is in fact 549 legitimate, then all future communication with that DHCPv6 server can 550 be protected by caching the public key. This does not provide 551 complete security, but it limits the opportunity to mount an attack 552 on a specific DHCPv6 client to the first time it communicates with a 553 new DHCPv6 server. 555 Downgrade attacks cannot be avoided if nodes are configured to accept 556 both secured and unsecured messages. A future specification may 557 provide a mechanism on how to treat unsecured DHCPv6 messages. 559 [RFC6273] has analyzed possible threats to the hash algorithms used 560 in SEND. Since the Secure DHCPv6 defined in this document uses the 561 same hash algorithms in similar way to SEND, analysis results could 562 be applied as well: current attacks on hash functions do not 563 constitute any practical threat to the digital signatures used in the 564 signature algorithm in the Secure DHCPv6. 566 A window of vulnerability for replay attacks exists until the 567 timestamp expires. Secure DHCPv6 nodes are protected against replay 568 attacks as long as they cache the state created by the message 569 containing the timestamp. The cached state allows the node to 570 protect itself against replayed messages. However, once the node 571 flushes the state for whatever reason, an attacker can re-create the 572 state by replaying an old message while the timestamp is still valid. 574 Attacks against time synchronization protocols such as NTP [RFC5905] 575 may cause Secure DHCPv6 nodes to have an incorrect timestamp value. 576 This can be used to launch replay attacks, even outside the normal 577 window of vulnerability. To protect against these attacks, it is 578 recommended that Secure DHCPv6 nodes keep independently maintained 579 clocks or apply suitable security measures for the time 580 synchronization protocols. 582 8. IANA Considerations 584 This document defines three new DHCPv6 [RFC3315] options. The IANA 585 is requested to assign values for these three options from the DHCP 586 Option Codes table of the DHCPv6 Parameters registry. The three 587 options are: 589 The Public Key Option (TBA1), described in Section 5.1. 591 The Certificate Option (TBA2), described in Section 5.2. 593 The Signature Option (TBA3), described in Section 5.3. 595 The IANA is also requested to add two new registry tables to the 596 DHCPv6 Parameters registry. The two tables are the Hash Algorithm 597 for Secure DHCPv6 table and the Signature Algorithm for Secure DHCPv6 598 table. 600 Initial values for these registries are given below. Future 601 assignments are to be made through Standards Action [RFC5226]. 602 Assignments for each registry consist of a name, a value and a RFC 603 number where the registry is defined. 605 Hash Algorithm for Secure DHCPv6. The values in this table are 606 16-bit unsigned integers. The following initial values are assigned 607 for Hash Algorithm for Secure DHCPv6 in this document: 609 Name | Value | RFCs 610 -------------------+---------+------------ 611 Reserved | 0x0000 | this document 612 SHA-1 | 0x0001 | this document 613 SHA-256 | 0x0002 | this document 615 Signature Algorithm for Secure DHCPv6. The values in this table are 616 16-bit unsigned integers. The following initial values are assigned 617 for Signature Algorithm for Secure DHCPv6 in this document: 619 Name | Value | RFCs 620 -------------------+---------+------------ 621 Reserved | 0x0000 | this document 622 RSASSA-PKCS1-v1_5 | 0x0001 | this document 624 9. Acknowledgements 626 The authors would like to thank Bernie Volz, Ted Lemon, Ralph Droms, 627 Jari Arkko, Sean Turner, Stephen Kent, Thomas Huth, David Schumacher, 628 Dacheng Zhang, Francis Dupont, Tomek Mrugalski, Gang Chen and other 629 members of the IETF DHC working groups for their valuable comments. 631 This document was produced using the xml2rfc tool [RFC2629]. 633 10. Change log [RFC Editor: Please remove] 635 draft-ietf-dhc-sedhcpv6-00: adopted by DHC WG. 2013-11-19. 637 draft-jiang-dhc-sedhcpv6-02: removed protection between relay agent 638 and server due to complexity, following the comments from Ted Lemon, 639 Bernie Volz. 2013-10-16. 641 draft-jiang-dhc-sedhcpv6-01: update according to review comments from 642 Ted Lemon, Bernie Volz, Ralph Droms. Separated Public Key/ 643 Certificate option into two options. Refined many detailed 644 processes. 2013-10-08. 646 draft-jiang-dhc-sedhcpv6-00: original version, this draft is a 647 replacement of draft-ietf-dhc-secure-dhcpv6, which reached IESG and 648 dead because of consideration regarding to CGA. The authors followed 649 the suggestion from IESG making a general public key based mechanism. 650 2013-06-29. 652 11. References 654 11.1. Normative References 656 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 657 Requirement Levels", BCP 14, RFC 2119, March 1997. 659 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 660 and M. Carney, "Dynamic Host Configuration Protocol for 661 IPv6 (DHCPv6)", RFC 3315, July 2003. 663 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 664 Housley, R., and W. Polk, "Internet X.509 Public Key 665 Infrastructure Certificate and Certificate Revocation List 666 (CRL) Profile", RFC 5280, May 2008. 668 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 669 Time Protocol Version 4: Protocol and Algorithms 670 Specification", RFC 5905, June 2010. 672 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 673 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 674 5996, September 2010. 676 11.2. Informative References 678 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 679 June 1999. 681 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 682 Hashes in Internet Protocols", RFC 4270, November 2005. 684 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 685 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 686 May 2008. 688 [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure 689 Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, 690 June 2011. 692 [RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1, 693 PKCS 1", November 2002. 695 Authors' Addresses 697 Sheng Jiang 698 Huawei Technologies Co., Ltd 699 Q14, Huawei Campus, No.156 Beiqing Road 700 Hai-Dian District, Beijing, 100095 701 P.R. China 703 Email: jiangsheng@huawei.com 704 Sean Shen 705 CNNIC 706 4, South 4th Street, Zhongguancun 707 Beijing 100190 708 P.R. China 710 Email: shenshuo@cnnic.cn