DHC Working Group Y. Cui
Internet-Draft L. Li
Intended status: Standards Track J. Wu
Expires: December 2, 2015 Tsinghua University
May 31, 2015

Authentication and Encryption Mechanism for DHCPv6
draft-cui-dhc-dhcpv6-encryption-00

Abstract

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 client/server authentication and encryption based on sender's certificates.

Status of This Memo

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 December 2, 2015.

Copyright Notice

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.


Table of Contents

1. Introduction

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.

The document discusses two possible solutions to achieve the authentication and encryption between DHCPv6 server and client. 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 achieves the authentication before encrypted DHCPv6 transaction. The identity of a DHCPv6 node is verified by the recipient before the DHCPv6 configuration process. Two new DHCPv6 messages, Encrypted-Request and Encrypted-Reply, are defined to exchange the certificates, timestamps, signatures of both sides. After the two-message authentication process, 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 authentication process is done during the Solicit-Advertise exchange. The following DHCPv6 messages are encrypted using public key, 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:

2. Requirements Language

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].

3. Solution A: Authentication before Encrypted DHCPv6

3.1. Solution Overview

This solution achieves mutual authentication before DHCPv6 transaction, and uses public keys to encrypt any following DHCPv6 messages. In the authentication process, two new DHCPv6 messages: Encrypted-Request and Encrypted-Reply are defined for exchanging certificate information. Encrypted-Request message is sent from DHCPv6 client to DHCPv6 server, which contains the signature option, the timestamp option and the certificate option defined in [I-D.ietf-dhc-sedhcpv6]. Encrypted-Reply message is sent from DHCPv6 server to DHCPv6 client, which contains the signature option, the certificate option, the timestamp option and server identifier option. Once the authentication process finished, the following DHCPv6 transaction are encrypted. One new defined DHCPv6 option: Encrypted-Message option and two new defined DHCPv6 messages: Encrypted-Query and Encrypted-Response are defined to fulfill the encryption pattern. The new defined Encrypted-Message option contains 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.

This solution is based on the public/private key pairs of the DHCPv6 client and server. The server and client first generate a public/private key pair and then obtain a public key certificate from CA that signs the public key. The deployment of the PKI is out of the scope of this document.

Before the DHCPv6 configuration process, the DHCPv6 client sends the Encrypted-Request message to the DHCPv6 server. Note that at this stage, the client does not send its DUID to the server for privacy protection. The client's identity is verified and the timestamp is checked for anti-replay protection. If the verification and timestamp check are successful, the server records the public key in its local key table and replies with an Encrypted-Reply message to the client. If the verification fails or the timestamp check fails, the server will discard the message or further blacklist the client.

Upon the receipte of the Encrypted-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. Otherwise, the client drops the message or blacklists the server.

        +-------------+                           +-------------+
        |DHCPv6 Client|                           |DHCPv6 Server|
        +-------------+                           +-------------+
        |            Encrypted-Request                  |                            
        |---------------------------------------------->|
        |    certificate option    signature option     |
        |                                               |
        |            Encrypted-Reply                    |
        |<----------------------------------------------|
        |    certificate option   signature option      |
        |         server identifier option              |
        |                                               |
		  

DHCPv6 Authentication Procedure

After successful mutual authentication, the following DHCPv6 messages are encrypted with the recipient's public key and encapsulated into the Encrypted-Message option. DHCPv6 client sends the Encrypted-Query message to server, which carries the server identifier option and an Encrypted-Message option. The Encrypted-Message option contains the encrypted DHCPv6 message. 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.

3.2. Client Behavior

The client MUST have a public/private key pair. The client is assigned a public key certificate by a CA.

If the client supports secure mode, before sending SOLICIT message, it multicasts the Encrypted-Request to the DHCPv6 servers before sending SOLICIT message. The Encrypted-Request message contains the signature option, timestamp option, certificate option. The certificate option carries the public key certificate of the client. The timestamp option carries the current time of the client. After creating the entire DHCPv6 header and options, the signature is created that is signed by the client's private key. The Encrypted-Request message MUST NOT contain the client's DUID or any other private information.

When the DHCPv6 client receives the Encrypted-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.

Once the authentication is completed, the client selects one authenticated DHCPv6 server for the following DHCPv6 transaction. 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.

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].

3.3. Server Behavior

