Internet DRAFT - draft-xu-dhc-cadhcp

draft-xu-dhc-cadhcp






DHC                                                                Y. Xu
Internet-Draft                                                S. Manning
Intended status: Standards Track                                 M. Wong
Expires: March 24, 2012                              Huawei Technologies
                                                      September 21, 2011


         An Authentication Method based on Certificate for DHCP
                       draft-xu-dhc-cadhcp-01.txt

Abstract

   This document defines a technique that can provide both entity
   authentication and message authentication based on certificate.  This
   protocol combines three existing options, authentication option as
   specified in delay authentication mechanism in [RFC3118] and the user
   authentication protocol option defined in [RFC2485].  The goal of
   this specification is to define methods based certificate to protect
   the integrity of DHCP message and stop the gaps of the existing delay
   authentication mechanism.  In order to meet these goals, we use the
   asymmetrical cryptography protection and some options about
   authentication that have been defined in other specifications.

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 March 24, 2012.

Copyright Notice

   Copyright (c) 2011 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



Xu                       Expires March 24, 2012                 [Page 1]

Internet-Draft       Certificate based DHCP Security      September 2011


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

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

































Xu                       Expires March 24, 2012                 [Page 2]

Internet-Draft       Certificate based DHCP Security      September 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Certificate based Authentication . . . . . . . . . . . . . . .  5
   4.  Unicast/Broadcast DHCPOFFER Message  . . . . . . . . . . . . .  7
   5.  Authentication between DHCP Server and Trusted Server  . . . .  8
   6.  Signature Generation . . . . . . . . . . . . . . . . . . . . .  8
   7.  Message Validation . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Entity Authentication  . . . . . . . . . . . . . . . . . . . .  9
   9.  Client Considerations  . . . . . . . . . . . . . . . . . . . .  9
   10. Server Considerations  . . . . . . . . . . . . . . . . . . . . 10
   11. Trusted Server Considerations  . . . . . . . . . . . . . . . . 10
   12. Application Example  . . . . . . . . . . . . . . . . . . . . . 11
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   14. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   15. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     16.1.  Normative References  . . . . . . . . . . . . . . . . . . 14
     16.2.  Informative References  . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14






























Xu                       Expires March 24, 2012                 [Page 3]

Internet-Draft       Certificate based DHCP Security      September 2011


1.  Introduction

   DHCP provides a framework for passing network configuration
   information to hosts on a TCP/IP network.  Most of these parameters
   are IP addresses.  DHCP server can allocate addresses to client
   dynamically.  To ensure the security of communication between DHCP
   client and DHCP server, network administrators wish to provide
   authentication for the DHCP client and DHCP messages.  [RFC3118]
   defines an authentication mechanism for DHCP, delay authentication
   protocol.  But it is vulnerable to denial of service attack through
   flooding with DHCPDISCOVER messages, which are not authenticated by
   Delay authentication protocol.  This attack may exhaust the addresses
   available for assignment by the DHCP server and other attacks and
   limitations.  As this delay authentication is based on the pre-shared
   key.  It increases the overload of key distribution and management in
   the implementation, e.g., when there are many DHCP clients in the
   network, if delay authentication is used, a great number of pre-
   shared key must be configured in DHCP server for different DHCP
   clients, it results in the overload as the pre-shared key
   configuration and management.  Additionally, the delayed
   authentication does not support inter-domain authentication.  As the
   delay mechanism relies on a shared secret between the two negotiating
   authorities.  For the case of servers providing service to local
   clients, the above mechanism may be sufficient.  But in the more
   general case of the clients roaming across domains it is not possible
   to create all the possible key associations beforehand.  Possible
   solutions to this problem may be possible to use the certificate and
   asymmetric algorithm.  As defined in [RFC5280] , certificates can be
   used in entity authentication widely.  But as the MTU in Ethernet
   usually is 1500 bytes, while the certificate is usually large as 1k
   or 2k bytes, DHCP message, such as DHCPDISCOVER messages and
   DHCPREQUEST messages in some scenario are broadcast messages, these
   cannot be fragmented into several messages.  Thus directly carrying
   certificates in DHCP messages is impossible.  Considering these
   reasons discussed above and the requirements of some operators for
   DHCP security, a new mechanism is proposed.

   This document defines a new method for Dynamic Host Configuration
   Protocol authentication based on certificates.  The basic design
   philosophy is performing authentication immediately between DHCP
   client and DHCP server by combining some authentication options,
   sending URL information and the Client identity specified in
   [RFC2485] and [RFC2132] instead of a certificate directly, and
   leveraging a mechanism where the DHCP server has been authenticated
   by a centralized trusted server.






