idnits 2.17.1 draft-jiang-dhc-sedhcpv6-02.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 (October 16, 2013) is 3846 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: April 19, 2014 CNNIC 6 October 16, 2013 8 Secure DHCPv6 with Public Key 9 draft-jiang-dhc-sedhcpv6-02 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 April 19, 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 331 [RFC5905] in UTC (Coordinated Universal Time), a 332 64-bit unsigned fixed-point number, in seconds 333 relative to 0h on 1 January 1900.). It can reduce 334 the danger of replay attacks. 336 Signature A variable-length field containing a digital 337 signature. The signature value is computed with 338 the hash algorithm and the signature algorithm, 339 as described in HA-id and SA-id. The signature 340 constructed by using the sender's private key 341 protects the following sequence of octets: 343 1. The DHCPv6 message header. 345 2. All DHCPv6 options including the Signature 346 option (fill the signature field with zeroes) 347 except for the Authentication Option. 349 The signature filed MUST be padded, with all 0, to 350 the next octet boundary if its size is not an even 351 multiple of 8 bits. The padding length depends on 352 the signature algorithm, which is indicated in the 353 SA-id field. 355 Note: if both signature and authentication option are presented, 356 signature option does not protect authentication option. It is 357 because both needs to apply hash algorithm to whole message, so there 358 must be a clear order and there could be only one last-created 359 option. In order to avoid update RFC3315 because of changing auth 360 option, the authors chose not include authentication option in the 361 signature. 363 6. Processing Rules and Behaviors 365 6.1. Processing Rules of Sender 367 The sender of a Secure DHCPv6 message could be a DHCPv6 server or a 368 DHCPv6 client. 370 The node must have a public/private key pair in order to create 371 Secure DHCPv6 messages. The node may have a certificate which is 372 signed by a CA trusted by both sender and recipient. 374 To support Secure DHCPv6, the Secure DHCPv6 enabled sender MUST 375 construct the DHCPv6 message following the rules defined in 376 [RFC3315]. 378 A Secure DHCPv6 message, except for Relay-forward and Relay-reply 379 messages, MUST contain either a the Public Key or Certificate option, 380 which MUST contructed as explained in Section 5.1 or Section 5.2. 382 A Secure DHCPv6 message, except for Relay-forward and Relay-reply 383 messages, MUST contain the Signature option, which MUST be 384 constructed as explained in Section 5.3. It protects the message 385 header and the message payload and all DHCPv6 options except for the 386 Signature option itself and the Authentication Option. Within the 387 Signature option the Timestamp field SHOULD be set to the current 388 time, according to sender's real time clock. 390 A Relay-forward and relay-reply message MUST NOT contain any Public 391 Key or Certificate option or Signature Option. 393 6.2. Processing Rules of Recipient 395 When receiving a DHCPv6 message, except for Relay-Forward and Relay- 396 Reply messages, a Secure DHCPv6 enabled recipient SHOULD discard the 397 DHCPv6 message if the Signature option is absent, or both the Public 398 Key and Certificate option is absent, or both the Public Key and 399 Certificate option are presented. If all three options are absent, 400 the recipient MAY fall back the unsecure DHCPv6 model. 402 The recipient SHOULD first check the authority of this sender. If 403 the sender uses a public key, the recipient SHOULD validate it by 404 finding a match public key from the local trust public key list, 405 which is pre-configured or recorded from previous communications. A 406 local trust public key list is a data table maintained by the 407 recipient. It restores public keys from all trustworthy senders. A 408 fast search index may be created for this data table. If the sender 409 uses certificate, the recipient SHOULD validate the sender's 410 certificate following the rules defined in [RFC5280]. An 411 implementation may then create a local trust certificate record. 413 The recipient may choose to further process the message from a sender 414 for which no authorization information exists. By recording the key 415 that was used by the sender, when the first time it is seen, the 416 recipient can make a leap of faith that the sender is trustworthy. 417 If no evidence to the contrary surfaces, the recipient can then 418 validate the sender as trustworthy when it subsequently sees the same 419 key used to sign messages from the same server. 421 At this point, the recipient has either recognized the authorization 422 of the sender, or decided to attempt a leap of faith. The recipient 423 MUST now authenticate the sender by verifying the Signature and 424 checking timestamp. The order of two procedures is left as an 425 implementation decision. It is RECOMMENDED to check timestamp first, 426 because signature verification is much more computationally 427 expensive. 429 The signature field verification MUST show that the signature has 430 been calculated as specified in Section 5.3. Only the messages that 431 get through both the signature verifications and timestamp check are 432 accepted as secured DHCPv6 messages and continue to be handled for 433 their contained DHCPv6 options as defined in [RFC3315]. Messages 434 that do not pass the above tests MUST be discarded or treated as 435 unsecure messages. 437 The recipient MAY record the verified public key or certificate for 438 future authentications. 440 Furthermore, the node that supports the verification of the Secure 441 DHCPv6 messages MAY record the following information: 443 Minbits The minimum acceptable key length for public keys. An upper 444 limit MAY also be set for the amount of computation needed when 445 verifying packets that use these security associations. The 446 appropriate lengths SHOULD be set according to the signature 447 algorithm and also following prudent cryptographic practice. For 448 example, minimum length 1024 and upper limit 2048 may be used for 449 RSA [RSA]. 451 A Relay-forward or Relay-reply message with any Public Key, 452 Certificate or the Signature option is invilad. The message SHOULD 453 be discarded silently. 455 6.3. Processing Rules of Relay Agent 457 To support Secure DHCPv6, relay agents just need to follow the same 458 processing rules defined in [RFC3315]. There is nothing more the 459 relay agents have to do, either verify the messages from client or 460 server, or add any secure DHCPv6 options. Actually, be definition in 461 this document, relay agents MUST NOT add any secure DHCPv6 options. 463 6.4. Timestamp Check 465 Recipients SHOULD be configured with an allowed timestamp Delta 466 value, a "fuzz factor" for comparisons, and an allowed clock drift 467 parameter. The recommended default value for the allowed Delta is 468 300 seconds (5 minutes); for fuzz factor 1 second; and for clock 469 drift, 0.01 second. 471 Note: the Timestamp mechanism is based on the assumption that 472 communication peers have rough synchronized clocks, with certain 473 allowed clock drift. So, accurate clock is not necessary. If one 474 has a clock too far from the current time, the timestamp mechanism 475 would not work. 477 To facilitate timestamp checking, each recipient SHOULD store the 478 following information for each sender, from which at least one 479 accepted secure DHCPv6 message is successfully verified (for both 480 timestamp check and signature verification): 482 o The receive time of the last received and accepted DHCPv6 message. 483 This is called RDlast. 485 o The time stamp in the last received and accepted DHCPv6 message. 486 This is called TSlast. 488 An verified (for both timestamp check and signature verification) 489 secure DHCPv6 message initiates the update of the above variables in 490 the recipient's record. 492 Recipients MUST check the Timestamp field as follows: 494 o When a message is received from a new peer (i.e., one that is not 495 stored in the cache), the received timestamp, TSnew, is checked, 496 and the message is accepted if the timestamp is recent enough to 497 the reception time of the packet, RDnew: 499 -Delta < (RDnew - TSnew) < +Delta 501 After the signature verification also successes, the RDnew and 502 TSnew values SHOULD be stored in the cache as RDlast and TSlast. 504 o When a message is received from a known peer (i.e., one that 505 already has an entry in the cache), the timestamp is checked 506 against the previously received Secure DHCPv6 message: 508 TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz 510 If this inequality does not hold, the recipient SHOULD silently 511 discard the message. If, on the other hand, the inequality holds, 512 the recipient SHOULD process the message. 514 Moreover, if the above inequality holds and TSnew > TSlast, the 515 recipient SHOULD update RDlast and TSlast after the signature 516 verification also successes. Otherwise, the recipient MUST NOT 517 update RDlast or TSlast. 519 An implementation MAY use some mechanism such as a timestamp cache to 520 strengthen resistance to replay attacks. When there is a very large 521 number of nodes on the same link, or when a cache filling attack is 522 in progress, it is possible that the cache holding the most recent 523 timestamp per sender will become full. In this case, the node MUST 524 remove some entries from the cache or refuse some new requested 525 entries. The specific policy as to which entries are preferred over 526 others is left as an implementation decision. 528 7. Security Considerations 530 This document provides new security features to the DHCPv6 protocol. 532 Using public key based security mechanism and its verification 533 mechanism in DHCPv6 message exchanging provides the authentication 534 and data integrity protection. Timestamp mechanism provides anti- 535 replay function. 537 The Secure DHCPv6 mechanism is based on the pre-condition that the 538 recipient knows the public key of senders or the sender's certificate 539 can be verified through a trust CA. It prevents DHCPv6 server 540 spoofing. The clients may decline the DHCPv6 messages from unknown/ 541 unverified servers, which may be fake servers; or may prefer DHCPv6 542 messages from known/verified servers over unsigned messages or 543 messages from unknown/unverified servers. The pre-configuration 544 operation also needs to be protected, which is out of scope. The 545 deployment of PKI is also out of scope. 547 However, when a DHCPv6 client first encounters a new public key or 548 new unverified certificate, it can make a leap of faith. If the 549 DHCPv6 server that used that public key or certificate is in fact 550 legitimate, then all future communication with that DHCPv6 server can 551 be protected by caching the public key. This does not provide 552 complete security, but it limits the opportunity to mount an attack 553 on a specific DHCPv6 client to the first time it communicates with a 554 new DHCPv6 server. 556 Downgrade attacks cannot be avoided if nodes are configured to accept 557 both secured and unsecured messages. A future specification may 558 provide a mechanism on how to treat unsecured DHCPv6 messages. 560 [RFC6273] has analyzed possible threats to the hash algorithms used 561 in SEND. Since the Secure DHCPv6 defined in this document uses the 562 same hash algorithms in similar way to SEND, analysis results could 563 be applied as well: current attacks on hash functions do not 564 constitute any practical threat to the digital signatures used in the 565 signature algorithm in the Secure DHCPv6. 567 A window of vulnerability for replay attacks exists until the 568 timestamp expires. Secure DHCPv6 nodes are protected against replay 569 attacks as long as they cache the state created by the message 570 containing the timestamp. The cached state allows the node to 571 protect itself against replayed messages. However, once the node 572 flushes the state for whatever reason, an attacker can re-create the 573 state by replaying an old message while the timestamp is still valid. 575 Attacks against time synchronization protocols such as NTP [RFC5905] 576 may cause Secure DHCPv6 nodes to have an incorrect timestamp value. 577 This can be used to launch replay attacks, even outside the normal 578 window of vulnerability. To protect against these attacks, it is 579 recommended that Secure DHCPv6 nodes keep independently maintained 580 clocks or apply suitable security measures for the time 581 synchronization protocols. 583 8. IANA Considerations 585 This document defines three new DHCPv6 [RFC3315] options. The IANA 586 is requested to assign values for these three options from the DHCP 587 Option Codes table of the DHCPv6 Parameters registry. The three 588 options are: 590 The Public Key Option (TBA1), described in Section 5.1. 592 The Certificate Option (TBA2), described in Section 5.2. 594 The Signature Option (TBA3), described in Section 5.3. 596 The IANA is also requested to add two new registry tables to the 597 DHCPv6 Parameters registry. The two tables are the Hash Algorithm 598 for Secure DHCPv6 table and the Signature Algorithm for Secure DHCPv6 599 table. 601 Initial values for these registries are given below. Future 602 assignments are to be made through Standards Action [RFC5226]. 603 Assignments for each registry consist of a name, a value and a RFC 604 number where the registry is defined. 606 Hash Algorithm for Secure DHCPv6. The values in this table are 607 16-bit unsigned integers. The following initial values are assigned 608 for Hash Algorithm for Secure DHCPv6 in this document: 610 Name | Value | RFCs 611 -------------------+---------+------------ 612 Reserved | 0x0000 | this document 613 SHA-1 | 0x0001 | this document 614 SHA-256 | 0x0002 | this document 616 Signature Algorithm for Secure DHCPv6. The values in this table are 617 16-bit unsigned integers. The following initial values are assigned 618 for Signature Algorithm for Secure DHCPv6 in this document: 620 Name | Value | RFCs 621 -------------------+---------+------------ 622 Reserved | 0x0000 | this document 623 RSASSA-PKCS1-v1_5 | 0x0001 | this document 625 9. Acknowledgements 627 The authors would like to thank Bernie Volz, Ted Lemon, Ralph Droms, 628 Jari Arkko, Sean Turner, Stephen Kent, Thomas Huth, David Schumacher, 629 Dacheng Zhang, Francis Dupont and other members of the IETF DHC 630 working groups for their valuable comments. 632 This document was produced using the xml2rfc tool [RFC2629]. 634 10. Change log [RFC Editor: Please remove] 636 draft-jiang-dhc-sedhcpv6-01: removed protection between relay agent 637 and server due to complexity, following the comments from Ted Lemon, 638 Bernie Volz. 2013-10-16. 640 draft-jiang-dhc-sedhcpv6-01: update according to review comments from 641 Ted Lemon, Bernie Volz, Ralph Droms. Separated Public Key/ 642 Certificate option into two options. Refined many detailed 643 processes. 2013-10-08. 645 draft-jiang-dhc-sedhcpv6-00: original version, this draft is a 646 replacement of draft-ietf-dhc-secure-dhcpv6, which reached IESG and 647 dead because of consideration regarding to CGA. The authors followed 648 the suggestion from IESG making a general public key based mechanism. 649 2013-06-29. 651 11. References 653 11.1. Normative References 655 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 656 Requirement Levels", BCP 14, RFC 2119, March 1997. 658 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 659 and M. Carney, "Dynamic Host Configuration Protocol for 660 IPv6 (DHCPv6)", RFC 3315, July 2003. 662 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 663 Housley, R., and W. Polk, "Internet X.509 Public Key 664 Infrastructure Certificate and Certificate Revocation List 665 (CRL) Profile", RFC 5280, May 2008. 667 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 668 Time Protocol Version 4: Protocol and Algorithms 669 Specification", RFC 5905, June 2010. 671 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 672 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 673 5996, September 2010. 675 11.2. Informative References 677 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 678 June 1999. 680 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 681 Hashes in Internet Protocols", RFC 4270, November 2005. 683 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 684 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 685 May 2008. 687 [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure 688 Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, 689 June 2011. 691 [RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1, 692 PKCS 1", November 2002. 694 Authors' Addresses 696 Sheng Jiang 697 Huawei Technologies Co., Ltd 698 Q14, Huawei Campus, No.156 Beiqing Road 699 Hai-Dian District, Beijing, 100095 700 P.R. China 702 Email: jiangsheng@huawei.com 703 Sean Shen 704 CNNIC 705 4, South 4th Street, Zhongguancun 706 Beijing 100190 707 P.R. China 709 Email: shenshuo@cnnic.cn