[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01                                                         
DHC                                                                Y. Xu
Internet-Draft                                                S. Manning
Intended status: Standards Track                                 M. Wong
Expires: December 17, 2011                           Huawei Technologies
                                                           June 15, 2011


         A authentication method based on certificate for DHCP
                       draft-xu-dhc-cadhcp-00.txt

Abstract

   This document defines a technique that can provide both entity
   authentication and message authentication based on certificates. This
   protocol combines existing options, such as the delay authentication
   mechanism in [RFC3118] and the user authentication protocol option
   defined in [RFC2485].  The goal of this specification is to define
   methods for certificates to protect the integrity of DHCP messages
   and close the gaps of the existing delay authentication mechanism.
   In order to meet these goals, we use the asymmetrical cryptograph
   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 December 11, 2011.

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
   publication of this document.  Please review these documents



Xu                      Expires December 11, 2011               [Page 1]


Internet-Draft       Certificate Based DHCP security           June 2011


   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 December 11, 2011               [Page 2]


Internet-Draft       Certificate Based DHCP security           June 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology used in this document  . . . . . . . . . . . . . .  4
   3.  Certificate Based Authentication . . . . . . . . . . . . . . .  4
   4.  Unicast DHCPOFFER Message  . . . . . . . . . . . . . . . . . .  6
   5.  Authentication between DHCP server and the trusted server  . .  7
   6.  The Generation of signature  . . . . . . . . . . . . . . . . .  8
   7.  Message validation . . . . . . . . . . . . . . . . . . . . . .  8
   8.  Entity authentication  . . . . . . . . . . . . . . . . . . . .  8
   9.  Client Considerations  . . . . . . . . . . . . . . . . . . . .  8
   10. Server Considerations  . . . . . . . . . . . . . . . . . . . .  9
   11. Trusted server Considerations  . . . . . . . . . . . . . . . .  9
   12. Application example  . . . . . . . . . . . . . . . . . . . . . 10
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   14. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   15. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
   16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     16.1.  Normative References  . . . . . . . . . . . . . . . . . . 11
     16.2.  Informative References  . . . . . . . . . . . . . . . . . 12
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12






























Xu                      Expires December 11, 2011               [Page 3]


Internet-Draft       Certificate Based DHCP security           June 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.  The DHCP server can allocate addresses to clients
   dynamically.  To ensure the security of communication between DHCP
   client and DHCP server, network administrators may wish to provide
   authentication for the DHCP clients and DHCP messages.  [RFC3118]
   defines an authentication mechanism for DHCP, the delay authentication
   protocol.  But it is vulnerable to denial of service attacks through
   flooding with DHCPDISCOVER messages, which are not authenticated by
   Delay authentication protocol.  This attack may overwhelm the DHCP
   server and exhaust the addresses available for assignment by the DHCP
   server.  Delay authentication is prone to other kinds of attacks and
   limitations.  Further, this delay authentication is based on a pre-shared key.
   This increases the overload of key distribution and management in
   the implementation. As defined in [RFC5280], certificates can be used
   in entity authentication widely.  The MTU in Ethernet is usually 1500
   bytes, while the certificate is usually as large as 1k or 2k bytes,
   and since DHCPDISCOVER messages and DHCPREQUEST messages are broadcast
   messages, these cannot be fragmented into several messages.  Thus,
   directly carrying certificates in DHCP messages is impossible.  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.


2.  Terminology used in this document

   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 trusted server's certificate.  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



Xu                      Expires December 11, 2011               [Page 4]


Internet-Draft       Certificate Based DHCP security           June 2011


   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 uses the certificate based
   authentication mechanism defined in this document.  In the
   certificate based authentication, the client requests authentication
   in the 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 sequence number 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:

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




Xu                      Expires December 11, 2011               [Page 5]


Internet-Draft       Certificate Based DHCP security           June 2011


   When the DHCP server receives the DHCPDISCOVER message, it can obtain
   the DHCP client's certificate 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 is 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.


4.  Unicast DHCPOFFER Message

   When DHCPOFFER 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 DHCP
   server's certificate 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.




Xu                      Expires December 11, 2011               [Page 6]


Internet-Draft       Certificate Based DHCP security           June 2011


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

                 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    | Flags|U|RSD|         Fragment Offset        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Certificate [0]     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.


         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


5.  Authentication between DHCP server and the 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



Xu                      Expires December 11, 2011               [Page 7]


Internet-Draft       Certificate Based DHCP security           June 2011


   established between DHCP server and the trusted server.


6.  The Generation of signature

   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.


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 client's
   certificate.  For the DHCPOFFER and the DHCPACK message, the client
   checks the replay detection field, if it is correct, the client
   validates the DHCP server's certificate 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 DHCP server's certificate 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 using
   certificates 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 client's private key.



Xu                      Expires December 11, 2011               [Page 8]


Internet-Draft       Certificate Based DHCP security           June 2011


    2.  The client MUST perform the validation of the DHCP server's
   certificate 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.


10.  DHCP Server Considerations

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

   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 client's
   certificates, which will increase the overhead of certificate
   management.  This is similar to the argument of not using PSK-based
   scheme.






Xu                      Expires December 11, 2011               [Page 9]


Internet-Draft       Certificate Based DHCP security           June 2011


12.  Application example


   +-------------+              +------------+     +---------------+
   |             |              |            |     |               |
   |   client    |              |DHCP server |     |Trusted Server |
   |             |              |            |     |               |
   +-------------+              +------------+     +---------------+
          |                           | Security Tunnel   |
          |                           |<----------------->|
          |         DHCP Discover     |                   |
          |-------------------------->|                   |
          |                           |  Security Tunnel  |
          |                           |<----------------->|
          |                           |download certificat|e
          |                           |<----------------->|
          |                           |                   |
          |                    +----------------------+   |
          |                    | Obtain 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 December 11, 2011              [Page 10]


Internet-Draft       Certificate Based DHCP security           June 2011


13.  Security Considerations

   1. On Signature: Signature calculation can be based on either sender's
   private key or receiver's public key, but with sender's private key,
   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 DHCP server's
   certificate.  Furthermore, the DHCPOFFER may then be signed by
   server's private key, which also provides the benefit of origin
   authentication.

   3.  Implementations MUST support the following attribute algorithm
   values

   a) Integrity Algorithm
    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.


15.  Acknowledgments

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




Xu                      Expires December 11, 2011              [Page 11]


Internet-Draft       Certificate Based DHCP security           June 2011


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

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

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

16.2.  Informative References


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




Author's Address

   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 December 11, 2011              [Page 12]