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

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 server authentication and encryption between the DHCPv6 client and server.

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 March 2, 2016.

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
• 2. Requirements Language
• 3. Solution Overview
• 4. Client Behavior
• 5. Server Behavior
• 6. New DHCPv6 Messages
• 7. New DHCPv6 Options
• 8. Security Considerations
• 9. IANA Considerations
• 10. Contributors
• 11. References
• 11.1. Normative References
• 11.2. Informative References
• Authors' Addresses

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. 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 limits the use of the certain options and 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. In addition, a separate encryption mechanism such as DTLS is also infeasible for DHCPv6, because the DHCPv6 relay can not recognize the 'secure' DHCPv6 message and may drop the DTLS messages.

The proposed solution achieves the server authentication and encryption between DHCPv6 client and server. The DHCPv6 server authentication is achieved before the DHCPv6 configuration process. The Information-request and Reply message exchange is used to contain the server's certificate. 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.

The proposed secure mechanism can provide the following functions to improve security of DHCPv6:

• authenticate the DHCPv6 server.
• Encrypt the DHCPv6 configuration messages between DHCPv6 client and server once the public keys exchange is completed.
• Anti-replay protection based on timestamps.

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 Overview

This solution proposes the server authentication before the standard DHCPv6 transactions; Once the authentication, the following DHCPv6 messages are encrypted with the recipient's public key. The encrypted DHCPv6 messages 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 proposed mechanism is used for the stateful DHCPv6 session starting with a SOLICIT message and the stateless DHCPv6 session starting with an Information-Request message.

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. A trust relationship for a certificate could be established by TOFU with option of other stronger mechanism depending on the application need. TOFU can be used by a client to authenticate a server and its message in default without a pre-established trust relationship between the client and the server.

The solution adds a two-way communication before the standard DHCPv6 configuration process. The DHCPv6 client firstly multicasts an Information-request message to the DHCPv6 servers. The Information-request message is RECOMMENDED to contain no options, so that it reveals no private information of the client. When receiving the Information-Request message, the server replies the Reply message that contains the server's certificate, timestamp, signature and DUID. Upon the receipt of the 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. For the stateful/stateless scenario, the Solicit/Information-request 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 DHCPv6 server sends the Encrypted-Response message to client which contains the Encrypted-Message option. The following figure shows the DHCPv6 authentication and encryption procedure for the client-server exchanges involving four messages.

[RFC7283] enables relays to support the newly defined DHCPv6 messages without any change.

        +-------------+                           +-------------+
        |DHCPv6 Client|                           |DHCPv6 Server|
        +-------------+                           +-------------+
               |            Information-Request           |                            
               |----------------------------------------->|
               |                                          |
               |                    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

4. Client Behavior

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 Information-Request message to the DHCPv6 servers. To protect the client's privacy, the Information-Request message is RECOMMENDED to 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 Reply message, it validates the server's identity and checks the timestamp. The server's authentication could be established by TOFU with option of other stronger mechanism depending on the application need. TOFU calls for accepting and storing a certificate associated with an asserted identity, without authenticating that assertion. The client creates a local trusted certificate record list for the verified certificate and the corresponding server identifier. A certificated that finds a match in the local trust certificate list is treated as verified. The timestamp is checked according to the rule defined in [I-D.ietf-dhc-sedhcpv6]. For the authenticated servers, the client selects one DHCPv6 server for network parameters configuration. And the following DHCPv6 message is encrypted using the elected server's public key.

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

5. Server Behavior

When the DHCPv6 server receives the Information-Request message, it replies the 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.

6. New DHCPv6 Messages

There are 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)                          .
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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