idnits 2.17.1 draft-ietf-dhc-sedhcpv6-19.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 7 instances of too long lines in the document, the longest one being 3 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 (January 2, 2017) is 2668 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 1098, but no explicit reference was found in the text == Unused Reference: 'RFC3971' is defined on line 1107, but no explicit reference was found in the text == Unused Reference: 'RFC4443' is defined on line 1117, but no explicit reference was found in the text == Unused Reference: 'RFC5905' is defined on line 1127, but no explicit reference was found in the text == Unused Reference: 'RSA' is defined on line 1180, 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 -- 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 (~~), 6 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: July 6, 2017 Y. Cui 6 Tsinghua University 7 T. Jinmei 8 Infoblox Inc. 9 T. Lemon 10 Nominum, Inc. 11 D. Zhang 12 January 2, 2017 14 Secure DHCPv6 15 draft-ietf-dhc-sedhcpv6-19 17 Abstract 19 DHCPv6 includes no deployable security mechanism that can protect 20 end-to-end communication between DHCP clients and servers. This 21 document describes a mechanism for using public key cryptography to 22 provide such security. The mechanism provides encryption in all 23 cases, and can be used for authentication based on pre-sharing of 24 authorized certificates. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 6, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Security Issues of DHCPv6 . . . . . . . . . . . . . . . . . . 4 64 5. Secure DHCPv6 Overview . . . . . . . . . . . . . . . . . . . 5 65 5.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 5 66 5.2. New Components . . . . . . . . . . . . . . . . . . . . . 6 67 5.3. Support for Algorithm Agility . . . . . . . . . . . . . . 7 68 5.4. Impact on RFC3315 . . . . . . . . . . . . . . . . . . . . 7 69 5.5. Applicability . . . . . . . . . . . . . . . . . . . . . . 8 70 6. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . 8 71 7. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . 11 72 8. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 13 73 9. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 13 74 9.1. Increasing Number Check . . . . . . . . . . . . . . . . . 13 75 10. Extensions for Secure DHCPv6 . . . . . . . . . . . . . . . . 14 76 10.1. New DHCPv6 Options . . . . . . . . . . . . . . . . . . . 14 77 10.1.1. Algorithm Option . . . . . . . . . . . . . . . . . . 14 78 10.1.2. Certificate Option . . . . . . . . . . . . . . . . . 17 79 10.1.3. Signature option . . . . . . . . . . . . . . . . . . 18 80 10.1.4. Increasing-number Option . . . . . . . . . . . . . . 19 81 10.1.5. Encryption-Key-Tag Option . . . . . . . . . . . . . 20 82 10.1.6. Encrypted-message Option . . . . . . . . . . . . . . 20 83 10.2. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . 21 84 10.3. Status Codes . . . . . . . . . . . . . . . . . . . . . . 22 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 86 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 87 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 88 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 89 14.1. Normative References . . . . . . . . . . . . . . . . . . 25 90 14.2. Informative References . . . . . . . . . . . . . . . . . 26 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 93 1. Introduction 95 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6, [RFC3315]) 96 allows DHCPv6 servers to flexibly provide addressing and other 97 configuration information relating to local network infrastructure to 98 DHCP clients. The protocol provides no deployable security 99 mechanism, and consequently is vulnerable to various attacks. 101 This document provides a brief summary of the security 102 vulnerabilities of the DHCPv6 protocol and then describes a new 103 extension to the protocol that provides two additional types of 104 security: 106 o authentication of the DHCPv6 client and the DHCPv6 server to 107 defend against active attacks, such as spoofing. 109 o encryption between the DHCPv6 client and the DHCPv6 server in 110 order to protect the DHCPv6 communication from pervasive 111 monitoring. 113 The extension specified in this document applies only to end-to-end 114 communication between DHCP servers and clients. Options added by 115 relay agents in Relay-Forward messages, and options other than the 116 client message in Relay-Reply messages sent by DHCP servers, are not 117 protected. Such communications are already protected using the 118 mechanism described in section 21.1 in [RFC3315]. 120 This extension introduces two new DHCPv6 messages: the Encrypted- 121 Query and the Encrypted-Response messages. It defines six new DHCPv6 122 options: the Algorithm, Certificate, Signature, Increasing-number, 123 Encryption-Key-Tag option and Encrypted-message options. The 124 Algorithm, Certificate, Signature, and Increasing-number options are 125 used for authentication. The Encryption-Query message, Encryption- 126 Response message, Encrypted-message option and Encryption-Key-Tag 127 option are used for encryption. 129 2. Requirements Language 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 a DHCPv6 request on a 144 link to obtain DHCPv6 configuration parameters from 145 one or more DHCPv6 servers using the encryption and 146 optional authentication mechanisms defined in this 147 document. 149 secure DHCPv6 server: A DHCPv6 server that implements the 150 authentication and encryption mechanisms defined in 151 this document, and is configured to use them. 153 4. Security Issues of DHCPv6 155 [RFC3315] defines an authentication mechanism with integrity 156 protection. This mechanism uses a symmetric key that is shared by 157 the client and server for authentication. It does not provide any 158 key distribution mechanism. 160 For this approach, operators can set up a key database for both 161 servers and clients from which the client obtains a key before 162 running DHCPv6. However, manual key distribution runs counter to the 163 goal of minimizing the configuration data needed at each host. 164 Consequently, there are no known deployments of this security 165 mechanism. 167 [RFC3315] provides an additional mechanism for preventing off-network 168 timing attacks using the Reconfigure message: the Reconfigure Key 169 authentication method. However, this method protects only the 170 Reconfigure message. The key is transmitted in plaintext to the 171 client in earlier exchanges and so this method is vulnerable to on- 172 path active attacks. 174 Anonymity Profile for DHCP Clients [RFC7844] explains how to generate 175 DHCPv4 or DHCPv6 requests that minimize the disclosure of identifying 176 information. However, the anonymity profile limits the use of the 177 certain options. It also cannot anticipate new options that may 178 contain private information. In addition, the anonymity profile does 179 not work in cases where the client wants to maintain anonymity from 180 eavesdroppers but must identify itself to the DHCP server with which 181 it intends to communicate. 183 Privacy consideration for DHCPv6 [RFC7824] presents an analysis of 184 the privacy issues associated with the use of DHCPv6 by Internet 185 users. No solutions are presented. 187 Current DHCPv6 messages are still transmitted in cleartext and the 188 privacy information within the DHCPv6 message is not protected from 189 passive attack, such as pervasive monitoring [RFC7258]. The privacy 190 information of the IPv6 host, such as DUID, may be gleaned to find 191 location information, previous visited networks and so on. [RFC7258] 192 claims that pervasive monitoring should be mitigated in the design of 193 IETF protocol, where possible. 195 To better address the problem of passive monitoring and to achieve 196 authentication without requiring a symmetric key distribution 197 solution for DHCP, this document defines an asymmetric key 198 authentication and encryption mechanism. This protects against both 199 active attacks, such as spoofing, and passive attacks, such as 200 pervasive monitoring. 202 5. Secure DHCPv6 Overview 204 5.1. Solution Overview 206 The following figure illustrates the secure DHCPv6 procedure. 207 Briefly, this extension establishes the server's identity with an 208 anonymous Information-Request exchange. Once the server's identity 209 has been established, the client may either choose to communicate 210 with the server or not. Not communicating with an unknown server 211 avoids revealing private information, but if there is no known server 212 on a particular link, the client will be unable to communicate with a 213 DHCP server. 215 If the client chooses to communicate with the selected server(s), it 216 uses the Encrypted-Query message to encapsulate its communications to 217 the DHCP server. The server responds with Encrypted-Response 218 messages. Normal DHCP messages are encapsulated in these two new 219 messages using the new defined Encrypted-message option. Besides the 220 Encrypted-message option, the Signature option is defined to verify 221 the integrity of the DHCPv6 messages and then authentication of the 222 client and the server. The Increasing number option is defined to 223 detect a replay attack. 225 +-------------+ +-------------+ 226 |DHCPv6 Client| |DHCPv6 Server| 227 +-------------+ +-------------+ 228 | Information-request | 229 |----------------------------------------->| 230 | Algorithm option | 231 | Option Request option | 232 | | 233 | Reply | 234 |<-----------------------------------------| 235 | Certificate option | 236 | Signature option | 237 | Increasing-number option | 238 | Server Identifier option | 239 | | 240 | Encryption-Query | 241 |----------------------------------------->| 242 | Encrypted-message option | 243 | Server Identifier option | 244 | Encryption-Key-Tag option | 245 | | 246 | Encryption-Response | 247 |<-----------------------------------------| 248 | Encrypted-message option | 249 | | 251 Figure 1: Secure DHCPv6 Procedure 253 5.2. New Components 255 The new components of the mechanism specified in this document are as 256 follows: 258 o Servers and clients that use certificates first generate a public/ 259 private key pair and then obtain a certificate that signs the 260 public key. The Certificate option is defined to carry the 261 certificate of the sender. 263 o The algorithm option is defined to carry the algorithms lists for 264 algorithm agility. 266 o The signature is generated using the private key to verify the 267 integrity of the DHCPv6 messages. The Signature option is defined 268 to carry the signature. 270 o The increasing number is used to detect replayed packet. The 271 Increasing-number option is defined to carry a strictly-increasing 272 serial number. 274 o The encryption key Tag is calculated from the public key data. 275 The Encryption-Key-Tag option is defined to identify the used 276 public/private key pair. 278 o The Encrypted-message option is defined to contain the encrypted 279 DHCPv6 message. 281 o The Encrypted-Query message is sent from the secure DHCPv6 client 282 to the secure DHCPv6 server. The Encrypted-Query message MUST 283 contain the Encrypted-message option and Encryption-Key-Tag 284 option. In addition, the Server Identifier option MUST be 285 included if it is contained in the original DHCPv6 message. The 286 Encrypted-Query message MUST NOT contain any other options. 288 o The Encrypted-Response message is sent from the secure DHCPv6 289 server to the secure DHCPv6 client. The Encrypted-Response 290 message MUST contain the Encrypted-message option. The Encrypted- 291 Response message MUST NOT contain any other options. 293 5.3. Support for Algorithm Agility 295 In order to provide a means of addressing problems that may emerge 296 with existing hash algorithms, signature algorithm and encryption 297 algorithms in the future, this document provides a mechanism to 298 support algorithm agility. The support for algorithm agility in this 299 document is mainly a algorithm notification mechanism between the 300 client and the server. The same client and server SHOULD use the 301 same algorithm in a single communication session. The sender can 302 offer a set of algorithms, and then the receiver selects one 303 algorithm for the future communication. 305 5.4. Impact on RFC3315 307 For secure DHCPv6, the Solicit and Rebind messages can be sent only 308 to the selected server(s) which share one common certificate. If the 309 client doesn't like the received Advertise(s) it could restart the 310 whole process and selects another certificate, but it will be more 311 expensive, and there's no guarantee that other servers can provide 312 better Advertise(s). 314 [RFC3315] provides an additional mechanism for preventing off-network 315 timing attacks using the Reconfigure message: the Reconfigure Key 316 authentication method. Secure DHCPv6 can protect the Reconfigure 317 message using the encryption method. So the Reconfigure Key 318 authentication method SHOULD NOT be used if Secure DHCPv6 is applied. 320 5.5. Applicability 322 In principle, secure DHCPv6 is applicable in any environment where 323 physical security on the link is not assured and attacks on DHCPv6 324 are a concern. In practice, however, authenticated and encrypted 325 DHCPv6 configuration will rely on some operational assumptions mainly 326 regarding public key distribution and management. In order to 327 achieve the wider use of secure DHCPv6, opportunistic security 328 [RFC7435] can be applied to secure DHCPv6 deployment, which allows 329 DHCPv6 encryption in environments where support for authentication or 330 a key distribution mechanism is not available. 332 Secure DHCPv6 can achieve authentication and encryption based on pre- 333 sharing of authorized certificates. The One feasible environment in 334 an early deployment stage would be enterprise networks. In 335 enterprise networks, the client is manually pre-configured with the 336 trusted servers' public key and the server is also manually pre- 337 configured with the trusted clients' public keys. In some scenario, 338 such as coffee shop where the certificate cannot be validated and one 339 wants access to the Internet, then the DHCPv6 configuration process 340 can be encrypted without authentication. 342 Note that this deployment scenario based on manual operation is not 343 much different from the existing, shared-secret based authentication 344 mechanisms defined in [RFC3315] in terms of operational costs. 345 However, Secure DHCPv6 is still securer than the shared-secret 346 mechanism in that even if clients' keys stored for the server are 347 stolen that does not mean an immediate threat as these are public 348 keys. In addition, if some kind of Public Key Infrastructure (PKI) 349 is used with Secure DHCPv6, even if the initial installation of the 350 certificates is done manually, it will help reduce operational costs 351 of revocation in case a private key (especially that of the server) 352 is compromised. 354 6. DHCPv6 Client Behavior 356 The secure DHCPv6 client is pre-configured with a certificate and its 357 corresponding private key for client authentication. If the client 358 does not obtain a certificate from Certificate Authority (CA), it can 359 generate the self-signed certificate. 361 The secure DHCPv6 client sends an Information-request message as per 362 [RFC3315]. The Information-request message is used by the DHCPv6 363 client to request the server's certificate information without having 364 addresses, prefixes or any non-security options assigned to it. The 365 contained Option Request option MUST carry the option code of the 366 Certificate option. In addition, the contained Algorithm option MUST 367 be constructed as explained in Section 10.1.1. The Information- 368 request message MUST NOT include any other DHCPv6 options except the 369 above options to minimize the client's privacy information leakage. 371 When receiving the Reply messages from the DHCPv6 servers, a secure 372 DHCPv6 client discards any DHCPv6 message that meets any of the 373 following conditions: 375 o the Signature option is missing, 377 o multiple Signature options are present, 379 o the Certificate option is missing. 381 And then the client first checks acknowledged hash, signature and 382 encryption algorithms that the server supports. If the hash 383 algorithm field is zero, then it indicates that the hash algorithm is 384 fixed according to the corresponding signature algorithm. The client 385 also uses the acknowledged algorithms in the return messages. 387 Then the client checks the authority of the server. In some scenario 388 where non-authenticated encryption can be accepted, such as coffee 389 shop, then authentication is optional and can be skipped. For the 390 certificate check method, the client validates the certificates 391 through the pre-configured local trusted certificates list or other 392 methods. A certificate that finds a match in the local trust 393 certificates list is treated as verified. If the certificate check 394 fails, the Reply message is dropped. 396 The client MUST now authenticate the server by verifying the 397 signature and checking increasing number, if there is a Increasing- 398 number option. The order of two procedures is left as an 399 implementation decision. It is RECOMMENDED to check increasing 400 number first, because signature verification is much more 401 computationally expensive. The client checks the Increasing-number 402 option according to the rule defined in Section 9.1. For the message 403 without an Increasing-number option, according to the client's local 404 policy, it MAY be acceptable or rejected. The Signature field 405 verification MUST show that the signature has been calculated as 406 specified in Section 10.1.3. Only the messages that get through both 407 the signature verification and increasing number check (if there is a 408 Increasing-number option) are accepted. Reply message that does not 409 pass the above tests MUST be discarded. 411 If there are multiple authenticated DHCPv6 certs, the client selects 412 one DHCPv6 cert for the following communication. The selected 413 certificate may correspond to multiple DHCPv6 servers. If there are 414 no authenticated DHCPv6 certs or existing servers fail 415 authentication, the client should retry a number of times. The 416 client conducts the server discovery process as per section 18.1.5 of 417 [RFC3315] to avoid a packet storm. In this way, it is difficult for 418 a rogue server to beat out a busy "real" server. And then the client 419 takes some alternative action depending on its local policy, such as 420 attempting to use an unsecured DHCPv6 server. 422 Once the server has been authenticated, the DHCPv6 client sends the 423 Encrypted-Query message to the DHCPv6 server. The Encrypted-Query 424 message contains the Encrypted-message option, which MUST be 425 constructed as explained in Section 10.1.6. The Encrypted-message 426 option contains the encrypted DHCPv6 message using the public key 427 contained in the selected cert. In addition, the Server Identifier 428 option MUST be included if it is in the original message (i.e. 429 Request, Renew, Decline, Release) to avoid the need for other servers 430 receiving the message to attempt to decrypt it. The Encrypted-Query 431 message MUST include the Encryption-Key-Tag option to identify the 432 used public/private key pair, which is constructed as explained in 433 Section 10.1.5. The Encrypted-Query message MUST NOT contain any 434 other DHCPv6 option except the Server Identifier option, Encryption- 435 Key-Tag option, Encrypted-Message option. 437 The first DHCPv6 message sent from the client to the server, such as 438 Solicit message, MUST contain the Certificate option, Signature 439 option and Increasing-number option for client authentication. The 440 encryption text SHOULD be formatted as explain in [RFC5652]. The 441 Certificate option MUST be constructed as explained in 442 Section 10.1.2. In addition, one and only one Signature option MUST 443 be contained, which MUST be constructed as explained in 444 Section 10.1.3. One and only one Increasing-number option SHOULD be 445 contained, which MUST be constructed as explained in Section 10.1.4. 446 In addition, the subsequent encrypted DHCPv6 message sent from the 447 client can also contain the Increasing-number option to defend 448 against replay attack. 450 For the received Encrypted-Response message, the client MUST drop the 451 Encrypted-Response message if other DHCPv6 option except Encrypted- 452 message option is contained. Then, the client extracts the 453 Encrypted-message option and decrypts it using its private key to 454 obtain the original DHCPv6 message. In this document, it is assumed 455 that the client uses only one certificate for the encrypted DHCPv6 456 configuration. So, the corresponding private key is used for 457 decryption. After the decryption, it handles the message as per 458 [RFC3315]. If the decrypted DHCPv6 message contains the Increasing- 459 number option, the DHCPv6 client checks it according to the rule 460 defined in Section 9.1. 462 If the client fails to get the proper parameters from the chosen 463 server(s), it can select another authenticated certificate and send 464 the Encrypted-Query message to another authenticated server(s) for 465 parameters configuration until the client obtains the proper 466 parameters. 468 When the decrypted message is Reply message with an error status 469 code, the error status code indicates the failure reason on the 470 server side. According to the received status code, the client MAY 471 take follow-up action: 473 o Upon receiving an AuthenticationFail error status code, the client 474 is not able to build up the secure communication with the server. 475 However, there may be other DHCPv6 servers available that 476 successfully complete authentication. The client MAY use the 477 AuthenticationFail as a hint and switch to other DHCPv6 server if 478 it has another one. The client SHOULD retry with another 479 authenticated certificate. However, if the client decides to 480 retransmit using the same certificate after receiving 481 AuthenticationFail, it MUST NOT retransmit immediately and MUST 482 follow normal retransmission routines defined in [RFC3315]. 484 o Upon receiving a ReplayDetected error status code, the client MAY 485 resend the message with an adjusted Increasing-number option 486 according to the returned number from the DHCPv6 server. 488 o Upon receiving a SignatureFail error status code, the client MAY 489 resend the message following normal retransmission routines 490 defined in [RFC3315]. 492 7. DHCPv6 Server Behavior 494 The secure DHCPv6 server is pre-configured with a certificate and its 495 corresponding private key for server authentication. If the server 496 does not obtain the certificate from Certificate Authority (CA), it 497 can generate the self-signed certificate. 499 When the DHCPv6 server receives the Information-request message and 500 the contained Option Request option identifies the request is for the 501 server's certificate information, it SHOULD first check the hash, 502 signature, encryption algorithms sets that the client supports. The 503 server selects one hash, signature, encryption algorithm from the 504 acknowledged algorithms sets for the future communication. And then, 505 the server replies with a Reply message to the client. The Reply 506 message MUST contain the requested Certificate option, which MUST be 507 constructed as explained in Section 10.1.2, and Server Identifier 508 option. In addition, the Reply message MUST contain one and only one 509 Signature option, which MUST be constructed as explained in 510 Section 10.1.3. Besides, the Reply message SHOULD contain one and 511 only one Increasing-number option, which MUST be constructed as 512 explained in Section 10.1.4. 514 Upon the receipt of Encrypted-Query message, the server MUST drop the 515 message if the other DHCPv6 option is contained except Server 516 Identifier option, Encryption-Key-Tag option, Encrypted-message 517 option. Then, the server checks the Server Identifier option. The 518 DHCPv6 server drops the message that is not for it, thus not paying 519 cost to decrypt messages. If it is the target server, according to 520 the Encryption-Key-Tag option, the server identifies the used public/ 521 private key pair and decrypts the Encrypted-message option using the 522 corresponding private key. If the decryption fails, the server 523 discards the received message. 525 If secure DHCPv6 server needs client authentication and decrypted 526 message is a Solicit/Information-request message which contains the 527 information for client authentication, the secure DHCPv6 server 528 discards the received message that meets any of the following 529 conditions: 531 o the Signature option is missing, 533 o multiple Signature options are present, 535 o the Certificate option is missing. 537 For the signature failure, the server SHOULD send an encrypted Reply 538 message with an UnspecFail (value 1, [RFC3315]) error status code to 539 the client. 541 The server validates the client's certificate through the local pre- 542 configured trusted certificates list. A certificate that finds a 543 match in the local trust certificates list is treated as verified. 544 The message that fails authentication validation MUST be dropped. In 545 such failure, the DHCPv6 server replies with an encrypted Reply 546 message with an AuthenticationFail error status code, defined in 547 Section 10.3, back to the client. At this point, the server has 548 either recognized the authentication of the client, or decided to 549 drop the message. 551 If the decrypted message contains the Increasing-number option, the 552 server checks it according to the rule defined in Section 9.1. If 553 the check fails, an encrypted Reply message with a ReplayDetected 554 error status code, defined in Section 10.3, should be sent back to 555 the client. In the Reply message, a Increasing-number option is 556 carried to indicate the server's stored number for the client to use. 557 According to the server's local policy, the message without an 558 Increasing-number option MAY be acceptable or rejected. 560 The Signature field verification MUST show that the signature has 561 been calculated as specified in Section 10.1.3. If the signature 562 check fails, the DHCPv6 server SHOULD send an encrypted Reply message 563 with a SignatureFail error status code. Only the clients that get 564 through both the signature verification and increasing number check 565 (if there is a Increasing-number option) are accepted as 566 authenticated clients and continue to be handled their message as 567 defined in [RFC3315]. 569 Once the client has been authenticated, the DHCPv6 server sends the 570 Encrypted-response message to the DHCPv6 client. The Encrypted- 571 response message MUST only contain the Encrypted-message option, 572 which MUST be constructed as explained in Section 10.1.6. The 573 encryption text SHOULD be formatted as explain in [RFC5652]. The 574 Encrypted-message option contains the encrypted DHCPv6 message that 575 is encrypted using the authenticated client's public key. To provide 576 the replay protection, the Increasing-number option can be contained 577 in the encrypted DHCPv6 message. 579 8. Relay Agent Behavior 581 When a DHCPv6 relay agent receives an Encrypted-query or Encrypted- 582 response message, it may not recognize this message. The unknown 583 messages MUST be forwarded as described in [RFC7283]. 585 When a DHCPv6 relay agent recognizes the Encrypted-query and 586 Encrypted-response messages, it forwards the message according to 587 section 20 of [RFC3315]. There is nothing more the relay agents have 588 to do, it neither needs to verify the messages from client or server, 589 nor add any secure DHCPv6 options. Actually, by definition in this 590 document, relay agents MUST NOT add any secure DHCPv6 options. 592 Relay-forward and Relay-reply messages MUST NOT contain any 593 additional Certificate option or Increasing-number option, aside from 594 those present in the innermost encapsulated messages from the client 595 or server. 597 9. Processing Rules 599 9.1. Increasing Number Check 601 In order to check the Increasing-number option, defined in 602 Section 10.1.4, the client/server has one stable stored number for 603 replay attack detection. The server should keep a record of the 604 increasing number forever. And the client keeps a record of the 605 increasing number during the DHCPv6 configuration process with the 606 DHCPv6 server. And the client can forget the increasing number 607 information after the transaction is finished. The client's initial 608 locally stored increasing number is zero. 610 It is essential to remember that the increasing number is finite. 611 All arithmetic dealing with sequence numbers must be performed modulo 612 2^64. This unsigned arithmetic preserves the relationship of 613 sequence numbers as they cycle from 2^64 - 1 to 0 again. 615 In order to check the Increasing-number option, the following 616 comparison is needed. 618 NUM.STO = the stored number in the client/server 620 NUM.REC = the acknowledged number from the received message 622 The Increasing-number option in the received message passes the 623 increasing number check if NUM.REC is more than NUM.STO. And then, 624 the value of NUM.STO is changed into the value of NUM.REC. 626 The increasing number check fails if NUM.REC is equal with or less 627 than NUM.STO 629 It is should be noted that 631 10. Extensions for Secure DHCPv6 633 This section describes the extensions to DHCPv6. Six new DHCPv6 634 options, two new DHCPv6 messages and six new status codes are 635 defined. 637 10.1. New DHCPv6 Options 639 10.1.1. Algorithm Option 641 The Algorithm option carries the algorithms sets for algorithm 642 agility, which is contained in the Information-request message. 644 0 1 2 3 645 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 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | OPTION_ALGORITHM | option-len | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 . EA-id List . 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 . SA-id List . 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 . HA-id List . 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 Figure 2: Algorithm Option 658 o option-code: OPTION_ALGORITHM (TBA1). 660 o option-len: length of EA-id List + length of SA-id List + length 661 of HA-id List in octets. 663 o EA-id: The format of the EA-id List field is shown in Figure 3. 665 0 1 2 3 666 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 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | EA-len | EA-id | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 . ... . 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | EA-id | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 EA-len The length of the following EA-ids. 677 EA-id 2-octets value to indicate the Encryption Algorithm id. 678 The client enumerates the list of encryption algorithms it 679 supports to the server. The encryption algorithm is used 680 for the encrypted DHCPv6 configuration process. This design 681 is adopted in order to provide encryption algorithm agility. 682 The value is from the Encryption Algorithm for Secure DHCPv6 683 registry in IANA. A registry of the initial assigned values 684 is defined in Section 12. The mandatory encryption 685 algorithms MUST be included. 687 Figure 3: EA-id List Field 689 o SA-id List: The format of the SA-id List field is shown in 690 Figure 4. 692 0 1 2 3 693 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 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | SA-len | SA-id | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 . ... . 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | SA-id | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 SA-len The length of the following SA-ids. 704 SA-id 2-octets value to indicate the Signature Algorithm id. 705 The client enumerates the list of signature algorithms it 706 supports to the server. This design is adopted in 707 order to provide signature algorithm agility. The 708 value is from the Signature Algorithm for Secure 709 DHCPv6 registry in IANA. The support of RSASSA-PKCS1-v1_5 710 is mandatory. A registry of the initial assigned 711 values is defined in Section 12. The mandatory 712 signature algorithms MUST be included. 714 Figure 4: SA-id List Field 716 o HA-id List: The format of the HA-id List field is shown in 717 Figure 5. 719 0 1 2 3 720 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 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | HA-len | HA-id | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 . ... . 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | HA-id | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 HA-len The length of the following HA-ids. 731 HA-id 2-octets value to indicate the Hash Algorithm id. 732 The client enumerates the list of hash algorithms it 733 supports to the server. This design is adopted in order to 734 provide hash algorithm agility. The value is from the 735 Hash Algorithm for Secure DHCPv6 registry in IANA. The 736 support of SHA-256 is mandatory. A registry of the 737 initial assigned values is defined in Section 12. 738 The mandatory hash algorithms MUST be included. 740 Figure 5: HA-id List Field 742 10.1.2. Certificate Option 744 The Certificate option carries the certificate of the client/server, 745 which is contained in the Reply message. The format of the 746 Certificate option is described as follows: 748 0 1 2 3 749 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 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | OPTION_CERTIFICATE | option-len | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | EA-id | SA-id | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | | 756 . Certificate . 757 | | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 Figure 6: Certificate Option 762 o option-code: OPTION_CERTIFICATE (TBA2). 764 o option-len: 4 + length of Certificate in octets. 766 o EA-id: Encryption Algorithm id which is used for the certificate. 768 o SA-id: Signature Algorithm id which is used for the certificate. 770 o Certificate: A variable-length field containing certificates. The 771 encoding of certificate and certificate data MUST be in format as 772 defined in Section 3.6, [RFC7296]. The support of X.509 773 certificate is mandatory. 775 It should be noticed that the scenario where the values of EA-id and 776 SA-id are both 0 makes no sense and the client MUST discard a message 777 with such values. 779 10.1.3. Signature option 781 The Signature option contains a signature that is signed by the 782 private key to be attached to the Reply message. The Signature 783 option could be in any place within the DHCPv6 message while it is 784 logically created after the entire DHCPv6 header and options. It 785 protects the entire DHCPv6 header and options, including itself. The 786 format of the Signature option is described as follows: 788 0 1 2 3 789 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 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | OPTION_SIGNATURE | option-len | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | SA-id | HA-id | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | | 796 . Signature (variable length) . 797 . . 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 Figure 7: Signature Option 802 o option-code: OPTION_SIGNATURE (TBA3). 804 o option-len: 4 + length of Signature field in octets. 806 o SA-id: Signature Algorithm id. The signature algorithm is used 807 for computing the signature result. This design is adopted in 808 order to provide signature algorithm agility. The value is from 809 the Signature Algorithm for Secure DHCPv6 registry in IANA. The 810 support of RSASSA-PKCS1-v1_5 is mandatory. A registry of the 811 initial assigned values is defined in Section 12. 813 o HA-id: Hash Algorithm id. The hash algorithm is used for 814 computing the signature result. This design is adopted in order 815 to provide hash algorithm agility. The value is from the Hash 816 Algorithm for Secure DHCPv6 registry in IANA. The support of 817 SHA-256 is mandatory. A registry of the initial assigned values 818 is defined in Section 12. If the hash algorithm is fixed 819 according to the corresponding signature algorithm, the HA-id 820 field is set to zero. 822 o Signature: A variable-length field containing a digital signature. 823 The signature value is computed with the hash algorithm and the 824 signature algorithm, as described in HA-id and SA-id. The 825 Signature field MUST be padded, with all 0, to the next octet 826 boundary if its size is not a multiple of 8 bits. The padding 827 length depends on the signature algorithm, which is indicated in 828 the SA-id field. 830 Note: If Secure DHCPv6 is used, the DHCPv6 message is encrypted in a 831 way that the authentication mechanism defined in RFC3315 does not 832 understand. So the Authentication option SHOULD NOT be used if 833 Secure DHCPv6 is applied. 835 10.1.4. Increasing-number Option 837 The Increasing-number option carries the strictly increasing number 838 for anti-replay protection, which is contained in the Reply message 839 and the encrypted DHCPv6 message. It is optional. 841 0 1 2 3 842 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 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | OPTION_INCREASING_NUM | option-len | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | | 847 | Increasing-Num (64-bit) | 848 | | 849 | | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 option-code OPTION_INCREASING_NUM (TBA4). 854 option-len 8, in octets. 856 Increasing-Num A strictly increasing number for the replay attack detection 857 which is more than the local stored number. 859 Figure 8: Increasing-number Option 861 10.1.5. Encryption-Key-Tag Option 863 The Encryption-Key-Tag option carries the key identifier which is 864 calculated from the public key data. The Encrypted-Query message 865 MUST contain the Encryption-Key-Tag option to identify the used 866 public/private key pair. 868 0 1 2 3 869 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 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | OPTION_ENCRYPTION_KEY_TAG | option-len | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | | 874 . encryption key tag . 875 . (variable) . 876 . . 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 Figure 9: Encryption-Key-Tag Option 881 option-code OPTION_ENCRYPTION_KEY_TAG (TBA5). 883 option-len Length of the encryption key tag. 885 encryption key tag A variable length field containing the encryption 886 key tag sent from the client to server to identify the used 887 public/private key pair. The encryption key tag is calculated 888 from the public key data, like fingerprint of a specific public 889 key. How to generate the encryption key tag adopts the method 890 define in Appendix B in [RFC4034] and section 5.5 in [RFC6840]. 891 The data of the public key is used as input of the generation 892 function. 894 10.1.6. Encrypted-message Option 896 The Encrypted-message option carries the encrypted DHCPv6 message, 897 which is calculated with the recipient's public key. The Encrypted- 898 message option is contained in the Encrypted-Query message or the 899 Encrypted-Response message. 901 The format of the Encrypted-message option is: 903 0 1 2 3 904 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 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | option-code | option-len | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | | 909 . encrypted DHCPv6 message . 910 . (variable) . 911 . . 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 Figure 10: Encrypted-message Option 916 option-code OPTION_ENCRYPTED_MSG (TBA6). 918 option-len Length of the encrypted DHCPv6 message. 920 encrypted DHCPv6 message A variable length field containing the 921 encrypted DHCPv6 message. In Encrypted-Query message, it contains 922 encrypted DHCPv6 message sent from a client to server. In 923 Encrypted-response message, it contains encrypted DHCPv6 message 924 sent from a server to client. 926 10.2. New DHCPv6 Messages 928 Two new DHCPv6 messages are defined to achieve the DHCPv6 encryption: 929 Encrypted-Query and Encrypted-Response. Both the DHCPv6 messages 930 defined in this document share the following format: 932 0 1 2 3 933 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 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | msg-type | transaction-id | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | | 938 . options . 939 . (variable) . 940 | | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 Figure 11: The format of Encrypted-Query and Encrypted-Response 944 Messages 946 msg-type Identifier of the message type. It can be either 947 Encrypted-Query (TBA7) or DHCPv6-Response (TBA8). 949 transaction-id The transaction ID for this message exchange. 951 options The Encrypted-Query message MUST contain the 952 Encrypted-message option, Encryption-Key-Tag option 953 and Server Identifier option if the message in the 954 Encrypted-message option has a Server Identifier 955 option. The Encrypted-Response message MUST only 956 contain the Encrypted-message option. 958 10.3. Status Codes 960 The following new status codes, see Section 5.4 of [RFC3315] are 961 defined. 963 o AuthenticationFail (TBD9): indicates that the message from the 964 DHCPv6 client fails authentication check. 966 o ReplayDetected (TBD10): indicates the message from DHCPv6 client 967 fails the increasing number check. 969 o SignatureFail (TBD11): indicates the message from DHCPv6 client 970 fails the signature check. 972 11. Security Considerations 974 This document provides the authentication and encryption mechanisms 975 for DHCPv6. 977 [RFC6273] has analyzed possible threats to the hash algorithms used 978 in SEND. Since Secure DHCPv6 defined in this document uses the same 979 hash algorithms in similar way to SEND, analysis results could be 980 applied as well: current attacks on hash functions do not constitute 981 any practical threat to the digital signatures used in the signature 982 algorithm in Secure DHCPv6. 984 There are some mandatory algorithm for encryption algorithm in this 985 document. It may be at some point that the mandatory algorithm is no 986 longer safe to use. 988 A server or a client, whose local policy accepts messages without a 989 Increasing-number option, may have to face the risk of replay 990 attacks. 992 If the client tries more than one cert for client authentication, the 993 server can easily get a client that implements this to enumerate its 994 entire cert list and probably learn a lot about a client that way. 995 For this security item, It is RECOMMENDED that client certificates 996 could be tied to specific server certificates by configuration. 998 12. IANA Considerations 1000 This document defines six new DHCPv6 [RFC3315] options. The IANA is 1001 requested to assign values for these six options from the DHCPv6 1002 Option Codes table of the DHCPv6 Parameters registry maintained in 1003 http://www.iana.org/assignments/dhcpv6-parameters. The six options 1004 are: 1006 The Algorithm Option (TBA1), described in Section 10.1.2. 1008 The Certificate Option (TBA2), described in Section 10.1.2. 1010 The Signature Option (TBA3), described in Section 10.1.3. 1012 The Increasing-number Option (TBA4),described in Section 10.1.4. 1014 The Encryption-Key-Tag Option (TBA5),described in Section 10.1.5. 1016 The Encrypted-message Option (TBA6), described in Section 10.1.6. 1018 The IANA is also requested to assign value for these two messages 1019 from the DHCPv6 Message Types table of the DHCPv6 Parameters registry 1020 maintained in http://www.iana.org/assignments/dhcpv6-parameters. The 1021 two messages are: 1023 The Encrypted-Query Message (TBA7), described in Section 10.2. 1025 The Encrypted-Response Message (TBA8), described in Section 10.2. 1027 The IANA is also requested to add three new registry tables to the 1028 DHCPv6 Parameters registry maintained in 1029 http://www.iana.org/assignments/dhcpv6-parameters. The three tables 1030 are the Hash Algorithm for Secure DHCPv6 table, the Signature 1031 Algorithm for Secure DHCPv6 table and the Encryption Algorithm for 1032 Secure DHCPv6 table. 1034 Initial values for these registries are given below. Future 1035 assignments are to be made through Standards Action [RFC5226]. 1036 Assignments for each registry consist of a name, a value and a RFC 1037 number where the registry is defined. 1039 Hash Algorithm for Secure DHCPv6. The values in this table are 8-bit 1040 unsigned integers. The following initial values are assigned for 1041 Hash Algorithm for Secure DHCPv6 in this document: 1043 Name | Value | RFCs 1044 -------------------+---------+-------------- 1045 SigAlg-Combined | ox00 | this document 1046 SHA-256 | 0x01 | this document 1047 SHA-512 | 0x02 | this document 1049 Signature Algorithm for Secure DHCPv6. The values in this table are 1050 8-bit unsigned integers. The following initial values are assigned 1051 for Signature Algorithm for Secure DHCPv6 in this document: 1053 Name | Value | RFCs 1054 -------------------+---------+-------------- 1055 Non-SigAlg | 0x00 | this document 1056 RSASSA-PKCS1-v1_5 | 0x01 | this document 1058 Encryption algorithm for Secure DHCPv6. The values in this table are 1059 8-bit unsigned integers. The following initial values are assigned 1060 for encryption algorithm for Secure DHCPv6 in this document: 1062 Name | Value | RFCs 1063 -------------------+---------+-------------- 1064 Non-EncryAlg | 0x00 | this document 1065 RSA | 0x01 | this document 1067 IANA is requested to assign the following new DHCPv6 Status Codes, 1068 defined in Section 10.3, in the DHCPv6 Parameters registry maintained 1069 in http://www.iana.org/assignments/dhcpv6-parameters: 1071 Code | Name | Reference 1072 ---------+-----------------------+-------------- 1073 TBD9 | AuthenticationFail | this document 1074 TBD10 | ReplayDetected | this document 1075 TBD11 | SignatureFail | this document 1077 13. Acknowledgements 1079 The authors would like to thank Tomek Mrugalski, Bernie Volz, 1080 Jianping Wu, Randy Bush, Yiu Lee, Sean Shen, Ralph Droms, Jari Arkko, 1081 Sean Turner, Stephen Farrell, Christian Huitema, Stephen Kent, Thomas 1082 Huth, David Schumacher, Francis Dupont, Gang Chen, Suresh Krishnan, 1083 Fred Templin, Robert Elz, Nico Williams, Erik Kline, Alan DeKok, 1084 Bernard Aboba, Sam Hartman, Zilong Liu and other members of the IETF 1085 DHC working group for their valuable comments. 1087 This document was produced using the xml2rfc tool [RFC2629]. 1089 14. References 1091 14.1. Normative References 1093 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1094 Requirement Levels", BCP 14, RFC 2119, 1095 DOI 10.17487/RFC2119, March 1997, 1096 . 1098 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1099 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1100 December 1998, . 1102 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1103 C., and M. Carney, "Dynamic Host Configuration Protocol 1104 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1105 2003, . 1107 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1108 "SEcure Neighbor Discovery (SEND)", RFC 3971, 1109 DOI 10.17487/RFC3971, March 2005, 1110 . 1112 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1113 Rose, "Resource Records for the DNS Security Extensions", 1114 RFC 4034, DOI 10.17487/RFC4034, March 2005, 1115 . 1117 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1118 Control Message Protocol (ICMPv6) for the Internet 1119 Protocol Version 6 (IPv6) Specification", RFC 4443, 1120 DOI 10.17487/RFC4443, March 2006, 1121 . 1123 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1124 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1125 . 1127 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1128 "Network Time Protocol Version 4: Protocol and Algorithms 1129 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1130 . 1132 [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and 1133 Implementation Notes for DNS Security (DNSSEC)", RFC 6840, 1134 DOI 10.17487/RFC6840, February 2013, 1135 . 1137 [RFC7283] Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6 1138 Messages", RFC 7283, DOI 10.17487/RFC7283, July 2014, 1139 . 1141 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1142 Kivinen, "Internet Key Exchange Protocol Version 2 1143 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1144 2014, . 1146 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 1147 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 1148 December 2014, . 1150 [RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy 1151 Considerations for DHCPv6", RFC 7824, 1152 DOI 10.17487/RFC7824, May 2016, 1153 . 1155 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 1156 Profiles for DHCP Clients", RFC 7844, 1157 DOI 10.17487/RFC7844, May 2016, 1158 . 1160 14.2. Informative References 1162 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1163 DOI 10.17487/RFC2629, June 1999, 1164 . 1166 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1167 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1168 DOI 10.17487/RFC5226, May 2008, 1169 . 1171 [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure 1172 Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, 1173 DOI 10.17487/RFC6273, June 2011, 1174 . 1176 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1177 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1178 2014, . 1180 [RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1, 1181 PKCS 1", November 2002. 1183 Authors' Addresses 1185 Sheng Jiang 1186 Huawei Technologies Co., Ltd 1187 Q14, Huawei Campus, No.156 Beiqing Road 1188 Hai-Dian District, Beijing, 100095 1189 CN 1191 Email: jiangsheng@huawei.com 1193 Lishan Li 1194 Tsinghua University 1195 Beijing 100084 1196 P.R.China 1198 Phone: +86-15201441862 1199 Email: lilishan48@gmail.com 1201 Yong Cui 1202 Tsinghua University 1203 Beijing 100084 1204 P.R.China 1206 Phone: +86-10-6260-3059 1207 Email: yong@csnet1.cs.tsinghua.edu.cn 1209 Tatuya Jinmei 1210 Infoblox Inc. 1211 3111 Coronado Drive 1212 Santa Clara, CA 1213 US 1215 Email: jinmei@wide.ad.jp 1217 Ted Lemon 1218 Nominum, Inc. 1219 2000 Seaport Blvd 1220 Redwood City, CA 94063 1221 USA 1223 Phone: +1-650-381-6000 1224 Email: Ted.Lemon@nominum.com 1225 Dacheng Zhang 1226 Beijing 1227 CN 1229 Email: dacheng.zhang@gmail.com