idnits 2.17.1 draft-ietf-dhc-sedhcpv6-21.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 : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 21, 2017) is 2592 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 739 -- Looks like a reference, but probably isn't: '2' on line 741 == Unused Reference: 'RFC2460' is defined on line 1277, but no explicit reference was found in the text == Unused Reference: 'RFC3971' is defined on line 1286, but no explicit reference was found in the text == Unused Reference: 'RFC4443' is defined on line 1296, but no explicit reference was found in the text == Unused Reference: 'RFC5905' is defined on line 1306, but no explicit reference was found in the text == Unused Reference: 'RFC6840' is defined on line 1311, but no explicit reference was found in the text == Unused Reference: 'RFC6273' is defined on line 1355, but no explicit reference was found in the text == Unused Reference: 'RSA' is defined on line 1364, 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) ** Downref: Normative reference to an Informational RFC: RFC 7435 ** Downref: Normative reference to an Informational RFC: RFC 7824 == Outdated reference: A later version (-05) exists of draft-ietf-dhc-relay-server-security-03 -- 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: 6 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group L. Li 3 Internet-Draft Tsinghua University 4 Intended status: Standards Track S. Jiang 5 Expires: August 25, 2017 Huawei Technologies Co., Ltd 6 Y. Cui 7 Tsinghua University 8 T. Jinmei 9 Infoblox Inc. 10 T. Lemon 11 Nominum, Inc. 12 D. Zhang 13 February 21, 2017 15 Secure DHCPv6 16 draft-ietf-dhc-sedhcpv6-21 18 Abstract 20 DHCPv6 includes no deployable security mechanism that can protect 21 end-to-end communication between DHCP clients and servers. This 22 document describes a mechanism for using public key cryptography to 23 provide such security. The mechanism provides encryption in all 24 cases, and can be used for authentication based on pre-sharing of 25 authorized certificates. 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 August 25, 2017. 44 Copyright Notice 46 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . 3 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. Security Issues of DHCPv6 . . . . . . . . . . . . . . . . . . 4 65 5. Secure DHCPv6 Overview . . . . . . . . . . . . . . . . . . . 5 66 5.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 5 67 5.2. New Components . . . . . . . . . . . . . . . . . . . . . 6 68 5.3. Support for Algorithm Agility . . . . . . . . . . . . . . 7 69 5.4. Impact on RFC3315 . . . . . . . . . . . . . . . . . . . . 7 70 5.5. Applicability . . . . . . . . . . . . . . . . . . . . . . 8 71 6. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . 8 72 7. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . 11 73 8. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 13 74 9. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 14 75 9.1. Increasing Number Check . . . . . . . . . . . . . . . . . 14 76 9.2. Encryption Key Tag Calculation . . . . . . . . . . . . . 14 77 10. Extensions for Secure DHCPv6 . . . . . . . . . . . . . . . . 15 78 10.1. New DHCPv6 Options . . . . . . . . . . . . . . . . . . . 15 79 10.1.1. Algorithm Option . . . . . . . . . . . . . . . . . . 15 80 10.1.2. Certificate Option . . . . . . . . . . . . . . . . . 17 81 10.1.3. Signature option . . . . . . . . . . . . . . . . . . 18 82 10.1.4. Increasing-number Option . . . . . . . . . . . . . . 20 83 10.1.5. Encryption-Key-Tag Option . . . . . . . . . . . . . 20 84 10.1.6. Encrypted-message Option . . . . . . . . . . . . . . 21 85 10.2. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . 21 86 10.3. Status Codes . . . . . . . . . . . . . . . . . . . . . . 22 87 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 88 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 89 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 90 14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 25 91 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 92 15.1. Normative References . . . . . . . . . . . . . . . . . . 28 93 15.2. Informative References . . . . . . . . . . . . . . . . . 29 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 96 1. Introduction 98 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6, [RFC3315]) 99 allows DHCPv6 servers to flexibly provide addressing and other 100 configuration information relating to local network infrastructure to 101 DHCP clients. The protocol provides no deployable security 102 mechanism, and consequently is vulnerable to various attacks. 104 This document provides a brief summary of the security 105 vulnerabilities of the DHCPv6 protocol and then describes a new 106 extension to the protocol that provides two additional types of 107 security: 109 o authentication of the DHCPv6 client and the DHCPv6 server to 110 defend against active attacks, such as spoofing. 112 o encryption between the DHCPv6 client and the DHCPv6 server in 113 order to protect the DHCPv6 communication from pervasive 114 monitoring. 116 The extension specified in this document applies only to end-to-end 117 communication between DHCP servers and clients. Options added by 118 relay agents in Relay-Forward messages, and options other than the 119 client message in Relay-Reply messages sent by DHCP servers, are not 120 protected. Such communications are already protected using the 121 mechanism described in [I-D.ietf-dhc-relay-server-security]. 123 This extension introduces two new DHCPv6 messages: the Encrypted- 124 Query and the Encrypted-Response messages. It defines six new DHCPv6 125 options: the Algorithm, Certificate, Signature, Increasing-number, 126 Encryption-Key-Tag option and Encrypted-message options. 128 2. Requirements Language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119] when they 133 appear in ALL CAPS. When these words are not in ALL CAPS (such as 134 "should" or "Should"), they have their usual English meanings, and 135 are not to be interpreted as [RFC2119] key words. 137 3. Terminology 139 This section defines terminology specific to secure DHCPv6 used in 140 this document. 142 secure DHCPv6 client: A node that initiates a DHCPv6 request on a 143 link to obtain DHCPv6 configuration parameters from 144 one or more DHCPv6 servers using the encryption and 145 optional authentication mechanisms defined in this 146 document. 148 secure DHCPv6 server: A DHCPv6 server that implements the 149 authentication and encryption mechanisms defined in 150 this document, and is configured to use them. 152 4. Security Issues of DHCPv6 154 [RFC3315] defines an authentication mechanism with integrity 155 protection. This mechanism uses a symmetric key that is shared by 156 the client and server for authentication. It does not provide any 157 key distribution mechanism. 159 For this approach, operators can set up a key database for both 160 servers and clients from which the client obtains a key before 161 running DHCPv6. However, manual key distribution runs counter to the 162 goal of minimizing the configuration data needed at each host. 163 Consequently, there are no known deployments of this security 164 mechanism. 166 [RFC3315] provides an additional mechanism for preventing off-network 167 timing attacks using the Reconfigure message: the Reconfigure Key 168 authentication method. However, this method protects only the 169 Reconfigure message. The key is transmitted in plaintext to the 170 client in earlier exchanges and so this method is vulnerable to on- 171 path active attacks. 173 Anonymity Profile for DHCP Clients [RFC7844] explains how to generate 174 DHCPv4 or DHCPv6 requests that minimize the disclosure of identifying 175 information. However, the anonymity profile limits the use of the 176 certain options. It also cannot anticipate new options that may 177 contain private information. In addition, the anonymity profile does 178 not work in cases where the client wants to maintain anonymity from 179 eavesdroppers but must identify itself to the DHCP server with which 180 it intends to communicate. 182 Privacy consideration for DHCPv6 [RFC7824] presents an analysis of 183 the privacy issues associated with the use of DHCPv6 by Internet 184 users. No solutions are presented. 186 Current DHCPv6 messages are still transmitted in cleartext and the 187 privacy information within the DHCPv6 message is not protected from 188 passive attack, such as pervasive monitoring [RFC7258]. The privacy 189 information of the IPv6 host, such as DUID, may be gleaned to find 190 location information, previous visited networks and so on. [RFC7258] 191 claims that pervasive monitoring should be mitigated in the design of 192 IETF protocol, where possible. 194 To better address the problem of passive monitoring and to achieve 195 authentication without requiring a symmetric key distribution 196 solution for DHCP, this document defines an asymmetric key 197 authentication and encryption mechanism. This protects against both 198 active attacks, such as spoofing, and passive attacks, such as 199 pervasive monitoring. 201 5. Secure DHCPv6 Overview 203 5.1. Solution Overview 205 The following figure illustrates the secure DHCPv6 procedure. 206 Briefly, this extension establishes the server's identity with an 207 anonymous Information-Request exchange. Once the server's identity 208 has been established, the client may either choose to communicate 209 with the server or not. Not communicating with an unknown server 210 avoids revealing private information, but if there is no known server 211 on a particular link, the client will be unable to communicate with a 212 DHCP server. 214 If the client chooses to communicate with the selected server(s), it 215 uses the Encrypted-Query message to encapsulate its communications to 216 the DHCP server. The server responds with Encrypted-Response 217 messages. Normal DHCP messages are encapsulated in these two new 218 messages using the new defined Encrypted-message option. Besides the 219 Encrypted-message option, the Signature option is defined to verify 220 the integrity of the DHCPv6 messages and then authentication of the 221 client and the server. The Increasing number option is defined to 222 detect a replay attack. 224 +-------------+ +-------------+ 225 |DHCPv6 Client| |DHCPv6 Server| 226 +-------------+ +-------------+ 227 | Information-request | 228 |----------------------------------------->| 229 | Algorithm option | 230 | Option Request option | 231 | | 232 | Reply | 233 |<-----------------------------------------| 234 | Certificate option | 235 | Signature option | 236 | Increasing-number option | 237 | Server Identifier option | 238 | | 239 | Encryption-Query | 240 |----------------------------------------->| 241 | Encrypted-message option | 242 | Server Identifier option | 243 | Encryption-Key-Tag option | 244 | | 245 | Encryption-Response | 246 |<-----------------------------------------| 247 | Encrypted-message option | 248 | | 250 Figure 1: Secure DHCPv6 Procedure 252 5.2. New Components 254 The new components of the mechanism specified in this document are as 255 follows: 257 o Servers and clients that use certificates first generate a public/ 258 private key pair and then obtain a certificate that signs the 259 public key. The Certificate option is defined to carry the 260 certificate of the sender. 262 o The algorithm option is defined to carry the algorithms lists for 263 algorithm agility. 265 o The signature is generated using the private key to verify the 266 integrity of the DHCPv6 messages. The Signature option is defined 267 to carry the signature. 269 o The increasing number is used to detect replayed packet. The 270 Increasing-number option is defined to carry a strictly-increasing 271 serial number. 273 o The encryption key Tag is calculated from the public key data. 274 The Encryption-Key-Tag option is defined to identify the used 275 public/private key pair. 277 o The Encrypted-message option is defined to contain the encrypted 278 DHCPv6 message. 280 o The Encrypted-Query message is sent from the secure DHCPv6 client 281 to the secure DHCPv6 server. The Encrypted-Query message MUST 282 contain the Encrypted-message option and Encryption-Key-Tag 283 option. In addition, the Server Identifier option MUST be 284 included if it is contained in the original DHCPv6 message. The 285 Encrypted-Query message MUST NOT contain any other options. 287 o The Encrypted-Response message is sent from the secure DHCPv6 288 server to the secure DHCPv6 client. The Encrypted-Response 289 message MUST contain the Encrypted-message option. The Encrypted- 290 Response message MUST NOT contain any other options. 292 5.3. Support for Algorithm Agility 294 In order to provide a means of addressing problems that may emerge 295 with existing hash algorithms, signature algorithm and encryption 296 algorithms in the future, this document provides a mechanism to 297 support algorithm agility. The support for algorithm agility in this 298 document is mainly a algorithm notification mechanism between the 299 client and the server. The same client and server MUST use the same 300 algorithm in a single communication session. The client can offer a 301 set of algorithms, and then the server selects one algorithm for the 302 future communication. 304 5.4. Impact on RFC3315 306 For secure DHCPv6, the Solicit and Rebind messages can be sent only 307 to the selected server(s) which share one common certificate. If the 308 client doesn't like the received Advertise(s) it could restart the 309 whole process and selects another certificate, but it will be more 310 expensive, and there's no guarantee that other servers can provide 311 better Advertise(s). 313 [RFC3315] provides an additional mechanism for preventing off-network 314 timing attacks using the Reconfigure message: the Reconfigure Key 315 authentication method. Secure DHCPv6 can protect the Reconfigure 316 message using the encryption method. So the Reconfigure Key 317 authentication method SHOULD NOT be used if Secure DHCPv6 is applied. 319 5.5. Applicability 321 In principle, secure DHCPv6 is applicable in any environment where 322 physical security on the link is not assured and attacks on DHCPv6 323 are a concern. In practice, however, authenticated and encrypted 324 DHCPv6 configuration will rely on some operational assumptions mainly 325 regarding public key distribution and management. In order to 326 achieve the wider use of secure DHCPv6, opportunistic security 327 [RFC7435] can be applied to secure DHCPv6 deployment, which allows 328 DHCPv6 encryption in environments where support for authentication or 329 a key distribution mechanism is not available. 331 Secure DHCPv6 can achieve authentication and encryption based on pre- 332 sharing of authorized certificates. One feasible environment in an 333 early deployment stage would be enterprise networks. In enterprise 334 networks, the client is manually pre-configured with the trusted 335 servers' public key and the server can also be manually pre- 336 configured with the trusted clients' public keys. In some scenario, 337 such as coffee shop where the certificate cannot be validated and one 338 wants access to the Internet, then the DHCPv6 configuration process 339 can be encrypted without authentication. 341 Note that this deployment scenario based on manual operation is not 342 much different from the existing, shared-secret based authentication 343 mechanisms defined in [RFC3315] in terms of operational costs. 344 However, Secure DHCPv6 is still securer than the shared-secret 345 mechanism in that even if clients' keys stored for the server are 346 stolen that does not mean an immediate threat as these are public 347 keys. In addition, if some kind of Public Key Infrastructure (PKI) 348 is used with Secure DHCPv6, even if the initial installation of the 349 certificates is done manually, it will help reduce operational costs 350 of revocation in case a private key (especially that of the server) 351 is compromised. 353 6. DHCPv6 Client Behavior 355 The secure DHCPv6 client is pre-configured with a certificate and its 356 corresponding private key for client authentication. If the client 357 does not obtain a certificate from Certificate Authority (CA), it can 358 generate the self-signed certificate. 360 The secure DHCPv6 client sends an Information-request message as per 361 [RFC3315]. The Information-request message is used by the DHCPv6 362 client to request the server's certificate information without having 363 addresses, prefixes or any non-security options assigned to it. The 364 contained Option Request option MUST carry the option code of the 365 Certificate option. In addition, the contained Algorithm option MUST 366 be constructed as explained in Section 10.1.1. The Information- 367 request message MUST NOT include any other DHCPv6 options except the 368 above options to minimize the client's privacy information leakage. 370 When receiving the Reply messages from the DHCPv6 servers, a secure 371 DHCPv6 client discards any DHCPv6 message that meets any of the 372 following conditions: 374 o the Signature option is missing, 376 o multiple Signature options are present, 378 o the Certificate option is missing. 380 And then the client first checks acknowledged hash, signature and 381 encryption algorithms that the server supports. The client checks 382 the signature/encryption algorithms through the certificate option 383 and checks the signature/hash algorithms through the signature 384 option. The SA-id in the certificate option must be equal to the SA- 385 id in the signature option. If they are different, then the client 386 drops the Reply message. The client uses the acknowledged algorithms 387 in the subsequent messages. 389 Then the client checks the authority of the server. In some scenario 390 where non-authenticated encryption can be accepted, such as coffee 391 shop, then authentication is optional and can be skipped. For the 392 certificate check method, the client validates the certificates 393 through the pre-configured local trusted certificates list or other 394 methods. A certificate that finds a match in the local trust 395 certificates list is treated as verified. If the certificate check 396 fails, the Reply message is dropped. 398 The client MUST now authenticate the server by verifying the 399 signature and checking increasing number, if there is a Increasing- 400 number option. The order of two procedures is left as an 401 implementation decision. It is RECOMMENDED to check increasing 402 number first, because signature verification is much more 403 computationally expensive. The client checks the Increasing-number 404 option according to the rule defined in Section 9.1. For the message 405 without an Increasing-number option, according to the client's local 406 policy, it MAY be acceptable or rejected. The Signature field 407 verification MUST show that the signature has been calculated as 408 specified in Section 10.1.3. Only the messages that get through both 409 the signature verification and increasing number check (if there is a 410 Increasing-number option) are accepted. Reply message that does not 411 pass the above tests MUST be discarded. 413 If there are multiple authenticated DHCPv6 certs, the client selects 414 one DHCPv6 cert for the following communication. The selected 415 certificate may correspond to multiple DHCPv6 servers. If there are 416 no authenticated DHCPv6 certs or existing servers fail 417 authentication, the client should retry a number of times. The 418 client conducts the server discovery process as per section 18.1.5 of 419 [RFC3315] to avoid a packet storm. In this way, it is difficult for 420 a rogue server to beat out a busy "real" server. And then the client 421 takes some alternative action depending on its local policy, such as 422 attempting to use an unsecured DHCPv6 server. 424 Once the server has been authenticated, the DHCPv6 client sends the 425 Encrypted-Query message to the DHCPv6 server. The Encrypted-Query 426 message contains the Encrypted-message option, which MUST be 427 constructed as explained in Section 10.1.6. The Encrypted-message 428 option contains the encrypted DHCPv6 message using the public key 429 contained in the selected cert. In addition, the Server Identifier 430 option MUST be included if it is in the original message (i.e. 431 Request, Renew, Decline, Release) to avoid the need for other servers 432 receiving the message to attempt to decrypt it. The Encrypted-Query 433 message MUST include the Encryption-Key-Tag option to identify the 434 used public/private key pair, which is constructed as explained in 435 Section 10.1.5. The Encrypted-Query message MUST NOT contain any 436 other DHCPv6 option except the Server Identifier option, Encryption- 437 Key-Tag option, Encrypted-Message option. 439 The first DHCPv6 message sent from the client to the server, such as 440 Solicit message, MUST contain the related information for client 441 authentication. The encryption text SHOULD be formatted as explain 442 in [RFC5652]. The Certificate option MUST be constructed as 443 explained in Section 10.1.2. In addition, one and only one Signature 444 option MUST be contained, which MUST be constructed as explained in 445 Section 10.1.3. One and only one Increasing-number option SHOULD be 446 contained, which MUST be constructed as explained in Section 10.1.4. 447 In addition, the subsequent encrypted DHCPv6 message sent from the 448 client can also contain the Increasing-number option to defend 449 against replay attack. 451 For the received Encrypted-Response message, the client MUST drop the 452 Encrypted-Response message if other DHCPv6 option except Encrypted- 453 message option is contained. If the transaction-id is 0, the client 454 also try to decrypt it. Then, the client extracts the Encrypted- 455 message option and decrypts it using its private key to obtain the 456 original DHCPv6 message. In this document, it is assumed that the 457 client will not have multiple DHCPv6 sessions with different DHCPv6 458 servers using different key pairs and only one key pair is used for 459 the encrypted DHCPv6 configuration process. After the decryption, it 460 handles the message as per [RFC3315].If the decrypted DHCPv6 message 461 contains the Increasing-number option, the DHCPv6 client checks it 462 according to the rule defined in Section 9.1. 464 If the client fails to get the proper parameters from the chosen 465 server(s), it can select another authenticated certificate and send 466 the Encrypted-Query message to another authenticated server(s) for 467 parameters configuration until the client obtains the proper 468 parameters. 470 When the decrypted message is Reply message with an error status 471 code, the error status code indicates the failure reason on the 472 server side. According to the received status code, the client MAY 473 take follow-up action: 475 o Upon receiving an AuthenticationFail error status code, the client 476 is not able to build up the secure communication with the server. 477 However, there may be other DHCPv6 servers available that 478 successfully complete authentication. The client MAY use the 479 AuthenticationFail as a hint and switch to other DHCPv6 server if 480 it has another one. The client SHOULD retry with another 481 authenticated certificate. However, if the client decides to 482 retransmit using the same certificate after receiving 483 AuthenticationFail, it MUST NOT retransmit immediately and MUST 484 follow normal retransmission routines defined in [RFC3315]. 486 o Upon receiving a ReplayDetected error status code, the client MAY 487 resend the message with an adjusted Increasing-number option 488 according to the returned number from the DHCPv6 server. 490 o Upon receiving a SignatureFail error status code, the client MAY 491 resend the message following normal retransmission routines 492 defined in [RFC3315]. 494 7. DHCPv6 Server Behavior 496 The secure DHCPv6 server is pre-configured with a certificate and its 497 corresponding private key for server authentication. If the server 498 does not obtain the certificate from Certificate Authority (CA), it 499 can generate the self-signed certificate. 501 When the DHCPv6 server receives the Information-request message and 502 the contained Option Request option identifies the request is for the 503 server's certificate information, it SHOULD first check the hash, 504 signature, encryption algorithms sets that the client supports. The 505 server selects one hash, signature, encryption algorithm from the 506 acknowledged algorithms sets for the future communication. And then, 507 the server replies with a Reply message to the client. The Reply 508 message MUST contain the requested Certificate option, which MUST be 509 constructed as explained in Section 10.1.2, and Server Identifier 510 option. In addition, the Reply message MUST contain one and only one 511 Signature option, which MUST be constructed as explained in 512 Section 10.1.3. Besides, the Reply message SHOULD contain one and 513 only one Increasing-number option, which MUST be constructed as 514 explained in Section 10.1.4. 516 Upon the receipt of Encrypted-Query message, the server MUST drop the 517 message if the other DHCPv6 option is contained except Server 518 Identifier option, Encryption-Key-Tag option, Encrypted-message 519 option. Then, the server checks the Server Identifier option. The 520 DHCPv6 server drops the message that is not for it, thus not paying 521 cost to decrypt messages. If it is the target server, according to 522 the Encryption-Key-Tag option, the server identifies the used public/ 523 private key pair and decrypts the Encrypted-message option using the 524 corresponding private key. It is essential to note that the 525 encryption key tag is not a unique identifier. It is theoretically 526 possible for two different public keys to share one common encryption 527 key tag. The encryption key tag is used to limit the possible 528 candidate keys, but it does not uniquely identify a public/private 529 key pair. The server MUST try all corresponding key pairs. If the 530 server cannot find the corresponding private key of the key tag or 531 the corresponding private key of the key tag is invalid for 532 decryption, then the server drops the received message. 534 If secure DHCPv6 server needs client authentication and decrypted 535 message is a Solicit/Information-request message which contains the 536 information for client authentication, the secure DHCPv6 server 537 discards the received message that meets any of the following 538 conditions: 540 o the Signature option is missing, 542 o multiple Signature options are present, 544 o the Certificate option is missing. 546 For the signature failure, the server SHOULD send an encrypted Reply 547 message with an UnspecFail (value 1, [RFC3315]) error status code to 548 the client. 550 The server validates the client's certificate through the local pre- 551 configured trusted certificates list. A certificate that finds a 552 match in the local trust certificates list is treated as verified. 553 If the server does not know the certificate and can accept the non- 554 authenticated encryption, then the server skips the authentication 555 process and uses it for encryption only. The message that fails 556 authentication validation MUST be dropped. In such failure, the 557 DHCPv6 server replies with an encrypted Reply message with an 558 AuthenticationFail error status code, defined in Section 10.3, back 559 to the client. At this point, the server has either recognized the 560 authentication of the client, or decided to drop the message. 562 If the decrypted message contains the Increasing-number option, the 563 server checks it according to the rule defined in Section 9.1. If 564 the check fails, an encrypted Reply message with a ReplayDetected 565 error status code, defined in Section 10.3, should be sent back to 566 the client. In the Reply message, a Increasing-number option is 567 carried to indicate the server's stored number for the client to use. 568 According to the server's local policy, the message without an 569 Increasing-number option MAY be acceptable or rejected. 571 The Signature field verification MUST show that the signature has 572 been calculated as specified in Section 10.1.3. If the signature 573 check fails, the DHCPv6 server SHOULD send an encrypted Reply message 574 with a SignatureFail error status code. Only the clients that get 575 through both the signature verification and increasing number check 576 (if there is a Increasing-number option) are accepted as 577 authenticated clients and continue to be handled their message as 578 defined in [RFC3315]. 580 Once the client has been authenticated, the DHCPv6 server sends the 581 Encrypted-response message to the DHCPv6 client. If the DHCPv6 582 message is Reconfigure message, then the server set the transaction- 583 id of the Encrypted-Response message to 0. The Encrypted-response 584 message MUST only contain the Encrypted-message option, which MUST be 585 constructed as explained in Section 10.1.6. The encryption text 586 SHOULD be formatted as explain in [RFC5652]. The Encrypted-message 587 option contains the encrypted DHCPv6 message that is encrypted using 588 the authenticated client's public key. To provide the replay 589 protection, the Increasing-number option SHOULD be contained in the 590 encrypted DHCPv6 message. 592 8. Relay Agent Behavior 594 When a DHCPv6 relay agent receives an Encrypted-query or Encrypted- 595 response message, it may not recognize this message. The unknown 596 messages MUST be forwarded as described in [RFC7283]. 598 When a DHCPv6 relay agent recognizes the Encrypted-query and 599 Encrypted-response messages, it forwards the message according to 600 section 20 of [RFC3315]. There is nothing more the relay agents have 601 to do, it neither needs to verify the messages from client or server, 602 nor add any secure DHCPv6 options. Actually, by definition in this 603 document, relay agents MUST NOT add any secure DHCPv6 options. 605 Relay-forward and Relay-reply messages MUST NOT contain any 606 additional Certificate option or Increasing-number option, aside from 607 those present in the innermost encapsulated messages from the client 608 or server. 610 9. Processing Rules 612 9.1. Increasing Number Check 614 In order to check the Increasing-number option, defined in 615 Section 10.1.4, the client/server has one stable stored number for 616 replay attack detection. The server should keep a record of the 617 increasing number forever. And the client keeps a record of the 618 increasing number during the DHCPv6 configuration process with the 619 DHCPv6 server. And the client can forget the increasing number 620 information after the transaction is finished. The client's initial 621 locally stored increasing number is set to zero. 623 It is essential to remember that the increasing number is finite. 624 All arithmetic dealing with sequence numbers must be performed modulo 625 2^64. This unsigned arithmetic preserves the relationship of 626 sequence numbers as they cycle from 2^64 - 1 to 0 again. 628 In order to check the Increasing-number option, the following 629 comparison is needed. 631 NUM.STO = the stored number in the client/server 633 NUM.REC = the acknowledged number from the received message 635 The Increasing-number option in the received message passes the 636 increasing number check if NUM.REC is more than NUM.STO. And then, 637 the value of NUM.STO is changed into the value of NUM.REC. 639 The increasing number check fails if NUM.REC is equal with or less 640 than NUM.STO. 642 9.2. Encryption Key Tag Calculation 644 The generation method of the encryption key tag adopts the method 645 define in Appendix B in [RFC4034]. 647 The following reference implementation calculates the value of the 648 encryption key tag. The input is the data of the public key. The 649 code is written for clarity not efficiency. 651 /* 652 * First octet of the key tag is the most significant 8 bits of the 653 * return value; 654 * Second octet of the key tag is the least significant 8 bits of the 655 * return value. 656 */ 658 unsigned int 659 keytag ( 660 unsigned char key[], /* the RDATA part of the DNSKEY RR */ 661 unsigned int keysize /* the RDLENGTH */ 662 ) 663 { 664 unsigned long ac; /* assumed to be 32 bits or larger */ 665 int i; /* loop index */ 667 for ( ac = 0, i = 0; i < keysize; ++i ) 668 ac += (i & 1) ? key[i] : key[i] << 8; 669 ac += (ac >> 16) & 0xFFFF; 670 return ac & 0xFFFF; 671 } 673 10. Extensions for Secure DHCPv6 675 This section describes the extensions to DHCPv6. Six new DHCPv6 676 options, two new DHCPv6 messages and six new status codes are 677 defined. 679 10.1. New DHCPv6 Options 681 10.1.1. Algorithm Option 683 The Algorithm option carries the algorithms sets for algorithm 684 agility, which is contained in the Information-request message. 686 0 1 2 3 687 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 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | OPTION_ALGORITHM | option-len | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 . EA-id List . 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 . SHA-id List . 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 Figure 2: Algorithm Option 698 o option-code: OPTION_ALGORITHM (TBA1). 700 o option-len: length of EA-id List + length of SHA-id List in 701 octets. 703 o EA-id: The format of the EA-id List field is shown in Figure 3. 705 0 1 2 3 706 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 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | EA-len | EA-id | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 . ... . 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | EA-id | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 EA-len The length of the following EA-ids. 717 EA-id 2-octets value to indicate the Encryption Algorithm id. 718 The client enumerates the list of encryption algorithms it 719 supports to the server. The encryption algorithm is used 720 for the encrypted DHCPv6 configuration process. This design 721 is adopted in order to provide encryption algorithm agility. 722 The value is from the Encryption Algorithm for Secure DHCPv6 723 registry in IANA. A registry of the initial assigned values 724 is defined in Section 12. The RSA algorithm, as the mandatory 725 encryption algorithm, MUST be included. 727 Figure 3: EA-id List Field 729 o SHA-id List: The format of the SHA-id List field is shown in 730 Figure 4. The SHA-id List contains multiple pair of (SA-id, HA- 731 id). Each pair of (SA-id[i], HA-id[i]) is considered to specify a 732 specific signature method. 734 0 1 2 3 735 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 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | SHA-len | SA-id[1] | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | HA-id[1] | SA-id[2] | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | HA-id[2] | ... . 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 . ... . 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | SA-id[n] | HA-id[n] | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 SHA-len The length of the following SA-id and HA-id pairs. 750 SA-id 2-octets value to indicate the Signature Algorithm id. 751 The client enumerates the list of signature algorithms it 752 supports to the server. This design is adopted in 753 order to provide signature algorithm agility. The 754 value is from the Signature Algorithm for Secure 755 DHCPv6 registry in IANA. The support of RSASSA-PKCS1-v1_5 756 is mandatory. A registry of the initial assigned 757 values is defined in Section 12. The mandatory 758 signature algorithms MUST be included. 760 HA-id 2-octets value to indicate the Hash Algorithm id. 761 The client enumerates the list of hash algorithms it 762 supports to the server. This design is adopted in order to 763 provide hash algorithm agility. The value is from the 764 Hash Algorithm for Secure DHCPv6 registry in IANA. The 765 support of SHA-256 is mandatory. A registry of the 766 initial assigned values is defined in Section 12. 767 The mandatory hash algorithms MUST be included. 769 Figure 4: SHA-id List Field 771 10.1.2. Certificate Option 773 The Certificate option carries the certificate of the client/server, 774 which is contained in the Reply message. The format of the 775 Certificate option is described as follows: 777 0 1 2 3 778 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 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | OPTION_CERTIFICATE | option-len | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | EA-id | SA-id | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | | 785 . Certificate . 786 | | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 Figure 5: Certificate Option 791 o option-code: OPTION_CERTIFICATE (TBA2). 793 o option-len: 4 + length of Certificate in octets. 795 o EA-id: Encryption Algorithm id which is used for the certificate. 796 If the value of the EA-id is 0, then the public key in the 797 certificate is not used for encryption calculation. 799 o SA-id: Signature Algorithm id which is used for the certificate. 800 If the value of the EA-id is 0, then the public key in the 801 certificate is not used for signature calculation. 803 o Certificate: A variable-length field containing certificates. The 804 encoding of certificate and certificate data MUST be in format as 805 defined in Section 3.6, [RFC7296]. The support of X.509 806 certificate is mandatory. 808 It should be noticed that the scenario where the values of EA-id and 809 SA-id are both 0 makes no sense and the client MUST discard a message 810 with such values. 812 10.1.3. Signature option 814 The Signature option contains a signature that is signed by the 815 private key to be attached to the Reply message. The Signature 816 option could be in any place within the DHCPv6 message while it is 817 logically created after the entire DHCPv6 header and options. It 818 protects the entire DHCPv6 header and options, including itself. The 819 format of the Signature option is described as follows: 821 0 1 2 3 822 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 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | OPTION_SIGNATURE | option-len | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | SA-id | HA-id | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | | 829 . Signature (variable length) . 830 . . 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 Figure 6: Signature Option 835 o option-code: OPTION_SIGNATURE (TBA3). 837 o option-len: 4 + length of Signature field in octets. 839 o SA-id: Signature Algorithm id. The signature algorithm is used 840 for computing the signature result. This design is adopted in 841 order to provide signature algorithm agility. The value is from 842 the Signature Algorithm for Secure DHCPv6 registry in IANA. The 843 support of RSASSA-PKCS1-v1_5 is mandatory. A registry of the 844 initial assigned values is defined in Section 12. 846 o HA-id: Hash Algorithm id. The hash algorithm is used for 847 computing the signature result. This design is adopted in order 848 to provide hash algorithm agility. The value is from the Hash 849 Algorithm for Secure DHCPv6 registry in IANA. The support of 850 SHA-256 is mandatory. A registry of the initial assigned values 851 is defined in Section 12. 853 o Signature: A variable-length field containing a digital signature. 854 The signature value is computed with the hash algorithm and the 855 signature algorithm, as described in HA-id and SA-id. The 856 Signature field MUST be padded, with all 0, to the next octet 857 boundary if its size is not a multiple of 8 bits. The padding 858 length depends on the signature algorithm, which is indicated in 859 the SA-id field. 861 Note: If Secure DHCPv6 is used, the DHCPv6 message is encrypted in a 862 way that the authentication mechanism defined in RFC3315 does not 863 understand. So the Authentication option SHOULD NOT be used if 864 Secure DHCPv6 is applied. 866 10.1.4. Increasing-number Option 868 The Increasing-number option carries the strictly increasing number 869 for anti-replay protection, which is contained in the Reply message 870 and the encrypted DHCPv6 message. It is optional. 872 0 1 2 3 873 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 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | OPTION_INCREASING_NUM | option-len | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | | 878 | Increasing-Num (64-bit) | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 option-code OPTION_INCREASING_NUM (TBA4). 883 option-len 8, in octets. 885 Increasing-Num A strictly increasing number for the replay attack detection 886 which is more than the local stored number. 888 Figure 7: Increasing-number Option 890 10.1.5. Encryption-Key-Tag Option 892 The Encryption-Key-Tag option carries the key identifier which is 893 calculated from the public key data. The Encrypted-Query message 894 MUST contain the Encryption-Key-Tag option to identify the used 895 public/private key pair. 897 0 1 2 3 898 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 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | OPTION_ENCRYPTION_KEY_TAG | option-len | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | encryption key tag(16-bit) | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 Figure 8: Encryption-Key-Tag Option 907 option-code OPTION_ENCRYPTION_KEY_TAG (TBA5). 909 option-len 2, in octets. 911 encryption key tag A 16 bits field containing the encryption key tag 912 sent from the client to server to identify the used public/private 913 key pair. The encryption key tag is calculated from the public 914 key data, like fingerprint of a specific public key. The specific 915 calculation method of the encryption key tag is illustrated in 916 Section 9.2. 918 10.1.6. Encrypted-message Option 920 The Encrypted-message option carries the encrypted DHCPv6 message, 921 which is calculated with the recipient's public key. The Encrypted- 922 message option is contained in the Encrypted-Query message or the 923 Encrypted-Response message. 925 The format of the Encrypted-message option is: 927 0 1 2 3 928 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 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | option-code | option-len | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | | 933 . encrypted DHCPv6 message . 934 . (variable) . 935 . . 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 Figure 9: Encrypted-message Option 940 option-code OPTION_ENCRYPTED_MSG (TBA6). 942 option-len Length of the encrypted DHCPv6 message in octets. 944 encrypted DHCPv6 message A variable length field containing the 945 encrypted DHCPv6 message. In Encrypted-Query message, it contains 946 encrypted DHCPv6 message sent from a client to server. In 947 Encrypted-response message, it contains encrypted DHCPv6 message 948 sent from a server to client. 950 10.2. New DHCPv6 Messages 952 Two new DHCPv6 messages are defined to achieve the DHCPv6 encryption: 953 Encrypted-Query and Encrypted-Response. Both the DHCPv6 messages 954 defined in this document share the following format: 956 0 1 2 3 957 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 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | msg-type | transaction-id | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | | 962 . options . 963 . (variable) . 964 | | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 Figure 10: The format of Encrypted-Query and Encrypted-Response 968 Messages 970 msg-type Identifier of the message type. It can be either 971 Encrypted-Query (TBA7) or DHCPv6-Response (TBA8). 973 transaction-id The transaction ID for this message exchange. 975 options The Encrypted-Query message MUST contain the 976 Encrypted-message option, Encryption-Key-Tag option 977 and Server Identifier option if the message in the 978 Encrypted-message option has a Server Identifier 979 option. The Encrypted-Response message MUST only 980 contain the Encrypted-message option. 982 10.3. Status Codes 984 The following new status codes, see Section 5.4 of [RFC3315] are 985 defined. 987 o AuthenticationFail (TBD9): indicates that the message from the 988 DHCPv6 client fails authentication check. 990 o ReplayDetected (TBD10): indicates the message from DHCPv6 client 991 fails the increasing number check. 993 o SignatureFail (TBD11): indicates the message from DHCPv6 client 994 fails the signature check. 996 11. Security Considerations 998 This document provides the authentication and encryption mechanisms 999 for DHCPv6. 1001 There are some mandatory algorithm for encryption algorithm in this 1002 document. It may be at some point that the mandatory algorithm is no 1003 longer safe to use. 1005 A server or a client, whose local policy accepts messages without a 1006 Increasing-number option, may have to face the risk of replay 1007 attacks. 1009 Since the algorithm option isn't protected by a signature, the list 1010 can be forged without detection, which can lead to a downgrade 1011 attack. 1013 Likewise, since the Encryption-Key-Tag Option isn't protected, an 1014 attacker that can intercept the message can forge the value without 1015 detection. 1017 If the client tries more than one cert for client authentication, the 1018 server can easily get a client that implements this to enumerate its 1019 entire cert list and probably learn a lot about a client that way. 1020 For this security item, It is RECOMMENDED that client certificates 1021 could be tied to specific server certificates by configuration. 1023 12. IANA Considerations 1025 This document defines six new DHCPv6 [RFC3315] options. The IANA is 1026 requested to assign values for these six options from the DHCPv6 1027 Option Codes table of the DHCPv6 Parameters registry maintained in 1028 http://www.iana.org/assignments/dhcpv6-parameters. The six options 1029 are: 1031 The Algorithm Option (TBA1), described in Section 10.1.2. 1033 The Certificate Option (TBA2), described in Section 10.1.2. 1035 The Signature Option (TBA3), described in Section 10.1.3. 1037 The Increasing-number Option (TBA4),described in Section 10.1.4. 1039 The Encryption-Key-Tag Option (TBA5),described in Section 10.1.5. 1041 The Encrypted-message Option (TBA6), described in Section 10.1.6. 1043 The IANA is also requested to assign value for these two messages 1044 from the DHCPv6 Message Types table of the DHCPv6 Parameters registry 1045 maintained in http://www.iana.org/assignments/dhcpv6-parameters. The 1046 two messages are: 1048 The Encrypted-Query Message (TBA7), described in Section 10.2. 1050 The Encrypted-Response Message (TBA8), described in Section 10.2. 1052 The IANA is also requested to add three new registry tables to the 1053 DHCPv6 Parameters registry maintained in 1054 http://www.iana.org/assignments/dhcpv6-parameters. The three tables 1055 are the Hash Algorithm for Secure DHCPv6 table, the Signature 1056 Algorithm for Secure DHCPv6 table and the Encryption Algorithm for 1057 Secure DHCPv6 table. 1059 Initial values for these registries are given below. Future 1060 assignments are to be made through Standards Action [RFC5226]. 1061 Assignments for each registry consist of a name, a value and a RFC 1062 number where the registry is defined. 1064 Hash Algorithm for Secure DHCPv6. The values in this table are 1065 16-bit unsigned integers. The following initial values are assigned 1066 for Hash Algorithm for Secure DHCPv6 in this document: 1068 Name | Value | RFCs 1069 -------------------+---------+-------------- 1070 SHA-256 | 0x01 | this document 1071 SHA-512 | 0x02 | this document 1073 Signature Algorithm for Secure DHCPv6. The values in this table are 1074 16-bit unsigned integers. The following initial values are assigned 1075 for Signature Algorithm for Secure DHCPv6 in this document: 1077 Name | Value | RFCs 1078 -------------------+---------+-------------- 1079 Non-SigAlg | 0x00 | this document 1080 RSASSA-PKCS1-v1_5 | 0x01 | this document 1082 Encryption algorithm for Secure DHCPv6. The values in this table are 1083 16-bit unsigned integers. The following initial values are assigned 1084 for encryption algorithm for Secure DHCPv6 in this document: 1086 Name | Value | RFCs 1087 -------------------+---------+-------------- 1088 Non-EncryAlg | 0x00 | this document 1089 RSA | 0x01 | this document 1091 IANA is requested to assign the following new DHCPv6 Status Codes, 1092 defined in Section 10.3, in the DHCPv6 Parameters registry maintained 1093 in http://www.iana.org/assignments/dhcpv6-parameters: 1095 Code | Name | Reference 1096 ---------+-----------------------+-------------- 1097 TBD9 | AuthenticationFail | this document 1098 TBD10 | ReplayDetected | this document 1099 TBD11 | SignatureFail | this document 1101 13. Acknowledgements 1103 The authors would like to thank Tomek Mrugalski, Bernie Volz, 1104 Jianping Wu, Randy Bush, Yiu Lee, Sean Shen, Ralph Droms, Jari Arkko, 1105 Sean Turner, Stephen Farrell, Christian Huitema, Stephen Kent, Thomas 1106 Huth, David Schumacher, Francis Dupont, Gang Chen, Suresh Krishnan, 1107 Fred Templin, Robert Elz, Nico Williams, Erik Kline, Alan DeKok, 1108 Bernard Aboba, Sam Hartman, Zilong Liu and other members of the IETF 1109 DHC working group for their valuable comments. 1111 This document was produced using the xml2rfc tool [RFC2629]. 1113 14. Change log [RFC Editor: Please remove] 1115 draft-ietf-dhc-sedhcpv6-21: Add the reference of draft-ietf-dhc-relay 1116 -server-security. Change the SA-ID List as SHA-ID List and delete 1117 the HA-id List. The SHA-id List contains the SA-id and HA-id pairs. 1118 Add some statements about the Reconfigure message process. Add some 1119 specific text on the encryption key tag calculation method; Add more 1120 text on security consideration; Changes some mistakes and grammar 1121 mistakes 1123 draft-ietf-dhc-sedhcpv6-20: Correct a few grammar mistakes. 1125 draft-ietf-dhc-sedhcpv6-19: In client behavior part, we adds some 1126 description about opportunistic security. In this way, in some 1127 scenario, authentication is optional. Add the reference of RFC 4034 1128 for the encryption key tag calculation. Delete the part that the 1129 relay agent cache server announcements part. Add the assumption that 1130 the client's initial stored increasing number is set to zero. In 1131 this way, for the first time increasing number check in the Reply 1132 message, the check will always succeed, and then the locally stored 1133 number is changed into the contained number in the Reply message. 1134 Correct many grammar mistakes. 1136 draft-ietf-dhc-sedhcpv6-18: Add the Algorithm option. The algorithm 1137 option contains the EA-id List, SA-id List, HA-id List, and then the 1138 certificate and signature options do not contain the algorithm list; 1139 Add the Encryption Key Tag option to identify the used public/private 1140 key pair; Delete the AlgorithmNotSupported error status code; Delete 1141 some description on that secure DHCPv6 exchanges the server selection 1142 method; Delete the DecryptionFail error status code; For the case 1143 where the client's certificate is missed, then the server discards 1144 the received message. Add the assumption that: For DHCPv6 client, 1145 just one certificate is used for the DHCPv6 configuration. Add the 1146 statement that: For the first Encrypted-Query message, the server 1147 needs to try all the possible private keys and then records the 1148 relationship between the public key and the encryption key tag. 1150 draft-ietf-dhc-sedhcpv6-17: Change the format of the certificate 1151 option according to the comments from Bernie. 1153 draft-ietf-dhc-sedhcpv6-16: For the algorithm agility part, the 1154 provider can offer multiple EA-id, SA-id, HA-id and then receiver 1155 choose one from the algorithm set. 1157 draft-ietf-dhc-sedhcpv6-15: Increasing number option only contains 1158 the strictly increasing number; Add some description about why 1159 encryption is needed in Security Issues of DHCPv6 part; 1161 draft-ietf-dhc-sedhcpv6-14: For the deployment part, Tofu is out of 1162 scope and take Opportunistic security into consideration; Increasing 1163 number option is changed into 64 bits; Increasing number check is a 1164 separate section; IncreasingnumFail error status code is changed into 1165 ReplayDetected error status code; Add the section of "caused change 1166 to RFC3315"; 1168 draft-ietf-dhc-sedhcpv6-13: Change the Timestamp option into 1169 Increasing-number option and the corresponding check method; Delete 1170 the OCSP stampling part for the certificate check; Add the scenario 1171 where the hash and signature algorithms cannot be separated; Add the 1172 comparison with RFC7824 and RFC7844; Add the encryption text format 1173 and reference of RFC5652. Add the consideration of scenario where 1174 multiple DHCPv6 servers share one common DHCPv6 server. Add the 1175 statement that Encrypted-Query and Encrypted-Response messages can 1176 only contain certain options: Server Identifier option and Encrypted- 1177 message option. Add opportunistic security for deployment 1178 consideration. Besides authentication+encyrption mode, encryption- 1179 only mode is added. 1181 draft-ietf-dhc-sedhcpv6-12: Add the Signature option and timestamp 1182 option during server/client authentication process. Add the hash 1183 function and signature algorithm. Add the requirement: The 1184 Information-request message cannot contain any other options except 1185 ORO option. Modify the use of "SHOULD"; Delete the reference of 1186 RFC5280 and modify the method of client/server cert verification; Add 1187 the relay agent cache function for the quick response when there is 1188 no authenticated server. 2016-4-24. 1190 draft-ietf-dhc-sedhcpv6-11: Delete the Signature option, because the 1191 encrypted DHCPv6 message and the Information-request message (only 1192 contain the Certificate option) don't need the Signature option for 1193 message integrity check; Rewrite the "Applicability" section; Add the 1194 encryption algorithm negotiation process; To support the encryption 1195 algorithm negotiation, the Certificate option contains the EA- 1196 id(encryption algorithm identifier) field; Reserve the Timestamp 1197 option to defend against the replay attacks for encrypted DHCPv6 1198 configuration process; Modify the client behavior when there is no 1199 authenticated DHCPv6 server; Add the DecryptionFail error code. 1200 2016-3-9. 1202 draft-ietf-dhc-sedhcpv6-10: merge DHCPv6 authentication and DHCPv6 1203 encryption. The public key option is removed, because the device can 1204 generate the self-signed certificate if it is pre-configured the 1205 public key not the certificate. 2015-12-10. 1207 draft-ietf-dhc-sedhcpv6-09: change some texts about the deployment 1208 part.2015-12-10. 1210 draft-ietf-dhc-sedhcpv6-08: clarified what the client and the server 1211 should do if it receives a message using unsupported algorithm; 1212 refined the error code treatment regarding to AuthenticationFail and 1213 TimestampFail; added consideration on how to reduce the DoS attack 1214 when using TOFU; other general editorial cleanups. 2015-06-10. 1216 draft-ietf-dhc-sedhcpv6-07: removed the deployment consideration 1217 section; instead, described more straightforward use cases with TOFU 1218 in the overview section, and clarified how the public keys would be 1219 stored at the recipient when TOFU is used. The overview section also 1220 clarified the integration of PKI or other similar infrastructure is 1221 an open issue. 2015-03-23. 1223 draft-ietf-dhc-sedhcpv6-06: remove the limitation that only clients 1224 use PKI- certificates and only servers use public keys. The new text 1225 would allow clients use public keys and servers use PKI-certificates. 1226 2015-02-18. 1228 draft-ietf-dhc-sedhcpv6-05: addressed comments from mail list that 1229 responsed to the second WGLC. 2014-12-08. 1231 draft-ietf-dhc-sedhcpv6-04: addressed comments from mail list. 1232 Making timestamp an independent and optional option. Reduce the 1233 serverside authentication to base on only client's certificate. 1234 Reduce the clientside authentication to only Leaf of Faith base on 1235 server's public key. 2014-09-26. 1237 draft-ietf-dhc-sedhcpv6-03: addressed comments from WGLC. Added a 1238 new section "Deployment Consideration". Corrected the Public Key 1239 Field in the Public Key Option. Added consideration for large DHCPv6 1240 message transmission. Added TimestampFail error code. Refined the 1241 retransmission rules on clients. 2014-06-18. 1243 draft-ietf-dhc-sedhcpv6-02: addressed comments (applicability 1244 statement, redesign the error codes and their logic) from IETF89 DHC 1245 WG meeting and volunteer reviewers. 2014-04-14. 1247 draft-ietf-dhc-sedhcpv6-01: addressed comments from IETF88 DHC WG 1248 meeting. Moved Dacheng Zhang from acknowledgement to be co-author. 1249 2014-02-14. 1251 draft-ietf-dhc-sedhcpv6-00: adopted by DHC WG. 2013-11-19. 1253 draft-jiang-dhc-sedhcpv6-02: removed protection between relay agent 1254 and server due to complexity, following the comments from Ted Lemon, 1255 Bernie Volz. 2013-10-16. 1257 draft-jiang-dhc-sedhcpv6-01: update according to review comments from 1258 Ted Lemon, Bernie Volz, Ralph Droms. Separated Public Key/ 1259 Certificate option into two options. Refined many detailed 1260 processes. 2013-10-08. 1262 draft-jiang-dhc-sedhcpv6-00: original version, this draft is a 1263 replacement of draft-ietf-dhc-secure-dhcpv6, which reached IESG and 1264 dead because of consideration regarding to CGA. The authors followed 1265 the suggestion from IESG making a general public key based mechanism. 1266 2013-06-29. 1268 15. References 1270 15.1. Normative References 1272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1273 Requirement Levels", BCP 14, RFC 2119, 1274 DOI 10.17487/RFC2119, March 1997, 1275 . 1277 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1278 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1279 December 1998, . 1281 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1282 C., and M. Carney, "Dynamic Host Configuration Protocol 1283 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1284 2003, . 1286 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1287 "SEcure Neighbor Discovery (SEND)", RFC 3971, 1288 DOI 10.17487/RFC3971, March 2005, 1289 . 1291 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1292 Rose, "Resource Records for the DNS Security Extensions", 1293 RFC 4034, DOI 10.17487/RFC4034, March 2005, 1294 . 1296 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1297 Control Message Protocol (ICMPv6) for the Internet 1298 Protocol Version 6 (IPv6) Specification", RFC 4443, 1299 DOI 10.17487/RFC4443, March 2006, 1300 . 1302 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1303 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1304 . 1306 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1307 "Network Time Protocol Version 4: Protocol and Algorithms 1308 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1309 . 1311 [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and 1312 Implementation Notes for DNS Security (DNSSEC)", RFC 6840, 1313 DOI 10.17487/RFC6840, February 2013, 1314 . 1316 [RFC7283] Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6 1317 Messages", RFC 7283, DOI 10.17487/RFC7283, July 2014, 1318 . 1320 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1321 Kivinen, "Internet Key Exchange Protocol Version 2 1322 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1323 2014, . 1325 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 1326 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 1327 December 2014, . 1329 [RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy 1330 Considerations for DHCPv6", RFC 7824, 1331 DOI 10.17487/RFC7824, May 2016, 1332 . 1334 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 1335 Profiles for DHCP Clients", RFC 7844, 1336 DOI 10.17487/RFC7844, May 2016, 1337 . 1339 15.2. Informative References 1341 [I-D.ietf-dhc-relay-server-security] 1342 Volz, B. and Y. Pal, "Security of Messages Exchanged 1343 Between Servers and Relay Agents", draft-ietf-dhc-relay- 1344 server-security-03 (work in progress), February 2017. 1346 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1347 DOI 10.17487/RFC2629, June 1999, 1348 . 1350 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1351 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1352 DOI 10.17487/RFC5226, May 2008, 1353 . 1355 [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure 1356 Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, 1357 DOI 10.17487/RFC6273, June 2011, 1358 . 1360 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1361 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1362 2014, . 1364 [RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1, 1365 PKCS 1", November 2002. 1367 Authors' Addresses 1369 Lishan Li 1370 Tsinghua University 1371 Beijing 100084 1372 P.R.China 1374 Phone: +86-15201441862 1375 Email: lilishan48@gmail.com 1377 Sheng Jiang 1378 Huawei Technologies Co., Ltd 1379 Q14, Huawei Campus, No.156 Beiqing Road 1380 Hai-Dian District, Beijing, 100095 1381 CN 1383 Email: jiangsheng@huawei.com 1384 Yong Cui 1385 Tsinghua University 1386 Beijing 100084 1387 P.R.China 1389 Phone: +86-10-6260-3059 1390 Email: yong@csnet1.cs.tsinghua.edu.cn 1392 Tatuya Jinmei 1393 Infoblox Inc. 1394 3111 Coronado Drive 1395 Santa Clara, CA 1396 US 1398 Email: jinmei@wide.ad.jp 1400 Ted Lemon 1401 Nominum, Inc. 1402 2000 Seaport Blvd 1403 Redwood City, CA 94063 1404 USA 1406 Phone: +1-650-381-6000 1407 Email: Ted.Lemon@nominum.com 1409 Dacheng Zhang 1410 Beijing 1411 CN 1413 Email: dacheng.zhang@gmail.com