One document matched: draft-cui-dhc-dhcpv6-encryption-03.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-03" 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 proposed solution achieves the server authentication and encryption
between DHCPv6 client and server. The DHCPv6 server authentication is achieved
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.</t>
<t>The proposed secure mechanism can provide the following functions to improve
security of DHCPv6:</t>
<t>
<list style="symbols">
<t>authenticate 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 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. A trust relationship for a certificate could be established by TOFU with
option of other stronger mechanism depending on the application need. TOFU can be
used by a client to authenticate a server and its message in default without a
pre-established trust relationship between the client and the server.</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 and checks the timestamp. The server's authentication
could be established by TOFU with option of other stronger mechanism
depending on the application need. TOFU calls for accepting and storing
a certificate associated with an asserted identity, without authenticating
that assertion. The client creates a local trusted certificate record list
for the verified certificate and the corresponding server identifier.
A certificated that finds a match in the local trust certificate list
is treated as verified. The timestamp is checked according to the rule
defined in <xref target="I-D.ietf-dhc-sedhcpv6"/>. For the authenticated
servers, the client selects one DHCPv6 server for network parameters
configuration. And the following DHCPv6 message is encrypted using the
elected server's public key.</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"/>.
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 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="New DHCPv6 Messages">
<t>There are 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>The Encrypted-Message option are 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>There are 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:30:59 |