Skip to main content

Authentication and Encryption Mechanism for DHCPv6
draft-cui-dhc-dhcpv6-encryption-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Yong Cui , Lishan Li , Jianping Wu
Last updated 2015-05-31
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-cui-dhc-dhcpv6-encryption-00
DHC Working Group                                                 Y. Cui
Internet-Draft                                                     L. Li
Intended status: Standards Track                                   J. Wu
Expires: December 2, 2015                            Tsinghua University
                                                            May 31, 2015

           Authentication and Encryption Mechanism for DHCPv6
                   draft-cui-dhc-dhcpv6-encryption-00

Abstract

   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 2, 2015.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must

Cui, et al.             Expires December 2, 2015                [Page 1]
Internet-Draft              DHCPv6 Encryption                   May 2015

   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Solution A: Authentication before Encrypted DHCPv6  . . . . .   3
     3.1.  Solution Overview . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Client Behavior . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Server Behavior . . . . . . . . . . . . . . . . . . . . .   6
     3.4.  Discussion: No certificate? . . . . . . . . . . . . . . .   7
     3.5.  Possible Problem  . . . . . . . . . . . . . . . . . . . .   7
   4.  Solution B: Authentication with Encrypted DHCPv6  . . . . . .   7
     4.1.  Solution Overview . . . . . . . . . . . . . . . . . . . .   7
     4.2.  Client Behavior . . . . . . . . . . . . . . . . . . . . .   9
     4.3.  Server Behavior . . . . . . . . . . . . . . . . . . . . .   9
     4.4.  Possible Problem  . . . . . . . . . . . . . . . . . . . .  10
   5.  New DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . .  10
   6.  New DHCPv6 Options  . . . . . . . . . . . . . . . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   9.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  12
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     10.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   The Dynamic Host Configuration Protocol for IPv6 [RFC3315] enables
   DHCPv6 servers to configure network parameters dynamically.
   [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 [RFC7258].

   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 [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

Cui, et al.             Expires December 2, 2015                [Page 2]
Internet-Draft              DHCPv6 Encryption                   May 2015

   mitigated where possible.

   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.

   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.

   The proposed secure mechanism can provide the following functions to
   improve security of DHCPv6 client and server:

   o  Identify the DHCPv6 server/client before the DHCPv6 configuration
      transaction.

   o  Encrypt the DHCPv6 configuration messages between a DHCPv6 server
      and a client once the authentication is completed.

   o  Anti-replay protection based on timestamps.

2.  Requirements Language

   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 [RFC2119].

3.  Solution A: Authentication before Encrypted DHCPv6

3.1.  Solution Overview

   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

Cui, et al.             Expires December 2, 2015                [Page 3]
Internet-Draft              DHCPv6 Encryption                   May 2015

   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
   [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.

   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.

   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.

   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.

Cui, et al.             Expires December 2, 2015                [Page 4]
Internet-Draft              DHCPv6 Encryption                   May 2015

           +-------------+                           +-------------+
           |DHCPv6 Client|                           |DHCPv6 Server|
           +-------------+                           +-------------+
           |            Encrypted-Request                  |
           |---------------------------------------------->|
           |    certificate option    signature option     |
           |                                               |
           |            Encrypted-Reply                    |
           |<----------------------------------------------|
           |    certificate option   signature option      |
           |         server identifier option              |
           |                                               |

                      DHCPv6 Authentication Procedure

   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.

   [RFC7283] enables relays to support the newly defined DHCPv6 messages
   without any change.

3.2.  Client Behavior

   The client MUST have a public/private key pair.  The client is
   assigned a public key certificate by a CA.

   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.

   When the DHCPv6 client receives the Encrypted-Reply message, it

Cui, et al.             Expires December 2, 2015                [Page 5]
Internet-Draft              DHCPv6 Encryption                   May 2015

   validates the server's identity according to the rule defined in
   [RFC5280] and checks the timestamp according to the rule defined in
   [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.

   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.

   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 [RFC3315].

3.3.  Server Behavior

   When the DHCPv6 server receives the Encrypted-Request message, it
   validates the certificate according to the rule defined in [RFC5280]
   and checks timestamp according to the rule defined in
   [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.

   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.

   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.

Cui, et al.             Expires December 2, 2015                [Page 6]
Internet-Draft              DHCPv6 Encryption                   May 2015

3.4.  Discussion: No certificate?

   A trust relationship for a public key can be the result of
   Opportunistic Security [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.

3.5.  Possible Problem

   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.

4.  Solution B: Authentication with Encrypted DHCPv6

4.1.  Solution Overview

   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.

   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.

   For the encrypted message transaction, it follow the same encryption
   pattern as specified in solution A.  There are one newly DHCPv6

Cui, et al.             Expires December 2, 2015                [Page 7]
Internet-Draft              DHCPv6 Encryption                   May 2015

   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.

   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.

            +-------------+                           +-------------+
            |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              |
            |                                               |

                      DHCPv6 Authentication Procedure

Cui, et al.             Expires December 2, 2015                [Page 8]
Internet-Draft              DHCPv6 Encryption                   May 2015

4.2.  Client Behavior

   The client MUST have a public/private key pair.  The client is
   assigned a public key certificate by a CA.

   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.

   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 [RFC5280]
   and checks the timestamps according to the rule defined in
   [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.

   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.

   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 [RFC3315] when handling the original
   DHCPv6 messages.

4.3.  Server Behavior

   When the DHCPv6 server receives a Solicit message, it verifies the
   certificate according to the rule defined in [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.

   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

Cui, et al.             Expires December 2, 2015                [Page 9]
Internet-Draft              DHCPv6 Encryption                   May 2015

   messages that are not targeted for it, thus not paying cost to
   decrypt the message.

4.4.  Possible Problem

   According to [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 [RFC3315].

5.  New DHCPv6 Messages

   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:

      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)                          .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 1: The format of New DHCPv6 Messages

   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).

   transaction-id  The transaction ID for this message exchange.

   options         Options carried in this message.

6.  New DHCPv6 Options

   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.

   The format of the DHCPv4 Message option is:

Cui, et al.             Expires December 2, 2015               [Page 10]
Internet-Draft              DHCPv6 Encryption                   May 2015

      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                     .
     .                                                               .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 2: Encrypted-Message Option Format

   option-code  OPTION_Encrypted_MSG (TBA5 for solution A; TBA3 for
      solution B).

   option-len  Length of the encrypted DHCPv6 message.

   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.

7.  Security Considerations

   TBD

8.  IANA Considerations

   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.

   The four messages are:

   o  Encrypted-Query message (TBA1).

   o  Encrypted-Response message (TBA2).

   o  Encrypted-Request message (TBA3).

   o  Encrypted-Reply message (TBA4).

   The one option is:

   o  Encrypted-Message option (TBA5).

Cui, et al.             Expires December 2, 2015               [Page 11]
Internet-Draft              DHCPv6 Encryption                   May 2015

   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.

   The four messages are:

   o  Encrypted-Query message (TBA1).

   o  Encrypted-Response message (TBA2).

   The one option is:

   o  Encrypted-Message option (TBA3).

9.  Contributors

   The authors would like to thank Bernie Volz, Ralph Droms, Yiu Lee,
   Tomek Mrugalski, Fred Baker, Qi Sun, Zilong Liu, Cong Liu.

10.  References

10.1.  Normative References

   [I-D.ietf-dhc-sedhcpv6]
              Jiang, S., Shen, S., Zhang, D., and T. Jinmei, "Secure
              DHCPv6", draft-ietf-dhc-sedhcpv6-07 (work in progress),
              March 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

   [RFC7283]  Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6
              Messages", RFC 7283, July 2014.

   [RFC7435]  Dukhovni, V., "Opportunistic Security: Some Protection
              Most of the Time", RFC 7435, December 2014.

Cui, et al.             Expires December 2, 2015               [Page 12]
Internet-Draft              DHCPv6 Encryption                   May 2015

10.2.  Informative References

   [I-D.ietf-dhc-dhcpv6-privacy]
              Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy
              considerations for DHCPv6", draft-ietf-dhc-
              dhcpv6-privacy-00 (work in progress), February 2015.

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, May 2014.

Authors' Addresses

   Yong Cui
   Tsinghua University
   Beijing  100084
   P.R.China

   Phone: +86-10-6260-3059
   Email: yong@csnet1.cs.tsinghua.edu.cn

   Lishan Li
   Tsinghua University
   Beijing  100084
   P.R.China

   Phone: +86-15201441862
   Email: lilishan9248@126.com

   Jianping Wu
   Tsinghua University
   Beijing  100084
   P.R.China

   Phone: +86-10-6278-5983
   Email: jianping@cernet.edu.cn

Cui, et al.             Expires December 2, 2015               [Page 13]