Authentication and Encryption Mechanism for DHCPv6
draft-cui-dhc-dhcpv6-encryption-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 | Yong Cui , Lishan Li , Jianping Wu , Yiu Lee | ||
| Last updated | 2015-07-28 | ||
| RFC stream | (None) | ||
| Formats | |||
| 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-cui-dhc-dhcpv6-encryption-02
DHC Working Group Y. Cui
Internet-Draft L. Li
Intended status: Standards Track J. Wu
Expires: January 29, 2016 Tsinghua University
L. Yiu
Comcast
July 28, 2015
Authentication and Encryption Mechanism for DHCPv6
draft-cui-dhc-dhcpv6-encryption-02
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 January 29, 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 January 29, 2016 [Page 1]
Internet-Draft DHCPv6 Encryption July 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 A: Authentication before Encrypted DHCPv6 . . . . . 4
3.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 4
3.2. Client Behavior . . . . . . . . . . . . . . . . . . . . . 5
3.3. Server Behavior . . . . . . . . . . . . . . . . . . . . . 6
3.4. Possible Problem . . . . . . . . . . . . . . . . . . . . 7
4. Solution B: Authentication with Encrypted DHCPv6 . . . . . . 7
4.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 7
4.2. Client Behavior . . . . . . . . . . . . . . . . . . . . . 8
4.3. Server Behavior . . . . . . . . . . . . . . . . . . . . . 9
4.4. Possible Problem . . . . . . . . . . . . . . . . . . . . 9
5. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . . 9
6. New DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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
Cui, et al. Expires January 29, 2016 [Page 2]
Internet-Draft DHCPv6 Encryption July 2015
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 document discusses two possible solutions to achieve the server
authentication and encryption between DHCPv6 client and server. 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 server authentication 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 from pervasive monitoring.
In solution B, the server authentication process is done during the
DHCPv6 transaction. The following DHCPv6 messages are encrypted and
are also encapsulated into Encrypted-Query and Encrypted-Response.
In this way, the DHCPv6 client's privacy is protected.
The proposed secure mechanism can provide the following functions to
improve security of DHCPv6 client and server:
o Identify the DHCPv6 server.
o Encrypt the DHCPv6 configuration messages between DHCPv6 client
and server once the public keys exchange is completed.
o 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].
Cui, et al. Expires January 29, 2016 [Page 3]
Internet-Draft DHCPv6 Encryption July 2015
3. Solution A: Authentication before Encrypted DHCPv6
3.1. 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. The deployment of
the PKI is out of the scope of this document.
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.
Cui, et al. Expires January 29, 2016 [Page 4]
Internet-Draft DHCPv6 Encryption July 2015
+-------------+ +-------------+
|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
3.2. 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 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
Cui, et al. Expires January 29, 2016 [Page 5]
Internet-Draft DHCPv6 Encryption July 2015
the certificate. For the authenticated servers, the client selects
one DHCPv6 server for network parameters configuration.
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].
3.3. 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.
Cui, et al. Expires January 29, 2016 [Page 6]
Internet-Draft DHCPv6 Encryption July 2015
3.4. Possible Problem
Once the authentication is completed, one DHCPv6 server is selected
for address 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.
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. And the server obtains a public key
certificate from CA that signs the public key. The deployment of the
PKI is out of the scope of this document. The proposed mechanism
recommend that the Solicit/Information-Request message is modified to
carry no privacy information about the client. For the encrypted
message transaction, it follows the same encryption pattern as
specified in solution A.
The Solicit/Information-request message is recommended to carry no
privacy information of the client, such as DUID. Simultaneously, the
client's public key, timestamp, signature are included in the
Solicit/Information-Request message. The server encapsulates the
encrypted Advertise/Reply message 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.
The following figure shows the DHCPv6 authentication and encryption
procedure for the client-server exchanges involving four messages.
Cui, et al. Expires January 29, 2016 [Page 7]
Internet-Draft DHCPv6 Encryption July 2015
+-------------+ +-------------+
|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 and Encryption Procedure
4.2. 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
generates the Solicit/Advertise message that carries no privacy
information about the client, such as client's DUID. The client
multicasts the Solicit/Information-request message to the DHCPv6
servers, which contains the client's public key, 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
Cui, et al. Expires January 29, 2016 [Page 8]
Internet-Draft DHCPv6 Encryption July 2015
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/Information-Request
message, it checks the timestamp and the signature. If the check is
successful, 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/Reply
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 solutin A and solution B, there are both two DHCPv6 message
defined: Encrypted-Query and Encrypted-Response. Both DHCPv6
messages defined in this document share the following format:
Cui, et al. Expires January 29, 2016 [Page 9]
Internet-Draft DHCPv6 Encryption July 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
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 (TBA3).
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
Cui, et al. Expires January 29, 2016 [Page 10]
Internet-Draft DHCPv6 Encryption July 2015
response to a client.
7. Security Considerations
TBD
8. IANA Considerations
For solution A and solutino B, there are both two new DHCPv6 messages
defined and one new DHCPv6 option defined. The IANA is requested to
assign values for these two new messages and one new option.
The two messages are:
o Encrypted-Query message (TBA1).
o Encrypted-Response message (TBA2).
The one option is:
o 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", draft-ietf-dhc-sedhcpv6-08 (work in progress),
June 2015.
[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 January 29, 2016 [Page 11]
Internet-Draft DHCPv6 Encryption July 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>.
10.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-01 (work in progress), June 2015.
[I-D.ietf-dhc-dhcpv6-privacy]
Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy
considerations for DHCPv6", draft-ietf-dhc-
dhcpv6-privacy-00 (work in progress), February 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
Lishan Li
Tsinghua University
Beijing 100084
P.R.China
Phone: +86-15201441862
Email: lilishan9248@126.com
Cui, et al. Expires January 29, 2016 [Page 12]
Internet-Draft DHCPv6 Encryption July 2015
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 January 29, 2016 [Page 13]