idnits 2.17.1 draft-ietf-dhc-sedhcpv6-06.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 (February 18, 2015) is 3326 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 2460 (Obsoleted by RFC 8200) ** 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: 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: August 22, 2015 CNNIC 6 D. Zhang 7 Huawei Technologies Co., Ltd 8 T. Jinmei 9 Infoblox Inc. 10 February 18, 2015 12 Secure DHCPv6 13 draft-ietf-dhc-sedhcpv6-06 15 Abstract 17 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables 18 DHCPv6 servers to pass configuration parameters. It offers 19 configuration flexibility. If not being secured, DHCPv6 is 20 vulnerable to various attacks, particularly spoofing attacks. This 21 document analyzes the security issues of DHCPv6 and specifies a 22 Secure DHCPv6 mechanism for communications between DHCPv6 clients and 23 DHCPv6 servers. This document provides a DHCPv6 client/server 24 authentication mechanism based on sender's public/private key pairs 25 or certificates with associated private keys. The DHCPv6 message 26 exchanges are protected by the signature option and the timestamp 27 option newly defined in this document. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 22, 2015. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Requirements Language and Terminology . . . . . . . . . . . . 3 65 3. Security Overview of DHCPv6 . . . . . . . . . . . . . . . . . 4 66 4. Overview of Secure DHCPv6 Mechanism with Public Key . . . . . 4 67 4.1. New Components . . . . . . . . . . . . . . . . . . . . . 5 68 4.2. Support for Algorithm Agility . . . . . . . . . . . . . . 6 69 4.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 7 70 5. Extensions for Secure DHCPv6 . . . . . . . . . . . . . . . . 7 71 5.1. Public Key Option . . . . . . . . . . . . . . . . . . . . 7 72 5.2. Certificate Option . . . . . . . . . . . . . . . . . . . 8 73 5.3. Signature Option . . . . . . . . . . . . . . . . . . . . 9 74 5.4. Timestamp Option . . . . . . . . . . . . . . . . . . . . 10 75 5.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . 11 76 6. Processing Rules and Behaviors . . . . . . . . . . . . . . . 11 77 6.1. Processing Rules of Sender . . . . . . . . . . . . . . . 11 78 6.2. Processing Rules of Recipient . . . . . . . . . . . . . . 13 79 6.3. Processing Rules of Relay Agent . . . . . . . . . . . . . 15 80 6.4. Timestamp Check . . . . . . . . . . . . . . . . . . . . . 15 81 7. Deployment Consideration . . . . . . . . . . . . . . . . . . 17 82 7.1. Authentication on a client . . . . . . . . . . . . . . . 17 83 7.2. Authentication on a server . . . . . . . . . . . . . . . 17 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 86 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 87 11. Change log [RFC Editor: Please remove] . . . . . . . . . . . 20 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 89 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 90 12.2. Informative References . . . . . . . . . . . . . . . . . 22 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 93 1. Introduction 95 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6, [RFC3315]) 96 enables DHCPv6 servers to pass configuration parameters and offers 97 configuration flexibility. If not being secured, DHCPv6 is 98 vulnerable to various attacks, particularly spoofing attacks. 100 This document analyzes the security issues of DHCPv6 in details. 101 This document provides mechanisms for improving the security of 102 DHCPv6 between client and server: 104 o the identity of a DHCPv6 message sender, which can be a DHCPv6 105 server or a client, can be verified by a recipient. 107 o the integrity of DHCPv6 messages can be checked by the recipient 108 of the message. 110 o anti-replay protection based on timestamps. 112 Note: this secure mechanism in this document does not protect the 113 relay-relevant options, either added by a relay agent toward a server 114 or added by a server toward a relay agent, because they are only 115 transported within operator networks and considered less vulnerable. 116 Communication between a server and a relay agent, and communications 117 between relay agents, may be secured through the use of IPsec, as 118 described in section 21.1 in [RFC3315]. 120 The security mechanisms specified in this document is based on 121 sender's public/private key pairs or certificates with associated 122 private keys. The reason for such design and deployment 123 consideration are discussed in Section 7. It also integrates message 124 signatures for the integrity and timestamps for anti-replay. The 125 sender authentication procedure using certificates defined in this 126 document depends on deployed Public Key Infrastructure (PKI, 127 [RFC5280]). However, the deployment of PKI is out of the scope. 129 Secure DHCPv6 is applicable in environments where physical security 130 on the link is not assured (such as over wireless) and attacks on 131 DHCPv6 are a concern. 133 2. Requirements Language and Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in 138 [RFC2119] when they appear in ALL CAPS. When these words are not in 139 ALL CAPS (such as "should" or "Should"), they have their usual 140 English meanings, and are not to be interpreted as [RFC2119] key 141 words. 143 3. Security Overview of DHCPv6 145 DHCPv6 is a client/server protocol that provides managed 146 configuration of devices. It enables a DHCPv6 server to 147 automatically configure relevant network parameters on clients. In 148 the basic DHCPv6 specification [RFC3315], security of DHCPv6 messages 149 can be improved. 151 The basic DHCPv6 specifications can optionally authenticate the 152 origin of messages and validate the integrity of messages using an 153 authentication option with a symmetric key pair. [RFC3315] relies on 154 pre-established secret keys. For any kind of meaningful security, 155 each DHCPv6 client would need to be configured with its own secret 156 key; [RFC3315] provides no mechanism for doing this. 158 For the keyed hash function, there are two key management mechanisms. 159 The first one is a key management done out of band, usually through 160 some manual process. The second approach is to use Public Key 161 Infrastructure (PKI). 163 As an example of the first approach, operators can set up a key 164 database for both servers and clients from which the client obtains a 165 key before running DHCPv6. Manual key distribution runs counter to 166 the goal of minimizing the configuration data needed at each host. 168 [RFC3315] provides an additional mechanism for preventing off-network 169 timing attacks using the Reconfigure message: the Reconfigure Key 170 authentication method. However, this method provides little message 171 integrity or source integrity check, and it protects only the 172 Reconfigure message. This key is transmitted in plaintext. 174 In comparison, the security mechanism defined in this document allows 175 the public key database on the client or server to be populated 176 opportunistically or manually, depending on the degree of confidence 177 desired in a specific application. PKI security mechanism is simpler 178 in the local key management respect. 180 4. Overview of Secure DHCPv6 Mechanism with Public Key 182 This document introduces a Secure DHCPv6 mechanism that uses 183 signatures to secure the DHCPv6 protocol. In order to enable DHCPv6 184 clients and servers to perform mutual authentication without previous 185 key deployment, this solution provides a DHCPv6 client/server 186 authentication mechanism based on public/private key pairs and, 187 optionally, PKI certificates. The purpose of this design is to make 188 it easier to deploy DHCPv6 authentication and provides protection of 189 DHCPv6 message within the scope of whatever trust relationship exists 190 for the particular key used to authenticate the message. 192 In this document, we introduce a public key option, a certificate 193 option, a signature option and a timestamp option with corresponding 194 verification mechanisms. A DHCPv6 message can include a public key 195 option, and carrying a digital signature and a timestamp option. The 196 signature can be verified using the supplied public key. The 197 recipient processes the payload of the DHCPv6 message only if the 198 validation is successful: the signature validates, and a trust 199 relationship exists for the key. Alternatively, a DHCPv6 message can 200 include a certificate option, and also carrying a digital signature 201 and a timestamp option. The signature can be verified by the 202 recipient. The recipient processes the payload of the DHCPv6 message 203 only if the validation is successful: the certificate validates, and 204 a trust relationship exists on the recipient for the provided 205 certificate. The recipient processes the payload of the DHCPv6 206 message only if the validation is successful. The end-to-end 207 security protection can be bidirectional, covering messages from 208 servers to clients and from clients to servers. Additionally, the 209 optional timestamp mechanism provides anti-replay protection. 211 A trust relationship for a public key can be the result either of a 212 Trust-on-first-use (TOFU) policy, or a list of trusted keys 213 configured on the recipient. 215 A trust relationship for a certificate could also be treated either 216 as Trust-on-first-use or configured in a list of trusted certificate 217 authorities, depending on the application. Such applications are out 218 of scope for this document. 220 Secure DHCPv6 messages are commonly large. One example is normal 221 DHCPv6 message length plus a 1 KB for a X.509 certificate and 222 signature and 256 Byte for a signature. IPv6 fragments [RFC2460] are 223 highly possible. In practise, the total length would be various in a 224 large range. Hence, deployment of Secure DHCPv6 should also consider 225 the issues of IP fragment, PMTU, etc. Also, if there are firewalls 226 between secure DHCPv6 clients and secure DHCPv6 servers, it is 227 RECOMMENDED that the firewalls are configured to pass ICMP Packet Too 228 Big messages [RFC4443]. 230 4.1. New Components 232 The components of the solution specified in this document are as 233 follows: 235 o Servers and clients using public keys in their secure DHCPv6 236 messages generate a public/private key pair. A DHCPv6 option that 237 carries the public key is defined. 239 o Servers and clients that use certifiicates first generate a 240 public/private key pair and then obtain a public key certificate 241 from a Certificate Authority that signs the public key. Another 242 option is defined to carry the certificate. 244 o A signature generated using the private key which is used by the 245 receiver to verify the integrity of the DHCPv6 messages and then 246 the identity of the sender. 248 o A timestamp, to detect replayed packet. The secure DHCPv6 nodes 249 need to meet some accuracy requirements and be synced to global 250 time, while the timestamp checking mechanism allows a configurable 251 time value for clock drift. The real time provision is out of 252 scope of this document. 254 4.2. Support for Algorithm Agility 256 Hash functions are used to provide message integrity checks. In 257 order to provide a means of addressing problems that may emerge in 258 the future with existing hash algorithms, as recommended in 259 [RFC4270], this document provides a mechanism for negotiating the use 260 of more secure hashes in the future. 262 In addition to hash algorithm agility, this document also provides a 263 mechanism for signature algorithm agility. 265 The support for algorithm agility in this document is mainly a 266 unilateral notification mechanism from sender to recipient. A 267 recipient MAY support various algorithms simultaneously among 268 different senders, and the different senders in a same administrative 269 domain may be allowed to use various algorithms simultaneously. It 270 is NOT RECOMMENDED that the same sender and recipient use various 271 algorithms in a single communication session. 273 If the recipient does not support the algorithm used by the sender, 274 it cannot authenticate the message. In the client-to-server case, 275 the server SHOULD reply with an AlgorithmNotSupported status code 276 (defined in Section 5.5). Upon receiving this status code, the 277 client MAY resend the message protected with the mandatory algorithm 278 (defined in Section 5.3). 280 4.3. Applicability 282 By default, a secure DHCPv6 enabled client or server SHOULD start 283 with secure mode by sending secure DHCPv6 messages. If the recipient 284 is secure DHCPv6 enabled and the key or certificate authority is 285 trusted by the recipient, then their communication would be in secure 286 mode. In the scenario where the secure DHCPv6 enabled client and 287 server fail to build up secure communication between them, the secure 288 DHCPv6 enabled client MAY choose to send unsecured DHCPv6 message 289 towards the server according to its local policies. 291 In the scenario where the recipient is a legacy DHCPv6 server that 292 does not support secure mechanism, the DHCPv6 server (for all of 293 known DHCPv6 implementations) would just omit or disregard unknown 294 options (secure options defined in this document) and still process 295 the known options. The reply message would be unsecured, of course. 296 It is up to the local policy of the client whether to accept the 297 messages. If the client accepts the unsecured messages from the 298 DHCPv6 server, the subsequent exchanges will be in the unsecured 299 mode. 301 In the scenario where a legacy client sends an unsecured message to a 302 secure DHCPv6 enabled server, there are two possibilities depending 303 on the server policy. If the server's policy requires the 304 authentication, an UnspecFail (value 1, [RFC3315]) error status code, 305 SHOULD be returned. In such case, the client cannot build up the 306 connection with the server. If the server has been configured to 307 support unsecured clients, the server MAY fall back to the unsecured 308 DHCPv6 mode, and reply unsecured messages toward the client; 309 depending on the local policy, the server MAY continue to send the 310 secured reply messages with the consumption of computing resource. 311 The resources allocated for unsecured clients SHOULD be separated and 312 restricted. 314 5. Extensions for Secure DHCPv6 316 This section describes the extensions to DHCPv6. Four new options 317 have been defined. The new options MUST be supported in the Secure 318 DHCPv6 message exchange. 320 5.1. Public Key Option 322 The Public Key option carries the public key of the sender. The 323 format of the Public Key option is described as follows: 325 0 1 2 3 326 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 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | OPTION_PUBLIC_KEY | option-len | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | | 331 . Public Key (variable length) . 332 . . 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 option-code OPTION_PUBLIC_KEY (TBA1). 337 option-len Length of public key in octets. 339 Public Key A variable-length field containing a 340 SubjectPublicKeyInfo object specified in [RFC5280]. 341 The SubjectPublicKeyInfo structure is comprised with 342 a public key and an AlgorithmIdentifier object 343 which is specified in section 4.1.1.2, [RFC5280]. The 344 object identifiers for the supported algorithms and 345 the methods for encoding the public key materials 346 (public key and parameters) are specified in 347 [RFC3279], [RFC4055], and [RFC4491]. 349 5.2. Certificate Option 351 The Certificate option carries the public key certificate of the 352 client. The format of the Certificate option is described as 353 follows: 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | OPTION_CERTIFICATE | option-len | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | | 361 . Certificate (variable length) . 362 . . 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 option-code OPTION_CERTIFICATE (TBA2). 367 option-len Length of certificate in octets. 369 Certificate A variable-length field containing certificate. The 370 encoding of certificate and certificate data MUST 371 be in format as defined in Section 3.6, [RFC7296]. 372 The support of X.509 certificate - Signature (4) 373 is mandatory. 375 5.3. Signature Option 377 The Signature option allows a signature that is signed by the private 378 key to be attached to a DHCPv6 message. The Signature option could 379 be any place within the DHCPv6 message while it is logically created 380 after the entire DHCPv6 header and options, except for the 381 Authentication Option. It protects the entire DHCPv6 header and 382 options, including itself, except for the Authentication Option. The 383 format of the Signature option is described as follows: 385 0 1 2 3 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | OPTION_SIGNATURE | option-len | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | HA-id | SA-id | | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 392 | | 393 . Signature (variable length) . 394 . . 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 option-code OPTION_SIGNATURE (TBA3). 399 option-len 2 + Length of Signature field in octets. 401 HA-id Hash Algorithm id. The hash algorithm is used for 402 computing the signature result. This design is 403 adopted in order to provide hash algorithm agility. 404 The value is from the Hash Algorithm for Secure 405 DHCPv6 registry in IANA. The support of SHA-256 is 406 mandatory. A registry of the initial assigned values 407 is defined in Section 8. 409 SA-id Signature Algorithm id. The signature algorithm is 410 used for computing the signature result. This 411 design is adopted in order to provide signature 412 algorithm agility. The value is from the Signature 413 Algorithm for Secure DHCPv6 registry in IANA. The 414 support of RSASSA-PKCS1-v1_5 is mandatory. A 415 registry of the initial assigned values is defined 416 in Section 8. 418 Signature A variable-length field containing a digital 419 signature. The signature value is computed with 420 the hash algorithm and the signature algorithm, 421 as described in HA-id and SA-id. The signature 422 constructed by using the sender's private key 423 protects the following sequence of octets: 425 1. The DHCPv6 message header. 427 2. All DHCPv6 options including the Signature 428 option (fill the signature field with zeroes) 429 except for the Authentication Option. 431 The signature field MUST be padded, with all 0, to 432 the next octet boundary if its size is not a 433 multiple of 8 bits. The padding length depends on 434 the signature algorithm, which is indicated in the 435 SA-id field. 437 Note: if both signature and authentication option are present, 438 signature option does not protect the Authentication Option. It 439 allows the Authentication Option be created after signature has been 440 calculated and filled with the valid signature. It is because both 441 options need to apply hash algorithm to whole message, so there must 442 be a clear order and there could be only one last-created option. In 443 order to avoid update [RFC3315] because of changing auth option, the 444 authors chose not include authentication option in the signature. 446 5.4. Timestamp Option 448 The Timestamp option carries the current time on the sender. It adds 449 the anti-replay protection to the DHCPv6 messages. It is optional. 451 0 1 2 3 452 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 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | OPTION_TIMESTAMP | option-len | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | | 457 | Timestamp (64-bit) | 458 | | 459 | | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 option-code OPTION_TIMESTAMP (TBA4). 464 option-len 8, in octets. 466 Timestamp The current time of day (NTP-format timestamp 467 [RFC5905] in UTC (Coordinated Universal Time), a 468 64-bit unsigned fixed-point number, in seconds 469 relative to 0h on 1 January 1900.). It can reduce 470 the danger of replay attacks. 472 5.5. Status Codes 474 The following new status codes, see Section 5.4 of [RFC3315] are 475 defined. 477 o AlgorithmNotSupported (TBD5): indicates that the DHCPv6 server 478 does not support algorithms that sender used. 480 o AuthenticationFail (TBD6): indicates that the DHCPv6 client fails 481 authentication check. 483 o TimestampFail (TBD7): indicates the message from DHCPv6 client 484 fails the timestamp check. 486 o SignatureFail (TBD8): indicates the message from DHCPv6 client 487 fails the signature check. 489 6. Processing Rules and Behaviors 491 This section only covers the scenario where both DHCPv6 client and 492 DHCPv6 server are secure enabled. 494 6.1. Processing Rules of Sender 496 The sender of a Secure DHCPv6 message could be a DHCPv6 server or a 497 DHCPv6 client. 499 The sender must have a public/private key pair in order to create 500 Secure DHCPv6 messages. The sender may also have a public key 501 certificate, which is signed by a CA assumed to be trusted by the 502 recipient, and its corresponding private key. 504 To support Secure DHCPv6, the Secure DHCPv6 enabled sender MUST 505 construct the DHCPv6 message following the rules defined in 506 [RFC3315]. 508 A Secure DHCPv6 message sent by a DHCPv6 server or a client, except 509 for Relay-reply messages, MUST either contain a Public Key option, 510 which MUST be constructed as explained in Section 5.1, or a 511 Certificate option, which MUST be constructed as explained in 512 Section 5.2. 514 A Secure DHCPv6 message, except for Relay-forward and Relay-reply 515 messages, MUST contain one and only one Signature option, which MUST 516 be constructed as explained in Section 5.3. It protects the message 517 header and all DHCPv6 options except for the Authentication Option. 519 A Secure DHCPv6 message, except for Relay-forward and Relay-reply 520 messages, SHOULD contain one and only one Timestamp option, which 521 MUST be constructed as explained in Section 5.4. The Timestamp field 522 SHOULD be set to the current time, according to sender's real time 523 clock. 525 A Relay-forward and relay-reply message MUST NOT contain any 526 additional Public Key or Certificate option or Signature Option or 527 Timestamp Option, aside from those present in the innermost 528 encapsulated messages from the client or server. 530 If the sender is a DHCPv6 client, in the failure cases, it receives a 531 Reply message with an error status code. The error status code 532 indicates the failure reason on the server side. According to the 533 received status code, the client MAY take follow-up action: 535 o Upon receiving an AlgorithmNotSupported error status code, the 536 client SHOULD resend the message protected with one of the 537 mandatory algorithms. 539 o Upon receiving an AuthenticationFail error status code, the client 540 is not able to build up the secure communication with the 541 recipient. The client MAY switch to other public key certificate 542 if it has another one. But it SHOULD NOT retry with the same 543 certificate. However, if the client decides to retransmit using 544 the same certificate after receiving AuthenticationFail, it MUST 545 NOT retransmit immediately and MUST follow normal retransmission 546 routines defined in [RFC3315]. 548 o Upon receiving a TimestampFail error status code, the client MAY 549 fall back to unsecured mode, or resend the message without a 550 Timestamp option. However, the DHCPv6 server MAY not accept the 551 message without a Timestamp option. 553 o Upon receiving a SignatureFail error status code, the client MAY 554 resend the message following normal retransmission routines 555 defined in [RFC3315]. 557 6.2. Processing Rules of Recipient 559 The recipient of a Secure DHCPv6 message could be a DHCPv6 server or 560 a DHCPv6 client. In the failure cases, either DHCPv6 server or 561 client SHOULD NOT process received message, and the server SHOULD 562 reply a correspondent error status code, while the client does 563 nothing. The specific behavior depends on the configured local 564 policy. 566 When receiving a DHCPv6 message, except for Relay-Forward and Relay- 567 Reply messages, a Secure DHCPv6 enabled recipient SHOULD discard any 568 DHCPv6 messages that meet any of the following conditions: 570 o the Signature option is absent, 572 o multiple Signature options are present, 574 o both the Public Key option and the Certificate option are absent, 576 o both the Public Key option and the Certificate option are present. 578 In such failure, if the recipient is a DHCPv6 server, the server 579 SHOULD reply an UnspecFail (value 1, [RFC3315]) error status code. 580 If none of the Signature, Public Key or Certificate options is 581 present, the sender MAY be a legacy node or in unsecured mode, then, 582 the recipient MAY fall back to the unsecured DHCPv6 mode if its local 583 policy allows. 585 The recipient SHOULD first check the support of algorithms that 586 sender used. If not pass, the message is dropped. In such failure, 587 if the recipient is a DHCPv6 server, the server SHOULD reply an 588 AlgorithmNotSupported error status code, defined in Section 5.5, back 589 to the client. If both algorithms are supported, the recipient then 590 checks the authority of this sender. The recipient SHOULD also use 591 the same algorithms in the return messages. 593 If a Certificate option is provided, the recipient SHOULD validate 594 the certificate according to the rules defined in [RFC5280]. An 595 implementation may create a local trust certificate record for 596 verified certificates in order to avoid repeated verification 597 procedure in the future. A certificate that finds a match in the 598 local trust certificate list is treated as verified. 600 If a Public Key option is provided, the recipient SHOULD validate it 601 by finding a matching public key from the local trust public key 602 list, which is pre-configured or recorded from previous 603 communications (TOFU). A local trust public key list is a data table 604 maintained by the recipient. It stores public keys from all 605 trustworthy senders. 607 The message that fails authentication check MUST be dropped. In such 608 failure, the DHCPv6 server SHOULD reply an AuthenticationFail error 609 status code, defined in Section 5.5, back to the client. 611 The recipient MAY choose to further process messages from a sender 612 when there is no matched public key. By recording the public key, 613 when the first time it is seen, the recipient can make a Trust On 614 First Use that the sender is trustworthy. The circumstances under 615 which this might be done are out of scope for this document. 617 At this point, the recipient has either recognized the authentication 618 of the sender, or decided to drop the message. The recipient MUST 619 now authenticate the sender by verifying the signature and checking 620 timestamp (see details in Section 6.4), if there is a Timestamp 621 option. The order of two procedures is left as an implementation 622 decision. It is RECOMMENDED to check timestamp first, because 623 signature verification is much more computationally expensive. 624 Depending on server's local policy, the message without a Timestamp 625 option MAY be acceptable or rejected. If the server rejects such a 626 message, a TimestampFail error status code, defined in Section 5.5, 627 should be sent back to the client. The reply message that carries 628 the TimestampFail error status code SHOULD NOT carry a timestamp 629 option. 631 The signature field verification MUST show that the signature has 632 been calculated as specified in Section 5.3. Only the messages that 633 get through both the signature verifications and timestamp check (if 634 there is a Timestamp option) are accepted as secured DHCPv6 messages 635 and continue to be handled for their contained DHCPv6 options as 636 defined in [RFC3315]. Messages that do not pass the above tests MUST 637 be discarded or treated as unsecured messages. In the case the 638 recipient is DHCPv6 server, the DHCPv6 server SHOULD reply a 639 SignatureFail error status code, defined in Section 5.5, for the 640 signature verification failure; or a TimestampFail error status code, 641 defined in Section 5.5, for the timestamp check failure, back to the 642 client. 644 Furthermore, the node that supports the verification of the Secure 645 DHCPv6 messages MAY impose additional constraints for the 646 verification. For example, it may impose limits on minimum and 647 maximum key lengths. 649 Minbits The minimum acceptable key length for public keys. An upper 650 limit MAY also be set for the amount of computation needed when 651 verifying packets that use these security associations. The 652 appropriate lengths SHOULD be set according to the signature 653 algorithm and also following prudent cryptographic practice. For 654 example, minimum length 1024 and upper limit 2048 may be used for 655 RSA [RSA]. 657 A Relay-forward or Relay-reply message with any Public Key, 658 Certificate or the Signature option is invalid. The message MUST be 659 discarded silently. 661 6.3. Processing Rules of Relay Agent 663 To support Secure DHCPv6, relay agents just need to follow the same 664 processing rules defined in [RFC3315]. There is nothing more the 665 relay agents have to do, either verify the messages from client or 666 server, or add any secure DHCPv6 options. Actually, by definition in 667 this document, relay agents SHOULD NOT add any secure DHCPv6 options. 669 6.4. Timestamp Check 671 In order to check the Timestamp option, defined in Section 5.4, 672 recipients SHOULD be configured with an allowed timestamp Delta 673 value, a "fuzz factor" for comparisons, and an allowed clock drift 674 parameter. The recommended default value for the allowed Delta is 675 300 seconds (5 minutes); for fuzz factor 1 second; and for clock 676 drift, 0.01 second. 678 Note: the Timestamp mechanism is based on the assumption that 679 communication peers have roughly synchronized clocks, with certain 680 allowed clock drift. So, accurate clock is not necessary. If one 681 has a clock too far from the current time, the timestamp mechanism 682 would not work. 684 To facilitate timestamp checking, each recipient SHOULD store the 685 following information for each sender, from which at least one 686 accepted secure DHCPv6 message is successfully verified (for both 687 timestamp check and signature verification): 689 o The receive time of the last received and accepted DHCPv6 message. 690 This is called RDlast. 692 o The timestamp in the last received and accepted DHCPv6 message. 693 This is called TSlast. 695 A verified (for both timestamp check and signature verification) 696 secure DHCPv6 message initiates the update of the above variables in 697 the recipient's record. 699 Recipients MUST check the Timestamp field as follows: 701 o When a message is received from a new peer (i.e., one that is not 702 stored in the cache), the received timestamp, TSnew, is checked, 703 and the message is accepted if the timestamp is recent enough to 704 the reception time of the packet, RDnew: 706 -Delta < (RDnew - TSnew) < +Delta 708 After the signature verification also succeeds, the RDnew and 709 TSnew values SHOULD be stored in the cache as RDlast and TSlast. 711 o When a message is received from a known peer (i.e., one that 712 already has an entry in the cache), the timestamp is checked 713 against the previously received Secure DHCPv6 message: 715 TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz 717 If this inequality does not hold or RDnew < RDlast, the recipient 718 SHOULD silently discard the message. If, on the other hand, the 719 inequality holds, the recipient SHOULD process the message. 721 Moreover, if the above inequality holds and TSnew > TSlast, the 722 recipient SHOULD update RDlast and TSlast after the signature 723 verification also successes. Otherwise, the recipient MUST NOT 724 update RDlast or TSlast. 726 An implementation MAY use some mechanism such as a timestamp cache to 727 strengthen resistance to replay attacks. When there is a very large 728 number of nodes on the same link, or when a cache filling attack is 729 in progress, it is possible that the cache holding the most recent 730 timestamp per sender will become full. In this case, the node MUST 731 remove some entries from the cache or refuse some new requested 732 entries. The specific policy as to which entries are preferred over 733 others is left as an implementation decision. 735 An implementation MAY statefully record the latest timestamps from 736 senders. In such implementation, the timestamps MUST be strictly 737 monotonously increasing. This is reasonable given that DHCPv6 738 messages are rarely misordered. 740 7. Deployment Consideration 742 This document defines two directions of authentication: 743 authentication based on client's public key certificate and 744 authentication based on leap of faith to server's public key. 746 7.1. Authentication on a client 748 For clients, DHCPv6 authentication generally means verifying whether 749 the sender of DHCPv6 messages is a legal DHCPv6 server and verifying 750 whether the message has been modified during transmission. Because 751 the client may have to validate the authentication in the condition 752 of without connectivity wider than link-local, authentication with 753 certificates may not always be feasible. So, this document only 754 sticks on Leaf of Faith mode, to make sure the client talks to the 755 same previous server. 757 Message integrity is provided. But there is a chance for the client 758 to incorrectly trust a malicious server at the beginning of the first 759 session with the server (and therefore keep trusting it thereafter). 760 But the leap of faith mechanim guarantees the subsequent messages are 761 sent by the same previous server, and therefore narrows the attack 762 scope. This may make sense if the network can be reasonably 763 considered secure and requesting pre-configuration is deemed to be 764 infeasible. A small home network would be an example of such cases. 766 For environments that are neither controlled nor really trustworthy, 767 such as a network in a cafeteria, while the leap of faith mode, i.e., 768 silently trusting the server at the first time, would be too 769 insecure. But some middle ground might be justified, such as 770 requiring human intervention at the point of the leap of faith. 772 7.2. Authentication on a server 774 As for authentication on a server, there are several different 775 scenarios to consider, each of which has different applicability 776 issues. If the server allows the leap of faith mode, any malicious 777 user can pretend to be a new legitimate client. While the server can 778 always be considered to have connectivity to validate certificate, it 779 is feasible to check client certificates. 781 Network administrators may wish to constrain the allocation of 782 addresses to authorized hosts to avoid denial of service attacks in 783 "hostile" environments where the network medium is not physically 784 secured, such as wireless networks or college residence halls. A 785 server may have to selectively serve a specific client or deny 786 specific clients depending on the identity of the client in a 787 controlled environment, like a corporate intranet. But the support 788 from skilled staff or administrator may be required to set up the 789 clients. 791 8. Security Considerations 793 This document provides new security features to the DHCPv6 protocol. 795 Using public key based security mechanism and its verification 796 mechanism in DHCPv6 message exchanging provides the authentication 797 and data integrity protection. Timestamp mechanism provides anti- 798 replay function. 800 The Secure DHCPv6 mechanism is based on the pre-condition that the 801 recipient knows the public key of the sender or the sender's public 802 key certificate can be verified through a trust CA. Clients may 803 discard the DHCPv6 messages from unknown/unverified servers, which 804 may be fake servers; or may prefer DHCPv6 messages from known/ 805 verified servers over unsigned messages or messages from unknown/ 806 unverified servers. The pre-configuration operation also needs to be 807 protected, which is out of scope. The deployment of PKI is also out 808 of scope. 810 When a recipient first encounters a new public key, it may also store 811 the key using a Trust On First Use policy. If the sender that used 812 that public key is in fact legitimate, then all future communication 813 with that sender can be protected by storing the public key. This 814 does not provide complete security, but it limits the opportunity to 815 mount an attack on a specific recipient to the first time it 816 communicates with a new sender. 818 Downgrade attacks cannot be avoided if nodes are configured to accept 819 both secured and unsecured messages. A future specification may 820 provide a mechanism on how to treat unsecured DHCPv6 messages. 822 [RFC6273] has analyzed possible threats to the hash algorithms used 823 in SEND. Since the Secure DHCPv6 defined in this document uses the 824 same hash algorithms in similar way to SEND, analysis results could 825 be applied as well: current attacks on hash functions do not 826 constitute any practical threat to the digital signatures used in the 827 signature algorithm in the Secure DHCPv6. 829 A server, whose local policy accepts messages without a Timestamp 830 option, may have to face the risk of replay attacks. 832 A window of vulnerability for replay attacks exists until the 833 timestamp expires. Secure DHCPv6 nodes are protected against replay 834 attacks as long as they cache the state created by the message 835 containing the timestamp. The cached state allows the node to 836 protect itself against replayed messages. However, once the node 837 flushes the state for whatever reason, an attacker can re-create the 838 state by replaying an old message while the timestamp is still valid. 839 In addition, the effectiveness of timestamps is largely dependent 840 upon the accuracy of synchronization between communicating nodes. 841 However, how the two communicating nodes can be synchronized is out 842 of scope of this work. 844 Attacks against time synchronization protocols such as NTP [RFC5905] 845 may cause Secure DHCPv6 nodes to have an incorrect timestamp value. 846 This can be used to launch replay attacks, even outside the normal 847 window of vulnerability. To protect against these attacks, it is 848 recommended that Secure DHCPv6 nodes keep independently maintained 849 clocks or apply suitable security measures for the time 850 synchronization protocols. 852 One more consideration is that this protocol does reveal additional 853 client information in their certificate. It means less privacy. In 854 current practice, the client privacy and the client authentication 855 are mutually exclusive. 857 9. IANA Considerations 859 This document defines four new DHCPv6 [RFC3315] options. The IANA is 860 requested to assign values for these four options from the DHCPv6 861 Option Codes table of the DHCPv6 Parameters registry maintained in 862 http://www.iana.org/assignments/dhcpv6-parameters. The four options 863 are: 865 The Public Key Option (TBA1), described in Section 5.1. 867 The Certificate Option (TBA2), described in Section 5.2. 869 The Signature Option (TBA3), described in Section 5.3. 871 The Timestamp Option (TBA4),described in Section 5.4. 873 The IANA is also requested to add two new registry tables to the 874 DHCPv6 Parameters registry maintained in 875 http://www.iana.org/assignments/dhcpv6-parameters. The two tables 876 are the Hash Algorithm for Secure DHCPv6 table and the Signature 877 Algorithm for Secure DHCPv6 table. 879 Initial values for these registries are given below. Future 880 assignments are to be made through Standards Action [RFC5226]. 881 Assignments for each registry consist of a name, a value and a RFC 882 number where the registry is defined. 884 Hash Algorithm for Secure DHCPv6. The values in this table are 8-bit 885 unsigned integers. The following initial values are assigned for 886 Hash Algorithm for Secure DHCPv6 in this document: 888 Name | Value | RFCs 889 -------------------+---------+-------------- 890 SHA-256 | 0x01 | this document 891 SHA-512 | 0x02 | this document 893 Signature Algorithm for Secure DHCPv6. The values in this table are 894 8-bit unsigned integers. The following initial values are assigned 895 for Signature Algorithm for Secure DHCPv6 in this document: 897 Name | Value | RFCs 898 -------------------+---------+-------------- 899 RSASSA-PKCS1-v1_5 | 0x01 | this document 901 IANA is requested to assign the following new DHCPv6 Status Codes, 902 defined in Section 5.5, in the DHCPv6 Parameters registry maintained 903 in http://www.iana.org/assignments/dhcpv6-parameters: 905 Code | Name | Reference 906 ---------+-----------------------+-------------- 907 TBD5 | AlgorithmNotSupported | this document 908 TBD6 | AuthenticationFail | this document 909 TBD7 | TimestampFail | this document 910 TBD8 | SignatureFail | this document 912 10. Acknowledgements 914 The authors would like to thank Bernie Volz, Ted Lemon, Ralph Droms, 915 Jari Arkko, Sean Turner, Stephen Kent, Thomas Huth, David Schumacher, 916 Francis Dupont, Tomek Mrugalski, Gang Chen, Qi Sun, Suresh Krishnan, 917 Fred Templin and other members of the IETF DHC working group for 918 their valuable comments. 920 This document was produced using the xml2rfc tool [RFC2629]. 922 11. Change log [RFC Editor: Please remove] 924 draft-ietf-dhc-sedhcpv6-06: remove the limitation that only clients 925 use PKI- certificates and only servers use public keys. The new text 926 would allow clients use public keys and servers use PKI-certificates 928 draft-ietf-dhc-sedhcpv6-05: addressed comments from mail list that 929 responsed to the second WGLC. 931 draft-ietf-dhc-sedhcpv6-04: addressed comments from mail list. 932 Making timestamp an independent and optional option. Reduce the 933 serverside authentication to base on only client's certificate. 934 Reduce the clientside authentication to only Leaf of Faith base on 935 server's public key. 2014-09-26. 937 draft-ietf-dhc-sedhcpv6-03: addressed comments from WGLC. Added a 938 new section "Deployment Consideration". Corrected the Public Key 939 Field in the Public Key Option. Added consideration for large DHCPv6 940 message transmission. Added TimestampFail error code. Refined the 941 retransmission rules on clients. 2014-06-18. 943 draft-ietf-dhc-sedhcpv6-02: addressed comments (applicability 944 statement, redesign the error codes and their logic) from IETF89 DHC 945 WG meeting and volunteer reviewers. 2014-04-14. 947 draft-ietf-dhc-sedhcpv6-01: addressed comments from IETF88 DHC WG 948 meeting. Moved Dacheng Zhang from acknowledgement to be co-author. 949 2014-02-14. 951 draft-ietf-dhc-sedhcpv6-00: adopted by DHC WG. 2013-11-19. 953 draft-jiang-dhc-sedhcpv6-02: removed protection between relay agent 954 and server due to complexity, following the comments from Ted Lemon, 955 Bernie Volz. 2013-10-16. 957 draft-jiang-dhc-sedhcpv6-01: update according to review comments from 958 Ted Lemon, Bernie Volz, Ralph Droms. Separated Public Key/ 959 Certificate option into two options. Refined many detailed 960 processes. 2013-10-08. 962 draft-jiang-dhc-sedhcpv6-00: original version, this draft is a 963 replacement of draft-ietf-dhc-secure-dhcpv6, which reached IESG and 964 dead because of consideration regarding to CGA. The authors followed 965 the suggestion from IESG making a general public key based mechanism. 966 2013-06-29. 968 12. References 970 12.1. Normative References 972 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 973 Requirement Levels", BCP 14, RFC 2119, March 1997. 975 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 976 (IPv6) Specification", RFC 2460, December 1998. 978 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 979 Identifiers for the Internet X.509 Public Key 980 Infrastructure Certificate and Certificate Revocation List 981 (CRL) Profile", RFC 3279, April 2002. 983 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 984 and M. Carney, "Dynamic Host Configuration Protocol for 985 IPv6 (DHCPv6)", RFC 3315, July 2003. 987 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 988 Algorithms and Identifiers for RSA Cryptography for use in 989 the Internet X.509 Public Key Infrastructure Certificate 990 and Certificate Revocation List (CRL) Profile", RFC 4055, 991 June 2005. 993 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 994 Message Protocol (ICMPv6) for the Internet Protocol 995 Version 6 (IPv6) Specification", RFC 4443, March 2006. 997 [RFC4491] Leontiev, S. and D. Shefanovski, "Using the GOST R 998 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 999 Algorithms with the Internet X.509 Public Key 1000 Infrastructure Certificate and CRL Profile", RFC 4491, May 1001 2006. 1003 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1004 Housley, R., and W. Polk, "Internet X.509 Public Key 1005 Infrastructure Certificate and Certificate Revocation List 1006 (CRL) Profile", RFC 5280, May 2008. 1008 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1009 Time Protocol Version 4: Protocol and Algorithms 1010 Specification", RFC 5905, June 2010. 1012 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1013 Kivinen, "Internet Key Exchange Protocol Version 2 1014 (IKEv2)", STD 79, RFC 7296, October 2014. 1016 12.2. Informative References 1018 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1019 June 1999. 1021 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 1022 Hashes in Internet Protocols", RFC 4270, November 2005. 1024 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1025 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1026 May 2008. 1028 [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure 1029 Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, 1030 June 2011. 1032 [RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1, 1033 PKCS 1", November 2002. 1035 Authors' Addresses 1037 Sheng Jiang (editor) 1038 Huawei Technologies Co., Ltd 1039 Q14, Huawei Campus, No.156 Beiqing Road 1040 Hai-Dian District, Beijing, 100095 1041 CN 1043 Email: jiangsheng@huawei.com 1045 Sean Shen 1046 CNNIC 1047 4, South 4th Street, Zhongguancun 1048 Beijing 100190 1049 CN 1051 Email: shenshuo@cnnic.cn 1053 Dacheng Zhang 1054 Huawei Technologies Co., Ltd 1055 Q14, Huawei Campus, No.156 Beiqing Road 1056 Hai-Dian District, Beijing, 100095 1057 CN 1059 Email: zhangdacheng@huawei.com 1061 Tatuya Jinmei 1062 Infoblox Inc. 1063 3111 Coronado Drive 1064 Santa Clara, CA 1065 US 1067 Email: jinmei@wide.ad.jp