| DHC Working Group | Y. Cui |
| Internet-Draft | L. Li |
| Intended status: Standards Track | J. Wu |
| Expires: January 7, 2016 | Tsinghua University |
| L. Yiu | |
| Comcast | |
| July 6, 2015 |
Authentication and Encryption Mechanism for DHCPv6
draft-cui-dhc-dhcpv6-encryption-01
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCPv6 servers to configure network parameters. However, due to the unsecured nature, various critical identifiers used in DHCPv6 are vulnerable to several types of attacks, particularly pervasive monitoring. This document provides a mechanism to secure DHCPv6 messages, which achieves the server authentication and encryption based on sender's certificate/public key.
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 January 7, 2016.
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.
The Dynamic Host Configuration Protocol for IPv6 [RFC3315] enables DHCPv6 servers to configure network parameters dynamically. [I-D.ietf-dhc-dhcpv6-privacy] analyses the DHCPv6 privacy issues and discusses how various identifiers used in DHCPv6 could become a source for gleaning additional information of an individual. Due to the unsecured nature of DHCPv6, the various critical identifiers are vulnerable to several types of attacks, particularly pervasive monitoring [RFC7258].
Prior work has addressed some aspects of DHCPv6 security, but until now there has been little work on privacy between a DHCPv6 client and server. Secure DHCPv6 [I-D.ietf-dhc-sedhcpv6] provides the authentication mechanism between DHCPv6 client and server along with the DHCPv6 transaction. However, the DHCPv6 message is still transmitted in clear text and the private information within the DHCPv6 message is not protected from pervasive monitoring. The IETF has expressed strong agreement that PM is an attack that needs to be mitigated where possible. Anonymity profile for DHCP clients [I-D.ietf-dhc-anonymity-profile] provides guidelines on the composition of DHCPv4 or DHCPv6 request to minimize the disclosure of identifying information. However, anonymity profile cannot protect the all identifiers used in DHCP if new option containing some private information is defined. In addition, the anonymity profile cannot work in some situation where the clients want anonymity to attackers but not to the valid DHCP server.
The document discusses two possible solutions to achieve the server authentication and encryption between DHCPv6 client and server. It should be noted that the two solutions cannot coexist at the same time. One solution need to be selected to solve the DHCPv6 privacy problem. Solution A specifies a security mechanism which achieve the server authentication before the DHCPv6 configuration process. Two new DHCPv6 messages, Encryption-Request and Encryption-Reply, are defined to exchange the certificates, timestamps, signatures of the server. After the server authentication, the following DHCPv6 messages are encrypted and encapsulated into two newly defined DHCPv6 messages: Encrypted-Query and Encrypted-Response. In this way, identifiers including the entity's DUID are protected from pervasive monitoring.
In solution B, the server authentication process is done during the Solicit-Advertise exchange. The following DHCPv6 messages are encrypted using public keys, and are also encapsulated into Encrypted-Query and Encrypted-Response. In this way, the DHCPv6 server and client's privacy is protected.
The proposed secure mechanism can provide the following functions to improve security of DHCPv6 client and server:
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 solution proposes the client authenticates the server before standard DHCPv6 transactions; The server and client use public keys to encrypt all other DHCPv6 messages.
In the authentication process, two new client-server DHCPv6 messages, Encryption-Request and Encryption-Reply, are defined for the server authentication. Once the server authentication is finished, the following DHCPv6 transactions can be encrypted using the sender's public key. The encrypted DHCPv6 messages for the following transactions [RFC3315] are put into the newly defined Encrypted-Message option, and encapsulated into Encrypted-Query and Encrypted-Response DHCPv6 messages that are defined in this document. The Encrypted-Query message is sent from client to server, which contains the server identifier option and an Encrypted-Message option. The Encrypted-Response message is sent from server to client, containing the Encrypted-Message option.
This solution is based on the public/private key pairs of the DHCPv6 client and server. The server and client firstly generate a pair of public/private keys. The server should acquire a public key certificate from the CA that signs the public key. The deployment of the PKI is out of the scope of this document. If the client does not have public/private key pair, cleartext is used as the baseline communication security policy.
The solution adds a two-way communication before the DHCPv6 configuration process. The DHCPv6 client firstly multicasts an Encryption-Request message to the DHCPv6 servers. The message contains no options, so that it reveals no private information of the client. When receiving the Encryption-Request message, the server replies the Encryption-Reply message that contains the server's certificate, signature and DUID.
Upon the receipt of the Encryption-Reply message, the DHCPv6 client verifies the identity of the DHCPv6 server and checks the timestamp. If the validation and timestamp check are successful, the client gets the server's DUID as well as the public key from the certificate. For the authenticated servers, the client selects one DHCPv6 server for network parameters configuration.
After the server authentication, the following DHCPv6 messages are encrypted with the recipient's public key and encapsulated into the Encrypted-Message option. The Solicit message MUST contain the public key option, the timestamp option and the signature option for client's public key exchange. The client sends the Encrypted-Query message to server, which carries the server identifier option and an Encrypted-Message option. The server identifier option is externally visible. For the authenticated target server, it decrypts the Encrypted-Message option by its private key. The DHCPv6 server drops message containing a server identifier option not matching the server's DUID, thus not paying cost to decrypt the message. The DHCPv6 server sends the Encrypted-Response message to client which contains the Encrypted-Message option.
[RFC7283] enables relays to support the newly defined DHCPv6 messages without any change.
+-------------+ +-------------+
|DHCPv6 Client| |DHCPv6 Server|
+-------------+ +-------------+
| Encryption-Request |
|----------------------------------------->|
| |
| Encryption-Reply |
|<-----------------------------------------|
| certificate option signature option |
| timestamp option |
| server identifier option |
| |
| Encryption-Query |
|----------------------------------------->|
| Encrypted-Message option (Solicit) |
| server identifier option |
| |
| Encryption-Query |
|<-----------------------------------------|
| Encrypted-Message option (Advertise) |
| |
| Encryption-Query |
|----------------------------------------->|
| Encrypted-Message option (Request) |
| server identifier option |
| |
| Encryption-Query |
|<-----------------------------------------|
| Encrypted-Message option (Reply) |
DHCPv6 Authentication and Encryption Procedure
If the client supports the secure mode, it MUST generate a public/private key pair. For the client supporting the secure mode, it multicasts the Encryption-Request to the DHCPv6 servers before sending SOLICIT message. To protect the client's privacy, the Encryption-Request message SHOULD reveal no private information to the server. To provide a "dummy" Encryption-Request message, it is RECOMMENDED to send the Encryption-Request message with no option.
When the DHCPv6 client receives the Encryption-Reply message, it validates the server's identity according to the rule defined in [RFC5280] and checks the timestamp according to the rule defined in [I-D.ietf-dhc-sedhcpv6]. The client creates a local trusted certificate record for the verified certificate and the corresponding server identifier. The client obtains the server's public key from the certificate. For the authenticated servers, the client selects one DHCPv6 server for network parameters configuration.
Once the public keys exchange is completed, the DHCPv6 messages sent from client to server are encrypted using the public key retrieved from the server's certificate. The encrypted DHCPv6 message is encapsulated into the Encrypted-Message option. The Encrypted-Query message is constructed with the Encrypted-Message option and server identifier option. The server identifier option is externally visible to avoid extra cost by those unselected servers. If the client fails to get the proper parameters from the chosen server, it will send the Encrypted-Query message to other authenticated servers for IPv6 configuration. The Solicit message MUST contain the public key option, the timestamp option and the signature option for client's public key exchange. The selected server is informed of the client's public key through the Solicit message which is decrypted from the Encrypted-Message option.
For the received Encrypted-Response message, the client extracts the Encrypted-Message option and decrypts it using its private key to obtain the original DHCPv6 message. Then it handles the message as per [RFC3315].
When the DHCPv6 server receives the Encryption-Request message, it replies the Encryption-Reply message to the client, which includes the server's digital signature, certificate, timestamp and server identifier.
On the receipt of Encrypted-Query message, the server checks the visible server identifier option. It decrypts the Encrypted-Message option using its private key if it is the target server. The DHCPv6 server drops the messages that are not for it, thus not paying cost to decrypt the message. If the decrypted message is the Solicit message, the server checks the timestamp and the signature. If the check succeeds, the server is informed of the client's public key through the contained public key option.
The DHCPv6 messages, which is sent from server to client, is encrypted using the public key from the client's certificate. The encrypted DHCPv6 message is encapsulated into the Encrypted-Message option. The Encrypted-Response message contains the Encrypted-Message option.
Once the authentication is completed, one DHCPv6 server is selected for address allocation from the authenticated DHCPv6 servers. And the following DHCPv6 message is encrypted using the selected server's public key. If the client fails to get the proper parameters from the chosen server, it will send the Encrypted-Query message to other authenticated server for parameters configuration until the client obtains the proper parameters. It should be noted that if the client does not have connectivity to an authority, there might be problem for the client to get the certificate and validate it, which potentially breaks the mechanism.
Another solution is also provided, which does not introduce new messages exchange procedure. The two solutions cannot coexist. One solution could be selected to solve the DHCPv6 privacy problem. This proposed solution is also based on the public/private key pairs of the DHCPv6 client and server. And the server obtains a public key certificate from CA that signs the public key. The deployment of the PKI is out of the scope of this document.
The server authentication and public keys exchange process are completed along with the DHCPv6 transaction. We recommend that the Solicit message is modified to carry no privacy information about the client, such as the client's DUID. In Solicit message, the client includes its public key for encryption, while in Advertise message, the server would include its own certificate.
For the encrypted message transaction, it follow the same encryption pattern as specified in solution A. There are one newly DHCPv6 option: Encrypted-Message option and two newly defined DHCPv6 message: Encrypted-Query and Encrypted-Response. The Encrypted-Message carries the encrypted DHCPv6 message. The Encrypted-Query message is sent from client to server, which contains the server identifier option and an Encrypted-Message option. The Encrypted-Response message is sent from server to client which contains the Encrypted-Message option.
The Solicit message is recommended to carry no privacy information of the client. Simultaneously, the client's public key, timestamp, signature are included in the Solicit message. The server encapsulates the encrypted Advertise message into the Encrypted-Message option. The server then sends the Encrypted-Response message to the client with Encrypted-Message option, the certificate option, the signature option, the timestamp option. The DHCPv6 client validates the server's identity and checks the timestamp. If the validation and timestamp check are successful, the client decrypts the Encrypted-Message option and get the Advertise message. For the following DHCPv6 transaction, the client sends the Encrypted-Query message to the server, which contains the server identifier option and Encrypted-Message option. The server sends the Encrypted-Response message to the client, which contains the Encrypted-Message option.
+-------------+ +-------------+
|DHCPv6 Client| |DHCPv6 Server|
+-------------+ +-------------+
| Solicit message |
|---------------------------------------------->|
| certificate option signature option |
| |
| Encrypted-Response message |
|<----------------------------------------------|
| certificate option signature option |
| Encrypted-Message option |
| |
| Encrypted-Query message |
|---------------------------------------------->|
| Server ID option Encrypted-Message option |
| |
| Encrypted-Response message |
|<----------------------------------------------|
| Encrypted-Message option |
| |
DHCPv6 Authentication Procedure
If the client supports the secure mode, it MUST generate a public/private key pair. For the client supporting the secure mode, it generates the Solicit message that carries no privacy information about the client, such as client's DUID. The client multicasts the Solicit message to the DHCPv6 servers, which contains the client's public key, timestamp and signature. After creating the entire DHCPv6 header and options, the signature is created that is signed by the client's private key.
When the DHCPv6 client receives the Encrypted-Response message with the certificate option, signature option, and timestamp option, it verifies the certificate according to the rule defined in [RFC5280] and checks the timestamps according to the rule defined in [I-D.ietf-dhc-sedhcpv6]. The client creates a local trust certificate record for the verified certificate and the corresponding server identifier. Simultaneously, the client decrypts the content of Encrypted-Message option to obtain the Advertise message.
Once the authentication is completed, the client sends the Encrypted-Query message to the server, which contains the server identifier option and Encrypted-Message option. The Encrypted-Message option contains the DHCPv6 message encrypted with the server's public key. The server identifier option is externally visible to avoid extra decryption cost by those unchosen servers.
When the client receives the Encrypted-Response message, the client decrypts the Encrypted-Message option to obtain the DHCPv6 message. The client follows the rules in [RFC3315] when handling the original DHCPv6 messages.
When the DHCPv6 server receives a Solicit message, it checks the timestamp and the signature. If the check is successful, it sends the Encrypted-Response message to the client, which includes the server's certificate, timestamp, signature and Encrypted-Message option containing the encrypted Advertise message.
After the Authentication, the server sends the Encrypted-Response message to client, which contains the Encrypted-Message option. For the received Encrypted-Query message, the server checks the server identifier option. It decrypts the Encrypted-Message option using its private key if it is the target server. The DHCPv6 server drops messages that are not targeted for it, thus not paying cost to decrypt the message.
According to [RFC3315], the client DUID is used for selecting addresses to assign to an IA. Other options which carries the privacy information, such as IA_NA or IA_TA, may also affect the address selection. In addtion, the Solicit message without client DUID violates Solicit message validation described in [RFC3315].
For solution A, there are four DHCPv6 message defined: Encryption-Request, Encryption-Reply, Encrypted-Query and Encrypted-Response. For sulution B, there are only two DHCPv6 message defined: Encrypted-Query and Encrypted-Response. Both DHCPv6 messages defined in this document share the following format:
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type | transaction-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . options . . (variable) . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The format of New DHCPv6 Messages
For the two solution, the Encrypted-Message option are all defined, which carries the DHCPv6 message that is encrypted with the recipient's public key.
The format of the DHCPv4 Message option is:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. encrypted DHCPv6 message .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Encrypted-Message Option Format
TBD
For solution A, there are four new DHCPv6 messages defined and one new DHCPv6 option defined. If the solution A is selected, the IANA is requested to assign values for these four new messages and one new option.
The four messages are:
The one option is:
For solution B, there are two new DHCPv6 messages defined and one new DHCPv6 option defined. If the solution B is selected, the IANA is requested to assign values for these two new messages and one new option.
The four messages are:
The one option is:
The authors would like to thank Bernie Volz, Ralph Droms, Yiu Lee, Tomek Mrugalski, Fred Baker, Qi Sun, Zilong Liu, Cong Liu.
| [I-D.ietf-dhc-sedhcpv6] | Jiang, S., Shen, S., Zhang, D. and T. Jinmei, "Secure DHCPv6", Internet-Draft draft-ietf-dhc-sedhcpv6-08, June 2015. |
| [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. |
| [RFC7283] | Cui, Y., Sun, Q. and T. Lemon, "Handling Unknown DHCPv6 Messages", RFC 7283, July 2014. |
| [RFC7435] | Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, December 2014. |
| [I-D.ietf-dhc-anonymity-profile] | Huitema, C., Mrugalski, T. and S. Krishnan, "Anonymity profile for DHCP clients", Internet-Draft draft-ietf-dhc-anonymity-profile-01, June 2015. |
| [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. |
| [RFC7258] | Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, May 2014. |