idnits 2.17.1 draft-jiang-dhc-sedhcpv6-01.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 08, 2013) is 3843 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 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 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 11, 2014 CNNIC 6 October 08, 2013 8 Secure DHCPv6 with Public Key 9 draft-jiang-dhc-sedhcpv6-01 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. This mechanism is based on public/private key pairs. The 19 authority of the sender may depend on either pre-configuration 20 mechanism or Public Key Infrastructure. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 11, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Language and Terminology . . . . . . . . . . . . 3 58 3. Security Overview of DHCPv6 . . . . . . . . . . . . . . . . . 3 59 4. Secure DHCPv6 Overview . . . . . . . . . . . . . . . . . . . 4 60 4.1. New Components . . . . . . . . . . . . . . . . . . . . . 5 61 4.2. Support for algorithm agility . . . . . . . . . . . . . . 5 62 5. Extensions for Secure DHCPv6 . . . . . . . . . . . . . . . . 6 63 5.1. Public Key Option . . . . . . . . . . . . . . . . . . . . 6 64 5.2. Certificate Option . . . . . . . . . . . . . . . . . . . 6 65 5.3. Signature Option . . . . . . . . . . . . . . . . . . . . 7 66 6. Processing Rules and Behaviors . . . . . . . . . . . . . . . 8 67 6.1. Processing Rules of Sender . . . . . . . . . . . . . . . 8 68 6.2. Processing Rules of Recipient . . . . . . . . . . . . . . 9 69 6.3. Processing Rules of Relay Agent . . . . . . . . . . . . . 11 70 6.4. Timestamp Check . . . . . . . . . . . . . . . . . . . . . 11 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 76 10.2. Informative References . . . . . . . . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Introduction 81 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6, [RFC3315]) 82 enables DHCPv6 servers to pass configuration parameters. It offers 83 configuration flexibility. If not secured, DHCPv6 is vulnerable to 84 various attacks, particularly spoofing attacks. 86 This document analyzes the security issues of DHCPv6 in details. 87 This document provides mechanisms for improving the security of 88 DHCPv6: 90 o the identity of a DHCPv6 message sender, which can be a DHCPv6 91 server, a relay agent or a client, can be verified by a recipient. 93 o the integrity of DHCPv6 messages can be checked by the recipient 94 of the message. 96 The security mechanisms specified in this document is based on self- 97 generated public/private key pairs. It also integrates timestamps 98 for anti-replay. The authentication procedure defined in this 99 document may depend on either deployed Public Key Infrastructure 100 (PKI, [RFC5280]) or pre-configured sender's public key. However, the 101 deployment of PKI or pre-configuration is out of the scope. 103 Secure DHCPv6 is applicable in environments where physical security 104 on the link is not assured (such as over wireless) and attacks on 105 DHCPv6 are a concern. 107 2. Requirements Language and Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in 112 [RFC2119] when they appear in ALL CAPS. When these words are not in 113 ALL CAPS (such as "should" or "Should"), they have their usual 114 English meanings, and are not to be interpreted as [RFC2119] key 115 words. 117 3. Security Overview of DHCPv6 119 DHCPv6 is a client/server protocol that provides managed 120 configuration of devices. It enables DHCPv6 server to automatically 121 configure relevant network parameters on clients. In the basic 122 DHCPv6 specification [RFC3315], security of DHCPv6 message can be 123 improved in a few respects. 125 a. The basic DHCPv6 specifications can optionally authenticate the 126 origin of messages and validate the integrity of messages using 127 an authentication option with a symmetric key pair. [RFC3315] 128 relies on pre-established secret keys. For any kind of 129 meaningful security, each DHCPv6 client would need to be 130 configured with its own secret key; [RFC3315] provides no 131 mechanism for doing this. 133 For the key of the hash function, there are two key management 134 mechanisms. Firstly, the key management is done out of band, 135 usually through some manual process. For example, operators can 136 set up a key database for both servers and clients which the 137 client obtains a key before running DHCPv6. 139 Manual key distribution runs counter to the goal of minimizing 140 the configuration data needed at each host. [RFC3315] provides 141 an additional mechanism for preventing off-network timing attacks 142 using the Reconfigure message: the Reconfigure Key authentication 143 method. However, this method provides no message integrity or 144 source integrity check. This key is transmitted in plaintext. 146 In comparison, the public/private key security mechanism allows 147 the keys to be generated by the sender, and allows the public key 148 database on the recipient to be populated opportunistically or 149 manually, depending on the degree of confidence desired in a 150 specific application. PKI security mechanism is simpler in the 151 local key management respect. 153 b. Communication between a server and a relay agent, and 154 communication between relay agents, can be secured through the 155 use of IPsec, as described in section 21.1 in [RFC3315]. 156 However, IPsec is quite complicated. A simpler security 157 mechanism, which can be easier to deploy, is desirable. 159 4. Secure DHCPv6 Overview 161 To solve the above mentioned security issues, we introduce the use of 162 public/private key pair mechanism into DHCPv6, also with timestamp. 163 The authority of the sender may depend on either pre-configuration 164 mechanism or PKI. By combining with the signatures, sender identity 165 can be verified and messages protected. 167 This document introduces a Secure DHCPv6 mechanism that uses a public 168 /private key pair to secure the DHCPv6 protocol. It has two modes; 169 in both modes, the sender has a public/private key pair. In the 170 first mode, the public key of the sender is pre-shared with the 171 recipient, either opportunistically or through a manual process. In 172 the second mode, the sender has a certificate for its public key, 173 signed by a Certificate Authority that is trust by the recipient. It 174 is possible for the same public key to be used with different 175 recipients in both modes. 177 In this document, we introduce a public key option, a certificate 178 option and a signature options with a corresponding verification 179 mechanism. Timestamp is integrated into signature options. A DHCPv6 180 message (from a server, a relay agent or a client), with either a 181 public key or certificate option, and carrying a digital signature, 182 can be verified by the recipient for both the timestamp and 183 authentication, then process the payload of the DHCPv6 message only 184 if the validation is successful. 186 This improves communication security of DHCPv6 messages. The 187 authentication options [RFC3315] may also be used for replay 188 protection. 190 Because the sender can be a DHCPv6 server, a relay agent or a client, 191 the end-to-end security protection can be from DHCPv6 servers to 192 relay agents or clients, or from clients to DHCPv6 servers. Relay 193 agents MAY add its own Secure DHCPv6 options in Relay-Forward 194 messages when transmitting client messages to the server. 196 4.1. New Components 198 The components of the solution specified in this document are as 199 follows: 201 o The node generates a public/private key pair. A DHCPv6 option is 202 defined that carries the public key. 204 The node may also obtain a certificate from a Certificate 205 Authority that can be used to establish the trustworthiness of the 206 node. A second option is defined to carry the certificate. 207 Because the certificate contains the public key, there is never a 208 need to send both options at the same time. 210 o A signature generated using the private key that protects the 211 integrity of the DHCPv6 messages and authenticates the identity of 212 the sender. 214 o A timestamp, to detect and prevent packet replay. The secure 215 DHCPv6 nodes need to meet some accuracy requirements and be synced 216 to global time, while the timestamp checking mechanism allows a 217 configurable time value for clock drift. 219 4.2. Support for algorithm agility 221 Hash functions are used to provide message integrity checks. In 222 order to provide a means of addressing problems that may emerge in 223 the future with existing hash algorithms, as recommended in 224 [RFC4270], this document provides a mechanism for negotiating the use 225 of more secure hashes in the future. 227 In addition to hash algorithm agility, this document also provides a 228 mechanism for signature algorithm agility. 230 The support for algorithm agility in this document is mainly a 231 unilateral notification mechanism from sender to recipient. If the 232 recipient does not support the algorithm used by the sender, it 233 cannot authenticate the message. Senders in a same administrative 234 domain are not required to upgrade to a new algorithm simultaneously. 236 5. Extensions for Secure DHCPv6 238 This section extends DHCPv6. Three new options have been defined. 239 The new options MUST be supported in the Secure DHCPv6 message 240 exchange. 242 5.1. Public Key Option 244 The Public Key option carries the public key of the sender. The 245 format of the Public Key option is described as follows: 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | OPTION_Public_Key | option-len | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | | 253 . Public Key (variable length) . 254 . . 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 option-code OPTION_PK_PARAMETER (TBA1). 259 option-len Length of public key in octets. 261 Public Key A variable-length field containing public key. 263 5.2. Certificate Option 265 The Certificate option carries the certificate of the sender. The 266 format of the Certificate option is described as follows: 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | OPTION_Certificate | option-len | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | | 274 . Certificate (variable length) . 275 . . 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 option-code OPTION_CERT_PARAMETER (TBA2). 279 option-len Length of certificate in octets. 281 Certificate A variable-length field containing certificate. 283 5.3. Signature Option 285 The Signature option allows public key-based signatures to be 286 attached to a DHCPv6 message. The Signature option could be any 287 place within the DHCPv6 message. It protects the entire DHCPv6 288 header and options, except for the Authentication Option. The format 289 of the Signature option is described as follows: 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | OPTION_SIGNATURE | option-len | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | HA-id | SA-id | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Timestamp (64-bit) | 299 | | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | | 302 . Signature (variable length) . 303 . . 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 option-code OPTION_SIGNATURE (TBA3). 308 option-len 12 + Length of Signature field in octets. 310 HA-id Hash Algorithm id. The hash algorithm is used for 311 computing the signature result. This design is 312 adopted in order to provide hash algorithm agility. 313 The value is from the Hash Algorithm for Secure 314 DHCPv6 registry in IANA. The initial values are 315 assigned for SHA-1 is 0x0001. 317 SA-id Signature Algorithm id. The signature algorithm is 318 used for computing the signature result. This 319 design is adopted in order to provide signature 320 algorithm agility. The value is from the Signature 321 Algorithm for Secure DHCPv6 registry in IANA. The 322 initial values are assigned for RSASSA-PKCS1-v1_5 323 is 0x0001. 325 Timestamp The current time of day (NTP-format timestamp 326 [RFC5905] in UTC (Coordinated Universal Time), a 327 64-bit unsigned fixed-point number, in seconds 328 relative to 0h on 1 January 1900.). It can reduce 329 the danger of replay attacks. 331 Signature A variable-length field containing a digital 332 signature. The signature value is computed with 333 the hash algorithm and the signature algorithm, 334 as described in HA-id and SA-id. The signature 335 constructed by using the sender's private key 336 protects the following sequence of octets: 338 1. The DHCPv6 message header. 340 2. All DHCPv6 options including the Signature 341 option (fill the signature field with zeroes) 342 except for the Authentication Option. 344 The signature filed MUST be padded, with all 0, to 345 the next octet boundary if its size is not an even 346 multiple of 8 bits. The padding length depends on 347 the signature algorithm, which is indicated in the 348 SA-id field. 350 6. Processing Rules and Behaviors 352 6.1. Processing Rules of Sender 354 The sender of a Secure DHCPv6 message could be a DHCPv6 server, a 355 DHCPv6 relay agent or a DHCPv6 client. 357 The node must have a public/private key pair in order to create 358 Secure DHCPv6 messages. The node may have a certificate which is 359 signed by a CA trusted by both sender and recipient. 361 To support Secure DHCPv6, the Secure DHCPv6 enabled sender MUST 362 construct the DHCPv6 message following the rules defined in 363 [RFC3315]. 365 A Secure DHCPv6 message MUST contain the Signature option, in which 366 Timestamp field MUST be set correctly, either a Public Key or 367 Certificate option, except for Relay-forward and Relay-reply 368 Messages. The Timestamp field SHOULD be set to the current time, 369 according to sender's real time clock. 371 If a relay agent adds its own options in a Relay-forward message, it 372 MAY contain a Signature option and one of a Public Key or Certificate 373 option. If it does not any add new options it MUST NOT add any 374 Public Key or Certificate or Signature option into Relay-forward 375 message. If there are more than a number of Relay agents (the number 376 depends on the lengths of public key and signature, typical number is 377 four) in the way and each of them adds their own options, it may 378 exceed the IPv6 MTU. However, this can be considered as a rare 379 deployment scenario. 381 Relay-reply Messages MUST NOT contain any Public Key or Certificate 382 option since it appears in the Relay Message Option. If a server 383 adds addition options for relay agents in Relay-reply message, it MAY 384 contain a Signature Option. If it does not add any addition options, 385 it MUST NOT add the Signature Option into the Relay-reply message. 387 The Signature option MUST be constructed as explained in Section 5.3. 388 It protects the message header and the message payload and all DHCPv6 389 options except for the Signature option itself and the Authentication 390 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. If 405 the sender uses certificate, the recipient SHOULD validate the 406 sender's certificate following the rules defined in [RFC5280]. An 407 implementation may then create a local trust certificate record. 409 The recipient may choose to further process the message from a sender 410 for which no authorization information exists. By recording the key 411 that was used by the sender, when the first time it is seen, the 412 recipient can make a leap of faith that the sender is trustworthy. 413 If no evidence to the contrary surfaces, the recipient can then 414 validate the sender as trustworthy when it subsequently sees the same 415 key used to sign messages from the same server. 417 At this point, the recipient has either recognized the authorization 418 of the sender, or decided to attempt a leap of faith. The recipient 419 MUST now authenticate the sender by verifying the Signature and 420 checking timestamp. The order of two procedures is left as an 421 implementation decision. It is RECOMMENDED to check timestamp first, 422 because signature verification is much more computationally 423 expensive. 425 The signature field verification MUST show that the signature has 426 been calculated as specified in Section 5.3. Only the messages that 427 get through both the signature verifications and timestamp check are 428 accepted as secured DHCPv6 messages and continue to be handled for 429 their contained DHCPv6 options as defined in [RFC3315]. Messages 430 that do not pass the above tests MUST be discarded or treated as 431 unsecure messages. 433 The recipient MAY record the verified public key or certificate for 434 future authentications. 436 Furthermore, the node that supports the verification of the Secure 437 DHCPv6 messages MAY record the following information: 439 Minbits The minimum acceptable key length for public keys. An upper 440 limit MAY also be set for the amount of computation needed when 441 verifying packets that use these security associations. The 442 appropriate lengths SHOULD be set according to the signature 443 algorithm and also following prudent cryptographic practice. For 444 example, minimum length 1024 and upper limit 2048 may be used for 445 RSA [RSA]. 447 A Relay-forward message without any addition option to Relay Message 448 option or a Relay-forward message with both addition options and the 449 Signature option is accepted for a Secure DHCPv6 enabled server. 450 Otherwise, the message SHOULD be discarded or treated as unsecure 451 message. If Signature option is presented in the Relay-forward 452 message, the signature verification and timestamp check are needed. 453 The server MUST also verify signature for the encapsulated client 454 DHCPv6 message in the Relay Message Option. 456 A Relay-reply message without any addition option to Relay Message 457 option or a Relay-reply message with both addition options and the 458 Signature Option is accepted for a Secure DHCPv6 enabled server. 459 Otherwise, the message SHOULD be discarded or treated as unsecure 460 message. If the Signature Option is presented in the Relay-reply 461 message, the signature verification and timestamp check are needed. 462 The relay agents obtain the public key or certificate of the server 463 from the Public Key or Certificate option encapsulated in the Relay 464 Message option. 466 6.3. Processing Rules of Relay Agent 468 To support Secure DHCPv6, relay agents MUST follow the same 469 processing rules defined in [RFC3315]. 471 In the client-relay-server scenario, the relay agent MAY verify the 472 signature as a recipient before relaying the client message further, 473 following verification procedure define in Section 6.2. In the case 474 of failure, it MUST discard the DHCPv6 message. However, the 475 verification procedure on relay agents does not save the load of the 476 DHCPv6 server. The server still MUST verify the signature by itself 477 in order to prevent the attack between the relay agent and server. 479 In the server-relay-client scenario, if the Signature Option and 480 addition options are presented, the relay agent MUST verify the 481 signature before relaying the server message further, following 482 verification procedure define in Section 6.2. In the case of 483 failure, it MUST discard the DHCPv6 message. 485 The relay agent MAY also verify the signature for the encapsulated 486 DHCPv6 message in the Relay Message Option. This can be helpful if 487 the DHCPv6 response traverses a separate administrative domain, or if 488 the relay agent is in a separate administrative domain. However, 489 this is not necessary because the DHCPv6 client validation will catch 490 any modification to the response. 492 6.4. Timestamp Check 494 Recipients SHOULD be configured with an allowed timestamp Delta 495 value, a "fuzz factor" for comparisons, and an allowed clock drift 496 parameter. The recommended default value for the allowed Delta is 497 300 seconds (5 minutes); for fuzz factor 1 second; and for clock 498 drift, 0.01 second. 500 To facilitate timestamp checking, each recipient SHOULD store the 501 following information for each sender: 503 o The receive time of the last received and accepted DHCPv6 message. 504 This is called RDlast. 506 o The time stamp in the last received and accepted DHCPv6 message. 507 This is called TSlast. 509 An accepted secure DHCPv6 message is any successfully verified (for 510 both timestamp check and signature verification) DHCPv6 message from 511 the given peer. It initiates the update of the above variables. 513 Recipients MUST then check the Timestamp field as follows: 515 o When a message is received from a new peer (i.e., one that is not 516 stored in the cache), the received timestamp, TSnew, is checked, 517 and the message is accepted if the timestamp is recent enough to 518 the reception time of the packet, RDnew: 520 -Delta < (RDnew - TSnew) < +Delta 522 The RDnew and TSnew values SHOULD be stored in the cache as RDlast 523 and TSlast. 525 o When a message is received from a known peer (i.e., one that 526 already has an entry in the cache), the timestamp is checked 527 against the previously received Secure DHCPv6 message: 529 TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz 531 If this inequality does not hold, the recipient SHOULD silently 532 discard the message. If, on the other hand, the inequality holds, 533 the recipient SHOULD process the message. 535 Moreover, if the above inequality holds and TSnew > TSlast, the 536 recipient SHOULD update RDlast and TSlast. Otherwise, the 537 recipient MUST NOT update RDlast or TSlast. 539 An implementation MAY use some mechanism such as a timestamp cache to 540 strengthen resistance to replay attacks. When there is a very large 541 number of nodes on the same link, or when a cache filling attack is 542 in progress, it is possible that the cache holding the most recent 543 timestamp per sender will become full. In this case, the node MUST 544 remove some entries from the cache or refuse some new requested 545 entries. The specific policy as to which entries are preferred over 546 others is left as an implementation decision. 548 7. Security Considerations 550 This document provides new security features to the DHCPv6 protocol. 552 Using public key based security mechanism and its verification 553 mechanism in DHCPv6 message exchanging provides the authentication 554 and data integrity protection. Timestamp mechanism provides anti- 555 replay function. 557 The Secure DHCPv6 mechanism is based on the pre-condition that the 558 recipient knows the public key of senders or the sender's certificate 559 can be verified through a trust CA. It prevents DHCPv6 server 560 spoofing. The clients may decline the DHCPv6 messages from unknown/ 561 unverified servers, which may be fake servers; or may prefer DHCPv6 562 messages from known/verified servers over unsigned messages or 563 messages from unknown/unverified servers. The pre-configuration 564 operation also needs to be protected, which is out of scope. The 565 deployment of PKI is also out of scope. 567 However, when a DHCPv6 client first encounters a new public key or 568 new unverified certificate, it can make a leap of faith. If the 569 DHCPv6 server that used that public key or certificate is in fact 570 legitimate, then all future communication with that DHCPv6 server can 571 be protected by caching the public key. This does not provide 572 complete security, but it limits the opportunity to mount an attack 573 on a specific DHCPv6 client to the first time it communicates with a 574 new DHCPv6 server. 576 Downgrade attacks cannot be avoided if nodes are configured to accept 577 both secured and unsecured messages. A future specification may 578 provide a mechanism on how to treat unsecured DHCPv6 messages. 580 [RFC6273] has analyzed possible threats to the hash algorithms used 581 in SEND. Since the Secure DHCPv6 defined in this document uses the 582 same hash algorithms in similar way to SEND, analysis results could 583 be applied as well: current attacks on hash functions do not 584 constitute any practical threat to the digital signatures used in the 585 signature algorithm in the Secure DHCPv6. 587 A window of vulnerability for replay attacks exists until the 588 timestamp expires. Secure DHCPv6 nodes are protected against replay 589 attacks as long as they cache the state created by the message 590 containing the timestamp. The cached state allows the node to 591 protect itself against replayed messages. However, once the node 592 flushes the state for whatever reason, an attacker can re-create the 593 state by replaying an old message while the timestamp is still valid. 595 Attacks against time synchronization protocols such as NTP [RFC5905] 596 may cause Secure DHCPv6 nodes to have an incorrect timestamp value. 597 This can be used to launch replay attacks, even outside the normal 598 window of vulnerability. To protect against these attacks, it is 599 recommended that Secure DHCPv6 nodes keep independently maintained 600 clocks or apply suitable security measures for the time 601 synchronization protocols. 603 8. IANA Considerations 605 This document defines three new DHCPv6 [RFC3315] options. The IANA 606 is requested to assign values for these three options from the DHCP 607 Option Codes table of the DHCPv6 Parameters registry. The three 608 options are: 610 The Public Key Option (TBA1), described in Section 5.1. 612 The Certificate Option (TBA2), described in Section 5.2. 614 The Signature Option (TBA3), described in Section 5.3. 616 The IANA is also requested to add two new registry tables to the 617 DHCPv6 Parameters registry. The two tables are the Hash Algorithm 618 for Secure DHCPv6 table and the Signature Algorithm for Secure DHCPv6 619 table. 621 Initial values for these registries are given below. Future 622 assignments are to be made through Standards Action [RFC5226]. 623 Assignments for each registry consist of a name, a value and a RFC 624 number where the registry is defined. 626 Hash Algorithm for Secure DHCPv6. The values in this table are 627 16-bit unsigned integers. The following initial values are assigned 628 for Hash Algorithm for Secure DHCPv6 in this document: 630 Name | Value | RFCs 631 -------------------+---------+------------ 632 Reserved | 0x0000 | this document 633 SHA-1 | 0x0001 | this document 634 SHA-256 | 0x0002 | this document 636 Signature Algorithm for Secure DHCPv6. The values in this table are 637 16-bit unsigned integers. The following initial values are assigned 638 for Signature Algorithm for Secure DHCPv6 in this document: 640 Name | Value | RFCs 641 -------------------+---------+------------ 642 Reserved | 0x0000 | this document 643 RSASSA-PKCS1-v1_5 | 0x0001 | this document 645 9. Acknowledgements 647 The authors would like to thank Bernie Volz, Ted Lemon, Ralph Droms, 648 Jari Arkko, Sean Turner, Stephen Kent, Thomas Huth, David Schumacher, 649 Dacheng Zhang, Francis Dupont and other members of the IETF DHC 650 working groups for their valuable comments. 652 This document was produced using the xml2rfc tool [RFC2629]. 654 10. References 656 10.1. Normative References 658 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 659 Requirement Levels", BCP 14, RFC 2119, March 1997. 661 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 662 and M. Carney, "Dynamic Host Configuration Protocol for 663 IPv6 (DHCPv6)", RFC 3315, July 2003. 665 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 666 Housley, R., and W. Polk, "Internet X.509 Public Key 667 Infrastructure Certificate and Certificate Revocation List 668 (CRL) Profile", RFC 5280, May 2008. 670 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 671 Time Protocol Version 4: Protocol and Algorithms 672 Specification", RFC 5905, June 2010. 674 10.2. Informative References 676 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 677 June 1999. 679 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 680 Hashes in Internet Protocols", RFC 4270, November 2005. 682 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 683 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 684 May 2008. 686 [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure 687 Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, 688 June 2011. 690 [RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1, 691 PKCS 1", November 2002. 693 [sha-1] National Institute of Standards and Technology, "Secure 694 Hash Standard, FIBS PUB 180-1", April 1995, 695 . 697 Authors' Addresses 699 Sheng Jiang 700 Huawei Technologies Co., Ltd 701 Q14, Huawei Campus, No.156 Beiqing Road 702 Hai-Dian District, Beijing, 100095 703 P.R. China 705 Email: jiangsheng@huawei.com 706 Sean Shen 707 CNNIC 708 4, South 4th Street, Zhongguancun 709 Beijing 100190 710 P.R. China 712 Email: shenshuo@cnnic.cn