idnits 2.17.1 draft-ietf-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 (April 15, 2014) is 3657 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, Ed. 3 Internet-Draft Huawei Technologies Co., Ltd 4 Intended status: Standards Track S. Shen 5 Expires: October 17, 2014 CNNIC 6 D. Zhang 7 Huawei Technologies Co., Ltd 8 April 15, 2014 10 Secure DHCPv6 with Public Key 11 draft-ietf-dhc-sedhcpv6-02 13 Abstract 15 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables 16 DHCPv6 servers to pass configuration parameters. It offers 17 configuration flexibility. If not secured, DHCPv6 is vulnerable to 18 various attacks, particularly spoofing attacks. This document 19 analyzes the security issues of DHCPv6 and specifies a Secure DHCPv6 20 mechanism for communication between DHCPv6 client and server. This 21 mechanism is based on public/private key pairs. The authority of the 22 sender may depend on either pre-configuration mechanism or Public Key 23 Infrastructure. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 17, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Requirements Language and Terminology . . . . . . . . . . . . 3 61 3. Security Overview of DHCPv6 . . . . . . . . . . . . . . . . . 3 62 4. Overview of Secure DHCPv6 Mechanism with Public Key . . . . . 4 63 4.1. New Components . . . . . . . . . . . . . . . . . . . . . 5 64 4.2. Support for algorithm agility . . . . . . . . . . . . . . 6 65 4.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 66 5. Extensions for Secure DHCPv6 . . . . . . . . . . . . . . . . 7 67 5.1. Public Key Option . . . . . . . . . . . . . . . . . . . . 7 68 5.2. Certificate Option . . . . . . . . . . . . . . . . . . . 7 69 5.3. Signature Option . . . . . . . . . . . . . . . . . . . . 8 70 5.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . 10 71 6. Processing Rules and Behaviors . . . . . . . . . . . . . . . 10 72 6.1. Processing Rules of Sender . . . . . . . . . . . . . . . 10 73 6.2. Processing Rules of Recipient . . . . . . . . . . . . . . 11 74 6.3. Processing Rules of Relay Agent . . . . . . . . . . . . . 13 75 6.4. Timestamp Check . . . . . . . . . . . . . . . . . . . . . 13 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 79 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 17 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 82 11.2. Informative References . . . . . . . . . . . . . . . . . 18 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 85 1. Introduction 87 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6, [RFC3315]) 88 enables DHCPv6 servers to pass configuration parameters. It offers 89 configuration flexibility. If not secured, DHCPv6 is vulnerable to 90 various attacks, particularly spoofing attacks. 92 This document analyzes the security issues of DHCPv6 in details. 93 This document provides mechanisms for improving the security of 94 DHCPv6 between client and server: 96 o the identity of a DHCPv6 message sender, which can be a DHCPv6 97 server or a client, can be verified by a recipient. 99 o the integrity of DHCPv6 messages can be checked by the recipient 100 of the message. 102 Note: this secure mechanism in this document does not protect the 103 relay-relevant options, either added by a relay agent toward a server 104 or added by a server toward a relay agent, are considered less 105 vulnerable, because they are only transported within operator 106 networks. Communication between a server and a relay agent, and 107 communication between relay agents, may be secured through the use of 108 IPsec, as described in section 21.1 in [RFC3315]. 110 The security mechanisms specified in this document is based on self- 111 generated public/private key pairs. It also integrates timestamps 112 for anti-replay. The authentication procedure defined in this 113 document may depend on either deployed Public Key Infrastructure 114 (PKI, [RFC5280]) or pre-configured sender's public key. However, the 115 deployment of PKI or pre-configuration is out of the scope. 117 Secure DHCPv6 is applicable in environments where physical security 118 on the link is not assured (such as over wireless) and attacks on 119 DHCPv6 are a concern. 121 2. Requirements Language and Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in 126 [RFC2119] when they appear in ALL CAPS. When these words are not in 127 ALL CAPS (such as "should" or "Should"), they have their usual 128 English meanings, and are not to be interpreted as [RFC2119] key 129 words. 131 3. Security Overview of DHCPv6 133 DHCPv6 is a client/server protocol that provides managed 134 configuration of devices. It enables DHCPv6 server to automatically 135 configure relevant network parameters on clients. In the basic 136 DHCPv6 specification [RFC3315], security of DHCPv6 message can be 137 improved. 139 The basic DHCPv6 specifications can optionally authenticate the 140 origin of messages and validate the integrity of messages using an 141 authentication option with a symmetric key pair. [RFC3315] relies on 142 pre-established secret keys. For any kind of meaningful security, 143 each DHCPv6 client would need to be configured with its own secret 144 key; [RFC3315] provides no mechanism for doing this. 146 For the key of the hash function, there are two key management 147 mechanisms. Firstly, the key management is done out of band, usually 148 through some manual process. For example, operators can set up a key 149 database for both servers and clients which the client obtains a key 150 before running DHCPv6. 152 Manual key distribution runs counter to the goal of minimizing the 153 configuration data needed at each host. [RFC3315] provides an 154 additional mechanism for preventing off-network timing attacks using 155 the Reconfigure message: the Reconfigure Key authentication method. 156 However, this method provides no message integrity or source 157 integrity check. This key is transmitted in plaintext. 159 In comparison, the public/private key security mechanism allows the 160 keys to be generated by the sender, and allows the public key 161 database on the recipient to be populated opportunistically or 162 manually, depending on the degree of confidence desired in a specific 163 application. PKI security mechanism is simpler in the local key 164 management respect. 166 4. Overview of Secure DHCPv6 Mechanism with Public Key 168 In order to enable a DHCP client and a server mutually authenticate 169 each other without previous key deployment, this document introduces 170 the use of public/private key pair mechanism into DHCPv6, also with 171 timestamp. The authority of the sender may depend on either pre- 172 configuration mechanism or PKI. By combining with the signatures, 173 sender identity can be verified and messages protected. 175 This document introduces a Secure DHCPv6 mechanism that uses a public 176 /private key pair to secure the DHCPv6 protocol. In order to enable 177 DHCP clients and servers to perform mutual authentication, this 178 solution provides two public key based mechanisms with different 179 security strengths. One is stronger and only the certificate signed 180 by a trusted CA or preconfigured public key can be accepted. The 181 other one, called as leap of faith (LoF) mechanism, is relatively 182 weak. It allows a client/server pair, that lacks essential trust 183 relationship, to build up their trust relationship at run time for 184 subsequent exchanges based on faith. This design simplifies the 185 precondition of deploying DHCPv6 authentication and provides limited 186 protection of DHCPv6 message. 188 In the proposed soltuion, both public/private key pairs or 189 certificates are can be used in authentication. When using public/ 190 private key pairs directly, the public key of the sender is pre- 191 shared with the recipient, either opportunistically or through a 192 manual process. When using certificates, the sender has a 193 certificate for its public key, signed by a CA that is trusted by the 194 recipient. It is possible for the same public key to be used with 195 different recipients in both modes. 197 In this document, we introduce a public key option, a certificate 198 option and a signature option with a corresponding verification 199 mechanism. Timestamp is integrated into signature options. A DHCPv6 200 message (from a server or a client), with either a public key or 201 certificate option, and carrying a digital signature, can be verified 202 by the recipient for both the timestamp and authentication, then 203 process the payload of the DHCPv6 message only if the validation is 204 successful. Because the sender can be a DHCPv6 server or a client, 205 the end-to-end security protection can be from DHCPv6 servers to 206 clients, or from clients to DHCPv6 servers. 208 The recipient may choose to further process the message from a sender 209 for which no authentication information exists, either non-matched 210 public key or certificate cannot be verified. By recording the 211 public key or unverifiable certificate that was used by the sender, 212 when the first time it is seen, the recipient can make a leap of 213 faith that the sender is trustworthy. If no evidence to the contrary 214 surfaces, the recipient can then validate the sender as trustworthy 215 when it subsequently sees the same public key or certificate used to 216 sign messages from the same sender. In opposite, once the recipient 217 has determined that it is being attacked, it can either forget that 218 sender, or remember that sender in a blacklist and drop further 219 packets associated with that sender. 221 This improves communication security of DHCPv6 messages. The 222 authentication options [RFC3315] may also be used for replay 223 protection. 225 4.1. New Components 227 The components of the solution specified in this document are as 228 follows: 230 o The node generates a public/private key pair. A DHCPv6 option is 231 defined that carries the public key. 233 The node may also obtain a certificate from a Certificate 234 Authority that can be used to establish the trustworthiness of the 235 node. Another option is defined to carry the certificate. 236 Because the certificate contains the public key, there is never a 237 need to send both options at the same time. 239 o A signature generated using the private key that protects the 240 integrity of the DHCPv6 messages and authenticates the identity of 241 the sender. 243 o A timestamp, to detect and prevent packet replay. The secure 244 DHCPv6 nodes need to meet some accuracy requirements and be synced 245 to global time, while the timestamp checking mechanism allows a 246 configurable time value for clock drift. 248 4.2. Support for algorithm agility 250 Hash functions are used to provide message integrity checks. In 251 order to provide a means of addressing problems that may emerge in 252 the future with existing hash algorithms, as recommended in 253 [RFC4270], this document provides a mechanism for negotiating the use 254 of more secure hashes in the future. 256 In addition to hash algorithm agility, this document also provides a 257 mechanism for signature algorithm agility. 259 The support for algorithm agility in this document is mainly a 260 unilateral notification mechanism from sender to recipient. If the 261 recipient does not support the algorithm used by the sender, it 262 cannot authenticate the message. In this case, the receiver SHOULD 263 reply with a NotSupportAlgorithm status code (defined in 264 Section 5.4). Upon receiving this status code, the sender MAY resend 265 the message protected with the mandatory algorithms (defined in 266 Section 5.3). Therefore, the senders in a same administrative domain 267 may be allowed to use various algorithms simultaneously. 269 4.3. Applicability 271 By default, a secure DHCPv6 enabled client SHOULD start with secure 272 model. It sends a DHCPv6 message with secure options. If the 273 recipient is secure DHCPv6 enabled server, their communication should 274 be in secure model. In the scenario where the secure DHCPv6 enabled 275 client and server fail to build up secure communication between them, 276 they may fall back the unsecure model, if both client and server 277 allow it. 279 In the scenario where the recipient is a legacy DHCPv6 server that 280 does not support secure mechanism, the DHCPv6 server (for most of 281 known DHCPv6 implemenations) would just omit or disregard unknown 282 options and still process the known options. The reply message would 283 be unsecured, of course. It is up to the local policy of the client 284 whether to accept the messages. If the client accept the unsecure 285 messages from the DHCPv6 server. The subsequent exchanges will be in 286 unsecure model. 288 In the scenario where a legacy client sends a unsecure message to a 289 secure DHCPv6 enabled server, there are two possibilities depending 290 on the server policy. If the server mandidates the authentication, 291 an UnspecFail (value 1, [RFC3315]) error status code, SHOULD be 292 returned. In such case, the client cannot build up the connection 293 with the server. If the server has been configured to support 294 unsecured request, the server would fall back the unsecure DHCPv6 295 model, and reply unsecure messages toward the client. 297 5. Extensions for Secure DHCPv6 299 This section extends DHCPv6. Three new options have been defined. 300 The new options MUST be supported in the Secure DHCPv6 message 301 exchange. 303 5.1. Public Key Option 305 The Public Key option carries the public key of the sender. The 306 format of the Public Key option is described as follows: 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | OPTION_PK_PARAMETER | option-len | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | | 314 . Public Key (variable length) . 315 . . 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 option-code OPTION_PK_PARAMETER (TBA1). 320 option-len Length of public key in octets. 322 Public Key A variable-length field containing public key. The 323 key MUST be represented as a lower-case hexadecimal 324 string with the most significant octet of the key 325 first. Typically, the length of a 2048-bit RSA 326 public key is 256 bytes. 328 5.2. Certificate Option 330 The Certificate option carries the certificate of the sender. The 331 format of the Certificate option is described as follows: 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | OPTION_CERT_PARAMETER | option-len | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | | 339 . Certificate (variable length) . 340 . . 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 option-code OPTION_CERT_PARAMETER (TBA2). 345 option-len Length of certificate in octets, maximum 65535. 347 Certificate A variable-length field containing certificate. The 348 encoding of certificate and certificate data MUST 349 be in format as defined in Section 3.6, [RFC5996]. 350 The support of X.509 certificate is mandatory. The 351 length of a certificate is various. In this 352 specification, typically, the maximum length is 353 65535 bytes. 355 5.3. Signature Option 357 The Signature option allows public key-based signatures to be 358 attached to a DHCPv6 message. The Signature option could be any 359 place within the DHCPv6 message. It protects the entire DHCPv6 360 header and options, except for the Authentication Option. The format 361 of the Signature option is described as follows: 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | OPTION_SIGNATURE | option-len | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | HA-id | SA-id | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Timestamp (64-bit) | 371 | | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | | 374 . Signature (variable length) . 375 . . 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 option-code OPTION_SIGNATURE (TBA3). 380 option-len 12 + Length of Signature field in octets. 382 HA-id Hash Algorithm id. The hash algorithm is used for 383 computing the signature result. This design is 384 adopted in order to provide hash algorithm agility. 385 The value is from the Hash Algorithm for Secure 386 DHCPv6 registry in IANA. The support of SHA-256 is 387 mandatory. A registry of the initial assigned values 388 is defined in Section 8. 390 SA-id Signature Algorithm id. The signature algorithm is 391 used for computing the signature result. This 392 design is adopted in order to provide signature 393 algorithm agility. The value is from the Signature 394 Algorithm for Secure DHCPv6 registry in IANA. The 395 support of RSASSA-PKCS1-v1_5 is mandatory. A 396 registry of the initial assigned values is defined 397 in Section 8. 399 Timestamp The current time of day (NTP-format timestamp 400 [RFC5905] in UTC (Coordinated Universal Time), a 401 64-bit unsigned fixed-point number, in seconds 402 relative to 0h on 1 January 1900.). It can reduce 403 the danger of replay attacks. 405 Signature A variable-length field containing a digital 406 signature. The signature value is computed with 407 the hash algorithm and the signature algorithm, 408 as described in HA-id and SA-id. The signature 409 constructed by using the sender's private key 410 protects the following sequence of octets: 412 1. The DHCPv6 message header. 414 2. All DHCPv6 options including the Signature 415 option (fill the signature field with zeroes) 416 except for the Authentication Option. 418 The signature filed MUST be padded, with all 0, to 419 the next octet boundary if its size is not an even 420 multiple of 8 bits. The padding length depends on 421 the signature algorithm, which is indicated in the 422 SA-id field. 424 Note: if both signature and authentication option are presented, 425 signature option does not protect authentication option. It is 426 because both needs to apply hash algorithm to whole message, so there 427 must be a clear order and there could be only one last-created 428 option. In order to avoid update RFC3315 because of changing auth 429 option, the authors chose not include authentication option in the 430 signature. 432 5.4. Status Codes 434 o NotSupportAlgorithm (TBD4): indicates that the DHCPv6 server does 435 not support algorthims that sender used. 437 o AuthFailNotSupportLoF (TBD5): indicates that the DHCPv6 client 438 fails authentication check and the DHCPv6 server does not support 439 the leaf of faith model 441 o AuthFailSupportLoF (TBD6): indicates that the DHCPv6 client fails 442 authentication check. Although the DHCPv6 server does support the 443 leaf of faith, its list that stores public keys or unverifiable 444 certificates in the leap of faith model currently exceeds. 446 o SignitureFail (TBD7): indicates the message from DHCPv6 client 447 fails the signiture check. 449 6. Processing Rules and Behaviors 451 This section only covers the scenario where both DHCPv6 client and 452 server are secure enabled. 454 6.1. Processing Rules of Sender 456 The sender of a Secure DHCPv6 message could be a DHCPv6 server or a 457 DHCPv6 client. 459 The node must have a public/private key pair in order to create 460 Secure DHCPv6 messages. The node may have a certificate which is 461 signed by a CA trusted by both sender and recipient. 463 To support Secure DHCPv6, the Secure DHCPv6 enabled sender MUST 464 construct the DHCPv6 message following the rules defined in 465 [RFC3315]. 467 A Secure DHCPv6 message, except for Relay-forward and Relay-reply 468 messages, MUST contain either a the Public Key or Certificate option, 469 which MUST contructed as explained in Section 5.1 or Section 5.2. 471 A Secure DHCPv6 message, except for Relay-forward and Relay-reply 472 messages, MUST contain the Signature option, which MUST be 473 constructed as explained in Section 5.3. It protects the message 474 header all DHCPv6 options except for the Authentication Option. 475 Within the Signature option the Timestamp field SHOULD be set to the 476 current time, according to sender's real time clock. 478 A Relay-forward and relay-reply message MUST NOT contain any 479 additional Public Key or Certificate option or Signature Option, 480 aside from those present in the innermost encapsulated message from 481 the client or server. 483 If the sender is a DHCPv6 client, in the failure cases, it receives a 484 Reply message with an error status code. The error status code 485 indicates the failure reason on the server side. According to the 486 received status code, the client MAY take follow-up action: 488 o Upon receiving a NotSupportAlgorithm error status code, the client 489 MAY resend the message protected with the mandatory algorithms. 491 o Upon receiving an AuthFailNotSupportLoF error status code, the 492 client is not able to build up the secure communication with the 493 recipient. The client MAY switch to other certificate or public 494 key if it has. But it SHOULD NOT retry with the same certificate/ 495 public-key. 497 o Upon receiving an AuthFailSupportLoF error status code, the client 498 is not able to build up the secure communication with the 499 recipient. The client MAY switch to other certificate or public 500 key if it has. The client MAY retry with the same certificate/ 501 public-key later. 503 o Upon receiving a SignitureFail error status code, the client MAY 504 resend the message. 506 6.2. Processing Rules of Recipient 508 The recipient of a Secure DHCPv6 message could be a DHCPv6 server or 509 a DHCPv6 client. In the failure cases, both DHCPv6 server and client 510 SHOULD NOT process received message, and the server SHOULD reply a 511 correspondent error status could, while the client does nothing. 513 When receiving a DHCPv6 message, except for Relay-Forward and Relay- 514 Reply messages, a Secure DHCPv6 enabled recipient SHOULD discard the 515 DHCPv6 message if the Signature option is absent, or both the Public 516 Key and Certificate option is absent, or both the Public Key and 517 Certificate option are presented. In such failure, the DHCPv6 server 518 SHOULD reply an UnspecFail (value 1, [RFC3315]) error status code. 519 If all three options are absent, the sender MAY be legacy node or in 520 unsecure model, then, the recipient MAY fall back the unsecure DHCPv6 521 model if its local policy allows. 523 The recipient SHOULD first check the support of algorthims that 524 sender used. If all algorthims are supported, the recipient then 525 checks the authority of this sender. If not, the message is dropped. 527 In such failure, the DHCPv6 server SHOULD reply a NotSupportAlgorithm 528 error status code, defined in Section 5.4, back to the client.. 530 If the sender uses certificate, the recipient SHOULD validate the 531 sender's certificate following the rules defined in [RFC5280]. An 532 implementation may create a local trust certificate record for a 533 verified certificate in order to avoid repeated verfication procedure 534 in the future. A sender certificate that finds a match in the local 535 trust certificate list are treated as verified. A fast search index 536 may be created for this list. 538 If the sender uses a public key, the recipient SHOULD validate it by 539 finding a match public key from the local trust public key list, 540 which is pre-configured or recorded from previous communications. A 541 local trust public key list is a data table maintained by the 542 recipient. It restores public keys from all trustworthy senders. A 543 fast search index may be created for this list. 545 The recipient may choose to further process the message from a sender 546 for which no authentication information exists, either non-matched 547 public key or certificate cannot be verified. By recording the 548 public key or unverifiable certificate that was used by the sender, 549 when the first time it is seen, the recipient can make a leap of 550 faith (LoF) that the sender is trustworthy. If no evidence to the 551 contrary surfaces, the recipient can then validate the sender as 552 trustworthy for subsequent message exchanges. In opposite, once the 553 recipient has determined that it is being attacked, it can either 554 forget that key, or remember that key in a blacklist and drop further 555 packets associated with that key. 557 If recipient does not support the leap of faith model, the message 558 that fails authentication check MUST be dropped. In such failure, 559 the DHCPv6 server SHOULD reply an AuthFailNotSupportLoF error status 560 code, defined in Section 5.4, back to the client. 562 On the recipient that supports the leap of faith model, the number of 563 cached public keys or unverifiable certificates MUST be limited in 564 order to protect against resource exhaustion attacks. If the 565 recipient's list that stores public keys or unverifiable certificates 566 in the leap of faith model exceeds, the message that fails 567 authentication check MUST be dropped. In such failure, the DHCPv6 568 server SHOULD reply an AuthFailNotSupportLoF error status code, 569 defined in Section 5.4, back to the client. The resource releasing 570 policy against exceeding situations is out of scope. 572 At this point, the recipient has either recognized the authentication 573 of the sender, or decided to attempt a leap of faith. The recipient 574 MUST now authenticate the sender by verifying the Signature and 575 checking timestamp. The order of two procedures is left as an 576 implementation decision. It is RECOMMENDED to check timestamp first, 577 because signature verification is much more computationally 578 expensive. 580 The signature field verification MUST show that the signature has 581 been calculated as specified in Section 5.3. Only the messages that 582 get through both the signature verifications and timestamp check are 583 accepted as secured DHCPv6 messages and continue to be handled for 584 their contained DHCPv6 options as defined in [RFC3315]. Messages 585 that do not pass the above tests MUST be discarded or treated as 586 unsecure messages. In the signature verification failure case, the 587 DHCPv6 server SHOULD reply a SignatureFail error status code, defined 588 in Section 5.4, back to the client. 590 Furthermore, the node that supports the verification of the Secure 591 DHCPv6 messages MAY record the following information: 593 Minbits The minimum acceptable key length for public keys. An upper 594 limit MAY also be set for the amount of computation needed when 595 verifying packets that use these security associations. The 596 appropriate lengths SHOULD be set according to the signature 597 algorithm and also following prudent cryptographic practice. For 598 example, minimum length 1024 and upper limit 2048 may be used for 599 RSA [RSA]. 601 A Relay-forward or Relay-reply message with any Public Key, 602 Certificate or the Signature option is invilad. The message MUST be 603 discarded silently. 605 6.3. Processing Rules of Relay Agent 607 To support Secure DHCPv6, relay agents just need to follow the same 608 processing rules defined in [RFC3315]. There is nothing more the 609 relay agents have to do, either verify the messages from client or 610 server, or add any secure DHCPv6 options. Actually, by definition in 611 this document, relay agents MUST NOT add any secure DHCPv6 options. 613 6.4. Timestamp Check 615 Recipients SHOULD be configured with an allowed timestamp Delta 616 value, a "fuzz factor" for comparisons, and an allowed clock drift 617 parameter. The recommended default value for the allowed Delta is 618 300 seconds (5 minutes); for fuzz factor 1 second; and for clock 619 drift, 0.01 second. 621 Note: the Timestamp mechanism is based on the assumption that 622 communication peers have rough synchronized clocks, with certain 623 allowed clock drift. So, accurate clock is not necessary. If one 624 has a clock too far from the current time, the timestamp mechanism 625 would not work. 627 To facilitate timestamp checking, each recipient SHOULD store the 628 following information for each sender, from which at least one 629 accepted secure DHCPv6 message is successfully verified (for both 630 timestamp check and signature verification): 632 o The receive time of the last received and accepted DHCPv6 message. 633 This is called RDlast. 635 o The timestamp in the last received and accepted DHCPv6 message. 636 This is called TSlast. 638 An verified (for both timestamp check and signature verification) 639 secure DHCPv6 message initiates the update of the above variables in 640 the recipient's record. 642 Recipients MUST check the Timestamp field as follows: 644 o When a message is received from a new peer (i.e., one that is not 645 stored in the cache), the received timestamp, TSnew, is checked, 646 and the message is accepted if the timestamp is recent enough to 647 the reception time of the packet, RDnew: 649 -Delta < (RDnew - TSnew) < +Delta 651 After the signature verification also successes, the RDnew and 652 TSnew values SHOULD be stored in the cache as RDlast and TSlast. 654 o When a message is received from a known peer (i.e., one that 655 already has an entry in the cache), the timestamp is checked 656 against the previously received Secure DHCPv6 message: 658 TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz 660 If this inequality does not hold or RDnew < RDlast, the recipient 661 SHOULD silently discard the message. If, on the other hand, the 662 inequality holds, the recipient SHOULD process the message. 664 Moreover, if the above inequality holds and TSnew > TSlast, the 665 recipient SHOULD update RDlast and TSlast after the signature 666 verification also successes. Otherwise, the recipient MUST NOT 667 update RDlast or TSlast. 669 An implementation MAY use some mechanism such as a timestamp cache to 670 strengthen resistance to replay attacks. When there is a very large 671 number of nodes on the same link, or when a cache filling attack is 672 in progress, it is possible that the cache holding the most recent 673 timestamp per sender will become full. In this case, the node MUST 674 remove some entries from the cache or refuse some new requested 675 entries. The specific policy as to which entries are preferred over 676 others is left as an implementation decision. 678 7. Security Considerations 680 This document provides new security features to the DHCPv6 protocol. 682 Using public key based security mechanism and its verification 683 mechanism in DHCPv6 message exchanging provides the authentication 684 and data integrity protection. Timestamp mechanism provides anti- 685 replay function. 687 The Secure DHCPv6 mechanism is based on the pre-condition that the 688 recipient knows the public key of senders or the sender's certificate 689 can be verified through a trust CA. It prevents DHCPv6 server 690 spoofing. The clients may decline the DHCPv6 messages from unknown/ 691 unverified servers, which may be fake servers; or may prefer DHCPv6 692 messages from known/verified servers over unsigned messages or 693 messages from unknown/unverified servers. The pre-configuration 694 operation also needs to be protected, which is out of scope. The 695 deployment of PKI is also out of scope. 697 However, when a DHCPv6 client first encounters a new public key or a 698 new unverifiable certificate, it can make a leap of faith. If the 699 DHCPv6 server that used that public key or unverifiable certificate 700 is in fact legitimate, then all future communication with that DHCPv6 701 server can be protected by storing the public key or unverifiable 702 certificate. This does not provide complete security, but it limits 703 the opportunity to mount an attack on a specific DHCPv6 client to the 704 first time it communicates with a new DHCPv6 server. The number of 705 cached public keys or unverifiable certificates MUST be limited in 706 order to protect the DHCPv6 server against resource exhaustion 707 attacks. 709 Downgrade attacks cannot be avoided if nodes are configured to accept 710 both secured and unsecured messages. A future specification may 711 provide a mechanism on how to treat unsecured DHCPv6 messages. 713 [RFC6273] has analyzed possible threats to the hash algorithms used 714 in SEND. Since the Secure DHCPv6 defined in this document uses the 715 same hash algorithms in similar way to SEND, analysis results could 716 be applied as well: current attacks on hash functions do not 717 constitute any practical threat to the digital signatures used in the 718 signature algorithm in the Secure DHCPv6. 720 A window of vulnerability for replay attacks exists until the 721 timestamp expires. Secure DHCPv6 nodes are protected against replay 722 attacks as long as they cache the state created by the message 723 containing the timestamp. The cached state allows the node to 724 protect itself against replayed messages. However, once the node 725 flushes the state for whatever reason, an attacker can re-create the 726 state by replaying an old message while the timestamp is still valid. 727 In addition, the effectiveness of timestamps is largely dependent 728 upon the accuracy of synchronization between communicating nodes. 729 However, how the two communcating nodes can be synchronized is out of 730 scope of this work. 732 Attacks against time synchronization protocols such as NTP [RFC5905] 733 may cause Secure DHCPv6 nodes to have an incorrect timestamp value. 734 This can be used to launch replay attacks, even outside the normal 735 window of vulnerability. To protect against these attacks, it is 736 recommended that Secure DHCPv6 nodes keep independently maintained 737 clocks or apply suitable security measures for the time 738 synchronization protocols. 740 8. IANA Considerations 742 This document defines three new DHCPv6 [RFC3315] options. The IANA 743 is requested to assign values for these three options from the DHCP 744 Option Codes table of the DHCPv6 Parameters registry maintained in 745 http://www.iana.org/assignments/dhcpv6-parameters. The three options 746 are: 748 The Public Key Option (TBA1), described in Section 5.1. 750 The Certificate Option (TBA2), described in Section 5.2. 752 The Signature Option (TBA3), described in Section 5.3. 754 The IANA is also requested to add two new registry tables to the 755 DHCPv6 Parameters registry maintained in http://www.iana.org/ 756 assignments/dhcpv6-parameters. The two tables are the Hash Algorithm 757 for Secure DHCPv6 table and the Signature Algorithm for Secure DHCPv6 758 table. 760 Initial values for these registries are given below. Future 761 assignments are to be made through Standards Action [RFC5226]. 762 Assignments for each registry consist of a name, a value and a RFC 763 number where the registry is defined. 765 Hash Algorithm for Secure DHCPv6. The values in this table are 766 16-bit unsigned integers. The following initial values are assigned 767 for Hash Algorithm for Secure DHCPv6 in this document: 769 Name | Value | RFCs 770 -------------------+---------+-------------- 771 Reserved | 0x0000 | this document 772 SHA-1 | 0x0001 | this document 773 SHA-256 | 0x0002 | this document 774 SHA-512 | 0x0003 | this document 776 Signature Algorithm for Secure DHCPv6. The values in this table are 777 16-bit unsigned integers. The following initial values are assigned 778 for Signature Algorithm for Secure DHCPv6 in this document: 780 Name | Value | RFCs 781 -------------------+---------+-------------- 782 Reserved | 0x0000 | this document 783 RSASSA-PKCS1-v1_5 | 0x0001 | this document 785 IANA is requested to assign the following new DHCPv6 Status Codes, 786 defined in Section 5.4, in the DHCPv6 Parameters registry maintained 787 in http://www.iana.org/assignments/dhcpv6-parameters: 789 Code | Name | Reference 790 ---------+-----------------------+-------------- 791 TBD4 | NotSupportAlgorithm | this document 792 TBD5 | AuthFailNotSupportLoF | this document 793 TBD6 | AuthFailSupportLoF | this document 794 TBD7 | SignitureFail | this document 796 9. Acknowledgements 798 The authors would like to thank Bernie Volz, Ted Lemon, Ralph Droms, 799 Jari Arkko, Sean Turner, Stephen Kent, Thomas Huth, David Schumacher, 800 Francis Dupont, Tomek Mrugalski, Gang Chen, Qi Sun, Suresh Krishnan 801 and other members of the IETF DHC working groups for their valuable 802 comments. 804 This document was produced using the xml2rfc tool [RFC2629]. 806 10. Change log [RFC Editor: Please remove] 808 draft-ietf-dhc-sedhcpv6-02: addressed comments (applicability 809 statement, redesign the error codes and their logic) from IETF89 DHC 810 WG meeting and volunteer reviewers . 2014-04-14. 812 draft-ietf-dhc-sedhcpv6-01: addressed comments from IETF88 DHC WG 813 meeting. Moved Dacheng Zhang from acknowledgement to be co-author. 814 2014-02-14 816 draft-ietf-dhc-sedhcpv6-00: adopted by DHC WG. 2013-11-19. 818 draft-jiang-dhc-sedhcpv6-02: removed protection between relay agent 819 and server due to complexity, following the comments from Ted Lemon, 820 Bernie Volz. 2013-10-16. 822 draft-jiang-dhc-sedhcpv6-01: update according to review comments from 823 Ted Lemon, Bernie Volz, Ralph Droms. Separated Public Key/ 824 Certificate option into two options. Refined many detailed 825 processes. 2013-10-08. 827 draft-jiang-dhc-sedhcpv6-00: original version, this draft is a 828 replacement of draft-ietf-dhc-secure-dhcpv6, which reached IESG and 829 dead because of consideration regarding to CGA. The authors followed 830 the suggestion from IESG making a general public key based mechanism. 831 2013-06-29. 833 11. References 835 11.1. Normative References 837 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 838 Requirement Levels", BCP 14, RFC 2119, March 1997. 840 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 841 and M. Carney, "Dynamic Host Configuration Protocol for 842 IPv6 (DHCPv6)", RFC 3315, July 2003. 844 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 845 Housley, R., and W. Polk, "Internet X.509 Public Key 846 Infrastructure Certificate and Certificate Revocation List 847 (CRL) Profile", RFC 5280, May 2008. 849 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 850 Time Protocol Version 4: Protocol and Algorithms 851 Specification", RFC 5905, June 2010. 853 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 854 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 855 5996, September 2010. 857 11.2. Informative References 859 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 860 June 1999. 862 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 863 Hashes in Internet Protocols", RFC 4270, November 2005. 865 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 866 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 867 May 2008. 869 [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure 870 Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, 871 June 2011. 873 [RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1, 874 PKCS 1", November 2002. 876 Authors' Addresses 878 Sheng Jiang (editor) 879 Huawei Technologies Co., Ltd 880 Q14, Huawei Campus, No.156 Beiqing Road 881 Hai-Dian District, Beijing, 100095 882 P.R. China 884 Email: jiangsheng@huawei.com 886 Sean Shen 887 CNNIC 888 4, South 4th Street, Zhongguancun 889 Beijing 100190 890 P.R. China 892 Email: shenshuo@cnnic.cn 894 Dacheng Zhang 895 Huawei Technologies Co., Ltd 896 Q14, Huawei Campus, No.156 Beiqing Road 897 Hai-Dian District, Beijing, 100095 898 P.R. China 900 Email: zhangdacheng@huawei.com