One document matched: draft-cui-dhc-dhcpv6-encryption-02.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-02" 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 between the DHCPv6
client and server.</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 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.</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 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. </t>
<t>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.</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 DHCPv6 client and server
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 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. </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.</t>
<t>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.</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. 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.</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|
+-------------+ +-------------+
| 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) |
]]></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
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.</t>
<t>When the DHCPv6 client receives the 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 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.</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 Information-Request message, it replies the
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.</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. 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.</t>
<t>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.</t>
<figure align="center" title="DHCPv6 Authentication and Encryption 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/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.</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/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.</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 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:</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"> 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 (TBA3).</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 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.</t>
<t>The two 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:26 |