idnits 2.17.1 draft-ietf-dhc-sedhcpv6-12.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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (April 24, 2016) is 2924 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) == Unused Reference: 'RFC2460' is defined on line 1186, but no explicit reference was found in the text == Unused Reference: 'RFC4443' is defined on line 1200, but no explicit reference was found in the text == Unused Reference: 'RSA' is defined on line 1245, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 7283 (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: 3 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group S. Jiang 3 Internet-Draft Huawei Technologies Co., Ltd 4 Intended status: Standards Track L. Li 5 Expires: October 26, 2016 Y. Cui 6 Tsinghua University 7 T. Jinmei 8 Infoblox Inc. 9 T. Lemon 10 Nominum, Inc. 11 D. Zhang 12 April 24, 2016 14 Secure DHCPv6 15 draft-ietf-dhc-sedhcpv6-12 17 Abstract 19 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables 20 DHCPv6 servers to pass configuration parameters. It offers 21 configuration flexibility. If not secured, DHCPv6 is vulnerable to 22 various attacks. This document analyzes the security issues of 23 DHCPv6 and specifies the secure DHCPv6 mechanism for authentication 24 and encryption of messages between a DHCPv6 client and a DHCPv6 25 server. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 26, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Requirements Language and Terminology . . . . . . . . . . . . 3 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Security Issues of DHCPv6 . . . . . . . . . . . . . . . . . . 4 65 5. Secure DHCPv6 Overview . . . . . . . . . . . . . . . . . . . 5 66 5.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 5 67 5.2. New Components . . . . . . . . . . . . . . . . . . . . . 7 68 5.3. Support for Algorithm Agility . . . . . . . . . . . . . . 7 69 5.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 8 70 6. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . 9 71 7. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . 12 72 8. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 14 73 9. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 14 74 9.1. Timestamp Check . . . . . . . . . . . . . . . . . . . . . 14 75 10. Extensions for Secure DHCPv6 . . . . . . . . . . . . . . . . 16 76 10.1. New DHCPv6 Options . . . . . . . . . . . . . . . . . . . 16 77 10.1.1. Certificate Option . . . . . . . . . . . . . . . . . 16 78 10.1.2. Signature option . . . . . . . . . . . . . . . . . . 17 79 10.1.3. Timestamp Option . . . . . . . . . . . . . . . . . . 18 80 10.1.4. Encrypted-message Option . . . . . . . . . . . . . . 18 81 10.2. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . 19 82 10.3. Status Codes . . . . . . . . . . . . . . . . . . . . . . 20 83 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 84 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 85 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 86 14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 23 87 15. Open Issues [RFC Editor: Please remove] . . . . . . . . . . . 25 88 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 89 16.1. Normative References . . . . . . . . . . . . . . . . . . 25 90 16.2. Informative References . . . . . . . . . . . . . . . . . 26 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 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. 100 This document analyzes the security issues of DHCPv6 and provides the 101 following mechanisms for improving the security of DHCPv6 between the 102 DHCPv6 client and the DHCPv6 server: 104 o the authentication of the DHCPv6 client and the DHCPv6 server to 105 defend against active attacks, such as spoofing attack. 107 o the encryption between the DHCPv6 client and the DHCPv6 server in 108 order to protect the DHCPv6 from passive attacks, such as 109 pervasive monitoring. 111 Note: this secure mechanism in this document does not protect outer 112 options in Relay-Forward and Relay-Reply messages, either added by a 113 relay agent toward a server or added by a server toward a relay 114 agent. Communication between a server and a relay agent, and 115 communications between relay agents, may be secured through the use 116 of IPsec, as described in section 21.1 in [RFC3315]. 118 The security mechanism specified in this document achieves DHCPv6 119 authentication and encryption based on the sender's certificate. We 120 introduce two new DHCPv6 messages: Encrypted-Query message and 121 Encrypted-Response message and Four new DHCPv6 options: Certificate 122 option, Signature option, Timestamp option and Encrypted-message 123 option for DHCPv6 authentication and encryption. The Certificate 124 option, Signature option, Timestamp option are used for DHCPv6 125 client/server authentication. The Encryption-Query message, 126 Encryption-Response message and Encrypted-message option are used for 127 DHCPv6 encryption. 129 2. Requirements Language and Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119] when they 134 appear in ALL CAPS. When these words are not in ALL CAPS (such as 135 "should" or "Should"), they have their usual English meanings, and 136 are not to be interpreted as [RFC2119] key words. 138 3. Terminology 140 This section defines terminology specific to secure DHCPv6 used in 141 this document. 143 secure DHCPv6 client: A node that initiates the DHCPv6 request on a 144 link to obtain the DHCPv6 configuration parameters 145 from one or more DHCPv6 servers. The configuration 146 process is authenticated and encrypted using the 147 defined mechanisms in this document. 149 secure DHCPv6 server: A node that responds to requests from clients 150 using the authentication and encryption mechanism 151 defined in this document. 153 4. Security Issues of DHCPv6 155 DHCPv6 is a client/server protocol that provides managed 156 configuration of devices. It enables a DHCPv6 server to 157 automatically configure relevant network parameters on clients. The 158 basic DHCPv6 specification [RFC3315] defines security mechanisms, but 159 they have some flaws and can be improved. 161 The basic DHCPv6 specifications can optionally authenticate the 162 origin of messages and validate the integrity of messages using an 163 authentication option with a symmetric key pair. [RFC3315] relies on 164 pre-established secret keys. For any kind of meaningful security, 165 each DHCPv6 client would need to be configured with its own secret 166 key; [RFC3315] provides no mechanism for doing this. 168 For the out of band approach, operators can set up a key database for 169 both servers and clients from which the client obtains a key before 170 running DHCPv6. Manual key distribution runs counter to the goal of 171 minimizing the configuration data needed at each host. 173 [RFC3315] provides an additional mechanism for preventing off-network 174 timing attacks using the Reconfigure message: the Reconfigure Key 175 authentication method. However, this method protects only the 176 Reconfigure message. The key is transmitted in plaintext to the 177 client in earlier exchanges and so this method is vulnerable to 178 active attacks. 180 In addition, the current DHCPv6 messages are still transmitted in 181 cleartext and the privacy information within the DHCPv6 message is 182 not protected from passive attack, such as pervasive monitoring. The 183 IETF has expressed strong agreement that pervasive monitoring is an 184 attack that needs to be mitigated where possible in [RFC7258]. 186 In comparison, the security mechanisms defined in this document 187 provides for authentication and encryption based on the public key 188 certificates of the client and server. The DHCPv6 authentication can 189 protect DHCPv6 from active attacks, such as spoofing attack. And the 190 DHCPv6 encryption defends against passive attacks, such as pervasive 191 monitoring attack. 193 5. Secure DHCPv6 Overview 195 5.1. Solution Overview 197 This solution provides authentication and encryption mechanisms based 198 on the certificates of the DHCPv6 client and server. Before the 199 standard DHCPv6 configuration process, the Information-request and 200 Reply messages are exchanged to select the authenticated DHCPv6 201 server. After mutual authentication between the DHCPv6 client and 202 server, the following DHCPv6 configuration process is encrypted to 203 avoid the privacy information disclosure. We introduce two new 204 DHCPv6 messages: Encrypted-Query message, Encrypted-Response message 205 and four new DHCPv6 options: Encrypted-message option, Certificate 206 option, Signature option, Timestamp option. Based on the new defined 207 messages and options, the corresponding authentication and encryption 208 mechanisms are achieved. 210 The following figure illustrates secure DHCPv6 procedure. The DHCPv6 211 client first sends Information-request message as per [RFC3315]. The 212 Information-request message is used to request the servers for the 213 servers' certificates information, without going through any address, 214 prefix or non-security option assignment process. The Information- 215 request contains no DHCPv6 options except ORO option to avoid 216 client's privacy information disclosure. When receiving the 217 Information-request message, the server sends the Reply message that 218 contains the server's Certificate option, Signature option, Timestamp 219 option and Server Identifier option. Upon the receipt of the Reply 220 message, the DHCPv6 client verifies the server's identity according 221 to the contained options in the Reply message. If there are multiple 222 authenticated DHCPv6 server certs, the client selects one 223 authenticated DHCPv6 server for the following DHCPv6 configuration 224 process. If there are no authenticated DHCPv6 server cert or 225 existing server certs fails authentication, the client should retry a 226 number of times. In this way, it is difficult for a rogue server to 227 beat out a busy "real" server. And then the client takes some other 228 alternative action depending on its local policy. 230 After the server's authentication, the first DHCPv6 message sent from 231 the client to the server, such as Solicit message, contains the 232 client's Certificate information for client authentication. The 233 DHCPv6 client sends the Encrypted-Query message to server, which 234 carries the Encrypted-message option and the Server Identifier 235 option. The Encrypted-message option contains the encrypted DHCPv6 236 message sent from the client to the server. When the DHCPv6 server 237 receives the Encrypted-Query message, it decrypts the message using 238 its private key. If the decrypted message contains the client's 239 Certificate option, the DHCPv6 server verifies the client's identity 240 according to the contained client certificate information. 242 After the client's authentication, the server sends the Encrypted- 243 Response message to the client, which contains the Encrypted-message 244 option. The Encrypted-message option contains the encrypted DHCPv6 245 message sent from server to client, which is encrypted using the 246 client's public key. If the message fails client authentication, 247 then the server sends the corresponding error status code to the 248 client. During the encrypted DHCPv6 configuration process, the 249 Timestamp option can be contained in the encrypted DHCPv6 messages to 250 defend against replay attacks. 252 +-------------+ +-------------+ 253 |DHCPv6 Client| |DHCPv6 Server| 254 +-------------+ +-------------+ 255 | Information-request | 256 |----------------------------------------->| 257 | Option Request option | 258 | | 259 | Reply | 260 |<-----------------------------------------| 261 | Certificate option | 262 | Signature option | 263 | Timestamp option | 264 | Server Identifier option | 265 | | 266 | Encryption-Query | 267 |----------------------------------------->| 268 | Encrypted-message option | 269 | Server Identifier option | 270 | | 271 | Encryption-Response | 272 |<-----------------------------------------| 273 | Encrypted-message option | 274 | | 276 Secure DHCPv6 Procedure 278 5.2. New Components 280 The new components of the mechanism specified in this document are as 281 follows: 283 o Servers and clients that use certificates first generate a public/ 284 private key pair and then obtain a certificate that signs the 285 public key. The Certificate option is defined to carry the 286 certificate of the sender. 288 o A signature generated using the private key which is used by the 289 receiver to verify the integrity of the DHCPv6 messages and then 290 authentication of the client/server. Another option is defined to 291 carry the signature. 293 o A timestamp that can be used to detect replayed packet. The 294 Timestamp option is defined to carry the current time of the 295 client/server. The secure DHCPv6 client/server need to meet some 296 accuracy requirements and be synced to global time, while the 297 timestamp checking mechanism allows a configurable time value for 298 clock drift. The real time provision is out of scope of this 299 document. 301 o The Encrypted-message option that contains the encrypted DHCPv6 302 message. 304 o The Encrypted-Query message that is sent from the secure DHCPv6 305 client to the secure DHCPv6 server. The Encrypted-Query message 306 contains the Encrypted-message option and Server Identifier 307 option. 309 o The Encrypted-Response message that is sent from the secure DHCPv6 310 server to the secure DHCPv6 client. The Encrypted-Response 311 message contains the Encrypted-message option. 313 5.3. Support for Algorithm Agility 315 In order to provide a means of addressing problems that may emerge in 316 the future with existing hash algorithms, as recommended in 317 [RFC4270], this document provides a mechanism for negotiating the use 318 of more secure hashes in the future. 320 In addition to hash algorithm agility, this document also provides a 321 mechanism for signature algorithm and encryption algorithm agility. 323 The support for algorithm agility in this document is mainly a 324 unilateral notification mechanism from sender to recipient. A 325 recipient MAY support various algorithms simultaneously among 326 different senders, and the different senders in a same administrative 327 domain may be allowed to use various algorithms simultaneously. It 328 is NOT RECOMMENDED that the same sender and recipient use various 329 algorithms in a single communication session. 331 If the server does not support the algorithm used by the client, the 332 server SHOULD reply with an AlgorithmNotSupported status code 333 (defined in Section 10.3) to the client. Upon receiving this status 334 code, the client MAY resend the message protected with the mandatory 335 algorithm. 337 5.4. Applicability 339 In principle, Secure DHCPv6 is applicable in any environment where 340 physical security on the link is not assured and attacks on DHCPv6 341 are a concern. In practice, however, it will rely on some 342 operational assumptions mainly regarding public key distribution and 343 management, until more lessons are learned and more experiences are 344 achieved. 346 One feasible environment in an early deployment stage would be 347 enterprise networks. In such networks the security policy tends to 348 be strict and it will be easier to manage client hosts. One trivial 349 deployment scenario is therefore to manually pre-configure client 350 with the trusted servers' public key and manually register clients' 351 public keys for the server. It may also be possible to deploy an 352 internal PKI to make this less reliant on manual operations, although 353 it is currently subject to future study specifically how to integrate 354 such a PKI into the DHCPv6 service for the network. 356 Note that this deployment scenario based on manual operation is not 357 different very much from the existing, shared-secret based 358 authentication mechanisms defined in [RFC3315] in terms of 359 operational costs. However, Secure DHCPv6 is still securer than the 360 shared-secret mechanism in that even if clients' keys stored for the 361 server are stolen that does not mean an immediate threat as these are 362 public keys. In addition, if some kind of PKI is used with Secure 363 DHCPv6, even if the initial installation of the certificates is done 364 manually, it will help reduce operational costs of revocation in case 365 a private key (especially that of the server) is compromised. 367 It is believed that Secure DHCPv6 could be more widely applicable 368 with integration of generic PKI so that it will be more easily 369 deployed. But such a deployment requires more general issues with 370 PKI deployment be addressed, and it is currently unknown whether we 371 can find practical deployment scenarios. It is subject to future 372 study and experiments, and out of scope of this document. 374 6. DHCPv6 Client Behavior 376 For the secure DHCPv6 client, a certificate is needed for client 377 authentication. The client is pre-configured with a certificate and 378 its corresponding private key. If the client is pre-configured with 379 public key but not with a certificate, it can generate the self- 380 signed certificate for client authentication. 382 The secure DHCPv6 client sends Information-request message as per 383 [RFC3315]. The Information-request message is used by the DHCPv6 384 client to request the server's identity verification information 385 without having addresses, prefixes or any non-security options 386 assigned to it. The Information-request message MUST NOT include any 387 DHCPv6 options except ORO option to minimize client's privacy 388 information leakage. The Option Request option in the Information- 389 request message MUST contain the option code of the Certificate 390 option. 392 When receiving the Reply messages from DHCPv6 servers, a secure 393 DHCPv6 client discards any DHCPv6 messages that meet any of the 394 following conditions: 396 o the Signature option is missing, 398 o multiple Signature options are present, 400 o the Certificate option is missing. 402 And then the client first checks the support of the hash function, 403 signature algorithm and encryption algorithm that the server used. 404 If the check fails, the Reply message is dropped. If all the 405 algorithms are supported, the client then checks the authority of 406 this server. The client also uses the same algorithms in the return 407 messages. 409 The client validates the certificates through the pre-configured 410 local trusted certificates list or other methods. A certificate that 411 finds a match in the local trust certificate list is treated as 412 verified. If the client want to check server's certificate to see 413 whether it has been revoked, the OCSP stapling can be used. The 414 message transaction-id is used as the identifier of the authenticated 415 server's public key for encryption. At this point, the client has 416 either recognized the certificate of the server, or decided to drop 417 the message. 419 The client MUST now authenticate the server by verifying the 420 signature and checking timestamp (see details in Section 9.1), if 421 there is a Timestamp option. The order of two procedures is left as 422 an implementation decision. It is RECOMMENDED to check timestamp 423 first, because signature verification is much more computationally 424 expensive. 426 The Signature field verification MUST show that the signature has 427 been calculated as specified in Section 10.1.2. Only the messages 428 that get through both the signature verification and timestamp check 429 (if there is a Timestamp option) are accepted. Reply message that 430 does not pass the above tests MUST be discarded. 432 If there are multiple authenticated DHCPv6 servers, the client 433 selects one DHCPv6 server for the following network parameters 434 configuration. The client can also choose other implementation 435 method depending on the client's local policy if the defined protocol 436 can also run normally. For example, the client can try multiple 437 transactions (each encrypted with different public key) at the "same" 438 time. If there are no authenticated DHCPv6 servers or existing 439 servers failed authentication, the client should retry a number of 440 times. In this way, it is difficult for the rogue server to beat out 441 a busy "real" server. And then the client takes some alternative 442 action depending on its local policy, such as attempting to use an 443 unsecured DHCPv6 server. The client conducts the server discovery 444 process as per section 18.1.5 of [RFC3315] to avoid the packet storm. 446 Once the server has been authenticated, the DHCPv6 client sends the 447 Encrypted-Query message to the DHCPv6 server. The Encrypted-Query 448 message contains the Encrypted-message option, which MUST be 449 constructed as explained in Section 10.1.4, and Server Identifier 450 option. The Encrypted-message option contains the DHCPv6 message 451 that is encrypted using the selected server's public key. The Server 452 Identifier option is externally visible to avoid decryption cost by 453 those unselected servers. 455 For the encrypted DHCPv6 message sent from the DHCPv6 client to the 456 DHCPv6 server, the first DHCPv6 message, such as Solicit message, 457 MUST contain the Certificate option, Signature option and Timestamp 458 option for client authentication. The Certificate option MUST be 459 constructed as explained in Section 10.1.1. In addition, one and 460 only one Signature option MUST be contained, which MUST be 461 constructed as explained in Section 10.1.2. One and only one 462 Timestamp option SHOULD be contained, which MUST be constructed as 463 explained in Section 10.1.3. The Timestamp field SHOULD be set to 464 the current time, according to sender's real time clock. 466 If the client has multiple certificates with different public/private 467 key pairs, the message transaction-id is used as the identifier of 468 the client's private key for decryption. In addition, the subsequent 469 encrypted DHCPv6 message can contain the Timestamp option to defend 470 against replay attack. 472 For the received Encrypted-Response message, the client extracts the 473 Encrypted-message option and decrypts it using its private key to 474 obtain the original DHCPv6 message. Then it handles the message as 475 per [RFC3315]. If the decrypted DHCPv6 message contains the 476 Timestamp option, the DHCPv6 client checks the timestamp according to 477 the rule defined in Section 9.1. The DHCPv6 message, which fails the 478 timestamp check, MUST be discarded. If the client fails to get the 479 proper parameters from the chosen server, it sends the Encrypted- 480 Query message to another authenticated server for parameters 481 configuration until the client obtains the proper parameters. 483 When the client receives a Reply message with an error status code, 484 the error status code indicates the failure reason on the server 485 side. According to the received status code, the client MAY take 486 follow-up action: 488 o Upon receiving an AlgorithmNotSupported error status code, the 489 client SHOULD resend the message protected with one of the 490 mandatory algorithms. 492 o Upon receiving an AuthenticationFail error status code, the client 493 is not able to build up the secure communication with the server. 494 However, there may be other DHCPv6 servers available that 495 successfully complete authentication. The client MAY use the 496 AuthenticationFail as a hint and switch to other certificate if it 497 has another one; but otherwise treat the message containing the 498 status code as if it had not been received. But it SHOULD NOT 499 retry with the same certificate. However, if the client decides 500 to retransmit using the same certificate after receiving 501 AuthenticationFail, it MUST NOT retransmit immediately and MUST 502 follow normal retransmission routines defined in [RFC3315]. 504 o Upon receiving a DecryptionFail error status code, the client MAY 505 resend the message following normal retransmission routines 506 defined in [RFC3315]. 508 o Upon receiving a TimestampFail error status code, the client MAY 509 resend the message with an adjusted timestamp according to the 510 returned clock from the DHCPv6 server. The client SHOULD NOT 511 change its own clock, but only compute an offset for the 512 communication session. 514 o Upon receiving a SignatureFail error status code, the client MAY 515 resend the message following normal retransmission routines 516 defined in [RFC3315]. 518 7. DHCPv6 Server Behavior 520 For the secure DHCPv6 server, a certificate is needed for server 521 authentication. The server is pre-configured with a certificate and 522 its corresponding private key. If the server is pre-configured with 523 public key but not with a certificate, it can generate the self- 524 signed certificate for server authentication. 526 When the DHCPv6 server receives the Information-request message and 527 the contained Option Request option identifies the request is for the 528 server certificate information, it replies with a Reply message to 529 the client. The Reply message MUST contain the requested Certificate 530 option, which MUST be constructed as explained in Section 10.1.1, and 531 Server Identifier option. In addition, the Reply message MUST 532 contain one and only one Signature option, which MUST be constructed 533 as explained in Section 10.1.2. Besides, the Reply message SHOULD 534 contain one and only one Timestamp option, which MUST be constructed 535 as explained in Section 10.1.3. The Timestamp field SHOULD be set to 536 the current time, according to server's real time clock. 538 Upon the receipt of Encrypted-Query message, the server checks the 539 Server Identifier option. It decrypts the Encrypted-message option 540 using its private key if it is the target server. The DHCPv6 server 541 drops the message that is not for it, thus not paying cost to decrypt 542 messages not for it. 544 If the decrypted message is a Solicit/Information-request message, 545 the secure DHCPv6 server discards the received message that meets any 546 of the following conditions: 548 o the Signature option is missing, 550 o multiple Signature options are present, 552 o the Certificate option is missing. 554 In such failure, the server replies with an UnspecFail (value 1, 555 [RFC3315]) error status code. 557 The server SHOULD first check the support of the hash function, 558 signature algorithm, encryption algorithm that the client used. If 559 the check fails, the server SHOULD reply with an 560 AlgorithmNotSupported error status code, defined in Section 10.3, 561 back to the client. If all the algorithms are supported, the server 562 then checks the authority of this client. 564 The server validates the client's public key through the local pre- 565 configured trusted public keys list. A public key that finds a match 566 in the local trust public keys list is treated as verified. The 567 message that fails public key validation MUST be dropped. In such 568 failure, the DHCPv6 server replies with an AuthenticationFail error 569 status code, defined in Section 10.3, back to the client. At this 570 point, the server has either recognized the authentication of the 571 client, or decided to drop the message. 573 If the decrypted message contains the Timestamp option, the server 574 checks the timestamp according to the rule defined in Section 9.1. 575 If the timestamp check fails, a TimestampFail error status code, 576 defined in Section 10.3, should be sent back to the client. 577 Depending on server's local policy, the message without a Timestamp 578 option MAY be acceptable or rejected. If the server rejects such a 579 message, a TimestampFail error status code should be sent back to the 580 client. The Reply message that carries the TimestampFail error 581 status code carries a Timestamp option, which indicates the server's 582 clock for the client to use. 584 If the server does not send the Timestamp option, the client ignores 585 the timestamp check and verifies the signature. If there is a 586 timestamp option, the server MUST now authenticate the client by 587 verifying the signature and checking timestamp (see details in 588 Section 9.1). The order of two procedures is left as an 589 implementation decision. It is RECOMMENDED to check timestamp first, 590 because signature verification is much more computationally 591 expensive. Depending on server's local policy, the message without a 592 Timestamp option MAY be acceptable or rejected. If the server 593 rejects such a message, a TimestampFail error status code, defined in 594 Section 10.3, should be sent back to the client. The reply message 595 that carries the TimestampFail error status code SHOULD carry a 596 Timestamp option, which indicates the server's clock for the client 597 to use. 599 The Signature field verification MUST show that the signature has 600 been calculated as specified in Section 10.1.2. Only the clients 601 that get through both the signature verification and timestamp check 602 (if there is a Timestamp option) are accepted as authenticated 603 clients and continue to be handled their message as defined in 604 [RFC3315]. Clients that do not pass the above tests MUST be treated 605 as unauthenticated clients. The DHCPv6 server SHOULD reply a 606 SignatureFail error status code, defined in Section 10.3, for the 607 signature verification failure; or a TimestampFail error status code, 608 defined in Section 10.3, for the timestamp check failure, back to the 609 client. 611 Once the client has been authenticated, the DHCPv6 server sends the 612 Encrypted-response message to the DHCPv6 client. The Encrypted- 613 response message contains the Encrypted-message option, which MUST be 614 constructed as explained in Section 10.1.4. The Encrypted-message 615 option contains the encrypted DHCPv6 message that is encrypted using 616 the authenticated client's public key. To provide the replay 617 protection, the Timestamp option can be contained in the encrypted 618 DHCPv6 message. 620 8. Relay Agent Behavior 622 When a DHCPv6 relay agent receives an Encrypted-query or Encrypted- 623 response message, it may not recognize this message. The unknown 624 messages MUST be forwarded as described in [RFC7283]. 626 When a DHCPv6 relay agent recognizes the Encrypted-query and 627 Encrypted-response messages, it forwards the message according to 628 section 20 of [RFC3315]. There is nothing more the relay agents have 629 to do, it neither needs to verify the messages from client or server, 630 nor add any secure DHCPv6 options. Actually, by definition in this 631 document, relay agents MUST NOT add any secure DHCPv6 options. 633 Relay-forward and Relay-reply messages MUST NOT contain any 634 additional Certificate option or Timestamp option, aside from those 635 present in the innermost encapsulated messages from the client or 636 server. 638 Relay agent is RECOMMENDED to cache server announcements to form the 639 list of the available DHCPv6 server certs. If the relay agent 640 receives the Information-request message, then it replies with a list 641 of server certs available locally. In this way, the client can be 642 confident of a quick response, and therefore treat the lack of a 643 quick response as an indication that no authenticated DHCP servers 644 exist. 646 9. Processing Rules 648 9.1. Timestamp Check 650 In order to check the Timestamp option, defined in Section 10.1.3, 651 recipients SHOULD be configured with an allowed timestamp Delta 652 value, a "fuzz factor" for comparisons, and an allowed clock drift 653 parameter. The recommended default value for the allowed Delta is 654 300 seconds (5 minutes); for fuzz factor 1 second; and for clock 655 drift, 0.01 second. 657 Note: the Timestamp mechanism is based on the assumption that 658 communication peers have roughly synchronized clocks, within certain 659 allowed clock drift. So, an accurate clock is not necessary. If one 660 has a clock too far from the current time, the timestamp mechanism 661 would not work. 663 To facilitate timestamp checking, each recipient SHOULD store the 664 following information for each sender, from which at least one 665 accepted secure DHCPv6 message is successfully verified (for 666 timestamp check and signature verification): 668 o The receive time of the last received and accepted DHCPv6 message. 669 This is called RDlast. 671 o The timestamp in the last received and accepted DHCPv6 message. 672 This is called TSlast. 674 A verified (for timestamp check and signature verification) secure 675 DHCPv6 message initiates the update of the above variables in the 676 recipient's record. 678 Recipients MUST check the Timestamp field as follows: 680 o When a message is received from a new peer (i.e., one that is not 681 stored in the cache), the received timestamp, TSnew, is checked, 682 and the message is accepted if the timestamp is recent enough to 683 the reception time of the packet, RDnew: 685 -Delta < (RDnew - TSnew) < +Delta 687 After the signature verification also succeeds, the RDnew and 688 TSnew values SHOULD be stored in the cache as RDlast and TSlast. 690 o When a message is received from a known peer (i.e., one that 691 already has an entry in the cache), the timestamp is checked 692 against the previously received Secure DHCPv6 message: 694 TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz 696 If this inequality does not hold or RDnew < RDlast, the recipient 697 SHOULD silently discard the message. If, on the other hand, the 698 inequality holds, the recipient SHOULD process the message. 700 Moreover, if the above inequality holds and TSnew > TSlast, the 701 recipient SHOULD update RDlast and TSlast after the signature 702 verification also successes. Otherwise, the recipient MUST NOT 703 update RDlast or TSlast. 705 An implementation MAY use some mechanism such as a timestamp cache to 706 strengthen resistance to replay attacks. When there is a very large 707 number of nodes on the same link, or when a cache filling attack is 708 in progress, it is possible that the cache holding the most recent 709 timestamp per sender will become full. In this case, the node MUST 710 remove some entries from the cache or refuse some new requested 711 entries. The specific policy as to which entries are preferred over 712 others is left as an implementation decision. 714 An implementation MAY statefully record the latest timestamps from 715 senders. In such implementation, the timestamps MUST be strictly 716 monotonously increasing. This is reasonable given that DHCPv6 717 messages are rarely misordered. 719 10. Extensions for Secure DHCPv6 721 This section describes the extensions to DHCPv6. Four new DHCPv6 722 options, two new DHCPv6 messages and five new status codes are 723 defined. 725 10.1. New DHCPv6 Options 727 10.1.1. Certificate Option 729 The Certificate option carries the certificate of the client/server. 730 The format of the Certificate option is described as follows: 732 0 1 2 3 733 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 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | OPTION_CERTIFICATE | option-len | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | EA-id | | 738 +-+-+-+-+-+-+-+-+ . 739 . Certificate (variable length) . 740 . . 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 option-code OPTION_CERTIFICATE (TBA1). 745 option-len 1 + Length of certificate in octets. 747 EA-id Encryption Algorithm id. The encryption algorithm 748 is used for the encrypted DHCPv6 configuration 749 process. This design is adopted in order to provide 750 encryption algorithm agility. The value is from the 751 Encryption Algorithm for Secure DHCPv6 registry in 752 IANA. A registry of the initial assigned values 753 is defined in Section 12. 755 Certificate A variable-length field containing certificate. The 756 encoding of certificate and certificate data MUST 757 be in format as defined in Section 3.6, [RFC7296]. 758 The support of X.509 certificate is mandatory. 760 10.1.2. Signature option 762 The Signature option allows a signature that is signed by the private 763 key to be attached to a DHCPv6 message. The Signature option could 764 be in any place within the DHCPv6 message while it is logically 765 created after the entire DHCPv6 header and options. It protects the 766 entire DHCPv6 header and options, including itself. The format of 767 the Signature option is described as follows: 769 0 1 2 3 770 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 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | OPTION_SIGNATURE | option-len | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | HA-id | SA-id | | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 776 | | 777 . Signature (variable length) . 778 . . 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 option-code OPTION_SIGNATURE (TBA2). 783 option-len 2 + Length of Signature field in octets. 785 HA-id Hash Algorithm id. The hash algorithm is used for 786 computing the signature result. This design is 787 adopted in order to provide hash algorithm agility. 788 The value is from the Hash Algorithm for Secure 789 DHCPv6 registry in IANA. The support of SHA-256 is 790 mandatory. A registry of the initial assigned values 791 is defined in Section 12. 793 SA-id Signature Algorithm id. The signature algorithm is 794 used for computing the signature result. This 795 design is adopted in order to provide signature 796 algorithm agility. The value is from the Signature 797 Algorithm for Secure DHCPv6 registry in IANA. The 798 support of RSASSA-PKCS1-v1_5 is mandatory. A 799 registry of the initial assigned values is defined 800 in Section 12. 802 Signature A variable-length field containing a digital 803 signature. The signature value is computed with 804 the hash algorithm and the signature algorithm, 805 as described in HA-id and SA-id. The signature 806 constructed by using the sender's private key 807 protects the following sequence of octets: 809 1. The DHCPv6 message header. 811 2. All DHCPv6 options including the Signature 812 option (fill the Signature field with zeroes) 813 except for the Authentication Option. 815 The Signature field MUST be padded, with all 0, to 816 the next octet boundary if its size is not a 817 multiple of 8 bits. The padding length depends on 818 the signature algorithm, which is indicated in the 819 SA-id field. 821 Note: If Secure DHCPv6 is used, the DHCPv6 message is encrypted in a 822 way that the authentication mechanism defined in RFC3315 does not 823 understand. So the Authentication option SHOULD NOT be used if 824 Secure DHCPv6 is applied. 826 10.1.3. Timestamp Option 828 The Timestamp option carries the current time on the sender. It adds 829 the anti-replay protection to the DHCPv6 messages. It is optional. 831 0 1 2 3 832 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 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | OPTION_TIMESTAMP | option-len | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | | 837 | Timestamp (64-bit) | 838 | | 839 | | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 option-code OPTION_TIMESTAMP (TBA3). 844 option-len 8, in octets. 846 Timestamp The current time of day (SeND-format timestamp 847 in UTC (Coordinated Universal Time). It can reduce 848 the danger of replay attacks. The timestamp data MUST 849 be in format as defined in Section 5.3.1, [RFC3971]. 851 10.1.4. Encrypted-message Option 853 The Encrypted-message option carries the encrypted DHCPv6 message 854 with the recipient's public key. 856 The format of the Encrypted-message option is: 858 0 1 2 3 859 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 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | option-code | option-len | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | | 864 . encrypted DHCPv6 message . 865 . (variable) . 866 . . 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 Figure 1: Encrypted-message Option Format 871 option-code OPTION_ENCRYPTED_MSG (TBA4). 873 option-len Length of the encrypted DHCPv6 message. 875 encrypted DHCPv6 message A variable length field containing the 876 encrypted DHCPv6 message sent by the client or the server. In 877 Encrypted-Query message, it contains encrypted DHCPv6 message sent 878 by a client. In Encrypted-response message, it contains encrypted 879 DHCPv6 message sent by a server. 881 10.2. New DHCPv6 Messages 883 Two new DHCPv6 messages are defined to achieve the DHCPv6 encryption: 884 Encrypted-Query and Encrypted-Response. Both the DHCPv6 messages 885 defined in this document share the following format: 887 0 1 2 3 888 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 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | msg-type | transaction-id | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | | 893 . options . 894 . (variable) . 895 | | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 Figure 2: The format of Encrypted-Query and Encrypted-Response 899 Messages 901 msg-type Identifier of the message type. It can be either 902 Encrypted-Query (TBA5) or DHCPv6-Response (TBA6). 904 transaction-id The transaction ID for this message exchange. 906 options The Encrypted-Query message MUST contain the Server 907 Identifier option and Encrypted-message option. The 908 Encrypted-Response message MUST contain the 909 Encrypted-message option. 911 10.3. Status Codes 913 The following new status codes, see Section 5.4 of [RFC3315] are 914 defined. 916 o AlgorithmNotSupported (TBD7): indicates that the DHCPv6 server 917 does not support algorithms that sender used. 919 o AuthenticationFail (TBD8): indicates that the message from the 920 DHCPv6 client fails authentication check. 922 o TimestampFail (TBD9): indicates the message from DHCPv6 client 923 fails the timestamp check. 925 o SignatureFail (TBD10): indicates the message from DHCPv6 client 926 fails the signature check. 928 o DecryptionFail (TBD11): indicates the message from DHCPv6 client 929 fails the DHCPv6 message decryption. 931 11. Security Considerations 933 This document provides the authentication and encryption mechanisms 934 for DHCPv6. 936 [RFC6273] has analyzed possible threats to the hash algorithms used 937 in SEND. Since Secure DHCPv6 defined in this document uses the same 938 hash algorithms in similar way to SEND, analysis results could be 939 applied as well: current attacks on hash functions do not constitute 940 any practical threat to the digital signatures used in the signature 941 algorithm in Secure DHCPv6. 943 A server, whose local policy accepts messages without a Timestamp 944 option, may have to face the risk of replay attacks. 946 A window of vulnerability for replay attacks exists until the 947 timestamp expires. Secure DHCPv6 nodes are protected against replay 948 attacks as long as they cache the state created by the message 949 containing the timestamp. The cached state allows the node to 950 protect itself against replayed messages. However, once the node 951 flushes the state for whatever reason, an attacker can re-create the 952 state by replaying an old message while the timestamp is still valid. 953 In addition, the effectiveness of timestamps is largely dependent 954 upon the accuracy of synchronization between communicating nodes. 955 However, how the two communicating nodes can be synchronized is out 956 of scope of this work. 958 Attacks against time synchronization protocols such as NTP [RFC5905] 959 may cause Secure DHCPv6 nodes to have an incorrect timestamp value. 960 This can be used to launch replay attacks, even outside the normal 961 window of vulnerability. To protect against these attacks, it is 962 recommended that Secure DHCPv6 nodes keep independently maintained 963 clocks or apply suitable security measures for the time 964 synchronization protocols. 966 There are some mandatory algorithm for encryption algorithm in this 967 document. It may be at some point that the mandatory algorithm is no 968 longer safe to use. 970 If the client tries more than one cert for client authentication, the 971 server can easily get a client that implements this to enumerate its 972 entire cert list and probably learn a lot about a client that way. 974 12. IANA Considerations 976 This document defines four new DHCPv6 [RFC3315] options. The IANA is 977 requested to assign values for these four options from the DHCPv6 978 Option Codes table of the DHCPv6 Parameters registry maintained in 979 http://www.iana.org/assignments/dhcpv6-parameters. The four options 980 are: 982 The Certificate Option (TBA1), described in Section 10.1.1. 984 The Signature Option (TBA2), described in Section 10.1.2. 986 The Timestamp Option (TBA3),described in Section 10.1.3. 988 The Encrypted-message Option (TBA4), described in Section 10.1.4. 990 The IANA is also requested to assign value for these two messages 991 from the DHCPv6 Message Types table of the DHCPv6 Parameters registry 992 maintained in http://www.iana.org/assignments/dhcpv6-parameters. The 993 two messages are: 995 The Encrypted-Query Message (TBA5), described in Section 10.2. 997 The Encrypted-Response Message (TBA6), described in Section 10.2. 999 The IANA is also requested to add three new registry tables to the 1000 DHCPv6 Parameters registry maintained in 1001 http://www.iana.org/assignments/dhcpv6-parameters. The three tables 1002 are the Hash Algorithm for Secure DHCPv6 table, the Signature 1003 Algorithm for Secure DHCPv6 table and the Encryption Algorithm for 1004 Secure DHCPv6 table. 1006 Initial values for these registries are given below. Future 1007 assignments are to be made through Standards Action [RFC5226]. 1008 Assignments for each registry consist of a name, a value and a RFC 1009 number where the registry is defined. 1011 Hash Algorithm for Secure DHCPv6. The values in this table are 8-bit 1012 unsigned integers. The following initial values are assigned for 1013 Hash Algorithm for Secure DHCPv6 in this document: 1015 Name | Value | RFCs 1016 -------------------+---------+-------------- 1017 SHA-256 | 0x01 | this document 1018 SHA-512 | 0x02 | this document 1020 Signature Algorithm for Secure DHCPv6. The values in this table are 1021 8-bit unsigned integers. The following initial values are assigned 1022 for Signature Algorithm for Secure DHCPv6 in this document: 1024 Name | Value | RFCs 1025 -------------------+---------+-------------- 1026 RSASSA-PKCS1-v1_5 | 0x01 | this document 1028 Encryption algorithm for Secure DHCPv6. The values in this table are 1029 8-bit unsigned integers. The following initial values are assigned 1030 for encryption algorithm for Secure DHCPv6 in this document: 1032 Name | Value | RFCs 1033 -------------------+---------+-------------- 1034 RSA | 0 | this document 1036 IANA is requested to assign the following new DHCPv6 Status Codes, 1037 defined in Section 10.3, in the DHCPv6 Parameters registry maintained 1038 in http://www.iana.org/assignments/dhcpv6-parameters: 1040 Code | Name | Reference 1041 ---------+-----------------------+-------------- 1042 TBD7 | AlgorithmNotSupported | this document 1043 TBD8 | AuthenticationFail | this document 1044 TBD9 | TimestampFail | this document 1045 TBD10 | SignatureFail | this document 1046 TBD11 | DecryptionFail | this document 1048 13. Acknowledgements 1050 The authors would like to thank Tomek Mrugalski, Bernie Volz, 1051 Jianping Wu, Randy Bush, Yiu Lee, Sean Shen, Ralph Droms, Jari Arkko, 1052 Sean Turner, Stephen Farrell, Christian Huitema, Stephen Kent, Thomas 1053 Huth, David Schumacher, Francis Dupont, Gang Chen, Suresh Krishnan, 1054 Fred Templin, Robert Elz, Nico Williams, Erik Kline, Alan DeKok, 1055 Bernard Aboba, Sam Hartman, Qi Sun, Zilong Liu and other members of 1056 the IETF DHC working group for their valuable comments. 1058 This document was produced using the xml2rfc tool [RFC2629]. 1060 14. Change log [RFC Editor: Please remove] 1062 draft-ietf-dhc-sedhcpv6-12: Add the Signature option and timestamp 1063 option during server/client authentication process. Add the hash 1064 function and signature algorithm. Add the requirement: The 1065 Information-request message cannot contain any other options except 1066 ORO option. Modify the use of "SHOULD"; Delete the reference of 1067 RFC5280 and modify the method of client/server cert verification; Add 1068 the relay agent cache function for the quick response when there is 1069 no authenticated server. 2016-4-24. 1071 draft-ietf-dhc-sedhcpv6-11: Delete the Signature option, because the 1072 encrypted DHCPv6 message and the Information-request message (only 1073 contain the Certificate option) don't need the Signature option for 1074 message integrity check; Rewrite the "Applicability" section; Add the 1075 encryption algorithm negotiation process; To support the encryption 1076 algorithm negotiation, the Certificate option contains the EA- 1077 id(encryption algorithm identifier) field; Reserve the Timestamp 1078 option to defend against the replay attacks for encrypted DHCPv6 1079 configuration process; Modify the client behavior when there is no 1080 authenticated DHCPv6 server; Add the DecryptionFail error code. 1081 2016-3-9. 1083 draft-ietf-dhc-sedhcpv6-10: merge DHCPv6 authentication and DHCPv6 1084 encryption. The public key option is removed, because the device can 1085 generate the self-signed certificate if it is pre-configured the 1086 public key not the certificate. 2015-12-10. 1088 draft-ietf-dhc-sedhcpv6-09: change some texts about the deployment 1089 part.2015-12-10. 1091 draft-ietf-dhc-sedhcpv6-08: clarified what the client and the server 1092 should do if it receives a message using unsupported algorithm; 1093 refined the error code treatment regarding to AuthenticationFail and 1094 TimestampFail; added consideration on how to reduce the DoS attack 1095 when using TOFU; other general editorial cleanups. 2015-06-10. 1097 draft-ietf-dhc-sedhcpv6-07: removed the deployment consideration 1098 section; instead, described more straightforward use cases with TOFU 1099 in the overview section, and clarified how the public keys would be 1100 stored at the recipient when TOFU is used. The overview section also 1101 clarified the integration of PKI or other similar infrastructure is 1102 an open issue. 2015-03-23. 1104 draft-ietf-dhc-sedhcpv6-06: remove the limitation that only clients 1105 use PKI- certificates and only servers use public keys. The new text 1106 would allow clients use public keys and servers use PKI-certificates. 1107 2015-02-18. 1109 draft-ietf-dhc-sedhcpv6-05: addressed comments from mail list that 1110 responsed to the second WGLC. 2014-12-08. 1112 draft-ietf-dhc-sedhcpv6-04: addressed comments from mail list. 1113 Making timestamp an independent and optional option. Reduce the 1114 serverside authentication to base on only client's certificate. 1115 Reduce the clientside authentication to only Leaf of Faith base on 1116 server's public key. 2014-09-26. 1118 draft-ietf-dhc-sedhcpv6-03: addressed comments from WGLC. Added a 1119 new section "Deployment Consideration". Corrected the Public Key 1120 Field in the Public Key Option. Added consideration for large DHCPv6 1121 message transmission. Added TimestampFail error code. Refined the 1122 retransmission rules on clients. 2014-06-18. 1124 draft-ietf-dhc-sedhcpv6-02: addressed comments (applicability 1125 statement, redesign the error codes and their logic) from IETF89 DHC 1126 WG meeting and volunteer reviewers. 2014-04-14. 1128 draft-ietf-dhc-sedhcpv6-01: addressed comments from IETF88 DHC WG 1129 meeting. Moved Dacheng Zhang from acknowledgement to be co-author. 1130 2014-02-14. 1132 draft-ietf-dhc-sedhcpv6-00: adopted by DHC WG. 2013-11-19. 1134 draft-jiang-dhc-sedhcpv6-02: removed protection between relay agent 1135 and server due to complexity, following the comments from Ted Lemon, 1136 Bernie Volz. 2013-10-16. 1138 draft-jiang-dhc-sedhcpv6-01: update according to review comments from 1139 Ted Lemon, Bernie Volz, Ralph Droms. Separated Public Key/ 1140 Certificate option into two options. Refined many detailed 1141 processes. 2013-10-08. 1143 draft-jiang-dhc-sedhcpv6-00: original version, this draft is a 1144 replacement of draft-ietf-dhc-secure-dhcpv6, which reached IESG and 1145 dead because of consideration regarding to CGA. The authors followed 1146 the suggestion from IESG making a general public key based mechanism. 1147 2013-06-29. 1149 15. Open Issues [RFC Editor: Please remove] 1151 this protocol changes DHCPv6 message exchanges quite substantially: 1152 previously, the client first sends a Solicit message, gets possibly 1153 multiple Advertise messages, chooses the server (= sender of one of 1154 the Advertises) that would be best for the client, and then sends a 1155 Request to that chosen server. Now the server selection is done at 1156 the key exchange phase (the initial Information-request and Reply 1157 exchange), and the Solicit can be sent only to a single server. If 1158 the client doesn't like the Advertise it could restart the whole 1159 process, but it will be more expensive, and there's no guarantee that 1160 other servers can provide a better Advertise. 1162 One might argue that it's okay as "secure DHCPv6" is an "optional" 1163 extension. But, with keeping in mind that the current IETF trend is 1164 to make everything privacy-aware (often by making everything 1165 encrypted), I'd personally say we should consider it to be the 1166 standard mode of DHCPv6 operation even if users can still disable it. 1167 From this point of view, I think we should either 1169 o A. make the server selection behavior more compatible with the 1170 pre-encryption protocol, or 1172 o B. accept we give up the previous server selection feature for 1173 privacy (after careful assessment of its effect and with clear wg 1174 consensus), and explicitly note that. we might even have to 1175 reflect that in rfc3315bis. 1177 16. References 1179 16.1. Normative References 1181 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1182 Requirement Levels", BCP 14, RFC 2119, 1183 DOI 10.17487/RFC2119, March 1997, 1184 . 1186 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1187 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1188 December 1998, . 1190 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1191 C., and M. Carney, "Dynamic Host Configuration Protocol 1192 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1193 2003, . 1195 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1196 "SEcure Neighbor Discovery (SEND)", RFC 3971, 1197 DOI 10.17487/RFC3971, March 2005, 1198 . 1200 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1201 Control Message Protocol (ICMPv6) for the Internet 1202 Protocol Version 6 (IPv6) Specification", RFC 4443, 1203 DOI 10.17487/RFC4443, March 2006, 1204 . 1206 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1207 "Network Time Protocol Version 4: Protocol and Algorithms 1208 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1209 . 1211 [RFC7283] Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6 1212 Messages", RFC 7283, DOI 10.17487/RFC7283, July 2014, 1213 . 1215 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1216 Kivinen, "Internet Key Exchange Protocol Version 2 1217 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1218 2014, . 1220 16.2. Informative References 1222 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1223 DOI 10.17487/RFC2629, June 1999, 1224 . 1226 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 1227 Hashes in Internet Protocols", RFC 4270, 1228 DOI 10.17487/RFC4270, November 2005, 1229 . 1231 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1232 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1233 DOI 10.17487/RFC5226, May 2008, 1234 . 1236 [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure 1237 Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, 1238 DOI 10.17487/RFC6273, June 2011, 1239 . 1241 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1242 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1243 2014, . 1245 [RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1, 1246 PKCS 1", November 2002. 1248 Authors' Addresses 1250 Sheng Jiang 1251 Huawei Technologies Co., Ltd 1252 Q14, Huawei Campus, No.156 Beiqing Road 1253 Hai-Dian District, Beijing, 100095 1254 CN 1256 Email: jiangsheng@huawei.com 1258 Lishan Li 1259 Tsinghua University 1260 Beijing 100084 1261 P.R.China 1263 Phone: +86-15201441862 1264 Email: lilishan48@gmail.com 1266 Yong Cui 1267 Tsinghua University 1268 Beijing 100084 1269 P.R.China 1271 Phone: +86-10-6260-3059 1272 Email: yong@csnet1.cs.tsinghua.edu.cn 1274 Tatuya Jinmei 1275 Infoblox Inc. 1276 3111 Coronado Drive 1277 Santa Clara, CA 1278 US 1280 Email: jinmei@wide.ad.jp 1281 Ted Lemon 1282 Nominum, Inc. 1283 2000 Seaport Blvd 1284 Redwood City, CA 94063 1285 USA 1287 Phone: +1-650-381-6000 1288 Email: Ted.Lemon@nominum.com 1290 Dacheng Zhang 1291 Beijing 1292 CN 1294 Email: dacheng.zhang@gmail.com