Opportunistic Security for DHCPv6
draft-li-dhc-secure-dhcpv6-deployment-00

Abstract

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCPv6 servers to configure network parameters. To secure DHCPv6, the authentication and encryption mechanisms are proposed to protect the DHCPv6 privacy information. However, how to deploy the secure DHCPv6 mechanisms for DHCPv6 is not specified. This draft analysis the DHCPv6 threat model and various key management schemes for DHCPv6 deployment, and recommend the opportunistic security for DHCPv6 deployment.

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 April 12, 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. DHCPv6 threat model
• 4. Secure DHCPv6 mechanisms deployment
• 5. Opportunistic security for DHCP
• 6. Security Considerations
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses

1. Introduction

The Dynamic Host Configuration Protocol for IPv6 [RFC3315] enables DHCPv6 servers to configure network parameters dynamically. Due to the unsecured nature of DHCPv6, the various critical identifiers in DHCPv6 are vulnerable to several types of attacks, such as pervasive monitoring and spoofing attack. Currently, there have been some proposed mechanism to secure DHCPv6. Secure DHCPv6 [I-D.ietf-dhc-sedhcpv6] provides the authentication mechanism between DHCPv6 client and server along with the DHCPv6 transaction. [I-D.cui-dhc-dhcpv6-encryption] proposes the DHCPv6 encryption mechanism between the DHCPv6 client and server. However, how to deploy the proposed secure DHCPv6 mechanisms such as the key management is still not specified.

This document analyses the DHCPv6 threat model and the two secure DHCPv6 mechanisms deployment schemes: TOFU and PKI, which are suitable for different DHCPv6 security requirement. In order to meet the requirement of the different DHCPv6 security service, we recommend the opportunistic security for DHCPv6 deployment.

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. DHCPv6 threat model

Most of the privacy consideration for DHCPv6 focuses on the client privacy protection. As the public service infrastructure, the privacy protection of DHCPv6 server and relay agent is less important. DHCPv6 privacy consideration [I-D.ietf-dhc-dhcpv6-privacy] analyses the privacy problem for DHCPv6 client, which lists the various DHCPv6 options containing the privacy information and the possible attack to the DHCPv6 client. The attack specific to a DHCPv6 client is the possibility of the "rogue" server, which MAY provide the incorrect information to the client. In addition, the client is also faced with the pervasive monitoring attack. Pervasive monitoring MAY gleans the privacy information about the IPv6 host, which is used to find location information, previously visited networks and so on. [RFC7258] claims that pervasive monitoring should be mitigated in the design of IETF protocols, where possible.

The attack specific to a DHCPv6 server is the possibility of the invalid client masquerading as a valid client, which may cause the consuming to the address resources for DHCPv6 server.

4. Secure DHCPv6 mechanisms deployment

There have been some proposed secure DHCPv6 mechanisms. Secure DHCPv6 [I-D.ietf-dhc-sedhcpv6] provides the authentication mechanism between DHCPv6 client and server along with the DHCPv6 transaction. [I-D.cui-dhc-dhcpv6-encryption] proposes the DHCPv6 encryption mechanism between the DHCPv6 client and server. For the secure DHCPv6 mechanism deployment, the DHCPv6 server is always considered to have connectivity to authorized CA and verify the client's certificate. The difficulty for the deployment is that the client is difficult to verify the server's identity without access to network. How to deploy secure DHCPv6 mechanisms is based on the DHCPv6 security requirement and the client capability.

TOFU MAY play a role in the scenario where the DHCPv6 client is mobile and connects to random networks such as public coffee shops. In such scenario, the secure policy is loss and the DHCPv6 client MAY not previously establish the trusted relationship between the DHCPv6 server and client. The TOFU model assumes that an authenticated public key obtained on first contact is good enough to secure future communication. In addition, for the subsequent connections, if the received public key is conflicts with the cached key, the user MAY change the current cached kay without any validation. TOFU-based authentication has a clear improvement over completely insecure protocols, and it is also low-cost and simple to deploy. However, TOFU-based authentication make it difficult to distinguish rouge DHCPv6 servers by accepting any key on the initial connection. And it also has no protection against MitM attacks without the validation of the conflicted public key.

In the scenario where the tight security policy is required and the client are stable terminal devices, the PKI model MAY play a role to verify the certificate and perform the authentication. The client validates the server's certificate locally according to the rule defined in [RFC5280] through the preconfigured information. The client is preconfigured the trusted relationship between the DHCPv6 client and server, or one or multiple CA certificates, which form the certificate path. The PKI model achieve the authentication of the certificate all the time, which improve the security performance. However, without the preconfigured information, the DHCPv6 communication will fail. And it also brings the deployment difficulties.

5. Opportunistic security for DHCP

TOFU and PKI model are all comprehensive security protection against both passive and active attacks. If the authentication fails, the DHCPv6 transaction is clear text without any protection. For DHCPv6 service, the client is always cannot authenticate the server without access to network. So we propose the opportunistic security [RFC7435] for DHCPv6, which aims to achieve the maximum protection that is available.

Opportunistic security for DHCPv6 use encryption even when authentication is not available. Based on the DHCPv6 security requirement and the client capability, the incremental deployment is supported. When the client is pre-configured the server authentication information, such as one or multiple CA certificate which forms the certification path. Through the pre-configured CA certificate, the server's identity is verified according to the rule defined in [RFC5280]. When the client is not pre-configured the server authentication information, the client has no capability to verify the server's identity. If the server is authenticated and the public keys are exchanged, the communication is authenticated and encrypted, which protects the DHCPv6 transaction from passive and active attacks. If the server is not authenticated and the public keys are exchanged, the communication is not authenticated but encrypted, which protects the DHCPv6 transaction from passive attacks, such as pervasive monitoring attack. And encryption without authentication is better than clear text. If the server is not authenticated and the public keys are also not exchanged, clear text is used as the baseline communication security policy.

In the scenario where the tight security policy is required, such as the enterprise networks, the authentication and encryption are always both required. Opportunistic security can coexist with the explicit and never preempt the explicit security policies. For example, the enterprise's explicit policy is that authenticated and encrypted communication is required, which covers the default opportunistic security policy.

In the scenario where the security policy is loss, the DHCPv6 server MAY NOT be preconfigured the authentication information, such as the trusted relationship between the server and client, or the trusted CA certificates. It is difficult for the client to verify the server's certificate without access to the network. So the server authentication is optional in order to not impede the following DHCPv6 communication. After the public keys exchange, the non-authenticated encryption communication is applied to avoid the passive attack. In this way, the DHCPv6 message content is protected from the pervasive monitoring.

6. Security Considerations

TBD

7. References

7.1. Normative References

7.2. Informative References

Authors' Addresses