| DHC Working Group | Y. Lee |
| Internet-Draft | Comcast |
| Intended status: Informational | Y. Cui |
| Expires: September 9, 2015 | Z. Liu |
| L. Sun | |
| Tsinghua University | |
| March 8, 2015 |
Secure Access Mechanism for DHCPv6
draft-yiu-dhc-dhcpv6-sa-00
DHCPv6 [RFC3315] provides configuration parameters such as IPv6 network addresses for hosts. The unencrypted nature and use of various identifiers make its privacy and security become more vulnerable. With appropriate protection mechanisms, the privacy and security can be improved to some extent. This document specifies such a mechanism that builds a trusted relationship between DHCPv6 clients and servers before solicitation. The mechanism enables a valid client to find and access the legitimate server or reject and blacklist a rogue server.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 9, 2015.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
[RFC3315] specifies the Dynamic Host Configuration Protocol for IPv6. [I-D.ietf-dhc-dhcpv6-privacy] analyzes the DHCPv6 privacy issues and discusses how various identifiers used in DHCPv6 could become a source for gleaning additional information of an individual. Such identifiers are included in various DHCPv6 messages. In other words, there are important client information embedded in DHCPv6 messages. If the messages are sent to a rogue server or an invalid third party, end users' privacy and security may be compromised.
Current authentication models include secure DHCPv6 [I-D.ietf-dhc-sedhcpv6] and authentication mechanism defined in [RFC3315]. Both share the primary goal of validating the identity of message sender. They were not designed to protect client privacy. DHCPv6 messages such as SOLICIT contains sensitive client information, these messages are not protected. Further, current authentication mechanisms focus more on the identity of clients, they do not provide full authentication of the DHCPv6 server (e.g. server authentication in secure DHCPv6 is based on leap of faith). Current authentication mechanisms aim to protect the DHCPv6 server by preventing invalid clients from launching attacks such as DoS attack. However when considered client privacy, the authenticity of server really matters.
Hence there is a requirement to design a mechanism that sets up a trusted relationship between a client and a server before starting the DHCPv6 transaction (i.e. before DHCPv6 solicitation). In this document, we propose such a peer entity authentication called Secure Access by defining two new DHCPv6 messages. The Secure Access mechanism makes use of server and client certificates and achieves authentication through Public Key Infrastructure ([RFC5280]). With the designed mechanism, a valid client can find and access the legitimate server or reject and blacklist a rogue entity before standard DHCPv6 process.
The Secure Access mechanism specified in this document does not affect the current DHCP design. It is more like an alternative extension, only the client who wants to improve the privacy will use it. Another benefit is that further data protection solution such as encryption can be based on the trusted relationship built by this mechanism.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
This section briefly introduces the existed authentication models and discusses their pros and cons when compared with the design in this document.
Authentication mechanism defined in [RFC3315] provides a basic verification of DHCPv6 messages sender and contents through using an Authentication option. The Authentication option can be treated as a symmetric key, which is a simple but limited authentication pattern. Two specific protocol, Delayed Authentication Protocol and Reconfigure Key Authentication Protocol, are proposed along with this option. This authentication framework also allows future separate authentication protocols to be put forward but it seems not to be deployable.
Secure DHCPv6 ([I-D.ietf-dhc-sedhcpv6]) enhance the security of DHCPv6 by using server's public/private key pairs and client's certificates to authenticate. To ease the pre-configuration of authentication, the client make a leap of faith to trust the server. While the server provide full authentication of client through validating its certificate. Secure DHCPv6 also enables the recipient to check the message integrity and offers anti-replay protection using timestamps. Compared with authentication mechanism in [RFC3315], secure DHCPv6 is more lightweight and provide better protection when refers to the authentication of DHCPv6 clients.
The Secure Access mechanism defined in this document is mainly based on the server and client's certificates. Similar to secure DHCPv6, we also make use of PKI (Public Key Infrastructure) to authenticate relevant entities. Since both certificates of client and server are required, a full bidirectional authentication between client and server is available. The certificates used in this document are all X.509 v3 certificates whose details can be found in [RFC5280].
If a client desires to improve privacy when using DHCPv6, it can initiate the Secure Access process to achieve a peer entity authentication. The client applies for its public key certificate from a CA (Certificate Authority) which is signed by the CA's private key. Then the client implements a new DHCPv6 message called Authenticate and multicasts it to the servers. The Authenticate message MUST carry the Certificate option defined in [I-D.ietf-dhc-sedhcpv6] to provide server with client's public key certificate. It is RECOMMENDED that the Authenticate message does not carry options other than Certificate option for the privacy.
A legitimate server also needs to get its own certificate from CA as the client does. The server receives the Authenticate message needs to verify the client's certificate. Typically it uses the CA's public key to validate whether the client is trusted or not. Detailed process of the authentication is described in [RFC5280] and is out of scope of this document. If the client is valid, the server will respond a new DHCPv6 message called Authenticate-reply message which contains a Certificate option (carry the server's public key certificate) and a Server Unicast option. It is possible for the server to carry more information (more options) in the Authenticate-reply message (e.g. Server Unicast option).
The initiated client MAY receive more than one Authenticate-reply messages from different servers. It verifies each Authenticate-reply message by validating corresponding server certificate through PKI. If the Authenticate-reply message does not contain a Certificate option or the verification fails, the client will discard the message and further blacklist the server. The client remember those servers who pass the verification as legitimated ones. In this way, the client can find legitimate servers and trigger the normal DHCPv6 process in a more protected way (e.g. unicast or encryption).
This mechanism provides an end-to-end authentication between DHCPv6 clients and servers. When a relay agent is involved, the only function it performs is forwarding. Also the relay agent does not allowed to add any additional options.
The Secure Access mechanism also supports another lightweight mode which only based on the server's certificate. Since it is uncommon for a client to obtain a certificate from the CA, we have to make the mechanism applied to such a scenario that only server certificate is available. This may sacrifice the security of a DHCPv6 server to some extent but will not do harm to the client privacy. Since the server responses usually do not contain much client information. In this lightweight mode, the server responds an Authenticate-reply message as soon as it received a Authenticate message from the client. Then the client performs the same process as the common mode has described.
Two new DHCPv6 messages are defined to achieve the peer entity authentication between clients and servers before standard DHCPv6 process. The Authenticate message is always sent by the client to carry its certificate and the Authenticate-reply message is sent by the server for client to validate its legitimacy. This section describe the two new messages formats and structures.
Both Authenticate and Authenticate-reply message use the Client/Server message formats described in Section 6 of [RFC3315]. Two new message codes are defined in the following.
AUTHENTICATE (TBA1): The client multicasts an Authenticate message to available servers to request for legitimate servers. The Authenticate message contains client's certificate for server to check its validity.
AUTHENTICATE-REPLY (TBA2): The server sends an Authenticate-reply message to requesting client to prove its legitimacy by carrying the Certificate option. It also needs to include a Server Unicast option to provide the client with its address.
This section describes the behaviour of DHCPv6 clients and servers when Secure Access mechanism is deployed. It is suitable for the clients who are concerned about their privacy and are eager to improve it. All the behaviours are prior to the standard DHCPv6 process, that is to say the Secure Access mechanism will be finished before the DHCPv6 Solicit message is sent to the server.
If a client wants to improve its privacy by finding a legitimate server to communicate, it will be more reasonable that the requesting client is also valid. In the context of this document, only valid clients can obtain their certificates from a trusted CA. That would require the CA to judge whether a client is valid or not. A common and simple solution is to make the trusted CA handled by the ISP. In this way, the trusted CA could easily achieve the verification through ISP's registration data. While there could be more extra solutions and the actual CA implementation is out of scope of this document. A valid client can only have one certificate which is signed by the trusted CA.
Once the client obtains its certificate, it can trigger the Secure Access mechanism by multicasting the Authenticate message to the servers (i.e. using the multicast addresses defined in [RFC3315]). The client MUST insert only one Certificate option in the Authenticate message. The Certificate option is used to carry the client's certificate and is defined in [I-D.ietf-dhc-sedhcpv6]. In order not to leak any client information in the Secure Access phase, it is also RECOMMENDED that the Authenticate message does not include any other options except for Certificate option.
After sending out the Authenticate message, the client is waiting for servers' response. During this period, it will discard any DHCPv6 message that the message type is not AUTHENTICATE-REPLY. The client is not allowed to send any other message whose message type is not AUTHENTICATE until it finds an authenticated server.
On receipt of servers' Authenticate-reply messages, it first checks the options field. The client simply discards the message if it includes neither Certificate option nor Server Unicast option. If the Authenticate-reply message include a Server Unicast option but not a Certificate option, the client will blacklist this server as a rogue server. If the Authenticate-reply message include a Certificate option but not a Server Unicast option, the client will also discard the received message. When both Certificate option and Server Unicast option exist, the client extracts the Certificate options then verifies it through PKI. If the verification fails, the client will blacklist the server. The client remembers servers who pass the verification as legitimate servers and choose one to build trusted relationship. Based on the trusted relationship, the client can employ further protection means to initiate a standard DHCPv6 process. The further protection means are discussed in Section 7.
The client should implement a timer locally. If it has not received any Authenticate-reply message when the timer expires, it will reset the timer and resend its Authenticate message. If it still could not receive any Authenticate-reply in the second expiration, the client would treat this condition as a failure of authentication. There could be various solutions for the failure such as reporting to the user or starting standard DHCPv6 process that ignores the failure condition. Which solution is employed is dependent on the client side policy. The timer expiration and client side policy would vary in different scenarios, hence their implementations are out of scope of this document.
If a server is legitimate and support the Secure Access mechanism defined in this document, it should obtain its certificate from the same trusted CA when it is configured. Such server should provide services for both standard DHCPv6 process and DHCPv6 with Secure Access. When it receives a standard DHCPv6 message (e.g. Solicit), it just follows the procedure defined in [RFC3315].
When the server receives an Authenticate message, it is an indication that the client wishes to build a trusted relationship with a legitimate server. The server who is willing to be accessed by such a client extracts the Certificate option to validate the client through PKI. If there is no Certificate option or the authentication fails, the server will simply discard this message. If the client can be proved to be valid (i.e. its certificate is trusted), the server will respond an Authenticate-reply message to the valid client. The Authenticate-reply message MUST include only one Certificate option to carry server's certificate and one Server Unicast option. It should be noted that the only function of Server Unicast option is to provide the client with the server's IP address, whether to unicast a message in the following process is depend on the client side.
The server is allowed to add more options in the Authenticate-reply message to provide any other information that it is willing to present to the client. If the server receives an Authenticate message twice, it will resend an Authenticate-reply message.
If a server does not support the Secure Access mechanism defined in this document, it will simply discard the received Authenticate message and do nothing else.
The Secure Access mechanism also supports a lightweight mode that the authentication is only based on server certificates. Under this circumstance, the server does not need to validate the client's certificate. If a client wishes to start the Secure Access mechanism in a lightweight mode, it will multicast the Authenticate message without any option in it. If the server receives an Authenticate message without any option, it is an indication that the lightweight mode is employed. The server simply skips the process of validating a client, responds the Authenticate-reply with the server certificate. Then the client follows the same process after sending out Authenticate message as described in section 6.1 to finish the mechanism.
The Secure Access mechanism follows the peer entity authentication principle defined in section 6.3, second bullet of [RFC6973]. With the mechanism employed, it is possible for a client to find a legitimate server and then build a trusted relationship with it. The trusted relationship also makes further protection measures feasible. This section briefly discusses such two further protection methods that can be used to protect the later standard DHCPv6 process.
In a typical DHCPv6 process, a client is always not aware of the server's address when it sends the first message (i.e. Solicit message). Thus DHCPv6 makes use of multicast to send the Solicit message to any available server on the same link. The multicast characteristic encourages more rogue servers or eavesdroppers to appear. If the client could unicast message to the server, the privacy could be improved effectively. Following the [RFC3315], a client could unicast its message if it receives a Server Unicast option from the server. However in the current design, it is impossible to unicast a Solicit message or an Information-Request message which also contains important client information. This is due to both messages are always the first message in the standard DHCPv6 transaction (Client-server Exchange Involving Two Messages and Four Messages respectively).
With the Secure Access mechanism, the scenario that a Solicit message or an Information-Request could not be unicast would be solved. Since the server includes a Server Unicast option in the Authenticate-reply which is received before the standard DHCPv6 process. If the server can be proved as a legitimate server through the Secure Access mechanism, the client could then use the server address embedded in the Server Unicast option to unicast its Solicit message or Information-request message. It should be noted that the client may record multiple legitimate servers, it should choose one to start unicast transaction based on a local policy. The detailed policy is out of scope of this document.
DHCPv6 message contains various identifiers that may expose important client information. Confidentiality is always a better way to improve the privacy since it can make the data secret from the eavesdroppers. There are various encryption patterns could be used to add confidentiality to the DHCPv6 process, but each of them would require a pre-authentication to validate the identity of the two endpoints.
The Secure Access mechanism just provides such an end-to-end authentication to support the further encryption pattern. Encryption also introduces some drawbacks such as more overhead, larger packet size and so on. The encryption scheme for DHCPv6 should be lightweight and do not need to be perfect. The further details of DHCPv6 confidentiality is out of scope of this document and could be defined in another separate document.
TBD
This document defines two new DHCPv6 [RFC3315] messages. IANA is requested to assign the following new DHCPv6 Message types in the registry maintained in http://www.iana.org/assignments/dhcpv6-parameters:
AUTHENTICATE
AUTHENTICATE-REPLY
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC3315] | Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. |
| [RFC5280] | Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R. and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. |
| [RFC6973] | Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M. and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, July 2013. |
| [I-D.ietf-dhc-dhcpv6-privacy] | Krishnan, S., Mrugalski, T. and S. Jiang, "Privacy considerations for DHCPv6", Internet-Draft draft-ietf-dhc-dhcpv6-privacy-00, February 2015. |
| [I-D.ietf-dhc-sedhcpv6] | Jiang, S., Shen, S., Zhang, D. and T. Jinmei, "Secure DHCPv6", Internet-Draft draft-ietf-dhc-sedhcpv6-06, February 2015. |