secure DHCPv6 deployment
draft-li-dhc-secure-dhcpv6-deployment-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Lishan Li , Yong Cui , Jianping Wu , Sheng Jiang | ||
| Last updated | 2015-12-16 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-li-dhc-secure-dhcpv6-deployment-02
DHC Working Group L. Li
Internet-Draft Y. Cui
Intended status: Informational J. Wu
Expires: June 18, 2016 Tsinghua University
S. Jiang
Huawei Technologies Co., Ltd
December 16, 2015
secure DHCPv6 deployment
draft-li-dhc-secure-dhcpv6-deployment-02
Abstract
Secure DHCPv6 provides authentication and encryption mechanisms for
DHCPv6. This draft analyses the DHCPv6 threat model and provides
guideline for secure 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 June 18, 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
Li, et al. Expires June 18, 2016 [Page 1]
Internet-Draft secure DHCPv6 deployment December 2015
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. DHCPv6 threat model . . . . . . . . . . . . . . . . . . . . . 2
3. Secure DHCPv6 mechanism deployment . . . . . . . . . . . . . 3
3.1. Secure DHCPv6 Overview . . . . . . . . . . . . . . . . . 3
3.2. Secure DHCPv6 Deployment Difficulties . . . . . . . . . . 3
3.3. Scenario with Loose Security Policy . . . . . . . . . . . 3
3.4. Scenario with Strict Security Policy . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative References . . . . . . . . . . . . . . . . . . 5
5.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
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. Secure DHCPv6
[I-D.ietf-dhc-sedhcpv6] provides the authentication and encryption
mechanisms for DHCPv6.
This document analyses the DHCPv6 threat model and provides some
guideline for secure DHCPv6 deployment. For the secure DHCPv6
deployment, we mainly consider two different scenarios: public coffee
room with loose security policy and enterprise network with strict
security policy.
2. DHCPv6 threat model
DHCPv6 privacy consideration [I-D.ietf-dhc-dhcpv6-privacy] analyses
the privacy problem for DHCPv6, listing the various DHCPv6 options
containing the privacy information and the possible attack to the
DHCPv6.
Most of the privacy considerations for DHCPv6 focus on the client
privacy protection. As the public service infrastructures, the
privacy protection of DHCPv6 server and relay agent is less
important. The attack specific to a DHCPv6 client is the possibility
of the injection attack, spoofing attack, and rogue server. Because
of the above attacks, the client may be configured with the incorrect
configuration information, such as invalid IPv6 address. In
addition, the client is also faced up with passive attacks, such as
pervasive monitoring. Pervasive monitoring may glean the privacy
Li, et al. Expires June 18, 2016 [Page 2]
Internet-Draft secure DHCPv6 deployment December 2015
information of 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 "denial
of service" (Dos) attack. Invalid clients may masquerade as valid
clients to request IPv6 addresses continually. The attack may cause
the exhaustion of valid IPv6 addresses, CPU and network bandwidth.
In addition, it also causes problem for the maintenance and
management of the large tables on the DHCPv6 servers.
3. Secure DHCPv6 mechanism deployment
3.1. Secure DHCPv6 Overview
Secure DHCPv6 [I-D.ietf-dhc-sedhcpv6] provides the authentication and
encryption mechanisms for DHCPv6. The Information-request and Reply
messages are exchanged to achieve the server authentication. Then
the DHCPv6 client authentication is achieved through the first
message sent from client to server, which contains the client's
certificate information. Once the mutual authentication, the
following DHCPv6 messages are all encrypted with the recipient's
public key.
The DHCPv6 server authentication protects the DHCPv6 client from
injection attack, spoofing attack, and rogue server. The DHCPv6
client authentication protects the DHCPv6 server from Dos attack.
The DHCPv6 encryption protects the DHCPv6 from passive attack, such
as pervasive monitoring.
3.2. Secure DHCPv6 Deployment Difficulties
Because of the DHCPv6's specific property, the deployment of secure
DHCPv6 mechanism faces some specific difficulties. The DHCPv6 server
is always assumed to have connectivity to authorized CA and able to
verify the client's certificate. The difficulty of deployment is
that it is hard for the client to obtain itself certificate signed by
CA or verify the server's identity without access to the network.
According to the different DHCPv6 security requirement and the
client's pre-configured information, different schemes for secure
DHCPv6 deployment are used.
3.3. Scenario with Loose Security Policy
In the scenario where the security policy is loose, such as public
coffee room, the opportunistic security policy plays a role.
Opportunistic security provides DHCPv6 encryption even when the
Li, et al. Expires June 18, 2016 [Page 3]
Internet-Draft secure DHCPv6 deployment December 2015
mutual authentication is not available.
In such scenario, the client is mobile and connects to random
networks. Based on the client's capability, the DHCPv6 configuration
process is either authenticated and encrypted, or non-authenticated
and encrypted.
When the client is pre-configured with the certificate signed by CA
and the information for server's identity verification, it has the
capability to achieve the DHCPv6 client and server authentication.
The DHCPv6 configuration process is authenticated and encrypted,
which protects the DHCPv6 transaction from passive and active
attacks.
When the client is not pre-configured with the certificate signed by
CA or the information for server's identify verification, the
communication is non-authenticated and encrypted. Non-authenticated
and encrypted communication is better than cleartext, which defends
against pervasive monitoring and other passive attacks. Although the
client is not capable of verifying the server's identity, the client
can obtain the server's public key through the server's certificate.
For the client authentication, the client can send the self-signed
certificate to the server if the client is not configured with the
certificate signed by CA. For the DHCPv6 encryption, after the
mutual public key communication process, the DHCPv6 message is
encrypted with the recipient's public key.
3.4. Scenario with Strict Security Policy
In the scenario where the security policy is strict, such as
enterprise network, the local default security policy is that the
DHCPv6 configuration communication must be authenticated and
encrypted. Then the local security policy supersedes the
opportunistic security policy. Besides, the client is always stable
terminal device, which is pre-configured with the trusted servers'
certificates or the trusted CA certificates which forms the
certificate path. Through the pre-configured information, the client
achieves the server authentication locally according to the rule
defined in [RFC5280]. For the client authentication, the client
sends the CA signed certificate to server for client authentication.
For the DHCPv6 encryption, the DHCPv6 message is encrypted with the
recipient's public key contained in the certificate.
For the byod in enterprise network, the device is not pre-configured
with the server authentication information to verify the server's
identity. In this case, the trusted server's certificate can be
obtained out of band, such as QR code and other methods. Out of band
method is also suitable for the public coffee shops where the DHCPv6
Li, et al. Expires June 18, 2016 [Page 4]
Internet-Draft secure DHCPv6 deployment December 2015
client has strict security requirement.
4. Security Considerations
Opportunistic encryption is used for the secure DHCPv6 deployment in
the scenario where the security policy is loose. The DHCPv6
configuration process is non-authenticated but encryption if the
client is not pre-configured with the trusted servers' certificates
or trusted CAs' certificates. Downgrade attacks cannot be avoided if
the client is set the local policy that the DHCPv6 configuration
process must be authenticated and encrypted.
5. References
5.1. Normative References
[I-D.ietf-dhc-sedhcpv6]
Jiang, S., Li, L., Cui, Y., Jinmei, T., Lemon, T., and D.
Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-10 (work
in progress), December 2015.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[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, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <http://www.rfc-editor.org/info/rfc7435>.
5.2. Informative References
[I-D.ietf-dhc-dhcpv6-privacy]
Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy
considerations for DHCPv6", draft-ietf-dhc-
dhcpv6-privacy-01 (work in progress), August 2015.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <http://www.rfc-editor.org/info/rfc7258>.
Li, et al. Expires June 18, 2016 [Page 5]
Internet-Draft secure DHCPv6 deployment December 2015
Authors' Addresses
Lishan Li
Tsinghua University
Beijing 100084
P.R.China
Phone: +86-15201441862
Email: lilishan9248@126.com
Yong Cui
Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6260-3059
Email: yong@csnet1.cs.tsinghua.edu.cn
Jianping Wu
Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5983
Email: jianping@cernet.edu.cn
Sheng Jiang
Huawei Technologies Co., Ltd
Q14, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095
CN
Email: jiangsheng@huawei.com
Li, et al. Expires June 18, 2016 [Page 6]