When the DHCPv6 server receives the Encrypted-Request message, it validates the certificate according to the rule defined in [RFC5280] and checks timestamp according to the rule defined in [I-D.ietf-dhc-sedhcpv6]. If the verification and check are successful, the server creates a local trusted certificate record for verified certificates. And then it sends the Encrypted-Reply message to the client, which includes the server's digital signature, certificate, timestamp and server identifier. If the verification fails or the timestamp check fails, the server will discard the message or further blacklist the client.

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.

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.

3.4. Discussion: No certificate?

A trust relationship for a public key can be the result of Opportunistic Security [RFC7435] or explicit security policy. The explicit security policies preempt Opportunistic security. Opportunistic security maximizes the deployment of usable security without impeding communication. Cleartext is used as the baseline communication security policy if the authentication and encryption both are not supported. For more widely, authentication is optional for the encryption process. If the client does not have certificate but has public/private key pair to support encryption, any authentication check is disabled in order to avoid unnecessary communication failure. The use of encryption without authentication defends against pervasive monitoring and other passive attacks.

3.5. Possible Problem

Once the authentication is completed, one DHCPv6 server is selected for addr ess 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.

4. Solution B: Authentication with Encrypted DHCPv6

4.1. Solution Overview

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. The deployment of the PKI is out of the scope of this document.

The mutual authentication and public key 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 certificate for authentication, 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 certificate, timestamp, signature are included in the Solicit message. The DHCPv6 server validates the identity of the client and checks timestamp. If the verification and timestamp check is successful, the server encapsulates the Advertise message encrypted with the client's public key 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

4.2. Client Behavior

The client MUST have a public/private key pair. The client is assigned a public key certificate by a CA.

If the client supports 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 certificate, 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.

4.3. Server Behavior

When the DHCPv6 server receives a Solicit message, it verifies the certificate according to the rule defined in [RFC5280] and checks the timestamp. If the authentication is successful, the server creates a local trusted certificate record for verified certificates. And then 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.

4.4. Possible Problem

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].

5. New DHCPv6 Messages

For solution A, there are four DHCPv6 message defined: Encrypted-Request, Encrypted-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

msg-type
For solution A: Encrypted-Query (TBA1), Encrypted-Response (TBA2) Encrypted-Request (TBA3), Encrypted-Reply (TBA4). For solution B: Encrypted-Query (TBA1), Encrypted-Response (TBA2).
transaction-id
The transaction ID for this message exchange.
options
Options carried in this message.

6. New DHCPv6 Options

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

option-code
OPTION_Encrypted_MSG (TBA5 for solution A; TBA3 for solution B).
option-len
Length of the encrypted DHCPv6 message.
encrypted DHCPv6 message
The encrypted DHCPv6 message sent by the client or the server. In a Encrypted-Query message, it contains encrypted DHCPv6 message sent by a client. An Encrypted-response message contains encrypted DHCPv6 message sent by a server in response to a client.

7. Security Considerations

TBD

8. IANA Considerations

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:

  • Encrypted-Query message (TBA1).
  • Encrypted-Response message (TBA2).
  • Encrypted-Request message (TBA3).
  • Encrypted-Reply message (TBA4).

The one option is:

  • Encrypted-Message option (TBA5).

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:

  • Encrypted-Query message (TBA1).
  • Encrypted-Response message (TBA2).

The one option is:

  • Encrypted-Message option (TBA3).

9. Contributors

The authors would like to thank Bernie Volz, Ralph Droms, Yiu Lee, Tomek Mrugalski, Fred Baker, Qi Sun, Zilong Liu, Cong Liu.

10. References

10.1. Normative References

[I-D.ietf-dhc-sedhcpv6] Jiang, S., Shen, S., Zhang, D. and T. Jinmei, "Secure DHCPv6", Internet-Draft draft-ietf-dhc-sedhcpv6-07, March 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.

10.2. Informative References

[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.

Authors' Addresses

Yong Cui Tsinghua University Beijing, 100084 P.R.China Phone: +86-10-6260-3059 EMail: yong@csnet1.cs.tsinghua.edu.cn
Lishan Li Tsinghua University Beijing, 100084 P.R.China Phone: +86-15201441862 EMail: lilishan9248@126.com
Jianping Wu Tsinghua University Beijing, 100084 P.R.China Phone: +86-10-6278-5983 EMail: jianping@cernet.edu.cn