Xu                       Expires March 24, 2012                 [Page 4]

Internet-Draft       Certificate based DHCP Security      September 2011


2.  Terminology

   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.  Certificate based Authentication

   The DHCP client is configured with its certificate and the
   corresponding private key and the certificate of trusted server.  The
   DHCP server is configured with its certificate and the corresponding
   private key.  The trusted server is configured with its certificate
   and the corresponding private key and certificates of DHCP Clients.
   A DHCP client sends DHCPDISCOVER message that has been protected by
   its private key to DHCP server, the verification of the message is
   through the DHCP server and trusted server.  If successful, the DHCP
   server sends the DHCPOFFER message protected with the private key of
   the DHCP server.  And the DHCP client authenticates the DHCP server
   by the validation of the DHCPOFFER message.

   Based on the authentication option from [RFC3118] , if the protocol
   field is 2(TBD), the message authentication uses the certificate
   based authentication mechanism defined in this document.  In the
   certificate based authentication, the client requests authentication
   in DHCPDISCOVER message and the server replies with a DHCPOFFER
   message.  Three options are included in the DHCPDISCOVER message, the
   Authentication Option defined in this document, the Client-identifier
   Option defined in [RFC2132] and the User Authentication Protocol
   Option defined in [RFC2485] .  The DHCPDISCOVER message is signed
   with the private key of the DHCP client.  For the Authentication
   Option, unlike the delayed authentication mechanism, the signature
   generated with the DHCP client private key is added in the
   Authentication Information.  The Client-identifier Option (Option 61)
   is used to carry the DHCP client identifier.  If the DHCP client is
   configured with a certificate, the FQDN of certificate can be used as
   the DHCP client identifier.  The User Authentication Protocol Option
   is used to carry the URL of the trusted server, such as, a
   certificate server.  The URL of the trusted server can be configured
   out of band.

   The format of the authentication request in a DHCPDISCOVER or a
   DHCPINFORM message for certificate authentication is:








Xu                       Expires March 24, 2012                 [Page 5]

Internet-Draft       Certificate based DHCP Security      September 2011


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Code      |    Length     |0 0 0 0 0 0 1 0|   Algorithm   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     RDM       | Replay Detection (64 bits)                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Replay cont  |   Signature (128bytes/256bytes/512 bytes) ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   Figure 1.  The format of the authentication request (DHCPDISCOVER/
   DHCPINFORM)

   The code for the authentication option is 90, and the length field
   contains the length of protocol, RDM, algorithm, Replay Detection
   field, and Signature.  The protocol is defined to 2(00000010).  The
   signature field is used for message validation.  The other field is
   defined as [RFC3118] .

   When the DHCP server receives the DHCPDISCOVER message, it can obtain
   the certificate of DHCP client by the URL and the client identity.
   At first, the DHCP server searches the trusted server with the URL
   information, and forwards the client identity information to the
   trusted server to obtain the DHCP client certificate.  If the DHCP
   server is authenticated by a trusted server, the DHCP server
   downloads the DHCP client certificate from the trusted server.  The
   certificate may be protected with the secure tunnel, such as, SSL/
   TLS, which established between the DHCP server and the trusted
   server.  Through the authentication between DHCP server and the
   trusted server, only the legitimate DHCP server or the authenticated
   DHCP server can obtain the certificate of the DHCP client from the
   trusted server.

   After the trusted server receives the client identity information, it
   checks the validity of the client identity.  If it is legitimate, the
   trusted server will send the certificate to the DHCP server via the
   SSL/TLS tunnel.  Upon receiving the DHCP client certificate, the DHCP
   server checks that the subject field of certificate matches with the
   client identity.  The DHCP server validates the signature of the
   DHCPDISCOVER in Authentication Option.  If the validation is
   successful, it proves that the DHCP client is in possession of the
   private key corresponding to the certificate. At this time, the DHCP
   client has been authenticated with the certificate based
   authentication mechanism.







