One document matched: draft-cui-dhc-dhcpv6-encryption-04.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-04" ipr="trust200902">
<front>
<title abbrev="DHCPv6 Encryption">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 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.</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.
Due to the unsecured nature of DHCPv6, the various critical identifiers
are vulnerable to several types of attacks, particularly pervasive monitoring (PM)
<xref target="RFC7258"/>. <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.
The IETF has expressed strong agreement that PM is an attack that needs to
be mitigated where possible in <xref target="RFC7258"/>.</t>
<t>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 <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. 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 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.</t>
<t>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.</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>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. </t>
<t>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 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.</t>
<t>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.</t>
<figure align="center" title="DHCPv6 Encryption Procedure">
<artwork><![CDATA[
+-------------+ +-------------+
|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) |
]]></artwork>
</figure>
</section>
<section title="Client Behavior">
<t>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.</t>
<t>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
network parameters configuration.</t>
<t>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.</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 sends the Encrypted-Query
message to another authenticated server for parameters configuration
until the client obtains the proper parameters.
</t>
</section>
<section title="Relay Agent Behavior">
<t>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 <xref target="RFC7283"/>.</t>
<t>When a DHCPv6 relay agent recognizes the Encrypted-query and
Encrypted-response messages, it forwards the message according to
section 20 of <xref target="RFC3315"/>.</t>
</section>
<section title="Server Behavior">
<t>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.</t>
<t>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.</t>
<t>After the server is informed of the client's public key, the DHCPv6
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.</t>
</section>
<section title="New DHCPv6 Messages">
<t>There are two DHCPv6 messages 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">
<section title="Encrypted-message Option">
<t>The encrypted-message option carries the encrypted DHCPv6 message with the
recipient's public key.</t>
<t>The format of the encrypted-message option is: </t>
<figure align="center" anchor="option-dhcpv6-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 .
. (variable) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></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">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.</t>
</list>
</t>
</section>
<section title="Encryption Public Key Option">
<t>The encryption public key option is defined to carry the sender's
public key.</t>
<t>The format of the encryption public key option is: </t>
<figure align="center" anchor="option-dhcpv6-public-key"
title="Encryption Public Key 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. encryption public key .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="hanging">
<t hangText="option-code">OPTION_ENCRYPTION_PUBLIC_KEY (TBA4).</t>
<t hangText="option-len">Length of the encryption public key.</t>
<t hangText="encryption public key">A variable length field
containing the sender's public key. The sender's public key
is used for the following messages encryption.</t>
</list>
</t>
</section>
</section>
<section title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Considerations">
<t>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.</t>
<t>The two messages are:</t>
<t>
<list style="symbols">
<t>ENCRYPTED-QUERY (TBA1).</t>
<t>ENCRYPTED-RESPONSE (TBA2).</t>
</list>
</t>
<t>The two options are:</t>
<t>
<list style="symbols">
<t>OPTION_ENCRYPTED_MSG (TBA3) </t>
<t>OPTION_ENCRYPTION_PUBLIC_KEY (TBA4) </t>
</list>
</t>
</section>
<section title="Contributors">
<t>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.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3315;
&rfc5280;
&rfc7283;
&rfc7435;
</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" ?>
<?rfc include="reference.I-D.ietf-dhc-sedhcpv6" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:30:59 |