idnits 2.17.1 draft-ietf-dhc-sedhcpv6-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (December 10, 2015) is 3058 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 7283 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 2 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: June 12, 2016 Y. Cui 6 Tsinghua University 7 T. Jinmei 8 Infoblox Inc. 9 T. Lemon 10 Nominum, Inc. 11 D. Zhang 12 December 10, 2015 14 Secure DHCPv6 15 draft-ietf-dhc-sedhcpv6-10 17 Abstract 19 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables 20 DHCPv6 servers to pass configuration parameters. It offers 21 configuration flexibility. If not being secured, DHCPv6 is 22 vulnerable to various attacks. This document analyzes the security 23 issues of DHCPv6 and specifies a secure DHCPv6 mechanism for the 24 authentication and encryption between DHCPv6 client and DHCPv6 25 server. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on June 12, 2016. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Requirements Language and Terminology . . . . . . . . . . . . 3 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Security Issues of DHCPv6 . . . . . . . . . . . . . . . . . . 4 65 5. secure DHCPv6 overview . . . . . . . . . . . . . . . . . . . 5 66 5.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 5 67 5.2. New Components . . . . . . . . . . . . . . . . . . . . . 7 68 5.3. Support for Algorithm Agility . . . . . . . . . . . . . . 7 69 5.4. Imposed Additional Constraints . . . . . . . . . . . . . 8 70 5.5. Applicability . . . . . . . . . . . . . . . . . . . . . . 8 71 6. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . 9 72 7. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . 11 73 8. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 13 74 9. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 14 75 9.1. Timestamp Check . . . . . . . . . . . . . . . . . . . . . 14 76 10. Extensions for Secure DHCPv6 . . . . . . . . . . . . . . . . 15 77 10.1. New DHCPv6 Options . . . . . . . . . . . . . . . . . . . 15 78 10.1.1. Certificate Option . . . . . . . . . . . . . . . . . 15 79 10.1.2. Signature Option . . . . . . . . . . . . . . . . . . 16 80 10.1.3. Timestamp Option . . . . . . . . . . . . . . . . . . 17 81 10.1.4. Encrypted-message Option . . . . . . . . . . . . . . 18 82 10.2. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . 19 83 10.2.1. Encrypted-Query Message . . . . . . . . . . . . . . 19 84 10.2.2. Encrypted-Response Message . . . . . . . . . . . . . 19 85 10.3. Status Codes . . . . . . . . . . . . . . . . . . . . . . 20 86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 87 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 88 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 89 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 90 14.1. Normative References . . . . . . . . . . . . . . . . . . 23 91 14.2. Informative References . . . . . . . . . . . . . . . . . 24 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 94 1. Introduction 96 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6, [RFC3315]) 97 enables DHCPv6 servers to pass configuration parameters and offers 98 configuration flexibility. If not being secured, DHCPv6 is 99 vulnerable to various attacks. 101 This document analyzes the security issues of DHCPv6 in details and 102 provides the following mechanisms for improving the security of 103 DHCPv6 between client and server: 105 o the authentication of the DHCPv6 client and the DHCPv6 server to 106 defend against active attack, such as spoofing attack. 108 o the encryption between the DHCPv6 client and the DHCPv6 server in 109 order to protect the DHCPv6 from passive attack, such as pervasive 110 monitoring. 112 o the integrity check of DHCPv6 messages by the recipient of the 113 message based on signature. 115 o anti-replay protection based on timestamps. 117 Note: this secure mechanism in this document does not protect outer 118 options in Relay-Forward and Relay-Reply messages, either added by a 119 relay agent toward a server or added by a server toward a relay 120 agent, because they are only transported within operator networks and 121 considered less vulnerable. Communication between a server and a 122 relay agent, and communications between relay agents, may be secured 123 through the use of IPsec, as described in section 21.1 in [RFC3315]. 125 The security mechanisms specified in this document achieves the 126 DHCPv6 authentication and encryption based on the sender's public key 127 certificate. We introduce two new DHCPv6 messages: Encrypted-Query 128 message and Encrypted-Response message and four new DHCPv6 options: 129 certificate option, signature option, timestamp option and encrypted- 130 message option for the DHCPv6 authentication and encryption. The 131 certificate option is used for the DHCPv6 authentication. It also 132 integrates signature option for the integrity check and timestamps 133 option for anti-replay protection. The Encryption-Query message, 134 Encryption-Response message, and encrypted-message option are used 135 for the DHCPv6 encryption. 137 2. Requirements Language and Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119] when they 142 appear in ALL CAPS. When these words are not in ALL CAPS (such as 143 "should" or "Should"), they have their usual English meanings, and 144 are not to be interpreted as [RFC2119] key words. 146 3. Terminology 148 This section defines terminology specific to secure DHCPv6 used in 149 this document. 151 secure DHCPv6 client: A node that initiates the DHCPv6 request on a 152 link to obtain the DHCPv6 configuration parameters 153 from one or more DHCPv6 servers. The configuration 154 process is authenticated and encrypted using the 155 defined mechanisms in this document. 157 secure DHCPv6 server: A node that responds to requests from clients 158 using the authentication and encryption mechanism 159 defined in this document. 161 4. Security Issues of DHCPv6 163 DHCPv6 is a client/server protocol that provides managed 164 configuration of devices. It enables a DHCPv6 server to 165 automatically configure relevant network parameters on clients. The 166 basic DHCPv6 specification [RFC3315] defines security mechanisms, but 167 they have significant flaws and can be improved 169 The basic DHCPv6 specifications can optionally authenticate the 170 origin of message and validate the integrity of messages using an 171 authentication option with a symmetric key pair. [RFC3315] relies on 172 pre-established secret keys. For any kind of meaningful security, 173 each DHCPv6 client would need to be configured with its own secret 174 key; [RFC3315] provides no mechanism for doing this. 176 For the out of band approach, operators can set up a key database for 177 both servers and clients from which the client obtains a key before 178 running DHCPv6. Manual key distribution runs counter to the goal of 179 minimizing the configuration data needed at each host. 181 [RFC3315] provides an additional mechanism for preventing off-network 182 timing attacks using the Reconfigure message: the Reconfigure Key 183 authentication method. However, this method provides little message 184 integrity or source integrity check, and it protects only the 185 Reconfigure message. This key is transmitted in plaintext. 187 In addition, the current DHCPv6 messages are still transmitted in 188 clear text and the privacy information within the DHCPv6 message is 189 not protected from passive attack, such as pervasive monitoring. The 190 IETF has expressed strong agreement that PM is an attack that needs 191 to be mitigated where possible in [RFC7258]. 193 In comparison, the security mechanism defined in this document 194 provides the authentication and encryption mechanism based on the 195 public key certificates on the client or server. The DHCPv6 196 authentication can protect DHCPv6 from active attack, such as 197 spoofing attack. And the DHCPv6 encryption defends against passive 198 attack, such as pervasive monitoring attack. 200 5. secure DHCPv6 overview 202 5.1. Solution Overview 204 This solution provides the authentication and encryption mechanisms 205 based on the public certificates of the DHCPv6 client and server. 206 Before the standard DHCPv6 configuration process, the Information- 207 request and Reply messages are exchanged to select one authenticated 208 DHCPv6 server. The following DHCPv6 configuration process is 209 encrypted to avoid the privacy disclosure. We introduce two new 210 DHCPv6 messages: Encrypted-Query message, Encrypted-Response message 211 and four new DHCPv6 options: encrypted-message option, certificate 212 option, signature option, timestamp option. Based on the new defined 213 messages and options, the corresponding authentication and encryption 214 mechanisms are proposed. 216 The following figure illustrates the secure DHCPv6 procedure. The 217 DHCPv6 client first sends an Information-request message to the 218 standard multicast address to all DHCPv6 servers. The Information- 219 request message is used to request the servers for server 220 authentication information, without going through any address, prefix 221 or non-security option assignment process. The information-request 222 is sent without client's privacy information, such as client 223 identifier option to minimize information leak and increase client's 224 privacy. When receiving the Information-request message, the server 225 sends the Reply message that contains the server's certificate 226 option, signature option, timestamp option, and server identifier 227 option. Upon the receipt of the Reply message, the DHCPv6 client 228 verifies the server's identity according to the contained server 229 authentication information in Reply message. If there are multiple 230 authenticated DHCPv6 servers, the client selects one authenticated 231 DHCPv6 server for the following DHCPv6 configuration process. If 232 there are no authenticated DHCPv6 servers or existing servers failed 233 authentication, the client behavior is policy specific. Depending on 234 its policy, it can choose to connect repeat the server discovery 235 process after certain delay or attempt to connect to a different 236 network. 238 After the server's authentication, the first DHCPv6 message sent from 239 client to server, such as Solicit message, contains the client's 240 certificate option, signature option and timestamp option for client 241 authentication. The DHCPv6 message sent from client to server is 242 encrypted with the server's public key and encapsulated into the 243 encrypted-message option. The DHCPv6 client sends the Encrypted- 244 Query message to server, which carries the server identifier option 245 and the encrypted-message option. When the DHCPv6 server receives 246 the Encrypted-Query message, it decrypts the message using its 247 private key. If the decrypted message contains the client's 248 certificate option, signature option, timestamp option, the DHCPv6 249 server verifies the client's identity according to the contained 250 client authentication information. After the client's 251 authentication, the server sends the Encrypted-Response message to 252 the client, which contains the encrypted-message option. The 253 encrypted-message option contains the encrypted DHCPv6 message sent 254 from server to client, which is encrypted using the client's public 255 key. The message that fails client authentication, MUST be dropped. 256 And the server sends the corresponding error status code to client. 258 +-------------+ +-------------+ 259 |DHCPv6 Client| |DHCPv6 Server| 260 +-------------+ +-------------+ 261 | Information-request | 262 |----------------------------------------->| 263 | Option Request option | 264 | | 265 | Reply | 266 |<-----------------------------------------| 267 | certificate option | 268 | signature option | 269 | timestamp option | 270 | server identifier option | 271 | | 272 | Encryption-Query | 273 |----------------------------------------->| 274 | encrypted-message option | 275 | server identifier option | 276 | | 277 | Encryption-Response | 278 |<-----------------------------------------| 279 | encrypted-message option | 280 | | 282 Secure DHCPv6 Procedure 284 It is worth noticing that the signature on a Secure DHCPv6 message 285 can be expected to significantly increase the size of the message. 287 One example is normal DHCPv6 message length plus a 1 KB for a X.509 288 certificate and signature and 256 Byte for a signature. IPv6 289 fragments [RFC2460] are highly possible. In practise, the total 290 length would be various in a large range. Hence, deployment of 291 Secure DHCPv6 should also consider the issues of IP fragment, PMTU, 292 etc. Also, if there are firewalls between secure DHCPv6 clients and 293 secure DHCPv6 servers, it is RECOMMENDED that the firewalls are 294 configured to pass ICMP Packet Too Big messages [RFC4443]. 296 5.2. New Components 298 The new components of the solution specified in this document are as 299 follows: 301 o Servers and clients that use certificates first generate a public/ 302 private key pair and then obtain a public key certificate from a 303 Certificate Authority that signs the public key. One option is 304 defined to carry the certificate. 306 o A signature generated using the private key which is used by the 307 receiver to verify the integrity of the DHCPv6 messages and then 308 the authentication of the client/server. Another option is 309 defined to carry the signature. 311 o A timestamp that can be used to detect replayed packet. The 312 secure DHCPv6 client/server need to meet some accuracy 313 requirements and be synced to global time, while the timestamp 314 checking mechanism allows a configurable time value for clock 315 drift. The real time provision is out of scope of this document. 316 Another option is defined to carry the current time of the client/ 317 server. 319 o An encrypted-message option that contains the encrypted DHCPv6 320 message. 322 o An Encrypted-Query message that sent from client to server. The 323 Encrypted-Query message contains the encrypted-message option and 324 server identifier option. 326 o An Encrypted-Response message that sent from server to client. 327 The Encrypted-Response message contains the encrypted-message 328 option. 330 5.3. Support for Algorithm Agility 332 Hash functions are used to provide message integrity checks. In 333 order to provide a means of addressing problems that may emerge in 334 the future with existing hash algorithms, as recommended in 336 [RFC4270], this document provides a mechanism for negotiating the use 337 of more secure hashes in the future. 339 In addition to hash algorithm agility, this document also provides a 340 mechanism for signature algorithm agility. 342 The support for algorithm agility in this document is mainly a 343 unilateral notification mechanism from sender to recipient. A 344 recipient MAY support various algorithms simultaneously among 345 different senders, and the different senders in the same 346 administrative domain may be allowed to use various algorithms 347 simultaneously. It is NOT RECOMMENDED that the same sender and 348 recipient use various algorithms in a single communication session. 350 If the recipient does not support the algorithm used by the sender, 351 it cannot authenticate the message. In the client-to-server case, 352 the server SHOULD reply with an AlgorithmNotSupported status code 353 (defined in Section 10.3). Upon receiving this status code, the 354 client MAY resend the message protected with the mandatory algorithm 355 (defined in Section 10.1.2). 357 5.4. Imposed Additional Constraints 359 The client/server that supports the identity verification MAY impose 360 additional constraints for the verification. For example, it may 361 impose limits on minimum and maximum key lengths. 363 Minbits The minimum acceptable key length for public keys. An upper 364 limit MAY also be set for the amount of computation needed when 365 verifying packets that use these security associations. The 366 appropriate lengths SHOULD be set according to the signature 367 algorithm and also following prudent cryptographic practice. For 368 example, minimum length 1024 and upper limit 2048 may be used for 369 RSA [RSA]. 371 5.5. Applicability 373 Secure DHCPv6 is applicable in environments where physical security 374 on the link is not assured and attacks on DHCPv6 are a concern, such 375 as enterprise network. In enterprise network, the security policy is 376 strict and the clients are stable terminals. The PKI model is used 377 for the secure DHCPv6 deployment. The deployment of PKI is out of 378 the scope of this document. The server is always considered to have 379 connectivity to authorized CA and verify the clients' certificates. 380 The client performs the server authentication locally. The trusted 381 servers' certificates or trusted CAs' certificates, which form a 382 certification path [RFC5280], is deployed in the client to achieve 383 the server authentication. The DHCPv6 client obtains the trusted 384 certificates through the pre-configuration method or out of band, 385 such as QR code. After the mutual authentication, the DHCPv6 message 386 is encrypted with the recipient's public key, which is contained in 387 the certificate. 389 6. DHCPv6 Client Behavior 391 For the security DHCPv6 client, it must have a public certificate. 392 The client may be pre-configured with a public key certificate, which 393 is signed by a CA trusted by the server, and its corresponding 394 private key. 396 The DHCPv6 client multicasts the Information-request message to the 397 DHCPv6 servers. The Information-request message MUST NOT include any 398 option which may reveal the private information of the client, such 399 as the client identifier option. The information-request message is 400 used by the DHCPv6 client to request the server's identity 401 verification information without having addresses, prefixes or any 402 non-security options assigned to it. The Option Request option in 403 the Information-request message MUST contain the option code of 404 certificate option, signature option, timestamp option, and server 405 identifier option. 407 When receiving the Reply messages from DHCPv6 servers, a secure 408 DHCPv6 client SHOULD discard any DHCPv6 messages that meet any of the 409 following conditions: 411 o the signature option is missing, 413 o multiple signature options are present, 415 o the certificate option is missing. 417 And then the client SHOULD first check the support of the hash and 418 signature algorithms that the server used. If the check fails, the 419 Reply message SHOULD be dropped. If both hash and signature 420 algorithms are supported, the client then checks the authority of 421 this server. The client SHOULD also use the same algorithms in the 422 return messages. 424 The client SHOULD validate the certificate according to the rules 425 defined in [RFC5280]. An implementation may create a local trust 426 certificate record for verified certificates in order to avoid 427 repeated verification procedure in the future. A certificate that 428 finds a match in the local trust certificate list is treated as 429 verified. At this point, the client has either recognized the 430 authentication of the server, or decided to drop the message. 432 The client MUST now authenticate the server by verifying the 433 signature and checking timestamp (see details in Section 9.1), if 434 there is a timestamp option. The order of two procedures is left as 435 an implementation decision. It is RECOMMENDED to check timestamp 436 first, because signature verification is much more computationally 437 expensive. 439 The signature field verification MUST show that the signature has 440 been calculated as specified in Section 10.1.2. Only the messages 441 that get through both the signature verification and timestamp check 442 (if there is a timestamp option) are accepted. Reply message that 443 does not pass the above tests MUST be discarded. 445 If there are multiple authenticated DHCPv6 servers, the client 446 selects one DHCPv6 server for the following network parameters 447 configuration. If there are no authenticated DHCPv6 servers or 448 existing servers failed authentication, the client behavior is policy 449 specific. Depending on its policy, it can choose to connect using 450 plain, unencrypted DHCPv6, repeat the server discovery process after 451 certain delay or attempt to connect to a different network. The 452 client MUST NOT conduct the server discovery process immediately to 453 avoid the packet storm. 455 Once the server has been authenticated, the DHCPv6 client sends the 456 Encrypted-Query message to the DHCPv6 server. The Encrypted-Query 457 message is constructed with the encrypted-message option, which MUST 458 be constructed as explained in Section 10.1.4, and server identifier 459 option. The encrypted-message option contains the DHCPv6 message 460 that is encrypted using the selected server's public key. The server 461 identifier option is externally visible to avoid extra of decryption 462 cost by those unselected servers. 464 The information for client authentication is contained in the 465 Solicit/Information-request message, which is encrypted and then 466 encapsulated into the Encrypted-Query message to avoid client privacy 467 disclosure. The Solicit/Information-request message MUST contain the 468 certificate option, which MUST be constructed as explained in 469 Section 10.1.1. In addition, one and only one signature option MUST 470 be contained, which MUST be constructed as explained in 471 Section 10.1.2. It protects the message header and all DHCPv6 472 options except for the Authentication Option. One and only one 473 Timestamp option, which MUST be constructed as explained in 474 Section 10.1.3. The Timestamp field SHOULD be set to the current 475 time, according to sender's real time clock. 477 For the received Encrypted-Response message, the client extracts the 478 encrypted-message option and decrypts it using its private key to 479 obtain the original DHCPv6 message. Then it handles the message as 480 per [RFC3315]. If the client fails to get the proper parameters from 481 the chosen server, it sends the Encrypted-Query message to another 482 authenticated server for parameters configuration until the client 483 obtains the proper parameters. 485 When the client receives a Reply message with an error status code, 486 the error status code indicates the failure reason on the server 487 side. According to the received status code, the client MAY take 488 follow-up action: 490 o Upon receiving an AlgorithmNotSupported error status code, the 491 client SHOULD resend the message protected with one of the 492 mandatory algorithms. 494 o Upon receiving an AuthenticationFail error status code, the client 495 is not able to build up the secure communication with the 496 recipient. However, there may be other DHCPv6 servers available 497 that successfully complete authentication. The client MAY use the 498 AuthenticationFail as a hint and switch to other public key 499 certificate if it has another one; but otherwise treat the message 500 containing the status code as if it had not been received. But it 501 SHOULD NOT retry with the same certificate. However, if the 502 client decides to retransmit using the same certificate after 503 receiving AuthenticationFail, it MUST NOT retransmit immediately 504 and MUST follow normal retransmission routines defined in 505 [RFC3315]. 507 o Upon receiving a TimestampFail error status code, the client MAY 508 resend the message with an adjusted timestamp according to the 509 returned clock from the DHCPv6 server. The client SHOULD NOT 510 change its own clock, but only compute an offset for the 511 communication session. 513 o Upon receiving a SignatureFail error status code, the client MAY 514 resend the message following normal retransmission routines 515 defined in [RFC3315]. 517 7. DHCPv6 Server Behavior 519 For the secure DHCPv6 server, it also MUST have a public certificate. 520 The server may be pre-configured a public key certificate, which is 521 signed by a CA trusted by the server, and its corresponding private 522 key. 524 When the DHCPv6 server receives the Information-request message and 525 the contained Option Request option informs the request for the 526 server authentication information, it replies the Reply message to 527 the client. The reply message MUST contain the requested certificate 528 option, which MUST be constructed as explained in Section 10.1.1. In 529 addition, the Reply message MUST contain one and only one Signature 530 option, which MUST be constructed as explained in Section 10.1.2. It 531 protects the message header and all DHCPv6 options except for the 532 Authentication Option. Besides, the Reply message SHOULD contain one 533 and only one Timestamp option, which MUST be constructed as explained 534 in Section 10.1.3. The Timestamp field SHOULD be set to the current 535 time, according to server's real time clock. 537 Upon the receipt of Encrypted-Query message, the server checks the 538 server identifier option. It decrypts the encrypted-message option 539 using its private key if it is the target server. The DHCPv6 server 540 drops the message that is not for it, thus not paying cost to decrypt 541 the message. 543 If the decrypted message is Solicit/Information-request message, the 544 secure DHCPv6 server SHOULD discard the received message that meet 545 any of the following conditions: 547 o the signature option is missing, 549 o multiple signature options are present, 551 o the certificate option is missing. 553 In such failure, the server SHOULD reply an UnspecFail (value 1, 554 [RFC3315]) error status code. 556 The server SHOULD first check the support of the hash and signature 557 algorithms that the client used. If the check fails, the server 558 SHOULD reply with an AlgorithmNotSupported error status code, defined 559 in Section 10.3, back to the client. If both hash and signature 560 algorithms are supported, the server then checks the authority of 561 this client. 563 If a certificate option is provided, the server SHOULD validate the 564 certificate according to the rules defined in [RFC5280]. An 565 implementation may create a local trust certificate record for 566 verified certificates in order to avoid repeated verification 567 procedure in the future. A certificate that finds a match in the 568 local trust certificate list is treated as verified. 570 The message that fails certificate validation, MUST be dropped. In 571 such failure, the DHCPv6 server SHOULD reply an AuthenticationFail 572 error status code, defined in Section 10.3, back to the client. At 573 this point, the server has either recognized the authentication of 574 the client, or decided to drop the message. 576 If the server does not send the timestamp option, the client ignores 577 the timestamp check and verifies the signature. If there is a 578 timestamp option, the server MUST now authenticate the client by 579 verifying the signature and checking timestamp (see details in 580 Section 9.1). The order of two procedures is left as an 581 implementation decision. It is RECOMMENDED to check timestamp first, 582 because signature verification is much more computationally 583 expensive. Depending on server's local policy, the message without a 584 Timestamp option MAY be acceptable or rejected. If the server 585 rejects such a message, a TimestampFail error status code, defined in 586 Section 10.3, should be sent back to the client. The reply message 587 that carries the TimestampFail error status code SHOULD carry a 588 timestamp option, which indicates the server's clock for the client 589 to use. 591 The signature field verification MUST show that the signature has 592 been calculated as specified in Section 10.1.2. Only the clients 593 that get through both the signature verification and timestamp check 594 (if there is a Timestamp option) are accepted as authenticated 595 clients and continue to be handled their message as defined in 596 [RFC3315]. Clients that do not pass the above tests MUST be treated 597 as unauthenticated clients. The DHCPv6 server SHOULD reply a 598 SignatureFail error status code, defined in Section 10.3, for the 599 signature verification failure; or a TimestampFail error status code, 600 defined in Section 10.3, for the timestamp check failure, back to the 601 client. 603 Once the client has been authenticated, the DHCPv6 server sends the 604 Encrypted-response message to the DHCPv6 client. The Encrypted- 605 response message contains the encrypted-message option, which MUST be 606 constructed as explained in Section 10.1.4. The encrypted-message 607 option contains the encrypted DHCPv6 message that is encrypted using 608 the authenticated client's public key. 610 8. Relay Agent Behavior 612 When a DHCPv6 relay agent receives an Encrypted-query or Encrypted- 613 response message, it may not recognize this message. The unknown 614 messages MUST be forwarded as describes in [RFC7283]. 616 When a DHCPv6 relay agent recognizes the Encrypted-query and 617 Encrypted-response messages, it forwards the message according to 618 section 20 of [RFC3315]. There is nothing more the relay agents have 619 to do, it neither needs to verify the messages from client or server, 620 nor add any secure DHCPv6 options. Actually, by definition in this 621 document, relay agents SHOULD NOT add any secure DHCPv6 options. 623 Relay-forward and Relay-reply messages MUST NOT contain any 624 additional certificate option or signature Option or timestamp 625 Option, aside from those present in the innermost encapsulated 626 messages from the client or server. 628 9. Processing Rules 630 9.1. Timestamp Check 632 In order to check the Timestamp option, defined in Section 10.1.3, 633 recipients SHOULD be configured with an allowed timestamp Delta 634 value, a "fuzz factor" for comparisons, and an allowed clock drift 635 parameter. The recommended default value for the allowed Delta is 636 300 seconds (5 minutes); for fuzz factor 1 second; and for clock 637 drift, 0.01 second. 639 Note: the Timestamp mechanism is based on the assumption that 640 communication peers have roughly synchronized clocks, with certain 641 allowed clock drift. So, accurate clock is not necessary. If one 642 has a clock too far from the current time, the timestamp mechanism 643 would not work. 645 To facilitate timestamp checking, each recipient SHOULD store the 646 following information for each sender, from which at least one 647 accepted secure DHCPv6 message is successfully verified (for both 648 timestamp check and signature verification): 650 o The receive time of the last received and accepted DHCPv6 message. 651 This is called RDlast. 653 o The timestamp in the last received and accepted DHCPv6 message. 654 This is called TSlast. 656 A verified (for both timestamp check and signature verification) 657 secure DHCPv6 message initiates the update of the above variables in 658 the recipient's record. 660 Recipients MUST check the Timestamp field as follows: 662 o When a message is received from a new peer (i.e., one that is not 663 stored in the cache), the received timestamp, TSnew, is checked, 664 and the message is accepted if the timestamp is recent enough to 665 the reception time of the packet, RDnew: 667 -Delta < (RDnew - TSnew) < +Delta 669 After the signature verification also succeeds, the RDnew and 670 TSnew values SHOULD be stored in the cache as RDlast and TSlast. 672 o When a message is received from a known peer (i.e., one that 673 already has an entry in the cache), the timestamp is checked 674 against the previously received Secure DHCPv6 message: 676 TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz 678 If this inequality does not hold or RDnew < RDlast, the recipient 679 SHOULD silently discard the message. If, on the other hand, the 680 inequality holds, the recipient SHOULD process the message. 682 Moreover, if the above inequality holds and TSnew > TSlast, the 683 recipient SHOULD update RDlast and TSlast after the signature 684 verification also successes. Otherwise, the recipient MUST NOT 685 update RDlast or TSlast. 687 An implementation MAY use some mechanism such as a timestamp cache to 688 strengthen resistance to replay attacks. When there is a very large 689 number of nodes on the same link, or when a cache filling attack is 690 in progress, it is possible that the cache holding the most recent 691 timestamp per sender will become full. In this case, the node MUST 692 remove some entries from the cache or refuse some new requested 693 entries. The specific policy as to which entries are preferred over 694 others is left as an implementation decision. 696 An implementation MAY statefully record the latest timestamps from 697 senders. In such implementation, the timestamps MUST be strictly 698 monotonously increasing. This is reasonable given that DHCPv6 699 messages are rarely misordered. 701 10. Extensions for Secure DHCPv6 703 This section describes the extensions to DHCPv6. Five new DHCPv6 704 options, two new DHCPv6 messages and five status codes are defined. 706 10.1. New DHCPv6 Options 708 10.1.1. Certificate Option 710 The certificate option carries the public key certificate of the 711 client/server. The format of the certificate option is described as 712 follows: 714 0 1 2 3 715 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 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | OPTION_CERTIFICATE | option-len | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | | 720 . Certificate (variable length) . 721 . . 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 option-code OPTION_CERTIFICATE (TBA1). 726 option-len Length of certificate in octets. 728 Certificate A variable-length field containing certificate. The 729 encoding of certificate and certificate data MUST 730 be in format as defined in Section 3.6, [RFC7296]. 731 The support of X.509 certificate - Signature (4) 732 is mandatory. 734 10.1.2. Signature Option 736 The signature option allows a signature that is signed by the private 737 key to be attached to a DHCPv6 message. The signature option could 738 be any place within the DHCPv6 message while it is logically created 739 after the entire DHCPv6 header and options, except for the 740 Authentication Option. It protects the entire DHCPv6 header and 741 options, including itself, except for the Authentication Option. The 742 format of the Signature option is described as follows: 744 0 1 2 3 745 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 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | OPTION_SIGNATURE | option-len | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | HA-id | SA-id | | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 751 | | 752 . Signature (variable length) . 753 . . 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 option-code OPTION_SIGNATURE (TBA2). 758 option-len 2 + Length of Signature field in octets. 760 HA-id Hash Algorithm id. The hash algorithm is used for 761 computing the signature result. This design is 762 adopted in order to provide hash algorithm agility. 763 The value is from the Hash Algorithm for Secure 764 DHCPv6 registry in IANA. The support of SHA-256 is 765 mandatory. A registry of the initial assigned values 766 is defined in Section 8. 768 SA-id Signature Algorithm id. The signature algorithm is 769 used for computing the signature result. This 770 design is adopted in order to provide signature 771 algorithm agility. The value is from the Signature 772 Algorithm for Secure DHCPv6 registry in IANA. The 773 support of RSASSA-PKCS1-v1_5 is mandatory. A 774 registry of the initial assigned values is defined 775 in Section 8. 777 Signature A variable-length field containing a digital 778 signature. The signature value is computed with 779 the hash algorithm and the signature algorithm, 780 as described in HA-id and SA-id. The signature 781 constructed by using the sender's private key 782 protects the following sequence of octets: 784 1. The DHCPv6 message header. 786 2. All DHCPv6 options including the Signature 787 option (fill the signature field with zeroes) 788 except for the Authentication Option. 790 The signature field MUST be padded, with all 0, to 791 the next octet boundary if its size is not a 792 multiple of 8 bits. The padding length depends on 793 the signature algorithm, which is indicated in the 794 SA-id field. 796 Note: if both signature and authentication option are present, 797 signature option does not protect the Authentication Option. It 798 allows the Authentication Option be created after signature has been 799 calculated and filled with the valid signature. It is because both 800 options need to apply hash algorithm to whole message, so there must 801 be a clear order and there could be only one last-created option. 802 changing auth option, the authors chose not include authentication 803 option in the signature. 805 10.1.3. Timestamp Option 807 The Timestamp option carries the current time on the sender. It adds 808 the anti-replay protection to the DHCPv6 messages. It is optional. 810 0 1 2 3 811 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 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | OPTION_TIMESTAMP | option-len | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | | 816 | Timestamp (64-bit) | 817 | | 818 | | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 option-code OPTION_TIMESTAMP (TBA3). 823 option-len 8, in octets. 825 Timestamp The current time of day (SeND-format timestamp 826 in UTC (Coordinated Universal Time). It can reduce 827 the danger of replay attacks. 829 10.1.4. Encrypted-message Option 831 The encrypted-message option carries the encrypted DHCPv6 message 832 with the recipient's public key. 834 The format of the encrypted-message option is: 836 0 1 2 3 837 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 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | option-code | option-len | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | | 842 . encrypted DHCPv6 message . 843 . (variable) . 844 . . 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 Figure 1: encrypted-message Option Format 849 option-code OPTION_ENCRYPTED_MSG (TBA4). 851 option-len Length of the encrypted DHCPv6 message. 853 encrypted DHCPv6 message A variable length field containing the 854 encrypted DHCPv6 message sent by the client or the server. In 855 Encrypted-Query message, it contains encrypted DHCPv6 message sent 856 by a client. In Encrypted-response message, it contains encrypted 857 DHCPv6 message sent by a server. 859 10.2. New DHCPv6 Messages 861 10.2.1. Encrypted-Query Message 863 The Encrypted-Query message is sent from DHCPv6 client to DHCPv6 864 server, which contains the server identifier option and encrypted- 865 message option. 867 The format of the Encrypted-Query message is: 869 0 1 2 3 870 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 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | msg-type | transaction-id | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 . DUID . 875 | (variable) | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | | 878 . encrypted-message option . 879 . (variable) . 880 | | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 Figure 2: The format of Encrypted-Query Message 885 msg-type ENCRYPTED-QUERY (TBA5) 887 transaction-id The transaction ID for this message exchange. 889 DUID The DUID for the server. 891 encrypted-message option The encrypted DHCPv6 message. 893 10.2.2. Encrypted-Response Message 895 The Encrypted-Response message is sent from DHCPv6 server to DHCPv6 896 client, which contains the encrypted-message option. 898 The format of the Encrypted-Response message is: 900 0 1 2 3 901 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 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | msg-type | transaction-id | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | | 906 . encrypted-message option . 907 . (variable) . 908 | | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 Figure 3: The format of Encrypted-Response Message 913 msg-type ENCRYPTED-RESPONSE (TBA6). 915 transaction-id The transaction ID for this message exchange. 917 encrypted-message option The encrypted DHCPv6 message. 919 10.3. Status Codes 921 The following new status codes, see Section 5.4 of [RFC3315] are 922 defined. 924 o AlgorithmNotSupported (TBD7): indicates that the DHCPv6 server 925 does not support algorithms that sender used. 927 o AuthenticationFail (TBD8): indicates that the DHCPv6 client fails 928 authentication check. 930 o TimestampFail (TBD9): indicates the message from DHCPv6 client 931 fails the timestamp check. 933 o SignatureFail (TBD10): indicates the message from DHCPv6 client 934 fails the signature check. 936 11. Security Considerations 938 This document provides the authentication and encryption mechanisms 939 for DHCPv6. 941 [RFC6273] has analyzed possible threats to the hash algorithms used 942 in SEND. Since the Secure DHCPv6 defined in this document uses the 943 same hash algorithms in similar way to SEND, analysis results could 944 be applied as well: current attacks on hash functions do not 945 constitute any practical threat to the digital signatures used in the 946 signature algorithm in the Secure DHCPv6. 948 A server, whose local policy accepts messages without a Timestamp 949 option, may have to face the risk of replay attacks. 951 A window of vulnerability for replay attacks exists until the 952 timestamp expires. Secure DHCPv6 nodes are protected against replay 953 attacks as long as they cache the state created by the message 954 containing the timestamp. The cached state allows the node to 955 protect itself against replayed messages. However, once the node 956 flushes the state for whatever reason, an attacker can re-create the 957 state by replaying an old message while the timestamp is still valid. 958 In addition, the effectiveness of timestamps is largely dependent 959 upon the accuracy of synchronization between communicating nodes. 960 However, how the two communicating nodes can be synchronized is out 961 of scope of this work. 963 Attacks against time synchronization protocols such as NTP [RFC5905] 964 may cause Secure DHCPv6 nodes to have an incorrect timestamp value. 965 This can be used to launch replay attacks, even outside the normal 966 window of vulnerability. To protect against these attacks, it is 967 recommended that Secure DHCPv6 nodes keep independently maintained 968 clocks or apply suitable security measures for the time 969 synchronization protocols. 971 12. IANA Considerations 973 This document defines five new DHCPv6 [RFC3315] options. The IANA is 974 requested to assign values for these five options from the DHCPv6 975 Option Codes table of the DHCPv6 Parameters registry maintained in 976 http://www.iana.org/assignments/dhcpv6-parameters. The five options 977 are: 979 The Certificate Option (TBA1), described in Section 10.1.1. 981 The Signature Option (TBA2), described in Section 10.1.2. 983 The Timestamp Option (TBA3),described in Section 10.1.3. 985 The Encrypted-message Option (TBA4), described in Section 10.1.4. 987 The IANA is also requested to assign value for these two messages 988 from the DHCPv6 Message Types table of the DHCPv6 Parameters registry 989 maintained in http://www.iana.org/assignments/dhcpv6-parameters. The 990 two messages are: 992 The Encrypted-Query Message (TBA5), described in Section 10.2.1. 994 The Encrypted-Response Message (TBA6), described in 995 Section 10.2.2. 997 The IANA is also requested to add two new registry tables to the 998 DHCPv6 Parameters registry maintained in 999 http://www.iana.org/assignments/dhcpv6-parameters. The two tables 1000 are the Hash Algorithm for Secure DHCPv6 table and the Signature 1001 Algorithm for Secure DHCPv6 table. 1003 Initial values for these registries are given below. Future 1004 assignments are to be made through Standards Action [RFC5226]. 1005 Assignments for each registry consist of a name, a value and a RFC 1006 number where the registry is defined. 1008 Hash Algorithm for Secure DHCPv6. The values in this table are 8-bit 1009 unsigned integers. The following initial values are assigned for 1010 Hash Algorithm for Secure DHCPv6 in this document: 1012 Name | Value | RFCs 1013 -------------------+---------+-------------- 1014 SHA-256 | 0x01 | this document 1015 SHA-512 | 0x02 | this document 1017 Signature Algorithm for Secure DHCPv6. The values in this table are 1018 8-bit unsigned integers. The following initial values are assigned 1019 for Signature Algorithm for Secure DHCPv6 in this document: 1021 Name | Value | RFCs 1022 -------------------+---------+-------------- 1023 RSASSA-PKCS1-v1_5 | 0x01 | this document 1025 IANA is requested to assign the following new DHCPv6 Status Codes, 1026 defined in Section 10.3, in the DHCPv6 Parameters registry maintained 1027 in http://www.iana.org/assignments/dhcpv6-parameters: 1029 Code | Name | Reference 1030 ---------+-----------------------+-------------- 1031 TBD7 | AlgorithmNotSupported | this document 1032 TBD8 | AuthenticationFail | this document 1033 TBD9 | TimestampFail | this document 1034 TBD10 | SignatureFail | this document 1036 13. Acknowledgements 1038 The authors would like to thank Tomek Mrugalski, Bernie Volz, Randy 1039 Bush, Yiu Lee, Jianping Wu, Sean Shen, Ralph Droms, Jari Arkko, Sean 1040 Turner, Stephen Farrell, Christian Huitema, Stephen Kent, Thomas 1041 Huth, David Schumacher, Francis Dupont, Gang Chen, Suresh Krishnan, 1042 Fred Templin, Robert Elz, Nico Williams, Erik Kline, Alan DeKok, 1043 Bernard Aboba, Sam Hartman, Qi Sun, Zilong Liu, and other members of 1044 the IETF DHC working group for their valuable comments. 1046 This document was produced using the xml2rfc tool [RFC2629]. 1048 14. References 1050 14.1. Normative References 1052 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1053 Requirement Levels", BCP 14, RFC 2119, 1054 DOI 10.17487/RFC2119, March 1997, 1055 . 1057 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1058 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1059 December 1998, . 1061 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1062 C., and M. Carney, "Dynamic Host Configuration Protocol 1063 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1064 2003, . 1066 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1067 Control Message Protocol (ICMPv6) for the Internet 1068 Protocol Version 6 (IPv6) Specification", RFC 4443, 1069 DOI 10.17487/RFC4443, March 2006, 1070 . 1072 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1073 Housley, R., and W. Polk, "Internet X.509 Public Key 1074 Infrastructure Certificate and Certificate Revocation List 1075 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1076 . 1078 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1079 "Network Time Protocol Version 4: Protocol and Algorithms 1080 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1081 . 1083 [RFC7283] Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6 1084 Messages", RFC 7283, DOI 10.17487/RFC7283, July 2014, 1085 . 1087 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1088 Kivinen, "Internet Key Exchange Protocol Version 2 1089 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1090 2014, . 1092 14.2. Informative References 1094 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1095 DOI 10.17487/RFC2629, June 1999, 1096 . 1098 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 1099 Hashes in Internet Protocols", RFC 4270, 1100 DOI 10.17487/RFC4270, November 2005, 1101 . 1103 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1104 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1105 DOI 10.17487/RFC5226, May 2008, 1106 . 1108 [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure 1109 Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, 1110 DOI 10.17487/RFC6273, June 2011, 1111 . 1113 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1114 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1115 2014, . 1117 [RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1, 1118 PKCS 1", November 2002. 1120 Authors' Addresses 1122 Sheng Jiang 1123 Huawei Technologies Co., Ltd 1124 Q14, Huawei Campus, No.156 Beiqing Road 1125 Hai-Dian District, Beijing, 100095 1126 CN 1128 Email: jiangsheng@huawei.com 1130 Lishan Li 1131 Tsinghua University 1132 Beijing 100084 1133 P.R.China 1135 Phone: +86-15201441862 1136 Email: lilishan9248@126.com 1137 Yong Cui 1138 Tsinghua University 1139 Beijing 100084 1140 P.R.China 1142 Phone: +86-10-6260-3059 1143 Email: yong@csnet1.cs.tsinghua.edu.cn 1145 Tatuya Jinmei 1146 Infoblox Inc. 1147 3111 Coronado Drive 1148 Santa Clara, CA 1149 US 1151 Email: jinmei@wide.ad.jp 1153 Ted Lemon 1154 Nominum, Inc. 1155 2000 Seaport Blvd 1156 Redwood City, CA 94063 1157 USA 1159 Phone: +1-650-381-6000 1160 Email: Ted.Lemon@nominum.com 1162 Dacheng Zhang 1163 Beijing 1164 CN 1166 Email: dacheng.zhang@gmail.com