Internet DRAFT - draft-cui-dhc-dhcpv6-encryption
draft-cui-dhc-dhcpv6-encryption
DHC Working Group Y. Cui
Internet-Draft L. Li
Intended status: Standards Track J. Wu
Expires: April 20, 2016 Tsinghua University
L. Yiu
Comcast
October 18, 2015
Encryption Mechanism for DHCPv6
draft-cui-dhc-dhcpv6-encryption-04
Abstract
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables
DHCPv6 servers to configure network parameters dynamically. However,
due to the unsecured nature, various critical identifiers used in
DHCPv6 are vulnerable to several types of attack. In order to
protect the DHCPv6 from passive attack, such as pervasive monitoring
attack, this document provides a mechanism to achieve the 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 April 20, 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
Cui, et al. Expires April 20, 2016 [Page 1]
Internet-Draft DHCPv6 Encryption October 2015
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
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3
4. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 5
5. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 6
6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 6
7. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . . 7
8. New DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . 7
8.1. Encrypted-message Option . . . . . . . . . . . . . . . . 7
8.2. Encryption Public Key Option . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1. Normative References . . . . . . . . . . . . . . . . . . 9
12.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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 are
vulnerable to several types of attacks, particularly pervasive
monitoring (PM) [RFC7258]. [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. The IETF has expressed strong agreement that PM is
an attack that needs to be mitigated where possible in [RFC7258].
Prior work has addressed some aspects of DHCPv6 security, but until
now there has been little work to protect the DHCPv6 from passive
attack, such as pervasive monitoring attack. 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. 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
Cui, et al. Expires April 20, 2016 [Page 2]
Internet-Draft DHCPv6 Encryption October 2015
identifying information. However, anonymity profile limits the use
of the certain options and cannot protect 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 client wants anonymity to attackers but not to the valid
DHCP server. Besides, 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 provides a mechanism to achieve the encryption
between the DHCPv6 client and server in order to protect the DHCPv6
from passive attack, such as pervasive monitoring. Before the DHCPv6
configuration process, the Information-request and Reply messages
exchange is used to inform the client of the server's public key.
After the public key exchange, the following DHCPv6 messages are
encrypted and encapsulated into two newly defined DHCPv6 messages:
Encrypted-Query and Encrypted-Response. In this way, the various
identifiers contained in DHCPv6 message are protected from passive
attack.
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
In the proposed solution, the server's public key is communicated to
the client before the standard DHCPv6 transactions. Once the client
gets notified with the public key, the successive DHCPv6
configuration process can be encrypted with the recipient's public
key. The encrypted DHCPv6 messages are put into the newly defined
DHCPv6 option: encrypted-message option, and encapsulated into the
two new DHCPv6 messages: Encrypted-Query and Encrypted-Response.
This mechanism is used for the stateful DHCPv6 process starting with
a SOLICIT message and the stateless DHCPv6 process starting with an
Information-request message.
This solution is based on the public/private key pairs of the DHCPv6
client and server. The client/server firstly generates a pair of
public/private keys. The solution adds the Information-request and
Reply messages exchange before the standard DHCPv6 configuration
process. The information-request message is used by the client to
obtain the server's public key information without having addresses
assigned to it. The DHCPv6 client firstly multicasts an Information-
request message to DHCPv6 servers. The client MUST request the
encryption public key option in the Option Request option. When
Cui, et al. Expires April 20, 2016 [Page 3]
Internet-Draft DHCPv6 Encryption October 2015
receiving the Information-request message with the request for
encryption public key, the server sends the Reply message that
contains the server's public key option and server identifier option.
Upon the receipt of the Reply message, the DHCPv6 client records the
server's DUID as well as the corresponding public key. If the client
receives multiple Reply messages, the client selects one DHCPv6
server for the following network parameters configuration.
After the server's public key notification, the following DHCPv6
exchanges 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 to communicate the client's public key.
The client sends the Encrypted-Query message to server, which carries
the server identifier option and the encrypted-message option. The
DHCPv6 server replies with the Encrypted-Response message to client,
which contains the encrypted-message option. The following figure
illustrates the DHCPv6 encryption procedure of the client-server
exchanges involving four messages.
Cui, et al. Expires April 20, 2016 [Page 4]
Internet-Draft DHCPv6 Encryption October 2015
+-------------+ +-------------+
|DHCPv6 Client| |DHCPv6 Server|
+-------------+ +-------------+
| Information-request |
|----------------------------------------->|
| Option Request option |
| |
| Reply |
|<-----------------------------------------|
| encryption public key option |
| server identifier option |
| |
| Encryption-Query |
|----------------------------------------->|
| encrypted-message option (Solicit) |
| server identifier option |
| |
| Encryption-Response |
|<-----------------------------------------|
| encrypted-message option (Advertise) |
| |
| Encryption-Query |
|----------------------------------------->|
| encrypted-message option (Request) |
| server identifier option |
| |
| Encryption-Response |
|<-----------------------------------------|
| encrypted-message option (Reply) |
DHCPv6 Encryption Procedure
4. Client Behavior
If the client supports the encryption mode, it MUST generate a
public/private key pair. For the client supporting the encryption
mode, it multicasts the Information-request message to the DHCPv6
servers. The Information-request message MUST NOT include any option
which may reveal the private information of the client, such as the
client identifier option. The client MUST include an Option Request
option to request the encryption public key option.
When the DHCPv6 client receives the Reply messages, the client MUST
discard the those that do not contain the encryption public key
option or the sever identifier option. Upon the receipt of the Reply
message, the DHCPv6 client records the server's DUID as well as the
corresponding public key. If the client receives multiple Reply
messages, the client selects one DHCPv6 server for the following
Cui, et al. Expires April 20, 2016 [Page 5]
Internet-Draft DHCPv6 Encryption October 2015
network parameters configuration.
Once the server's public key is informed, the DHCPv6 client sends the
Encrypted-Query message to the DHCPv6 server. The Encrypted-Query
message is constructed with the encrypted-message option and server
identifier option. The encrypted-message option contains the DHCPv6
message that is encrypted using the selected server's public key.
The server identifier option is externally visible to avoid extra
cost by those unselected servers. The Solicit/Information-request
message MUST contain the public key option for the client's public
key exchange.
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 sends the Encrypted-Query message to another
authenticated server for parameters configuration until the client
obtains the proper parameters.
5. Relay Agent Behavior
When a DHCPv6 relay agent receives an Encrypted-query or Encrypted-
response message, it may not recognize this message. The unknown
messages MUST be forwarded as describes in [RFC7283].
When a DHCPv6 relay agent recognizes the Encrypted-query and
Encrypted-response messages, it forwards the message according to
section 20 of [RFC3315].
6. Server Behavior
When the DHCPv6 server receives the Information-request message with
encryption public key option request, it replies the Reply message to
the client, which includes the encryption public key option and
server identifier option.
Upon the receipt of 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 the message that is not for it, thus not paying cost to decrypt
the message. If the decrypted message is the Solicit/Information-
request message, the server MSUT discard the decrypted message that
does not include the encryption public key option. The server is
informed of the client's public through the encryption public key
option contained in the Solicit/Information-request message.
After the server is informed of the client's public key, the DHCPv6
Cui, et al. Expires April 20, 2016 [Page 6]
Internet-Draft DHCPv6 Encryption October 2015
messages, which is sent from server to client, is encrypted using the
client's public key. The encrypted DHCPv6 message is encapsulated
into the encrypted-message option. The Encrypted-Response message
contains the encrypted-message option.
7. New DHCPv6 Messages
There are two DHCPv6 messages 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 ENCRYPTED-QUERY (TBA1), ENCRYPTED-RESPONSE (TBA2).
transaction-id The transaction ID for this message exchange.
options Options carried in this message.
8. New DHCPv6 Options
8.1. Encrypted-message Option
The encrypted-message option carries the encrypted DHCPv6 message
with the recipient's public key.
The format of the encrypted-message option is:
Cui, et al. Expires April 20, 2016 [Page 7]
Internet-Draft DHCPv6 Encryption October 2015
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 .
. (variable) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: encrypted-message Option Format
option-code OPTION_ENCRYPTED_MSG (TBA3).
option-len Length of the encrypted DHCPv6 message.
encrypted DHCPv6 message A variable length field containing the
encrypted DHCPv6 message sent by the client or server. In
Encrypted-Query message, it contains encrypted DHCPv6 message sent
by a client. In Encrypted-response message, it contains encrypted
DHCPv6 message sent by a server.
8.2. Encryption Public Key Option
The encryption public key option is defined to carry the sender's
public key.
The format of the encryption public key 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. encryption public key .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Encryption Public Key Option Format
option-code OPTION_ENCRYPTION_PUBLIC_KEY (TBA4).
option-len Length of the encryption public key.
encryption public key A variable length field containing the
Cui, et al. Expires April 20, 2016 [Page 8]
Internet-Draft DHCPv6 Encryption October 2015
sender's public key. The sender's public key is used for the
following messages encryption.
9. Security Considerations
TBD
10. IANA Considerations
There are two new DHCPv6 messages defined and two new DHCPv6 options
defined. The IANA is requested to assign values for these two
messages and two options.
The two messages are:
o ENCRYPTED-QUERY (TBA1).
o ENCRYPTED-RESPONSE (TBA2).
The two options are:
o OPTION_ENCRYPTED_MSG (TBA3)
o OPTION_ENCRYPTION_PUBLIC_KEY (TBA4)
11. Contributors
The authors would like to thank Bernie Volz, Tomek Mrugalski, Ralph
Droms, Randy Bush, Stephen Farrell, Christian Huitema, Nico Williams,
Erik Kline, Alan DeKok, Bernard Aboba, Sam Hartman, Qi Sun, Zilong
Liu and Cong Liu.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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>.
Cui, et al. Expires April 20, 2016 [Page 9]
Internet-Draft DHCPv6 Encryption October 2015
[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>.
[RFC7283] Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6
Messages", RFC 7283, DOI 10.17487/RFC7283, July 2014,
<http://www.rfc-editor.org/info/rfc7283>.
[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>.
12.2. Informative References
[I-D.ietf-dhc-anonymity-profile]
Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
profile for DHCP clients", draft-ietf-dhc-anonymity-
profile-04 (work in progress), October 2015.
[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.
[I-D.ietf-dhc-sedhcpv6]
Jiang, S., Shen, S., Zhang, D., and T. Jinmei, "Secure
DHCPv6", draft-ietf-dhc-sedhcpv6-08 (work in progress),
June 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>.
Authors' Addresses
Yong Cui
Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6260-3059
Email: yong@csnet1.cs.tsinghua.edu.cn
Cui, et al. Expires April 20, 2016 [Page 10]
Internet-Draft DHCPv6 Encryption October 2015
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
Yiu Lee
Comcast
Philadelphia 19103
USA
Email: yiu_lee@cable.comcast.com
Cui, et al. Expires April 20, 2016 [Page 11]
