[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02                                                      
INTERNET-DRAFT                                               Vipul Gupta
                                                   SUN Microsystems, Inc
                                                            Jun 22, 1998

               Flexible Authentication for DHCP Messages

   Status of this Memo

   This document is an Internet Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [Bra96]. Internet Drafts are
   working documents of the Internet Engineering Task Force (IETF), its
   areas, and working groups. Note that other groups may also distribute
   working documents as Internet Drafts.

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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   This memo proposes minor extensions to the draft by Droms and Arbaugh
   [DrAr98] with the aim of offering greater flexibility in
   authenticating Dynamic Host Configuration Protocol (DHCP) messages.
   In particular, these changes add support for digital signatures to
   the existing support for keyed hashes. The use of digital signatures
   simplifies key management and also allows authentication of mobile
   clients that roam between different administrative domains. This
   proposal also includes hooks to support multiple forms of replay

   1. Introduction:

      The Dynamic Host Configuration Protocol (DHCP) [Drom97] provides
      an extensible framework through which a host can acquire various
      configuration parameters from a centrally managed server.
      Configuration parameters that may be obtained through DHCP
      include (among many others) the host's IP address, subnet mask,
      default router, DNS domain, DNS server and NTP servers. The

Gupta                      DHCP Authentication                  [Page 1]

INTERNET-DRAFT           Expires December, 1999                June 1999

      protocol as specified in RFC 2131 is susceptible to various
      security attacks including source spoofing, message modification,
      replays and eavesdropping.

      [DrAr99] outlines a mechanism (Protocol 1) for adding
      authentication information to DHCP messages. The mechanism
      guards against source spoofing, message alteration and replays.
      It assumes that the entities exchanging authenticated information
      share a secret key not known to anyone else. The sender uses this
      key to compute a keyed hash (or MAC) over the information to be
      protected and a replay detection field. This MAC is sent along
      with the DHCP message. The receiver recomputes the MAC over the
      same fields using its copy of the shared key. It compares the
      result against the MAC value received with the incoming message.
      A successful match authenticates the sender.

      This draft proposes simple extensions to Protocol 1 [DrAr99] with
      the aim of supporting public-key based authentication. It also
      includes hooks for future support of multiple forms of replay
      detection (e.g. using nonces). These extensions are described as a
      new "Protocol", with protocol number 2. Protocols 0 and 1 are
      described in [DrAr99]. Since Protocol 2 is a generalization of
      Protocol 1, the DHCP working group may decide to merge the two.
      Like [DrAr99], this note does not address confidentiality of DHCP

      This note is not a stand-alone document and must be read in
      conjunction with [DrAr99]. Additionally, the reader is assumed to
      be familiar with the following:

         o Dynamic Host Configuration Protocol [Drom97]
         o DHCP Continuation Option Code [ArKe97]

   1.1 Requirements Terminology

       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
       in this document are to be interpreted as described in RFC 2119

   2. Protocol 2

      The general format of the DHCP authentication option in this draft
      closely resembles the format in [DrAr99] with minor exceptions.

      The "Global Replay Counter" field has been renamed "Replay
      Detection Field" and the two most significant bits (RDM) in the

Gupta                      DHCP Authentication                  [Page 2]

INTERNET-DRAFT           Expires December, 1999                June 1999

      "Algorithm field" have been reserved to indicate the type of
      replay detection mechanism in use. One can envision using
      nonces for replay detection (as is done in IKE [RFC 2409]).
      Since nonces are generated randomly, a sequence of nonces need
      not be monotonically increasing (unlike the replay detection
      counter specified in [DrAr99]).

      The Authentication Information field is now subdivided into two
      variable length fields:

        1. Key ID -- This is a generalization of the "secret ID"
           field in Protocol 1 and identifies the public-key or
           shared-key needed to verify the authenticator.

           Several forms of key ID are supported including X.509
           certificates, hashes of X.509 certificates, certificate
           chains and opaque values.

        2. Authenticator -- This is a generalization of the "MAC" field
           in Protocol 1. It contains either a MAC or a digital
           signature depending on whether the authentication algorithm
           uses symmetric- or asymmetric- key cryptography.

       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     |  Protocol (2) |RDM| Algorithm |
       |                                                               |
       +              Replay Detection Field  (64 bits)                +
       |                                                               |
   - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ^ ^ |  Key ID Type  |         Key ID length         |  Reserved(0)  |
   | K +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   A e |                                                               |
   u y ~           Key ID Value ...     (variable length)              ~
   t ID~                                                               ~
   h V |                                                               |
     - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Info|                                                               |
   |   ~           Authenticator (variable length)  ...                ~
   V   |                                                               |
   -   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Code for the authentication option is TBD. The Length field
      contains the length of the entire option except for the code and
      length bytes. This length equals 10 plus the size of the
      authentication information (in bytes) and can typically be encoded

Gupta                      DHCP Authentication                  [Page 3]

INTERNET-DRAFT           Expires December, 1999                June 1999

      in a single byte.  However, for certain Key ID types (such as
      certificates) it is possible that the total length of the
      authentication option exceeds 255. In this case, the DHCP
      continuation option code [ArKe97] MUST be used and the length
      field MUST be set accordingly.

   2.1 The Replay Detection Method (RDM) field

      This two-bit field indicates the replay detection method used
      by the DHCP client and server. It determines how the Replay
      Detection Field is set by the sender and also how its contents
      are interpreted at the receiver.

         RDM field                     Description
         ---------                     -----------
            OO           When the RDM bits are 00, the Replay Detection
                         field is used in exactly the same manner
                         as the "Global Counter Field" of Protocol 1
                         specified in [DrAr99].
         01, 10, 11      These values are RESERVED and some of them will
                         be defined in a subsequent revision.

      An RDM value of 00 MUST be supported.

   2.2 Algorithm

      The Algorithm field determines which of several secret-key or
      public-key based authentication algorithms is used to compute
      the authenticator information.

      The following algorithms are supported (Public-key algorithms
      are identified by an asterisk next to their name):

      field       Description                 Reference
      -----       -----------                 ---------
        1         HMAC-MD5 keyed hash         [Rive92], [KBC97]
        2         HMAC-SHA keyed hash         [NIS94a], [KBC97]
        3         DSA*     signature          [NIS94b]
        4         RSA-MD5* RSA encryption     [RSA78]
                           of MD5 hash

       Algorithm 1 (HMAC-MD5) MUST be supported.

   2.3 Replay Detection Field

       The content and interpretation of this field is controlled by
       the RDM (Replay Detection Method) bits. As mentioned in Section

Gupta                      DHCP Authentication                  [Page 4]

INTERNET-DRAFT           Expires December, 1999                June 1999

       2.1, RDM values other than 00 are currently reserved. When RDM
       is 00, the Replay Detection Field is defined to mimic the
       "Global Replay Counter" in Protocol 1 [DrA99].

   2.4 Key ID

       The Key ID field is composed of four sub-fields including
       a RESERVED byte-long field which MUST be set to zero. Other
       sub-fields are:

         Key ID Type            This identifies the type of Key ID
                                information carried in the Key ID field.

         Key ID Length          Length of the Key ID Value field
                                expressed in bytes.

         Key ID Value           Contains the actual Key ID which
                                identifies either a secret key or a
                                public key needed to verify the

       The following Key ID Types are defined. Implementations MUST
       support the OPAQUE Key ID type.

        Key ID
        Type            Description
        -----           -----------

        RESV (0)        Reserved

        OPAQUE (1)      Indicates that the Key ID Value contains
                        an opaque value. How the receiver uses it
                        to look up a key is entirely a local matter
                        at the receiver. The presumption here is
                        that the sender and receiver have a previously
                        agreed method of mapping the opaque key ID
                        value to a key. This definition is consistent
                        with that of the "Secret ID" in Protocol 1.

Gupta                      DHCP Authentication                  [Page 5]

INTERNET-DRAFT           Expires December, 1999                June 1999

        X509_CERT (2)   Indicates that the Key ID Value subfield
                        contains a DER encoding of an X.509 certificate.
                        The public key contained in the certificate MUST
                        be for the same algorithm as indicated in the
                        Algorithm field. For example, if the Algorithm
                        field indicates DSA, the certificate MUST
                        include a DSA public key. Similarly, if the
                        Algorithm field indicates RSA-MD5, the
                        certificate MUST include an RSA public key.
                        After verifying the authenticity of the
                        certificate, the receiver SHOULD cache the
                        included public key in order to speed up
                        verification of subsequent messages from the
                        same sender.

      X509_CERT_CHAIN   Indicates that the Key ID Value subfield
           (3)          contains a chain of X.509 certificates.
                        This is useful if the receiver may not
                        have the authenticated public key of the
                        sender's certifying authority and may
                        need to follow a certificate chain to
                        establish the required trust.

       CERT_MD5_HASH    Indicates that the Key ID Value is the
           (4)          MD5 hash of a certificate. This is useful
                        in situations where the sender has reason
                        to believe that the corresponding
                        certificate is already available to the
                        receiver (e.g. it may have been sent in
                        a previous message or the receiver is known
                        to have access to a certificate repository
                        containing the sender's certificate). Due to
                        the collision resistance property of MD5, the
                        hash identifies a unique certificate with a high
                        degree of confidence. Sending the hash (16
                        bytes) rather than the actual certificate
                        results in smaller messages.

        5 - 255        RESERVED

   2.5 Authenticator

       The computation and verification of the Authenticator field
       depends on the type of the authentication Algorithm.

       When the Algorithm is one of HMAC-MD5 or HMAC-SHA1, the
       authenticator is computed using the HMAC generation algorithm
       with the MD5 [Rive2] or SHA [NIS94a] hash functions as described

Gupta                      DHCP Authentication                  [Page 6]

INTERNET-DRAFT           Expires December, 1999                June 1999

       in [KBC97]. When the Algorithm is DSS [NIS94b], the authenticator
       contains the DER encoding of two 20 byte numbers (r followed by
       s) representing the DSA signature. When the Algorithm is RSA-MD5,
       the authenticator contains the RSA encryption output (using the
       sender's private key) of an MD5 hash. In the case of DSS and
       RSA-MD5, it is the public-key corresponding to the private-key
       used for signing that MUST be identified in the Key ID field.

       The input for these computations is the same. It is the entire
       DHCP message (except as noted below) to be protected upto and
       including the authentication option. Before signing or computing
       the MAC, the authentication option (except for the authenticator)
       must be completely filled out and the authenticator field must be
       set to zeroes. Since a DHCP relay agent may alter the values of
       the 'giaddr' and 'hops' fields in the DHCP message, the contents
       of these two fields MUST also be set to zero for computation of
       the signature or MAC. A relay agent may append the DHCP relay
       agent option 82 after the authentication option. Options that
       appear after the authentication option will not be protected
       by the Authenticator described above.

   3. Client, Server, and Relay Agent Considerations

      These considerations are not affected in any way by the use of
      Protocol 2 instead of Protocol 1. Readers are referred to [DrAr99]
      for the details.

   4. Roaming Support for DHCP Clients

      Roaming can be loosely defined as the ability of a customer to
      "use any one of multiple Internet service providers (ISPs),
      while maintaining a formal, customer-vendor relationship with
      only one" (quoted from [AbBe99]). Each roaming user is uniquely
      identified by a Network Access Identifier (NAI) [AbBe99] which
      looks like joe@acme.net and includes enough information to
      identify the ISP with which that user has a formal customer-
      vendor relationship. Most ISPs that offer roaming services today
      use PPP (over dial-up) as the address allocation mechanism. In
      the future, ISPs that use DHCP for address allocation (such as
      some Cable Modem ISPs) may also wish to support roaming. In such
      a scenario, it is logical to use NAIs as DHCP client identifiers
      so both types of ISPs can identify users in a consistent fashion.

      This section outlines how the authentication option may be used to
      support DHCP clients roaming between different administrative
      domains. For this illustration, we consider a DHCP client
      associated with ISP-A that roams to a DHCP-enabled network
      belonging to ISP-B. We assume that these two ISPs have a roaming

Gupta                      DHCP Authentication                  [Page 7]

INTERNET-DRAFT           Expires December, 1999                June 1999

      agreement in place. The agreement may be indirect, e.g. through
      a broker such as iPass [iPass] or GRIC [GRIC].

      Before providing full network connectivity to the client, ISP-B
      would like to verify that it can bill ISP-A for the service.
      The following paragraphs describe one possible sequence of steps
      through which this can be accomplished. We assume that each client
      has a digital certificate issued by its ISP (the ISP may out
      source the actual issuance of certificates but that is unimportant
      for our discussion). The certificate is valid as long as the
      customer's account active and is revoked when the account is
      closed. Besides its own private key, the client also has a trusted
      copy of its ISP's public key. These keys may be carried on
      removable media such as a smart card. If keys are stored on the
      client's local storage (e.g. a portable computer's hard disk),
      then the private key MUST be stored encrypted with a user chosen
      password. Doing so minimizes the risk of a security breach should
      the client be stolen.

      The following example uses DSA signatures for authentication.

      1. The roaming client, C, plugs into a network slot (e.g. an RJ-45
         slot for a 10BaseT connection) and sends out a DHCPDISCOVER
         request with a request for authentication. The DHCP client
         identifier (Option 61 defined in RFC 2132) is set to contain
         the roaming user's Network Access Identifier.

      2. By looking at the NAI from Step 1, a DHCP server, S, on the
         the visited network can determine the ISP, ISP-A, to which the
         client belongs. The server checks that its ISP, ISP-B, has
         a roaming agreement with the client's ISP, ISP-A. If so, it
         responds with a DHCPOFFER message containing an authentication
         option. In this option, the Algorithm is set to DSA, the Key ID
         Type is set to X509_CERT_CHAIN and the Key ID Value is set to
         include the server's certificate (issued by ISP-B) and ISP-B's
         certificate signed by ISP-A. If the agreement between ISP-A and
         ISP-B is through a broker, K, then the certificate chain may
         instead contain: Server's certificate signed by ISP-B, ISP-B's
         certificate signed by K and K's certificate signed by ISP-A.
         Other combinations are also possible depending on the public
         keys that the client is expected to possess. The authenticator
         contains a DSA signature computed by the server using its
         private key.

      3. Using a locally available copy of ISP-A's public key, the
         client can verify the server's public key and signature and
         and authenticate the offer. If authentication is successful,
         the client sends out a DHCPREQUEST message. In the

Gupta                      DHCP Authentication                  [Page 8]

INTERNET-DRAFT           Expires December, 1999                June 1999

         authentication option, Algorithm is set to DSA, the Key ID Type
         is set to X509_CERT, the Key ID Value is set to include the
         client's certificate issued by ISP-A and the authenticator
         contains a DSA signature computed by the client using its
         private key.

      4. The server first verifies the client's certificate (this
         may require it to interact with another entity such as
         a certificate repository) and uses the public key it contains
         to verify the client's signature. If verification succeeds,
         it sends back a DHCPACK message completing the sign-on
         process, otherwise it sends back a DHCPNAK.

      Unlike typical dial-up roaming situations where only the client
      is authenticated, the scheme outlined above provides mutual
      authentication of the client and server.

   4.1 Theft of Service

     Note that nothing prevents a malicious client from configuring
     itself with a cleverly guessed IP address and other parameters
     that make sense for the visited network even before the
     authenticated DHCP exchange is completed. Preventing "theft of
     service" in this situation requires the placement of some sort
     of a packet filter between the client and the other hosts it may
     wish to communicate with. Initially, this filter is set to only
     allow DHCP traffic to/from the client. After the authenticated
     exchange is completed, filtering rules are changed automatically
     (through remote network administration) to allow full connectivity
     for the client in accordance with the client's service contract
     with ISP-A (e.g. different users may be offered different QoS).
     The filter rules revert to their more restrictive version when
     the DHCP lease expires or when it is voluntarily relinquished by
     the client.

     In a typical cable modem network, the cable modem is a natural
     choice for the placement of this filter/policy enforcer.

   5. Security Considerations

     This document describes a mechanism for adding source
     authentication, integrity protection and replay detection to DHCP
     messages. This mechanism does not address message confidentiality.

Gupta                      DHCP Authentication                  [Page 9]

INTERNET-DRAFT           Expires December, 1999                June 1999

   6. Revision History

     Version       Date                     Comments
     -------       ----                     --------
       00       Jun 23, 1998     Created initial version.

   7. Future Directions:

      DISCUSSION: It seems reasonable to include an authenticator in the
      very first message, i.e. DHCPDISCOVER. This gives DHCP servers an
      opportunity to authenticate the client before sending back any
      network configuration parameters making "theft of service" even
      harder for malicious clients.

      TODO: Add nonce based replay protection. The basic idea is as
      follows: DHCPDISCOVER message will include a "challenge" from
      the client, DHCPOFFER will include the server's "response" and
      its own "challenge", DHCPREQUEST will include the client's
      "response" etc.

      Such nonce-based replay detection minimizes the amount of replay
      related state that must be maintained across reboots.


      [AbBe99] Aboba, B. and Beadles, M., "Network Access Identifier"
               RFC 2486, Jan. 1999.

      [ArKe97] Arbaugh, W. and Keromytis, A., "DHCP Continuation
               Option Code", Internet-draft <draft-ietf-dhc-options-
               cont-00.txt>, work in progress, Nov. 1997.

      [Brad96] Bradner, S., "The Internet Standards Process -- Revision
               3", RFC 2026, Oct. 1996.

      [Brad97] Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", RFC 2219, Mar. 1997.

      [Drom97] Droms, R., "Dynamic Host Configuration Protocol", RFC
               2131, Mar. 1997.

      [DrAr99] Droms, R. and Arbaugh, W., "Authentication for DHCP
               Messages", Internet-draft <draft-ietf-dhc-
               authentication-10.txt>, work in progress, Jun. 1999.

      [GRIC]   See http://www.gric.com/

      [iPass]  See http://www.ipass.com/

Gupta                      DHCP Authentication                 [Page 10]

INTERNET-DRAFT           Expires December, 1999                June 1999

      [KBC97]  Krawczyk, H., Bellare, M., and Canetti, R., "HMAC:
               Keyed-Hashing for Message Authentication," RFC 2104,
               Feb. 1997.

      [Mill92] Mills, D., "Network Time Protocol (Version 3)", RFC
               1305, Mar. 1992.

      [NIS94a] NIST, "Secure Hash Standard", FIPS 180-1, National
               Institute of Standards and Technology, U.S. Department of
               Commerce, May 1994.

      [NIS94b] NIST, "Digital Signature Standard", FIPS 186, National
               Institute of Standards and Technology, U.S. Department
               of Commerce, May, 1994.

      [Rive92] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
               Apr. 1992.

      [RSA78]  Rivest, R., Shamir, A., and Adleman, L., "A Method for
               Obtaining Digital Signatures and Public-Key
               Cryptosystems", Communications of the ACM, v. 21, n. 2,
               Feb. 1978.
Author's Address

   Vipul Gupta
   Sun Microsystems, Inc.
   901 San Antonio Rd.
   Palo Alto, CA 94303

   Tel: (650) 786 3614
   Fax: (650) 786 6445
   EMail: vipul.gupta@eng.sun.com

Gupta                      DHCP Authentication                 [Page 11]