idnits 2.17.1 draft-yiu-dhc-dhcpv6-sa-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3315]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2015) is 3308 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-05) exists of draft-ietf-dhc-dhcpv6-privacy-00 == Outdated reference: A later version (-21) exists of draft-ietf-dhc-sedhcpv6-06 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group Y. Lee 3 Internet-Draft Comcast 4 Intended status: Informational Y. Cui 5 Expires: September 9, 2015 Z. Liu 6 L. Sun 7 Tsinghua University 8 March 8, 2015 10 Secure Access Mechanism for DHCPv6 11 draft-yiu-dhc-dhcpv6-sa-00 13 Abstract 15 DHCPv6 [RFC3315] provides configuration parameters such as IPv6 16 network addresses for hosts. The unencrypted nature and use of 17 various identifiers make its privacy and security become more 18 vulnerable. With appropriate protection mechanisms, the privacy and 19 security can be improved to some extent. This document specifies 20 such a mechanism that builds a trusted relationship between DHCPv6 21 clients and servers before solicitation. The mechanism enables a 22 valid client to find and access the legitimate server or reject and 23 blacklist a rogue server. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 9, 2015. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Related Works . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Overview of Secure Access Mechanism . . . . . . . . . . . . . 4 63 5. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . . 5 64 6. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 6.1. Client Behaviour . . . . . . . . . . . . . . . . . . . . 6 66 6.2. Server Behaviour . . . . . . . . . . . . . . . . . . . . 7 67 6.3. Behaviour in Lightweight Mode . . . . . . . . . . . . . . 8 68 7. Further Protection Considerations . . . . . . . . . . . . . . 8 69 7.1. Unicast . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 7.2. Encryption . . . . . . . . . . . . . . . . . . . . . . . 9 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 75 10.2. Informative References . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 [RFC3315] specifies the Dynamic Host Configuration Protocol for IPv6. 81 [I-D.ietf-dhc-dhcpv6-privacy] analyzes the DHCPv6 privacy issues and 82 discusses how various identifiers used in DHCPv6 could become a 83 source for gleaning additional information of an individual. Such 84 identifiers are included in various DHCPv6 messages. In other words, 85 there are important client information embedded in DHCPv6 messages. 86 If the messages are sent to a rogue server or an invalid third party, 87 end users' privacy and security may be compromised. 89 Current authentication models include secure DHCPv6 90 [I-D.ietf-dhc-sedhcpv6] and authentication mechanism defined in 91 [RFC3315]. Both share the primary goal of validating the identity of 92 message sender. They were not designed to protect client privacy. 93 DHCPv6 messages such as SOLICIT contains sensitive client 94 information, these messages are not protected. Further, current 95 authentication mechanisms focus more on the identity of clients, they 96 do not provide full authentication of the DHCPv6 server (e.g. server 97 authentication in secure DHCPv6 is based on leap of faith). Current 98 authentication mechanisms aim to protect the DHCPv6 server by 99 preventing invalid clients from launching attacks such as DoS attack. 100 However when considered client privacy, the authenticity of server 101 really matters. 103 Hence there is a requirement to design a mechanism that sets up a 104 trusted relationship between a client and a server before starting 105 the DHCPv6 transaction (i.e. before DHCPv6 solicitation). In this 106 document, we propose such a peer entity authentication called Secure 107 Access by defining two new DHCPv6 messages. The Secure Access 108 mechanism makes use of server and client certificates and achieves 109 authentication through Public Key Infrastructure ([RFC5280]). With 110 the designed mechanism, a valid client can find and access the 111 legitimate server or reject and blacklist a rogue entity before 112 standard DHCPv6 process. 114 The Secure Access mechanism specified in this document does not 115 affect the current DHCP design. It is more like an alternative 116 extension, only the client who wants to improve the privacy will use 117 it. Another benefit is that further data protection solution such as 118 encryption can be based on the trusted relationship built by this 119 mechanism. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 3. Related Works 129 This section briefly introduces the existed authentication models and 130 discusses their pros and cons when compared with the design in this 131 document. 133 Authentication mechanism defined in [RFC3315] provides a basic 134 verification of DHCPv6 messages sender and contents through using an 135 Authentication option. The Authentication option can be treated as a 136 symmetric key, which is a simple but limited authentication pattern. 137 Two specific protocol, Delayed Authentication Protocol and 138 Reconfigure Key Authentication Protocol, are proposed along with this 139 option. This authentication framework also allows future separate 140 authentication protocols to be put forward but it seems not to be 141 deployable. 143 Secure DHCPv6 ([I-D.ietf-dhc-sedhcpv6]) enhance the security of 144 DHCPv6 by using server's public/private key pairs and client's 145 certificates to authenticate. To ease the pre-configuration of 146 authentication, the client make a leap of faith to trust the server. 147 While the server provide full authentication of client through 148 validating its certificate. Secure DHCPv6 also enables the recipient 149 to check the message integrity and offers anti-replay protection 150 using timestamps. Compared with authentication mechanism in 151 [RFC3315], secure DHCPv6 is more lightweight and provide better 152 protection when refers to the authentication of DHCPv6 clients. 154 4. Overview of Secure Access Mechanism 156 The Secure Access mechanism defined in this document is mainly based 157 on the server and client's certificates. Similar to secure DHCPv6, 158 we also make use of PKI (Public Key Infrastructure) to authenticate 159 relevant entities. Since both certificates of client and server are 160 required, a full bidirectional authentication between client and 161 server is available. The certificates used in this document are all 162 X.509 v3 certificates whose details can be found in [RFC5280]. 164 If a client desires to improve privacy when using DHCPv6, it can 165 initiate the Secure Access process to achieve a peer entity 166 authentication. The client applies for its public key certificate 167 from a CA (Certificate Authority) which is signed by the CA's private 168 key. Then the client implements a new DHCPv6 message called 169 Authenticate and multicasts it to the servers. The Authenticate 170 message MUST carry the Certificate option defined in 171 [I-D.ietf-dhc-sedhcpv6] to provide server with client's public key 172 certificate. It is RECOMMENDED that the Authenticate message does 173 not carry options other than Certificate option for the privacy. 175 A legitimate server also needs to get its own certificate from CA as 176 the client does. The server receives the Authenticate message needs 177 to verify the client's certificate. Typically it uses the CA's 178 public key to validate whether the client is trusted or not. 179 Detailed process of the authentication is described in [RFC5280] and 180 is out of scope of this document. If the client is valid, the server 181 will respond a new DHCPv6 message called Authenticate-reply message 182 which contains a Certificate option (carry the server's public key 183 certificate) and a Server Unicast option. It is possible for the 184 server to carry more information (more options) in the Authenticate- 185 reply message (e.g. Server Unicast option). 187 The initiated client MAY receive more than one Authenticate-reply 188 messages from different servers. It verifies each Authenticate-reply 189 message by validating corresponding server certificate through PKI. 190 If the Authenticate-reply message does not contain a Certificate 191 option or the verification fails, the client will discard the message 192 and further blacklist the server. The client remember those servers 193 who pass the verification as legitimated ones. In this way, the 194 client can find legitimate servers and trigger the normal DHCPv6 195 process in a more protected way (e.g. unicast or encryption). 197 This mechanism provides an end-to-end authentication between DHCPv6 198 clients and servers. When a relay agent is involved, the only 199 function it performs is forwarding. Also the relay agent does not 200 allowed to add any additional options. 202 The Secure Access mechanism also supports another lightweight mode 203 which only based on the server's certificate. Since it is uncommon 204 for a client to obtain a certificate from the CA, we have to make the 205 mechanism applied to such a scenario that only server certificate is 206 available. This may sacrifice the security of a DHCPv6 server to 207 some extent but will not do harm to the client privacy. Since the 208 server responses usually do not contain much client information. In 209 this lightweight mode, the server responds an Authenticate-reply 210 message as soon as it received a Authenticate message from the 211 client. Then the client performs the same process as the common mode 212 has described. 214 5. New DHCPv6 Messages 216 Two new DHCPv6 messages are defined to achieve the peer entity 217 authentication between clients and servers before standard DHCPv6 218 process. The Authenticate message is always sent by the client to 219 carry its certificate and the Authenticate-reply message is sent by 220 the server for client to validate its legitimacy. This section 221 describe the two new messages formats and structures. 223 Both Authenticate and Authenticate-reply message use the Client/ 224 Server message formats described in Section 6 of [RFC3315]. Two new 225 message codes are defined in the following. 227 AUTHENTICATE (TBA1): The client multicasts an Authenticate message to 228 available servers to request for legitimate servers. The 229 Authenticate message contains client's certificate for server to 230 check its validity. 232 AUTHENTICATE-REPLY (TBA2): The server sends an Authenticate-reply 233 message to requesting client to prove its legitimacy by carrying the 234 Certificate option. It also needs to include a Server Unicast option 235 to provide the client with its address. 237 6. Behaviour 239 This section describes the behaviour of DHCPv6 clients and servers 240 when Secure Access mechanism is deployed. It is suitable for the 241 clients who are concerned about their privacy and are eager to 242 improve it. All the behaviours are prior to the standard DHCPv6 243 process, that is to say the Secure Access mechanism will be finished 244 before the DHCPv6 Solicit message is sent to the server. 246 6.1. Client Behaviour 248 If a client wants to improve its privacy by finding a legitimate 249 server to communicate, it will be more reasonable that the requesting 250 client is also valid. In the context of this document, only valid 251 clients can obtain their certificates from a trusted CA. That would 252 require the CA to judge whether a client is valid or not. A common 253 and simple solution is to make the trusted CA handled by the ISP. In 254 this way, the trusted CA could easily achieve the verification 255 through ISP's registration data. While there could be more extra 256 solutions and the actual CA implementation is out of scope of this 257 document. A valid client can only have one certificate which is 258 signed by the trusted CA. 260 Once the client obtains its certificate, it can trigger the Secure 261 Access mechanism by multicasting the Authenticate message to the 262 servers (i.e. using the multicast addresses defined in [RFC3315]). 263 The client MUST insert only one Certificate option in the 264 Authenticate message. The Certificate option is used to carry the 265 client's certificate and is defined in [I-D.ietf-dhc-sedhcpv6]. In 266 order not to leak any client information in the Secure Access phase, 267 it is also RECOMMENDED that the Authenticate message does not include 268 any other options except for Certificate option. 270 After sending out the Authenticate message, the client is waiting for 271 servers' response. During this period, it will discard any DHCPv6 272 message that the message type is not AUTHENTICATE-REPLY. The client 273 is not allowed to send any other message whose message type is not 274 AUTHENTICATE until it finds an authenticated server. 276 On receipt of servers' Authenticate-reply messages, it first checks 277 the options field. The client simply discards the message if it 278 includes neither Certificate option nor Server Unicast option. If 279 the Authenticate-reply message include a Server Unicast option but 280 not a Certificate option, the client will blacklist this server as a 281 rogue server. If the Authenticate-reply message include a 282 Certificate option but not a Server Unicast option, the client will 283 also discard the received message. When both Certificate option and 284 Server Unicast option exist, the client extracts the Certificate 285 options then verifies it through PKI. If the verification fails, the 286 client will blacklist the server. The client remembers servers who 287 pass the verification as legitimate servers and choose one to build 288 trusted relationship. Based on the trusted relationship, the client 289 can employ further protection means to initiate a standard DHCPv6 290 process. The further protection means are discussed in Section 7. 292 The client should implement a timer locally. If it has not received 293 any Authenticate-reply message when the timer expires, it will reset 294 the timer and resend its Authenticate message. If it still could not 295 receive any Authenticate-reply in the second expiration, the client 296 would treat this condition as a failure of authentication. There 297 could be various solutions for the failure such as reporting to the 298 user or starting standard DHCPv6 process that ignores the failure 299 condition. Which solution is employed is dependent on the client 300 side policy. The timer expiration and client side policy would vary 301 in different scenarios, hence their implementations are out of scope 302 of this document. 304 6.2. Server Behaviour 306 If a server is legitimate and support the Secure Access mechanism 307 defined in this document, it should obtain its certificate from the 308 same trusted CA when it is configured. Such server should provide 309 services for both standard DHCPv6 process and DHCPv6 with Secure 310 Access. When it receives a standard DHCPv6 message (e.g. Solicit), 311 it just follows the procedure defined in [RFC3315]. 313 When the server receives an Authenticate message, it is an indication 314 that the client wishes to build a trusted relationship with a 315 legitimate server. The server who is willing to be accessed by such 316 a client extracts the Certificate option to validate the client 317 through PKI. If there is no Certificate option or the authentication 318 fails, the server will simply discard this message. If the client 319 can be proved to be valid (i.e. its certificate is trusted), the 320 server will respond an Authenticate-reply message to the valid 321 client. The Authenticate-reply message MUST include only one 322 Certificate option to carry server's certificate and one Server 323 Unicast option. It should be noted that the only function of Server 324 Unicast option is to provide the client with the server's IP address, 325 whether to unicast a message in the following process is depend on 326 the client side. 328 The server is allowed to add more options in the Authenticate-reply 329 message to provide any other information that it is willing to 330 present to the client. If the server receives an Authenticate 331 message twice, it will resend an Authenticate-reply message. 333 If a server does not support the Secure Access mechanism defined in 334 this document, it will simply discard the received Authenticate 335 message and do nothing else. 337 6.3. Behaviour in Lightweight Mode 339 The Secure Access mechanism also supports a lightweight mode that the 340 authentication is only based on server certificates. Under this 341 circumstance, the server does not need to validate the client's 342 certificate. If a client wishes to start the Secure Access mechanism 343 in a lightweight mode, it will multicast the Authenticate message 344 without any option in it. If the server receives an Authenticate 345 message without any option, it is an indication that the lightweight 346 mode is employed. The server simply skips the process of validating 347 a client, responds the Authenticate-reply with the server 348 certificate. Then the client follows the same process after sending 349 out Authenticate message as described in section 6.1 to finish the 350 mechanism. 352 7. Further Protection Considerations 354 The Secure Access mechanism follows the peer entity authentication 355 principle defined in section 6.3, second bullet of [RFC6973]. With 356 the mechanism employed, it is possible for a client to find a 357 legitimate server and then build a trusted relationship with it. The 358 trusted relationship also makes further protection measures feasible. 359 This section briefly discusses such two further protection methods 360 that can be used to protect the later standard DHCPv6 process. 362 7.1. Unicast 364 In a typical DHCPv6 process, a client is always not aware of the 365 server's address when it sends the first message (i.e. Solicit 366 message). Thus DHCPv6 makes use of multicast to send the Solicit 367 message to any available server on the same link. The multicast 368 characteristic encourages more rogue servers or eavesdroppers to 369 appear. If the client could unicast message to the server, the 370 privacy could be improved effectively. Following the [RFC3315], a 371 client could unicast its message if it receives a Server Unicast 372 option from the server. However in the current design, it is 373 impossible to unicast a Solicit message or an Information-Request 374 message which also contains important client information. This is 375 due to both messages are always the first message in the standard 376 DHCPv6 transaction (Client-server Exchange Involving Two Messages and 377 Four Messages respectively). 379 With the Secure Access mechanism, the scenario that a Solicit message 380 or an Information-Request could not be unicast would be solved. 382 Since the server includes a Server Unicast option in the 383 Authenticate-reply which is received before the standard DHCPv6 384 process. If the server can be proved as a legitimate server through 385 the Secure Access mechanism, the client could then use the server 386 address embedded in the Server Unicast option to unicast its Solicit 387 message or Information-request message. It should be noted that the 388 client may record multiple legitimate servers, it should choose one 389 to start unicast transaction based on a local policy. The detailed 390 policy is out of scope of this document. 392 7.2. Encryption 394 DHCPv6 message contains various identifiers that may expose important 395 client information. Confidentiality is always a better way to 396 improve the privacy since it can make the data secret from the 397 eavesdroppers. There are various encryption patterns could be used 398 to add confidentiality to the DHCPv6 process, but each of them would 399 require a pre-authentication to validate the identity of the two 400 endpoints. 402 The Secure Access mechanism just provides such an end-to-end 403 authentication to support the further encryption pattern. Encryption 404 also introduces some drawbacks such as more overhead, larger packet 405 size and so on. The encryption scheme for DHCPv6 should be 406 lightweight and do not need to be perfect. The further details of 407 DHCPv6 confidentiality is out of scope of this document and could be 408 defined in another separate document. 410 8. Security Considerations 412 TBD 414 9. IANA Considerations 416 This document defines two new DHCPv6 [RFC3315] messages. IANA is 417 requested to assign the following new DHCPv6 Message types in the 418 registry maintained in http://www.iana.org/assignments/ 419 dhcpv6-parameters: 421 AUTHENTICATE 423 AUTHENTICATE-REPLY 425 10. References 426 10.1. Normative References 428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 429 Requirement Levels", BCP 14, RFC 2119, March 1997. 431 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 432 and M. Carney, "Dynamic Host Configuration Protocol for 433 IPv6 (DHCPv6)", RFC 3315, July 2003. 435 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 436 Housley, R., and W. Polk, "Internet X.509 Public Key 437 Infrastructure Certificate and Certificate Revocation List 438 (CRL) Profile", RFC 5280, May 2008. 440 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 441 Morris, J., Hansen, M., and R. Smith, "Privacy 442 Considerations for Internet Protocols", RFC 6973, July 443 2013. 445 10.2. Informative References 447 [I-D.ietf-dhc-dhcpv6-privacy] 448 Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy 449 considerations for DHCPv6", draft-ietf-dhc- 450 dhcpv6-privacy-00 (work in progress), February 2015. 452 [I-D.ietf-dhc-sedhcpv6] 453 Jiang, S., Shen, S., Zhang, D., and T. Jinmei, "Secure 454 DHCPv6", draft-ietf-dhc-sedhcpv6-06 (work in progress), 455 February 2015. 457 Authors' Addresses 459 Yiu L. Lee 460 Comcast 461 One Comcast Center 462 Philadelphia, PA 19103 463 U.S.A 465 Email: yiu_lee@cable.comcast.com 466 Yong Cui 467 Tsinghua University 468 Beijing 100084 469 P.R.China 471 Phone: +86-10-6260-3059 472 Email: yong@csnet1.cs.tsinghua.edu.cn 474 ZiLong Liu 475 Tsinghua University 476 Beijing 100084 477 P.R.China 479 Phone: +86-10-6278-5822 480 Email: liuzilong8266@163.com 482 Linhui Sun 483 Tsinghua University 484 Beijing 100084 485 P.R.China 487 Phone: +86-10-6278-5822 488 Email: lh.sunlinh@gmail.com