Xu                       Expires March 24, 2012                 [Page 6]

Internet-Draft       Certificate based DHCP Security      September 2011


4.  Unicast/Broadcast DHCPOFFER Message

   When DHCPOFFER message is unicast, it can be fragmented and maybe
   used to carry a certificate.  The DHCP server will use its private
   key to sign the DHCPOFFER message, which contains the configured
   information, such as Vendor Specific Information option, the
   Authentication option, and may contain other options.  The
   certificate of the DHCP server is included in the Authentication
   Option.  The format of the option is shown in Figure 2.  If the
   length exceeds the MTU, it can be fragmented with several messages
   with same sequence number specified as in [RFC3396] .  When the DHCP
   client receive whole the DHCPOFFER message, it obtains the
   certificate of DHCP server to check whether the certificate is valid,
   and validates the signature of the DHCPOFFER message.

   The following DHCPREQUEST message and the DHCPACK message can be
   validated by the same authentication mechanism.  The DHCP client
   protects the sending message with the signature generated by its
   private key.  The DHCP server validates the signature with the public
   key of the DHCP client.

   The format of the authentication information in a DHCPOFFER, DHCPACK
   message for certificate authentication is shown as follow,


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Code      |    Length     |0 0 0 0 0 0 1 0|   Algorithm   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     RDM       | Replay Detection (64 bits)                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Replay cont  |  Flags|U| RSD |         Fragment Offset       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Certificate [n]...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Signature (128bytes/256bytes/512 bytes) ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   Figure 2.  The format of the authentication information (DHCPOFFER/
   DHCPACK)

   We can use the new defined format of the option.  Then we can use the
   following format in DHCPOFFER, DHCPACK message.  And when the option
   exceeds 255 bytes, the method that specified in [RFC3396] will be
   used.





Xu                       Expires March 24, 2012                 [Page 7]

Internet-Draft       Certificate based DHCP Security      September 2011


         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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Code      |    Length     |0 0 0 0 0 0 1 0|   Algorithm   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     RDM       |   Replay Detection (64 bits)                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Replay cont  |   Certificate ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Signature (128bytes/256bytes/512 bytes) ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Figure 3.  The format of the new authentication option

   When DHCPOFFER message is broadcast, DHCP server sends to DHCP client
   DHCPOFFER message, which contains the public key of DHCP server, the
   certificate URL of the DHCP server and the signature of the DHCPOFFER
   with the private key of the DHCP server.  When DHCP client receives
   the public key of the server, it considers this certificate as a
   valid one temporarily.  The client authenticates the DHCPOFFER with
   this DHCP public key and gets the IP address allocated by the server.
   At that, the client achieves the certificate of DHCP server with the
   URL, and checks whether this certificates match with the public key
   carried in DHCPOFER message.  If they match, the client can affirm
   the validity of the server.


5.  Authentication between DHCP Server and Trusted Server

   The authentication mechanism between DHCP server and the trusted
   server may be any existing authentication method, such as, the SSL/
   TLS defined in [RFC4246] and [RFC5246] .  After the authentication
   between the trusted server and the DHCP server, the SSL/TLS tunnel is
   established between DHCP server and the trusted server.


6.  Signature Generation

   The signature of the message is generated through the private key and
   DHCP content, such as, DHCP message or some information like entity
   identity.  For the DHCPDISCOVER and the DHCPREQUEST message, the
   signature is generated with the private key of the DHCP client.  For
   the DHCPOFFER and the DHCPACK message, the signature is generated
   with the private key of the DHCP server and the DHCP contents.






Xu                       Expires March 24, 2012                 [Page 8]

Internet-Draft       Certificate based DHCP Security      September 2011


7.  Message Validation

   To validate the incoming DHCP messages, the receiver will check the
   signature with the corresponding public key.  For the DHCPDISCOVER
   and the DHCPREQUEST message, the DHCP server first checks whether the
   value in replay detection field is acceptable according to the replay
   detection method specified by the RDM field.  Next the server
   validates the signature with the public key in the certificate of
   client. for the DHCPOFFER and the DHCPACK message, the client checks
   the replay detection field, if it is correct, the client validates
   the certificate of DHCP server and checks the validity of the
   signature of the DHCP message to guarantee that this DHCP server has
   been authenticated.


