idnits 2.17.1 draft-ietf-dhc-sedhcpv6-04.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 (September 29, 2014) is 3497 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 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: 3 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: April 2, 2015 CNNIC 6 D. Zhang 7 Huawei Technologies Co., Ltd 8 T. Jinmei 9 Infoblox Inc. 10 September 29, 2014 12 Secure DHCPv6 13 draft-ietf-dhc-sedhcpv6-04 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 server's public/private key pairs 25 and client's certificates. The DHCPv6 message exchanges are 26 protected by the signature option and the timestamp option newly 27 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 April 2, 2015. 46 Copyright Notice 48 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . 12 79 6.3. Processing Rules of Relay Agent . . . . . . . . . . . . . 14 80 6.4. Timestamp Check . . . . . . . . . . . . . . . . . . . . . 15 81 7. Deployment Consideration . . . . . . . . . . . . . . . . . . 16 82 7.1. Authentication on a client . . . . . . . . . . . . . . . 16 83 7.2. Authentication on a server . . . . . . . . . . . . . . . 17 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 86 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . . . . . 22 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, are considered less 115 vulnerable, because they are only transported within operator 116 networks. Communication between a server and a relay agent, and 117 communications between relay agents, may be secured through the use 118 of IPsec, as described in section 21.1 in [RFC3315]. 120 The security mechanisms specified in this document is based on 121 server's public/private key pairs and client's certificates. The 122 reason for such design and deployment consideration are discussed in 123 Section 7. It also integrates message signatures for the integrity 124 and timestamps for anti-replay. The client authentication on server 125 procedure defined in this document depends on deployed Public Key 126 Infrastructure (PKI, [RFC5280]). However, the deployment of PKI is 127 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 key of the hash function, there are two key management 159 mechanisms. Firstly, the key management is done out of band, usually 160 through some manual process. For example, operators can set up a key 161 database for both servers and clients which the client obtains a key 162 before running DHCPv6. 164 Manual key distribution runs counter to the goal of minimizing the 165 configuration data needed at each host. 167 [RFC3315] provides an additional mechanism for preventing off-network 168 timing attacks using the Reconfigure message: the Reconfigure Key 169 authentication method. However, this method provides no message 170 integrity or source integrity check. This key is transmitted in 171 plaintext. 173 In comparison, the security mechanism defined in this document allows 174 the public key database on the client to be populated 175 opportunistically or manually, depending on the degree of confidence 176 desired in a specific application. PKI security mechanism is simpler 177 in the local key management respect. 179 4. Overview of Secure DHCPv6 Mechanism with Public Key 181 This document introduces a Secure DHCPv6 mechanism that uses 182 signatures to secure the DHCPv6 protocol. In order to enable DHCPv6 183 clients and DHCPv6 servers to perform mutual authentication without 184 previous key deployment, this solution provides a DHCPv6 client/ 185 server authentication mechanism based on server's public/private key 186 pairs and client's certificates: the server only accept the client 187 messages that are protected by the client certificate that is signed 188 by a trusted CA; a client can build up trust relationship with a 189 server for subsequent message exchanges based on leap of faith (LoF) 190 mechanism. This purpose of this design is to simplify the 191 precondition of deploying DHCPv6 authentication and provides limited 192 protection of DHCPv6 message. 194 In this document, we introduce a public key option (only sent by 195 servers), a certificate option (only sent by clients), a signature 196 option and a timestamp with corresponding verification mechanisms. A 197 DHCPv6 message from a server is attached with a public key option, 198 and carrying a digital signature and a timestamp option. It can be 199 verified by the client. The client processes the payload of the 200 DHCPv6 message only if the validation is successful. Reversely, a 201 DHCPv6 message from a client is attached with a certificate option, 202 and also carrying a digital signature and a timestamp option. It can 203 be verified by the server. The server processes the payload of the 204 DHCPv6 message only if the validation is successful. The end-to-end 205 security protection is bidirection that covers both from DHCPv6 206 servers to clients and from clients to DHCPv6 servers. Additionally, 207 the optional timestamp mechanism provides anti-replay protection. 209 By recording the public key that was used by the DHCPv6 server, when 210 the first time it is seen, the DHCPv6 client can make a leap of faith 211 that the server is trustworthy. If no evidence to the contrary 212 surfaces, the client can then validate the server as trustworthy when 213 it subsequently sees the same public key used to sign messages from 214 the same server. In opposite, once the client has determined that it 215 is being attacked, it can either forget that server, or remember that 216 server in a blacklist and drop further packets associated with that 217 server. 219 On the server DHCPv6 side, upon receiving the client's certificate, 220 the server asserts the validity of the certificate, for example 221 through PKI. 223 Secure DHCPv6 messages are commonly large. IPv6 fragments [RFC2460] 224 are highly possible. Hence, deployment of Secure DHCPv6 should also 225 consider the issues of IP fragment, PMTU, etc. Also, if there are 226 firewalls between secure DHCPv6 clients and secure DHCPv6 servers, it 227 is RECOMMENDED that the firewalls are configured to pass ICMP Packet 228 Too Big messages [RFC4443]. 230 4.1. New Components 232 The components of the solution specified in this document are as 233 follows: 235 o The server generates a public/private key pair. A DHCPv6 option 236 that carries the public key is defined. 238 o The client obtains a certificate from a Certificate Authority that 239 can be used to establish the trustworthiness with the server. 240 Another option is defined to carry the certificate. 242 o A signature generated using the private key which is used by the 243 receiver to verify the integrity of the DHCPv6 messages and then 244 the identity of the sender. 246 o A timestamp, to detect replayed packet. The secure DHCPv6 nodes 247 need to meet some accuracy requirements and be synced to global 248 time, while the timestamp checking mechanism allows a configurable 249 time value for clock drift. The real time provision is out of 250 scope. 252 4.2. Support for Algorithm Agility 254 Hash functions are used to provide message integrity checks. In 255 order to provide a means of addressing problems that may emerge in 256 the future with existing hash algorithms, as recommended in 257 [RFC4270], this document provides a mechanism for negotiating the use 258 of more secure hashes in the future. 260 In addition to hash algorithm agility, this document also provides a 261 mechanism for signature algorithm agility. 263 The support for algorithm agility in this document is mainly a 264 unilateral notification mechanism from sender to recipient. A 265 recipient MAY support various algorithms simultaneously, and the 266 different senders in a same administrative domain may be allowed to 267 use various algorithms simultaneously. 269 If the recipient does not support the algorithm used by the sender, 270 it cannot authenticate the message. In the client-to-server case, 271 the server SHOULD reply with an AlgorithmNotSupported status code 272 (defined in Section 5.5). Upon receiving this status code, the 273 client MAY resend the message protected with the mandatory algorithm 274 (defined in Section 5.3). 276 4.3. Applicability 278 By default, a secure DHCPv6 enabled client SHOULD start with secure 279 mode by sending secure DHCPv6 messages. If the recipient is secure 280 DHCPv6 enabled server, their communication would be in secure mode. 281 In the scenario where the secure DHCPv6 enabled client and server 282 fail to build up secure communication between them, the secure DHCPv6 283 enabled client MAY choose to send unsecured DHCPv6 message towards 284 the server according to its local policies. 286 In the scenario where the recipient is a legacy DHCPv6 server that 287 does not support secure mechanism, the DHCPv6 server (for all of 288 known DHCPv6 implementations) would just omit or disregard unknown 289 options (secure options defined in this document) and still process 290 the known options. The reply message would be unsecured, of course. 291 It is up to the local policy of the client whether to accept the 292 messages. If the client accepts the unsecured messages from the 293 DHCPv6 server, the subsequent exchanges will be in the unsecured 294 mode. 296 In the scenario where a legacy client sends an unsecured message to a 297 secure DHCPv6 enabled server, there are two possibilities depending 298 on the server policy. If the server's policy requires the 299 authentication, an UnspecFail (value 1, [RFC3315]) error status code, 300 SHOULD be returned. In such case, the client cannot build up the 301 connection with the server. If the server has been configured to 302 support unsecured clients, the server MAY fall back to the unsecured 303 DHCPv6 mode, and reply unsecured messages toward the client; 304 depending on the local policy, the server MAY continue to send the 305 secured reply messages with the consumption of computing resource. 306 The resources allocated for unsecured clients SHOULD be separated and 307 restricted. 309 5. Extensions for Secure DHCPv6 311 This section describes the extensions to DHCPv6. Four new options 312 have been defined. The new options MUST be supported in the Secure 313 DHCPv6 message exchange. 315 5.1. Public Key Option 317 The Public Key option carries the public key of the server. The 318 format of the Public Key option is described as follows: 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | OPTION_PK_PARAMETER | option-len | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | | 326 . Public Key (variable length) . 327 . . 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 option-code OPTION_PK_PARAMETER (TBA1). 332 option-len Length of public key in octets. 334 Public Key A variable-length field containing public key and 335 identify the algorithm with which the key is used 336 (e.g., RSA, DSA, or Diffie-Hellman). The algorithm 337 is identified using the AlgorithmIdentifier structure 338 specified in section 4.1.1.2, [RFC5280]. The object 339 identifiers for the supported algorithms and the 340 methods for encoding the public key materials 341 (public key and parameters) are specified in 342 [RFC3279], [RFC4055], and [RFC4491]. 344 5.2. Certificate Option 346 The Certificate option carries the certificate of the client. The 347 format of the Certificate option is described as follows: 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | OPTION_CERT_PARAMETER | option-len | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | | 355 . Certificate (variable length) . 356 . . 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 option-code OPTION_CERT_PARAMETER (TBA2). 361 option-len Length of certificate in octets. 363 Certificate A variable-length field containing certificate. The 364 encoding of certificate and certificate data MUST 365 be in format as defined in Section 3.6, [RFC5996]. 366 The support of X.509 certificate is mandatory. 368 5.3. Signature Option 370 The Signature option allows a signature that is signed by the private 371 key to be attached to a DHCPv6 message. The Signature option could 372 be any place within the DHCPv6 message while it is logically created 373 after the entire DHCPv6 header and options, except for the 374 Authentication Option. It protects the entire DHCPv6 header and 375 options, including itself, except for the Authentication Option. The 376 format of the Signature option is described as follows: 378 0 1 2 3 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | OPTION_SIGNATURE | option-len | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | HA-id | SA-id | | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 385 | | 386 . Signature (variable length) . 387 . . 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 option-code OPTION_SIGNATURE (TBA3). 392 option-len 2 + Length of Signature field in octets. 394 HA-id Hash Algorithm id. The hash algorithm is used for 395 computing the signature result. This design is 396 adopted in order to provide hash algorithm agility. 397 The value is from the Hash Algorithm for Secure 398 DHCPv6 registry in IANA. The support of SHA-256 is 399 mandatory. A registry of the initial assigned values 400 is defined in Section 8. 402 SA-id Signature Algorithm id. The signature algorithm is 403 used for computing the signature result. This 404 design is adopted in order to provide signature 405 algorithm agility. The value is from the Signature 406 Algorithm for Secure DHCPv6 registry in IANA. The 407 support of RSASSA-PKCS1-v1_5 is mandatory. A 408 registry of the initial assigned values is defined 409 in Section 8. 411 Signature A variable-length field containing a digital 412 signature. The signature value is computed with 413 the hash algorithm and the signature algorithm, 414 as described in HA-id and SA-id. The signature 415 constructed by using the sender's private key 416 protects the following sequence of octets: 418 1. The DHCPv6 message header. 420 2. All DHCPv6 options including the Signature 421 option (fill the signature field with zeroes) 422 except for the Authentication Option. 424 The signature field MUST be padded, with all 0, to 425 the next octet boundary if its size is not a 426 multiple of 8 bits. The padding length depends on 427 the signature algorithm, which is indicated in the 428 SA-id field. 430 Note: if both signature and authentication option are presented, 431 signature option does not protect the Authentication Option. It 432 allows the Authentication Option be created after signature has been 433 calculated and filled with the valid signature. It is because both 434 options need to apply hash algorithm to whole message, so there must 435 be a clear order and there could be only one last-created option. In 436 order to avoid update [RFC3315] because of changing auth option, the 437 authors chose not include authentication option in the signature. 439 5.4. Timestamp Option 441 The Timestamp option carries the current time on the sender. It adds 442 the anti-replay protection to the DHCPv6 messages. It is optional. 444 0 1 2 3 445 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 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | OPTION_TIMESTAMP | option-len | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | | 450 | Timestamp (64-bit) | 451 | | 452 | | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 option-code OPTION_TIMESTAMP (TBA4). 457 option-len 8, in octets. 459 Timestamp The current time of day (NTP-format timestamp 460 [RFC5905] in UTC (Coordinated Universal Time), a 461 64-bit unsigned fixed-point number, in seconds 462 relative to 0h on 1 January 1900.). It can reduce 463 the danger of replay attacks. 465 5.5. Status Codes 467 o AlgorithmNotSupported (TBD5): indicates that the DHCPv6 server 468 does not support algorithms that sender used. 470 o AuthenticationFail (TBD6): indicates that the DHCPv6 client fails 471 authentication check. 473 o TimestampFail (TBD7): indicates the message from DHCPv6 client 474 fails the timestamp check. 476 o SignatureFail (TBD8): indicates the message from DHCPv6 client 477 fails the signature check. 479 6. Processing Rules and Behaviors 481 This section only covers the scenario where both DHCPv6 client and 482 DHCPv6 server are secure enabled. 484 6.1. Processing Rules of Sender 486 The sender of a Secure DHCPv6 message could be a DHCPv6 server or a 487 DHCPv6 client. 489 The server must have a public/private key pair in order to create 490 Secure DHCPv6 messages. The client must have a certificate which is 491 signed by a CA trusted by both server and client. 493 To support secure DHCPv6, the secure DHCPv6 enabled sender MUST 494 construct the DHCPv6 message following the rules defined in 495 [RFC3315]. 497 A Secure DHCPv6 message, except for Relay-forward and Relay-reply 498 messages, MUST contain either a Public Key or a Certificate option, 499 which MUST be constructed as explained in Section 5.1 or Section 5.2. 501 A Secure DHCPv6 message, except for Relay-forward and Relay-reply 502 messages, MUST contain one and only one Signature option, which MUST 503 be constructed as explained in Section 5.3. It protects the message 504 header and all DHCPv6 options except for the Authentication Option. 506 A Secure DHCPv6 message, except for Relay-forward and Relay-reply 507 messages, MAY contain one and only one Timestamp option. The 508 Timestamp field SHOULD be set to the current time, according to 509 sender's real time clock. 511 A Relay-forward and relay-reply message MUST NOT contain any 512 additional Public Key or Certificate option or Signature Option or 513 Timestamp Option, aside from those present in the innermost 514 encapsulated messages from the client or server. 516 If the sender is a DHCPv6 client, in the failure cases, it receives a 517 Reply message with an error status code. The error status code 518 indicates the failure reason on the server side. According to the 519 received status code, the client MAY take follow-up action: 521 o Upon receiving an AlgorithmNotSupported error status code, the 522 client SHOULD resend the message protected with the mandatory 523 algorithms. 525 o Upon receiving an AuthenticationFail error status code, the client 526 is not able to build up the secure communication with the 527 recipient. The client MAY switch to other certificate if it has. 528 But it SHOULD NOT retry with the same certificate. It MAY retry 529 with the same certificate following normal retransmission routines 530 defined in [RFC3315]. 532 o Upon receiving a TimestampFail error status code, the client MAY 533 fall back to unsecured mode, or resend the message without a 534 Timestamp option. However, the DHCP server MAY not accept the 535 message without a Timestamp option. 537 o Upon receiving a SignatureFail error status code, the client MAY 538 resend the message following normal retransmission routines 539 defined in [RFC3315]. 541 6.2. Processing Rules of Recipient 543 The recipient of a Secure DHCPv6 message could be a DHCPv6 server or 544 a DHCPv6 client. In the failure cases, either DHCPv6 server or 545 client SHOULD NOT process received message, and the server SHOULD 546 reply a correspondent error status code, while the client does 547 nothing. The specific behavior depends on the configured local 548 policy. 550 When receiving a DHCPv6 message, except for Relay-Forward and Relay- 551 Reply messages, a secure DHCPv6 enabled recipient SHOULD discard any 552 DHCPv6 messages that meet any of the following conditions: 554 o the Signature option is absent, 556 o multiple Signature option is presented, 558 o the Public Key option is absent in the server-to-client message, 559 o the Certificate option is presented in the server-to-client 560 message, 562 o the Certificate option is absent in the client-to-server message, 564 o the Public Key option is presented in the client-to-server 565 message. 567 In such failure, if the recipient is a DHCPv6 server, the server 568 SHOULD reply an UnspecFail (value 1, [RFC3315]) error status code. 569 If neither of the Signature, Public Key or Certificate options is 570 presented, the sender MAY be a legacy node or in unsecured mode, 571 then, the recipient MAY fall back to the unsecured DHCPv6 mode if its 572 local policy allows. 574 The recipient SHOULD first check the support of algorithms that 575 sender used. If not pass, the message is dropped. In such failure, 576 if the recipient is a DHCPv6 server, the server SHOULD reply an 577 AlgorithmNotSupported error status code, defined in Section 5.5, back 578 to the client. If all algorithms are supported, the recipient then 579 checks the authority of this sender. 581 The DHCPv6 server SHOULD validate the client's certificate following 582 the rules defined in [RFC5280]. An implementation may create a local 583 trust certificate record for verified certificates in order to avoid 584 repeated verification procedure in the future. A client certificate 585 that finds a match in the local trust certificate list is treated as 586 verified. A fast search index may be created for this list. 588 The DHCPv6 client SHOULD validate it by finding a matching public key 589 from the local trust public key list, which is pre-configured or 590 recorded from previous communications. A local trust public key list 591 is a data table maintained by the recipient. It restores public keys 592 from all trustworthy senders. A fast search index may be created for 593 this list. The message that fails authentication check MUST be 594 dropped. In such failure, the DHCPv6 server SHOULD reply an 595 AuthenticationFail error status code, defined in Section 5.5, back to 596 the client. 598 The client MAY choose to further process messages from a server for 599 which there is no matched public key. By recording the public key, 600 when the first time it is seen, the client can make a leap of faith 601 (LoF) that the server is trustworthy. If no evidence to the contrary 602 surfaces, the client can then validate the server as trustworthy for 603 subsequent message exchanges. In opposite, once the client has 604 determined that it is being attacked, it can either forget that 605 public key, or remember that public key in a blacklist and drop 606 further packets associated with that public key. 608 At this point, the recipient has either recognized the authentication 609 of the sender, or decided to drop the message. The recipient MUST 610 now authenticate the sender by verifying the signature and checking 611 timestamp (see details in Section 6.4), if there is a Timestamp 612 option. The order of two procedures is left as an implementation 613 decision. It is RECOMMENDED to check timestamp first, because 614 signature verification is much more computationally expensive. 615 Depending on server's local policy, the message without a Timestamp 616 option MAY be acceptable or rejected. If the server rejects such a 617 message, a TimestampFail error status code, defined in Section 5.5, 618 should be sent back to the client. 620 The signature field verification MUST show that the signature has 621 been calculated as specified in Section 5.3. Only the messages that 622 get through both the signature verifications and timestamp check (if 623 there is a Timestamp option) are accepted as secured DHCPv6 messages 624 and continue to be handled for their contained DHCPv6 options as 625 defined in [RFC3315]. Messages that do not pass the above tests MUST 626 be discarded or treated as unsecured messages. In the case the 627 recipient is DHCPv6 server, the DHCPv6 server SHOULD reply a 628 SignatureFail error status code, defined in Section 5.5, for the 629 signature verification failure; or a TimestampFail error status code, 630 defined in Section 5.5, for the timestamp check failure, back to the 631 client. 633 Furthermore, the node that supports the verification of the Secure 634 DHCPv6 messages MAY record the following information: 636 Minbits The minimum acceptable key length for public keys. An upper 637 limit MAY also be set for the amount of computation needed when 638 verifying packets that use these security associations. The 639 appropriate lengths SHOULD be set according to the signature 640 algorithm and also following prudent cryptographic practice. For 641 example, minimum length 1024 and upper limit 2048 may be used for 642 RSA [RSA]. 644 A Relay-forward or Relay-reply message with any Public Key, 645 Certificate or the Signature option is invalid. The message MUST be 646 discarded silently. 648 6.3. Processing Rules of Relay Agent 650 To support Secure DHCPv6, relay agents just need to follow the same 651 processing rules defined in [RFC3315]. There is nothing more the 652 relay agents have to do, either verify the messages from client or 653 server, or add any secure DHCPv6 options. Actually, by definition in 654 this document, relay agents SHOULD NOT add any secure DHCPv6 options. 656 6.4. Timestamp Check 658 In order to check the Timestamp option, defined in Section 5.4, 659 recipients SHOULD be configured with an allowed timestamp Delta 660 value, a "fuzz factor" for comparisons, and an allowed clock drift 661 parameter. The recommended default value for the allowed Delta is 662 300 seconds (5 minutes); for fuzz factor 1 second; and for clock 663 drift, 0.01 second. 665 Note: the Timestamp mechanism is based on the assumption that 666 communication peers have roughly synchronized clocks, with certain 667 allowed clock drift. So, accurate clock is not necessary. If one 668 has a clock too far from the current time, the timestamp mechanism 669 would not work. 671 To facilitate timestamp checking, each recipient SHOULD store the 672 following information for each sender, from which at least one 673 accepted secure DHCPv6 message is successfully verified (for both 674 timestamp check and signature verification): 676 o The receive time of the last received and accepted DHCPv6 message. 677 This is called RDlast. 679 o The timestamp in the last received and accepted DHCPv6 message. 680 This is called TSlast. 682 A verified (for both timestamp check and signature verification) 683 secure DHCPv6 message initiates the update of the above variables in 684 the recipient's record. 686 Recipients MUST check the Timestamp field as follows: 688 o When a message is received from a new peer (i.e., one that is not 689 stored in the cache), the received timestamp, TSnew, is checked, 690 and the message is accepted if the timestamp is recent enough to 691 the reception time of the packet, RDnew: 693 -Delta < (RDnew - TSnew) < +Delta 695 After the signature verification also successes, the RDnew and 696 TSnew values SHOULD be stored in the cache as RDlast and TSlast. 698 o When a message is received from a known peer (i.e., one that 699 already has an entry in the cache), the timestamp is checked 700 against the previously received Secure DHCPv6 message: 702 TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz 704 If this inequality does not hold or RDnew < RDlast, the recipient 705 SHOULD silently discard the message. If, on the other hand, the 706 inequality holds, the recipient SHOULD process the message. 708 Moreover, if the above inequality holds and TSnew > TSlast, the 709 recipient SHOULD update RDlast and TSlast after the signature 710 verification also successes. Otherwise, the recipient MUST NOT 711 update RDlast or TSlast. 713 An implementation MAY use some mechanism such as a timestamp cache to 714 strengthen resistance to replay attacks. When there is a very large 715 number of nodes on the same link, or when a cache filling attack is 716 in progress, it is possible that the cache holding the most recent 717 timestamp per sender will become full. In this case, the node MUST 718 remove some entries from the cache or refuse some new requested 719 entries. The specific policy as to which entries are preferred over 720 others is left as an implementation decision. 722 7. Deployment Consideration 724 This document defines two directions of authentication: 725 authentication based on client's certificate and authentication based 726 on leap-of-faith (LoF) to server's public key. 728 7.1. Authentication on a client 730 For clients, DHCPv6 authentication generally means verifying whether 731 the sender of DHCP messages is a legal DHCPv6 server and verifying 732 whether the message has been modified during transmission. Because 733 the client may have to validate the authentication in the condition 734 of without connectivity wider than link-local, authentication with 735 certificates may not always be feasible. So, this document only 736 sticks on Leaf of Faith model, to make sure the client talks to the 737 same previous server. 739 Message integrity is provided. But there is a chance for the client 740 to incorrectly trust a malicious server at the beginning of the first 741 session with the server (and therefore keep trusting it thereafter). 742 But LoF guarantees the subsequent messages are sent by the same 743 previous server, and therefore narrows the attack scope. This may 744 make sense if the network can be reasonably considered secure and 745 requesting pre-configuration is deemed to be infeasible. A small 746 home network would be an example of such cases. 748 For environments that are neither controlled nor really trustworthy, 749 such as a network cafe, while LoF model, i.e. silently trusting the 750 server at the first time, would be too insecure. But some middle 751 ground might be justified, such as requiring human intervention at 752 the point of LoF. 754 7.2. Authentication on a server 756 As for authentication on a server, there are several different 757 scenarios to consider, each of which has different applicability 758 issues. If the server allows LoF any malicious user can pretend to 759 be a new legitimate client. While the server can always be 760 considered to have connectivity to validate certificate, it is 761 feasible to check client certificates. 763 Network administrators may wish to constrain the allocation of 764 addresses to authorized hosts to avoid denial of service attacks in 765 "hostile" environments where the network medium is not physically 766 secured, such as wireless networks or college residence halls. A 767 server may have to selectively serve a specific client or deny 768 specific clients depending on the identity of the client in a 769 controlled environment, like a corporate intranet. But the support 770 from skilled staff or administrator may be required to set up the 771 clients. 773 8. Security Considerations 775 This document provides new security features to the DHCPv6 protocol. 777 Using public key based security mechanism and its verification 778 mechanism in DHCPv6 message exchanging provides the authentication 779 and data integrity protection. Timestamp mechanism provides anti- 780 replay function. 782 The Secure DHCPv6 mechanism is based on the pre-condition that the 783 client knows the public key of servers or the client's certificate 784 can be verified through a trust CA. It prevents DHCPv6 server 785 spoofing. The clients may discard the DHCPv6 messages from unknown/ 786 unverified servers, which may be fake servers; or may prefer DHCPv6 787 messages from known/verified servers over unsigned messages or 788 messages from unknown/unverified servers. The pre-configuration 789 operation also needs to be protected, which is out of scope. The 790 deployment of PKI is also out of scope. 792 However, when a DHCPv6 client first encounters a new public key, it 793 can make a leap of faith. If the DHCPv6 server that used that public 794 key is in fact legitimate, then all future communication with that 795 DHCPv6 server can be protected by storing the public key. This does 796 not provide complete security, but it limits the opportunity to mount 797 an attack on a specific DHCPv6 client to the first time it 798 communicates with a new DHCPv6 server. 800 Downgrade attacks cannot be avoided if nodes are configured to accept 801 both secured and unsecured messages. A future specification may 802 provide a mechanism on how to treat unsecured DHCPv6 messages. 804 [RFC6273] has analyzed possible threats to the hash algorithms used 805 in SEND. Since the Secure DHCPv6 defined in this document uses the 806 same hash algorithms in similar way to SEND, analysis results could 807 be applied as well: current attacks on hash functions do not 808 constitute any practical threat to the digital signatures used in the 809 signature algorithm in the Secure DHCPv6. 811 A server, whose local policy accepts messages without a Timestamp 812 option, may have to face the risk of replay attacks. 814 A window of vulnerability for replay attacks exists until the 815 timestamp expires. Secure DHCPv6 nodes are protected against replay 816 attacks as long as they cache the state created by the message 817 containing the timestamp. The cached state allows the node to 818 protect itself against replayed messages. However, once the node 819 flushes the state for whatever reason, an attacker can re-create the 820 state by replaying an old message while the timestamp is still valid. 821 In addition, the effectiveness of timestamps is largely dependent 822 upon the accuracy of synchronization between communicating nodes. 823 However, how the two communicating nodes can be synchronized is out 824 of scope of this work. 826 Attacks against time synchronization protocols such as NTP [RFC5905] 827 may cause Secure DHCPv6 nodes to have an incorrect timestamp value. 828 This can be used to launch replay attacks, even outside the normal 829 window of vulnerability. To protect against these attacks, it is 830 recommended that Secure DHCPv6 nodes keep independently maintained 831 clocks or apply suitable security measures for the time 832 synchronization protocols. 834 9. IANA Considerations 836 This document defines three new DHCPv6 [RFC3315] options. The IANA 837 is requested to assign values for these three options from the DHCPv6 838 Option Codes table of the DHCPv6 Parameters registry maintained in 839 http://www.iana.org/assignments/dhcpv6-parameters. The three options 840 are: 842 The Public Key Option (TBA1), described in Section 5.1. 844 The Certificate Option (TBA2), described in Section 5.2. 846 The Signature Option (TBA3), described in Section 5.3. 848 The Timestamp Option (TBA4),described in Section 5.4. 850 The IANA is also requested to add two new registry tables to the 851 DHCPv6 Parameters registry maintained in 852 http://www.iana.org/assignments/dhcpv6-parameters. The two tables 853 are the Hash Algorithm for Secure DHCPv6 table and the Signature 854 Algorithm for Secure DHCPv6 table. 856 Initial values for these registries are given below. Future 857 assignments are to be made through Standards Action [RFC5226]. 858 Assignments for each registry consist of a name, a value and a RFC 859 number where the registry is defined. 861 Hash Algorithm for Secure DHCPv6. The values in this table are 8-bit 862 unsigned integers. The following initial values are assigned for 863 Hash Algorithm for Secure DHCPv6 in this document: 865 Name | Value | RFCs 866 -------------------+---------+-------------- 867 SHA-1 | 0x01 | this document 868 SHA-256 | 0x02 | this document 869 SHA-512 | 0x03 | this document 871 Signature Algorithm for Secure DHCPv6. The values in this table are 872 8-bit unsigned integers. The following initial values are assigned 873 for Signature Algorithm for Secure DHCPv6 in this document: 875 Name | Value | RFCs 876 -------------------+---------+-------------- 877 RSASSA-PKCS1-v1_5 | 0x01 | this document 879 IANA is requested to assign the following new DHCPv6 Status Codes, 880 defined in Section 5.5, in the DHCPv6 Parameters registry maintained 881 in http://www.iana.org/assignments/dhcpv6-parameters: 883 Code | Name | Reference 884 ---------+-----------------------+-------------- 885 TBD5 | AlgorithmNotSupported | this document 886 TBD6 | AuthenticationFail | this document 887 TBD7 | TimestampFail | this document 888 TBD8 | SignatureFail | this document 890 10. Acknowledgments 892 The authors would like to thank Bernie Volz, Ted Lemon, Ralph Droms, 893 Jari Arkko, Sean Turner, Stephen Kent, Thomas Huth, David Schumacher, 894 Francis Dupont, Tomek Mrugalski, Gang Chen, Qi Sun, Suresh Krishnan, 895 Fred Templin and other members of the IETF DHC working groups for 896 their valuable comments. 898 This document was produced using the xml2rfc tool [RFC2629]. 900 11. Change log [RFC Editor: Please remove] 902 draft-ietf-dhc-sedhcpv6-04: addressed comments from mail list. 903 Making timestamp an independent and optional option. Reduce the 904 serverside authentication to base on only client's certificate. 905 Reduce the clientside authentication to only Leaf of Faith base on 906 server's public key. 2014-09-26. 908 draft-ietf-dhc-sedhcpv6-03: addressed comments from WGLC. Added a 909 new section "Deployment Consideration". Corrected the Public Key 910 Field in the Public Key Option. Added consideration for large DHCPv6 911 message transmission. Added TimestampFail error code. Refined the 912 retransmission rules on clients. 2014-06-18. 914 draft-ietf-dhc-sedhcpv6-02: addressed comments (applicability 915 statement, redesign the error codes and their logic) from IETF89 DHC 916 WG meeting and volunteer reviewers. 2014-04-14. 918 draft-ietf-dhc-sedhcpv6-01: addressed comments from IETF88 DHC WG 919 meeting. Moved Dacheng Zhang from acknowledgement to be co-author. 920 2014-02-14. 922 draft-ietf-dhc-sedhcpv6-00: adopted by DHC WG. 2013-11-19. 924 draft-jiang-dhc-sedhcpv6-02: removed protection between relay agent 925 and server due to complexity, following the comments from Ted Lemon, 926 Bernie Volz. 2013-10-16. 928 draft-jiang-dhc-sedhcpv6-01: update according to review comments from 929 Ted Lemon, Bernie Volz, Ralph Droms. Separated Public Key/ 930 Certificate option into two options. Refined many detailed 931 processes. 2013-10-08. 933 draft-jiang-dhc-sedhcpv6-00: original version, this draft is a 934 replacement of draft-ietf-dhc-secure-dhcpv6, which reached IESG and 935 dead because of consideration regarding to CGA. The authors followed 936 the suggestion from IESG making a general public key based mechanism. 937 2013-06-29. 939 12. References 941 12.1. Normative References 943 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 944 Requirement Levels", BCP 14, RFC 2119, March 1997. 946 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 947 (IPv6) Specification", RFC 2460, December 1998. 949 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 950 Identifiers for the Internet X.509 Public Key 951 Infrastructure Certificate and Certificate Revocation List 952 (CRL) Profile", RFC 3279, April 2002. 954 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 955 and M. Carney, "Dynamic Host Configuration Protocol for 956 IPv6 (DHCPv6)", RFC 3315, July 2003. 958 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 959 Algorithms and Identifiers for RSA Cryptography for use in 960 the Internet X.509 Public Key Infrastructure Certificate 961 and Certificate Revocation List (CRL) Profile", RFC 4055, 962 June 2005. 964 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 965 Message Protocol (ICMPv6) for the Internet Protocol 966 Version 6 (IPv6) Specification", RFC 4443, March 2006. 968 [RFC4491] Leontiev, S. and D. Shefanovski, "Using the GOST R 969 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 970 Algorithms with the Internet X.509 Public Key 971 Infrastructure Certificate and CRL Profile", RFC 4491, May 972 2006. 974 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 975 Housley, R., and W. Polk, "Internet X.509 Public Key 976 Infrastructure Certificate and Certificate Revocation List 977 (CRL) Profile", RFC 5280, May 2008. 979 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 980 Time Protocol Version 4: Protocol and Algorithms 981 Specification", RFC 5905, June 2010. 983 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 984 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 985 5996, September 2010. 987 12.2. Informative References 989 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 990 June 1999. 992 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 993 Hashes in Internet Protocols", RFC 4270, November 2005. 995 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 996 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 997 May 2008. 999 [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure 1000 Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, 1001 June 2011. 1003 [RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1, 1004 PKCS 1", November 2002. 1006 Authors' Addresses 1008 Sheng Jiang (editor) 1009 Huawei Technologies Co., Ltd 1010 Q14, Huawei Campus, No.156 Beiqing Road 1011 Hai-Dian District, Beijing, 100095 1012 P.R. China 1014 Email: jiangsheng@huawei.com 1016 Sean Shen 1017 CNNIC 1018 4, South 4th Street, Zhongguancun 1019 Beijing 100190 1020 P.R. China 1022 Email: shenshuo@cnnic.cn 1024 Dacheng Zhang 1025 Huawei Technologies Co., Ltd 1026 Q14, Huawei Campus, No.156 Beiqing Road 1027 Hai-Dian District, Beijing, 100095 1028 P.R. China 1030 Email: zhangdacheng@huawei.com 1031 Tatuya Jinmei 1032 Infoblox Inc. 1033 3111 Coronado Drive 1034 Santa Clara, CA 1035 USA 1037 Email: jinmei@wide.ad.jp