One document matched: draft-cui-dhc-dhcpv6-encryption-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc autobreaks="no"?>
<?rfc subcompact="no"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3315 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY rfc5280 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY rfc7283 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7283.xml">
<!ENTITY rfc7258 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7258.xml">
<!ENTITY rfc7435 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7435.xml">
]>
<rfc category="std" docName="draft-cui-dhc-dhcpv6-encryption-01" ipr="trust200902">
<front>
<title abbrev="DHCPv6 Encryption">Authentication and Encryption Mechanism for DHCPv6</title>
<author fullname="Yong Cui" initials="Y." surname="Cui">
<organization>Tsinghua University</organization>
<address>
<postal>
<street/>
<city>Beijing</city>
<code>100084</code>
<country>P.R.China</country>
</postal>
<phone>+86-10-6260-3059</phone>
<email>yong@csnet1.cs.tsinghua.edu.cn</email>
</address>
</author>
<author fullname="Lishan Li" initials="L." surname="Li">
<organization>Tsinghua University</organization>
<address>
<postal>
<street/>
<city>Beijing</city>
<code>100084</code>
<country>P.R.China</country>
</postal>
<phone>+86-15201441862</phone>
<email>lilishan9248@126.com</email>
</address>
</author>
<author fullname="Jianping Wu" initials="J." surname="Wu">
<organization>Tsinghua University</organization>
<address>
<postal>
<street/>
<city>Beijing</city>
<code>100084</code>
<country>P.R.China</country>
</postal>
<phone>+86-10-6278-5983</phone>
<email>jianping@cernet.edu.cn</email>
</address>
</author>
<author fullname="Yiu Lee" initials="L." surname="Yiu">
<organization>Comcast</organization>
<address>
<postal>
<street/>
<city>Philadelphia</city>
<code>19103</code>
<country>USA</country>
</postal>
<phone></phone>
<email>yiu_lee@cable.comcast.com</email>
</address>
</author>
<date year="2015"/>
<workgroup>DHC Working Group</workgroup>
<abstract>
<t>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 based on sender's
certificate/public key.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The Dynamic Host Configuration Protocol for IPv6 <xref target="RFC3315"/>
enables DHCPv6 servers to configure network parameters dynamically. <xref target="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 <xref target="RFC7258"/>.</t>
<t>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 <xref target="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 <xref target="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 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.</t>
<t>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 achieve the server authentication before the DHCPv6 configuration process.
Two new DHCPv6 messages, Encryption-Request and Encryption-Reply, are defined to
exchange the certificates, timestamps, signatures of the server. 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. </t>
<t>In solution B, the server authentication process is done during the
Solicit-Advertise exchange. The following DHCPv6 messages are encrypted using
public keys, and are also encapsulated into Encrypted-Query and Encrypted-Response.
In this way, the DHCPv6 server and client's privacy is protected.</t>
<t>The proposed secure mechanism can provide the following functions to improve
security of DHCPv6 client and server:</t>
<t>
<list style="symbols">
<t>Identify the DHCPv6 server.</t>
<t>Encrypt the DHCPv6 configuration messages between a DHCPv6 server and a
client once the public keys exchange is completed.</t>
<t>Anti-replay protection based on timestamps.</t>
</list>
</t>
</section>
<section title="Requirements Language">
<t>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 <xref target="RFC2119"/>.
</t>
</section>
<section title="Solution A: Authentication before Encrypted DHCPv6">
<section title="Solution Overview">
<t>This solution proposes the client authenticates the server before
standard DHCPv6 transactions; The server and client use public keys to
encrypt all other DHCPv6 messages.</t>
<t>In the authentication process, two new client-server DHCPv6 messages,
Encryption-Request and Encryption-Reply, are defined for the server
authentication. Once the server authentication is finished, the following
DHCPv6 transactions can be encrypted using the sender's public key.
The encrypted DHCPv6 messages for the following transactions <xref target="RFC3315"/>
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 Encrypted-Query message is sent from client to
server, which contains the server identifier option and an Encrypted-Message
option. The Encrypted-Response message is sent from server to client, containing
the Encrypted-Message option. </t>
<t>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. If the
client does not have public/private key pair, cleartext is used as the baseline
communication security policy.</t>
<t>The solution adds a two-way communication before the DHCPv6 configuration
process. The DHCPv6 client firstly multicasts an Encryption-Request message
to the DHCPv6 servers. The message contains no options, so that it reveals no
private information of the client. When receiving the Encryption-Request message,
the server replies the Encryption-Reply message that contains the server's certificate,
signature and DUID.</t>
<t>Upon the receipt of the Encryption-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.</t>
<t>After the server authentication, the following DHCPv6 messages are encrypted
with the recipient's public key and encapsulated into the Encrypted-Message
option. The Solicit 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 server identifier option is externally
visible. For the authenticated target server, it decrypts the Encrypted-Message
option by its private key. The DHCPv6 server drops message containing a server
identifier option not matching the server's DUID, thus not paying cost to decrypt
the message. The DHCPv6 server sends the Encrypted-Response message to client
which contains the Encrypted-Message option.</t>
<t><xref target="RFC7283"/> enables relays to support the newly defined DHCPv6
messages without any change.</t>
<figure align="center" title="DHCPv6 Authentication and Encryption Procedure">
<artwork><![CDATA[
+-------------+ +-------------+
|DHCPv6 Client| |DHCPv6 Server|
+-------------+ +-------------+
| Encryption-Request |
|----------------------------------------->|
| |
| Encryption-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) |
]]></artwork>
</figure>
</section>
<section title="Client Behavior">
<t>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
Encryption-Request to the DHCPv6 servers before sending SOLICIT message.
To protect the client's privacy, the Encryption-Request message SHOULD 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. </t>
<t>When the DHCPv6 client receives the Encryption-Reply message, it validates
the server's identity according to the rule defined in <xref target="RFC5280"/>
and checks the timestamp according to the rule defined in <xref target="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 the certificate. For the authenticated servers, the
client selects one DHCPv6 server for network parameters configuration.</t>
<t>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 Encrypted-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.</t>
<t>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 <xref target="RFC3315"/>.</t>
</section>
<section title="Server Behavior">
<t>When the DHCPv6 server receives the Encryption-Request message, it replies the
Encryption-Reply message to the client, which includes the server's digital signature,
certificate, timestamp and server identifier.</t>
<t>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.</t>
<t>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.</t>
</section>
<!--
<section title="Discussion: No certificate? ">
<t>A trust relationship for a public key can be the result of Opportunistic Security
<xref target="RFC7435"/> or explicit security policy. The explicit security
policies preempt Opportunistic security. Opportunistic security maximizes the
deployment of usable security without impeding communication. Cleartext is
used as the baseline communication security policy if the authentication and
encryption both are not supported. For more widely, authentication is optional
for the encryption process. If the client does not have certificate but has
public/private key pair to support encryption, any authentication check is disabled
in order to avoid unnecessary communication failure. The use of encryption without
authentication defends against pervasive monitoring and other passive attacks.</t>
</section>
-->
<section title="Possible Problem">
<t>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. It should be noted that if the client does not have connectivity
to an authority, there might be problem for the client to get the certificate and
validate it, which potentially breaks the mechanism.</t>
</section>
</section>
<section title="Solution B: Authentication with Encrypted DHCPv6">
<section title="Solution Overview">
<t>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.</t>
<t>The server authentication and public keys exchange process are completed along with
the DHCPv6 transaction. We recommend that the Solicit message is modified to carry no
privacy information about the client, such as the client's DUID. In Solicit message,
the client includes its public key for encryption, while in Advertise message,
the server would include its own certificate.</t>
<t>For the encrypted message transaction, it follow the same encryption pattern as
specified in solution A. There are one newly DHCPv6 option: Encrypted-Message option
and two newly defined DHCPv6 message: Encrypted-Query and Encrypted-Response. The
Encrypted-Message carries the encrypted DHCPv6 message. The Encrypted-Query message
is sent from client to server, which contains the server identifier option and an
Encrypted-Message option. The Encrypted-Response message is sent from server to client
which contains the Encrypted-Message option.</t>
<t>The Solicit message is recommended to carry no privacy information of the client.
Simultaneously, the client's public key, timestamp, signature are included in the
Solicit message. The server encapsulates the encrypted Advertise 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.</t>
<figure align="center" title="DHCPv6 Authentication Procedure">
<artwork><![CDATA[
+-------------+ +-------------+
|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 |
| |
]]></artwork>
</figure>
</section>
<section title="Client Behavior">
<t>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
message that carries no privacy information about the client, such as client's
DUID. The client multicasts the Solicit 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.</t>
<t>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 <xref target="RFC5280"/> and
checks the timestamps according to the rule defined in <xref target="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.</t>
<t>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 decryption cost by those unchosen servers.</t>
<t>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 <xref target="RFC3315"/> when handling the original DHCPv6 messages.</t>
</section>
<section title="Server Behavior">
<t>When the DHCPv6 server receives a Solicit 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 message.</t>
<t>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.</t>
</section>
<section title="Possible Problem">
<t>According to <xref target="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 <xref target="RFC3315"/>.
</t>
</section>
</section>
<section title="New DHCPv6 Messages">
<t>For solution A, there are four DHCPv6 message defined: Encryption-Request,
Encryption-Reply, Encrypted-Query and Encrypted-Response. For sulution B, there
are only two DHCPv6 message defined: Encrypted-Query and Encrypted-Response.
Both DHCPv6 messages defined in this document share the following format:</t>
<figure align="center" anchor="new-msg-format"
title="The format of New DHCPv6 Messages">
<artwork><![CDATA[
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) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list hangIndent="16" style="hanging">
<t hangText="msg-type"> For solution A: Encrypted-Query (TBA1), Encrypted-Response (TBA2)
Encryption-Request (TBA3), Encryption-Reply (TBA4). For solution B: Encrypted-Query (TBA1),
Encrypted-Response (TBA2).</t>
<t hangText="transaction-id"> The transaction ID for this message
exchange.</t>
<t hangText="options"> Options carried in this message.</t>
</list></t>
</section>
<section title="New DHCPv6 Options" anchor="new-v6-options">
<t>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.</t>
<t>The format of the DHCPv4 Message option is: </t>
<figure align="center" anchor="option-dhcpv4-msg"
title="Encrypted-Message Option Format">
<artwork><![CDATA[
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 .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="hanging">
<t hangText="option-code">OPTION_Encrypted_MSG (TBA5 for solution A;
TBA3 for solution B).</t>
<t hangText="option-len">Length of the encrypted DHCPv6 message.</t>
<t hangText="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 response to a client.</t>
</list>
</t>
</section>
<section title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Considerations">
<t>For solution A, there are four new DHCPv6 messages defined and one new DHCPv6 option
defined. If the solution A is selected, the IANA is requested to assign values for these
four new messages and one new option.</t>
<t>The four messages are:</t>
<t>
<list style="symbols">
<t>Encrypted-Query message (TBA1).</t>
<t>Encrypted-Response message (TBA2).</t>
<t>Encryption-Request message (TBA3).</t>
<t>Encryption-Reply message (TBA4).</t>
</list>
</t>
<t>The one option is:</t>
<t>
<list style="symbols">
<t>Encrypted-Message option (TBA5).</t>
</list>
</t>
<t>For solution B, there are two new DHCPv6 messages defined and one new DHCPv6 option
defined. If the solution B is selected, the IANA is requested to assign values for these
two new messages and one new option.</t>
<t>The four messages are:</t>
<t>
<list style="symbols">
<t>Encrypted-Query message (TBA1).</t>
<t>Encrypted-Response message (TBA2).</t>
</list>
</t>
<t>The one option is:</t>
<t>
<list style="symbols">
<t>Encrypted-Message option (TBA3).</t>
</list>
</t>
</section>
<section title="Contributors">
<t>The authors would like to thank Bernie Volz, Ralph Droms, Yiu Lee, Tomek Mrugalski,
Fred Baker, Qi Sun, Zilong Liu, Cong Liu.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3315;
&rfc5280;
&rfc7283;
&rfc7435;
<?rfc include="reference.I-D.ietf-dhc-sedhcpv6" ?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.7258'?>
<?rfc include="reference.I-D.ietf-dhc-dhcpv6-privacy" ?>
<?rfc include="reference.I-D.ietf-dhc-anonymity-profile" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:31:00 |