8.  Entity Authentication

   The DHCP server authenticates the DHCP client by the validation of
   the DHCPDISCOVER message signature.  This validation is carried out
   by the DHCP server with the certificate of the DHCP client acquired
   from the trusted server.  The DHCP client authenticates the DHCP
   server by validating the certificate of DHCP server and the signature
   of the DHCPOFFER message.


9.  Client Considerations

   This section describes the behavior of a DHCP client using the
   certificate based authentication.

   1.  The client MUST include the authentication request option based
   on certificate where the protocol field is equal to 2 in its
   DHCPDISCOVER message along with the client identifier option and the
   User Authentication Protocol Option.  The DHCPDISCOVER message MUST
   sign the message with the private key client.

   2.  The client MUST perform the validation of the certificate of DHCP
   server and the signature of the DHCPOFFER message.

   3.  The client replies with a DHCPREQUEST message that MUST include
   authentication option protected by the same private key used in
   DHCPDISCOVER message.

   4.  If the client validates the DHCPOFFER it accepted, the client
   MUST validate the DHCPACK message from the server.






Xu                       Expires March 24, 2012                 [Page 9]

Internet-Draft       Certificate based DHCP Security      September 2011


10.  Server Considerations

   This section describes the behavior of a DHCP server in response to
   client message using certificate based authentication.

   General considerations

   1.  Each server MUST be authenticated by a trusted server and can
   maintain the secure link with this trusted server.

   2.  Each server MUST validate the incoming message with the public
   key of the DHCP client by obtaining the certificate of the DHCP
   client from the trusted server.

   3.  Each server MUST protect the sending message by the private key
   of the DHCP server.  If the replay detection check or the message
   signature validation fails, the server MUST discard the incoming
   message.


11.  Trusted Server Considerations

   The trusted server is only a general name for a certificate server.
   Any valid authentication mechanism may be used between DHCP server
   and trusted server.  The trusted server can regarded as high level
   sever that can authenticate DHCP servers.

   This section describes the behavior of the trusted server using
   certificate based authentication.

   1.  The trusted server MAY authenticate the DHCP server prior to the
   connection between the DHCP client and DHCP server.

   2.  The trusted server MUST distribute the certificate of the DHCP
   client to a legitimate DHCP server that has been authenticated.

   3.  Client certificates may be cached or obtained in real time, but
   caching has performance gain at the expense of memory usage.  As the
   client list grows, the DHCP server will use more memory to store the
   certificate of client, which will increase the overhead of
   certificate management.  This is similar to the argument of not using
   PSK-based scheme.









Xu                       Expires March 24, 2012                [Page 10]

Internet-Draft       Certificate based DHCP Security      September 2011


12.  Application Example


   +-------------+              +------------+     +---------------+
   |             |              |            |     |               |
   |   client    |              |DHCP server |     |Trusted Server |
   |             |              |            |     |               |
   +-------------+              +------------+     +---------------+
          |                           | Security Tunnel   |
          |                           |<----------------->|
          |         DHCP Discover     |                   |
          |-------------------------->|                   |
          |                           |  Security Tunnel  |
          |                           |<----------------->|
          |                           |download certificate|
          |                           |<----------------->|
          |                           |                   |
          |                    +----------------------+   |
          |                    | Obtian public key of |   |
          |                    | DHCP client,validate |   |
          |                    | the messsage         |   |
          |                    +----------------------+   |
          |       DHCP OFFER          |                   |
          |<------------------------->|                   |
          |                           |                   |
   +---------------------+            |                   |
   |Validate the message |            |                   |
   +---------------------+            |                   |
          |        DHCP Request       |                   |
          |-------------------------->|                   |
          |          DHCP ACK         |                   |
          |<------------------------->|                   |



   Figure 4.  DHCP Example Procedure

   Security tunnel will be established between DHCP server and Trust
   server before or after DHCP server receive DHCP DISCOVER message.
   With the DHCP client ID and the address information of trusted
   server, DHCP server obtain the corresponding public key of the DHCP
   client to validate the DHCP DISCOVER message.  If successful, the
   DHCP server will send DHCPOFFER to DHCP client specified according to
   unicast case or broadcast case.  And the client validates the DHCP
   OFFER corresponding to the two different cases.  The authentication
   of following messages can be used the similar mechanism.





