One document matched: draft-cui-dhc-dhcpv6-encryption-00.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-00" 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>
<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 client/server authentication and encryption based on
sender's certificates.</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.</t>
<t>The document discusses two possible solutions to achieve the authentication
and encryption between DHCPv6 server and client. 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 authentication before encrypted DHCPv6 transaction. The identity of
a DHCPv6 node is verified by the recipient before the DHCPv6 configuration process.
Two new DHCPv6 messages, Encrypted-Request and Encrypted-Reply, are defined to
exchange the certificates, timestamps, signatures of both sides. After the
two-message authentication process, 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 authentication process is done during the Solicit-Advertise
exchange. The following DHCPv6 messages are encrypted using public key, 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/client before the DHCPv6 configuration
transaction.</t>
<t>Encrypt the DHCPv6 configuration messages between a DHCPv6 server
and a client once the authentication 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 achieves mutual authentication before DHCPv6 transaction,
and uses public keys to encrypt any following DHCPv6 messages.
In the authentication process, two new DHCPv6 messages: Encrypted-Request
and Encrypted-Reply are defined for exchanging certificate information.
Encrypted-Request message is sent from DHCPv6 client to DHCPv6 server, which
contains the signature option, the timestamp option and the certificate
option defined in <xref target="I-D.ietf-dhc-sedhcpv6"/>. Encrypted-Reply
message is sent from DHCPv6 server to DHCPv6 client, which contains the
signature option, the certificate option, the timestamp option and server
identifier option. Once the authentication process finished, the following
DHCPv6 transaction are encrypted. One new defined DHCPv6 option:
Encrypted-Message option and two new defined DHCPv6 messages: Encrypted-Query
and Encrypted-Response are defined to fulfill the encryption pattern. The new
defined Encrypted-Message option contains 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>This solution is based on the public/private key pairs of the DHCPv6 client
and server. The server and client first generate a public/private key pair and
then obtain 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>Before the DHCPv6 configuration process, the DHCPv6 client sends the
Encrypted-Request message to the DHCPv6 server. Note that at this stage, the
client does not send its DUID to the server for privacy protection. The client's
identity is verified and the timestamp is checked for anti-replay protection. If
the verification and timestamp check are successful, the server records the public
key in its local key table and replies with an Encrypted-Reply message to the
client. If the verification fails or the timestamp check fails, the server will
discard the message or further blacklist the client.</t>
<t>Upon the receipte of the Encrypted-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. Otherwise, the client drops the message or blacklists
the server.</t>
<figure align="center" title="DHCPv6 Authentication Procedure">
<artwork><![CDATA[
+-------------+ +-------------+
|DHCPv6 Client| |DHCPv6 Server|
+-------------+ +-------------+
| Encrypted-Request |
|---------------------------------------------->|
| certificate option signature option |
| |
| Encrypted-Reply |
|<----------------------------------------------|
| certificate option signature option |
| server identifier option |
| |
]]></artwork>
</figure>
<t>After successful mutual authentication, the following DHCPv6 messages are
encrypted with the recipient's public key and encapsulated into the Encrypted-Message
option. DHCPv6 client sends the Encrypted-Query message to server, which carries the
server identifier option and an Encrypted-Message option. The Encrypted-Message option
contains the encrypted DHCPv6 message. 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>
</section>
<section title="Client Behavior">
<t>The client MUST have a public/private key pair. The client is assigned a public
key certificate by a CA.</t>
<t>If the client supports secure mode, before sending SOLICIT message, it
multicasts the Encrypted-Request to the DHCPv6 servers before sending SOLICIT
message. The Encrypted-Request message contains the signature option, timestamp
option, certificate option. The certificate option carries the public key certificate
of the client. The timestamp option carries the current time of the client. After
creating the entire DHCPv6 header and options, the signature is created that is
signed by the client's private key. The Encrypted-Request message MUST NOT contain
the client's DUID or any other private information.</t>
<t>When the DHCPv6 client receives the Encrypted-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. </t>
<t>Once the authentication is completed, the client selects one authenticated
DHCPv6 server for the following DHCPv6 transaction. 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.</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 Encrypted-Request message, it validates
the certificate according to the rule defined in <xref target="RFC5280"/> and
checks timestamp according to the rule defined in <xref target="I-D.ietf-dhc-sedhcpv6"/>.
If the verification and check are successful, the server creates a local trusted
certificate record for verified certificates. And then it sends the Encrypted-Reply
message to the client, which includes the server's digital signature, certificate,
timestamp and server identifier. If the verification fails or the timestamp check fails,
the server will discard the message or further blacklist the client.</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.</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 addr ess
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. The deployment of the PKI
is out of the scope of this document.</t>
<t>The mutual authentication and public key 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 certificate for authentication, 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 certificate, timestamp, signature are included in the
Solicit message. The DHCPv6 server validates the identity of the client and checks
timestamp. If the verification and timestamp check is successful, the server encapsulates
the Advertise message encrypted with the client's public key 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>The client MUST have a public/private key pair. The client is assigned
a public key certificate by a CA.</t>
<t>If the client supports 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 certificate, 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 verifies the certificate
according to the rule defined in <xref target="RFC5280"/> and checks the timestamp.
If the authentication is successful, the server creates a local trusted certificate
record for verified certificates. And then 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: Encrypted-Request,
Encrypted-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)
Encrypted-Request (TBA3), Encrypted-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>Encrypted-Request message (TBA3).</t>
<t>Encrypted-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" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:31:52 |