Xu                       Expires March 24, 2012                [Page 11]

Internet-Draft       Certificate based DHCP Security      September 2011


13.  Security Considerations

   1. on Signature

   Signature calculation can be based on either the private key of
   sender or the public key of receiver, but with the private key of
   sender, it has the effect of origin authentication.

   2.  On Authentication

   The two entity authentication is considered only bi-lateral
   authentication and not mutual authentication.  Each authentication is
   verified independently without both client and server contributing to
   the authentication.  When DHCPOFFER is unicast, it can be fragmented
   and maybe used to carry a certificate.  In this case, DHCP client may
   be able to receive the certificate of DHCP server.  Furthermore, the
   DHCPOFFER may then be signed by the private key of server, which also
   provides the benefit of origin authentication.

   3.  Delay authentication is based on symmetrical encryption algorithm,
   the certificated authentication method is based on asymmetrical 
   encryption algorithm.

   The comparison of symmetrical encryption algorithm and asymmetrical 
   encryption algorithm:

   On Calculation speed, symmetrical encryption algorithm is faster than
   asymmetric encoding algorithm.

   On Length of the key, asymmetrical encryption algorithm is longer than
   symmetrical encryption algorithm. And for asymmetrical encryption 
   algorithm, it is difficult to derive the decrypted key from the encrypt 
   key since they are different. So asymmetrical encryption algorithm has 
   the higher security level.
  
   On the overload and feasibility, it increases the overload of key 
   distribution and management in the implementation for symmetrical 
   encryption algorithm, as it needs to pre-configured key beforehand. 
   And asymmetrical encryption algorithm can support inter-domain 
   authentication preferably.

   4.  Implementations MUST support the following attribute algorithm
   values

   a) Integrity Algorithm



Xu                       Expires March 24, 2012                [Page 12]

Internet-Draft       Certificate based DHCP Security      September 2011


   i.  MD5

   ii.  SHA1

   Algorithm Type Value

   RESERVED 0

   HASH_MD5 1

   HASH_SHA1 2

   HASH_SHA256 3

   HASH_SHA384 4

   HASH_SHA512 5

   Standards Action 6-127

   Private Use 128-255

   Unassigned 256-32767

   b) signature algorithm

   i.  RSA

   Algorithm Type Value

   RESERVED 0

   RSA 1

   Standards Action 2-127

   Private Use 128-255

   Unassigned 256-32767


14.  IANA Considerations

   There may be IANA consideration for taking additional value for this
   option.  The values of the protocol field needed to be assigned from
   the numbering space.





Xu                       Expires March 24, 2012                [Page 13]

Internet-Draft       Certificate based DHCP Security      September 2011


15.  Acknowledgments

   Thanks to Sophia Bi, Serge Manning, Marcus Wong, Eric Chen, Xiangsong
   Cui and Rock Xie who contributed actively to this document.


16.  References

16.1.  Normative References

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

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, March 1997.

   [RFC2485]  Drach, S., "DHCP Option for The Open Group's User
              Authentication Protocol", RFC 2485, January 1999.

   [RFC3118]  Droms, R. and W. Arbaugh, "Authentication for DHCP
              Messages", RFC 3118, June 2001.

16.2.  Informative References

   [RFC3396]  Lemon, T. and S. Cheshire, "Encoding Long Options in the
              Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
              November 2002.

   [RFC4246]  Dolan, M., "International Standard Audiovisual Number
              (ISAN) URN Definition", RFC 4246, February 2006.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.















Xu                       Expires March 24, 2012                [Page 14]

Internet-Draft       Certificate based DHCP Security      September 2011


Authors' Addresses

   Yixian Xu
   Huawei Technologies
   Huawei Building, Xinxi Road No.3
   Haidian District, Beijing  100085
   P. R. China

   Phone: +86-10-82836300
   Email: xuyixian@huawei.com


   Serge Manning
   Huawei Technologies

   Phone: 001-9725435324
   Email: serge.manning@huawei.com


   Marcus Wong
   Huawei Technologies

   Phone: 001-908-5413505
   Email: mwong@huawei.com



























Xu                       Expires March 24, 2012                [Page 15]