Network Working Group                                   R. Droms (Editor) Droms, Editor
INTERNET DRAFT                                       Bucknell University
Obsoletes: draft-ietf-dhc-authentication-01.txt            February draft-ietf-dhc-authentication-02.txt            November 1996
                                                        Expires August 1996 May 1997

                    Authentication for DHCP Messages
                 <draft-ietf-dhc-authentication-02.txt>
                 <draft-ietf-dhc-authentication-03.txt>

Status of this memo

   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its 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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

Abstract

   The Dynamic Host Configuration Protocol (DHCP) [1] provides a
   framework for passing configuration information to hosts on a TCP/IP
   network.  In some situations, network administrators may wish to
   constrain the allocation of addresses to authorized hosts.
   Additionally, some network administrators may wish to provide for
   client
   authentication of DHCP messages from DHCP servers. The goal the source and contents of
   this proposal is to suggest DHCP messages.  This
   document defines a technique new DHCP option through which authorization
   tickets can be easily generated and newly attached hosts with proper
   authorization can be automatically configured from an authenticated
   DHCP server.

1. Introduction

   DHCP transports protocol stack configuration parameters from
   centrally administered servers to TCP/IP hosts.  Among those
   parameters are an IP address.  DHCP servers can be configured to
   dynamically allocate addresses from a pool of addresses, eliminating
   a manual step in configuration of TCP/IP hosts.

DRAFT               Authentication for DHCP Messages       February       November 1996

   In some situations, network administrators may wish to constrain the
   allocation of addresses to authorized hosts.  Such constraint may be
   desirable in "hostile" environments where the network medium is not
   physically secured, such as wireless networks or college residence
   halls.

   Additionally, some

   Some network administrators may wish to provide authentication of the
   source and contents of DHCP messages from DHCP servers.  In some
   environments, messages.  For example, clients may be
   subject to denial of service attacks through the use of bogus DHCP
   servers, or may simply be misconfigured due to unintentionally
   instantiated DHCP servers.

   The goal  Network administrators may wish to
   constrain the allocation of this proposal is addresses to suggest a technique through which
   authorization tickets can be easily generated and newly attached authorized hosts with proper authorization can be automatically configured from
   an authenticated DHCP server.

Overview

   The idea behind this proposal is to use well-known techniques to
   authenticate the source and contents avoid
   denial of DHCP messages.  Each
   authenticated DHCP message will include an encrypted value generated
   by service attacks in "hostile" environments where the source network
   medium is not physically secured, such as wireless networks or
   college residence halls.

   This document defines a message technique that can provide both entity
   authentication code (MAC), and will
   contain a message digest confirming authentication.

1.1 Requirements

   Throughout this document, the words that are used to define the message contents have
   not been altered in transit.

   There is one "feature"
   significance of DHCP particular requirements are capitalized.  These words
   are:

      o "MUST"

        This word or the adjective "REQUIRED" means that complicates the authentication of
   DHCP messages.  DHCP clients use limited broadcast for all messages.
   To allow for delivery
        item is an absolute requirement of DHCP messages to servers this specification.

      o "MUST NOT"

        This phrase means that are not on the
   same subnet, a DHCP relay agent on the same subnet as item is an absolute prohibition
        of this specification.

      o "SHOULD"

        This word or the client
   receives adjective "RECOMMENDED" means that there
        may exist valid reasons in particular circumstances to ignore
        this item, but the initial message full implications should be understood and forwards
        the message on to case carefully weighed before choosing a different course.

      o "SHOULD NOT"

        This phrase means that there may exist valid reasons in
        particular circumstances when the DHCP
   server.  The relay agent changes listed behavior is acceptable
        or even useful, but the contents of two fields -
   'giaddr' full implications should be understood
        and 'hops' - in the case carefully weighed before implementing any behavior
        described with this label.

DRAFT               Authentication for DHCP message.  Thus, Messages       November 1996

      o "MAY"

        This word or the message digest,
   which adjective "OPTIONAL" means that this item is
        truly optional.  One vendor may choose to be computed by include the item
        because a particular marketplace requires it or because it
        enhances the product, for example; another vendor may omit the
        same item.

1.2 Terminology

   This document uses the following terms:

      o "DHCP client"

        A DHCP client and confirmed by or "client" is an Internet host using DHCP to obtain
        configuration parameters such as a network address.

      o "DHCP server"

        A DHCP server of "server"is an Internet host that returns
        configuration parameters to DHCP clients.

2. Format of the server,
   cannot include authentication option

   The following diagram defines the 'giaddr' and 'hops' fields.

Message format of the DHCP
   authentication

   Suppose option:

    +----------+----------+----------+
    |   Code   |  Length  | Protocol |
    +----------+----------+----------+-----------+---
    |                  Authentication information    ...
    +----------+----------+----------+-----------+---

   The code for the sender, S, and receiver, R, share a secret key, K, where
   K authentication option is unique to any messages exchanged between S TBD, and R.  S the length field
   contains the length of the protocol and R are a
   DHCP client/server pair.  S forms authentication information
   fields in octets.  The protocol field defines the MAC by encoding a counter value
   with K. particular
   technique for authentication used in the option.

   This counter should be monotonically increasing document defines two protocols in sections 3 and 4, encoded with
   protocol field values 0 and large
   enough 1.  Protocol field values 2-254 are
   reserved for future use.  Other protocols may be defined according to hold an NTP-format timestamp.  The MAC:

       counter, f(K, MD(message + counter))

   (where MD is a message digest function as specified below) is
   included
   the procedure described in section 5.

3. Protocol 0

   If the DHCP message generated by S.  Encoding function f protocol field is 0, the authentication information field

DRAFT               Authentication for DHCP Messages       February       November 1996

   must have

   holds a simple authentication token:

    +----------+----------+----------+
    |   Code   |   n+1    |    0     |
    +----------+----------+----------+-----------+------
    |   Authentication token (n octets) ...
    +----------+----------+----------+-----------+------

   The authentication token is an opaque, unencoded value known to both
   the characteristics that K cannot be deduced from sender and receiver.  The sender inserts the MAC authentication token
   in the DHCP message and f(K, MD(message + counter)) can't be guessed.  R can then compute
   f(K, MD(message + counter)) to verify that S must have known K.
   Using a counter value such as the current time of day can reduce receiver matches the
   danger of replay attacks.

Key management

   Assume that token from the
   message to the shared key, K, token.  If the authentication option is distributed to present
   and the client through
   some out-of-band mechanism.  The client must store K locally for use
   in all authenticated DHCP messages.  The server must know token from the Ks for
   all authorized clients.

   To avoid centralized management of message does not match the shared token, the
   receiver MUST discard the message.

   Protocol 0 may be used to pass a list of random keys, suppose K plain-text password and provides
   only weak entity authentication and no message authentication.  This
   protocol is useful for each client rudimentary protection against, e.g.,
   inadvertently instantiated DHCP servers.

   DISCUSSION:

      The intent here is generated from some value unique to that client.
   That is, K = f(MK, unique-id), where MK is pass a secret master key and f
   is an encoding function constant, non-computed token such as described above.

   Each DHCP client must have
      a unique "client-id" through which its
   interactions with plain-text password.  Other types of entity authentication using
      computed tokens such as Kerberos tickets or one-time passwords
      will be defined as separate protocols.

4. Protocol 1

   If the DHCP server (specifically, protocol field is 1, the address
   currently allocated to authentication information contains
   an encrypted value generated by the client) can be identified.  This client-id
   may be a MAC address or source as a manufacturer's serial number; message
   authentication code (MAC) to provide message authentication and
   entity authentication.

   This technique is based on the specific
   choice HMAC protocol [3] using the MD5 hash
   {2].

DRAFT               Authentication for DHCP Messages       November 1996

4.1 Format

   The format of client-id is left to the network administrator. authentication information for protocol 1 is:

    +----------+----------+----------+
    |   Code   |    n     |    1     |
    +----------+----------+----------+----------+-
    |               Counter (8 octets)            ...
    +----------+----------+----------+----------+-
    |               MAC                           ...
    +----------+----------+----------+----------+-

   The
   client-id meets following definitions will be used in the requirements description of the unique-id used to generate
   authentication information for protocol 1:

   K
   in        - a secret value shared between the previous paragraph.

   Without knowledge source and destination
              of the master key MK, an unauthorized client cannot
   generate its own key K.  The server can quickly validate an incoming message from
   Counter  - the value of a new client 64-bit monotonically increasing counter
   HMAC-MD5 - the MAC generating function as defined by regenerating K from [3] and [2]

   The sender computes the client-id.  For
   known clients, MAC as described in [3].  The 'counter' field
   of the server can choose authentication option MUST be set to recover the client's K
   dynamically from value of a
   monotonically increasing counter and the client-id in 'MAC' field of the DHCP message, or can choose
   authentication option MUST be set to
   precompute and cache all 0s for the computation of
   the Ks MAC.  Because a priori.

Selection DHCP relay agent may alter the values of encoding function

   The exact encoding function is TBD.  One suggestion is to borrow from
   DNSSEC, in which the encoding function is designated by an identifier
   'giaddr' and 'hops' fields in the message.  The identifier then selects no encoding, DHCP message, the contents of those
   two fields MUST also be set to zero for the computation of the
   message digest.  Using a default
   encoding (using counter value such as the Public Key Cryptographic Standard current time of
   day (e.g., an NTP-format timestamp [4]) can reduce the danger of
   replay attacks.

   DISCUSSION:

      Protocol 1 specifies the use of HMAC-MD5.  Use of a different
      technique, such as specified in
   DNSSEC) which must HMAC-SHA, will be provided, or one of several other optional
   encodings.

Message contents verification

   MD5 is specified as a well-known mechanism for generating separate
      protocol.

4.2 Message validation

   To validate an incoming message, the receiver checks the 'counter'
   field and computes the MAC as described in [3]. If the 'counter'
   field does not contain a digest that can
   confirm value larger than the last value of
   'counter' used by the sender, the contents of a message have not been altered in
   transit. receiver MUST discard the incoming
   message. The only modification receiver MUST set the 'MAC' field of the authentication
   option to MD5 all 0s for use in computation of the MAC. Because a DHCP is to require
   that relay
   agent may alter the values of the 'giaddr' and 'hops' fields in the
   DHCP message, the contents of those two fields MUST also be set to all 0s for the MD5

DRAFT               Authentication for DHCP Messages       February       November 1996

   computation.

Message contents

   Putting all

   zero for the computation of this together, S builds: the MAC. If the MAC computed by the
   receiver does not match the MAC contained in the authentication
   option, the receiver MUST discard the DHCP message, counter, f(K, MD5(message - ('giaddr' message.

4.3 Key utilization

   Each DHCP client has a key, K.  The client uses its key to encode any
   messages it sends to the server and 'hops') +
   counter))

   where K is to authenticate and verify any
   messages it receives from the server.  The client's key.  R can then verify key must be
   initially distributed to the contents of client through some out-of-band
   mechanism, and must be stored locally on the
   message from client for use in all
   authenticated DHCP messages.  Once the MD5 digest value, and verify client has been given its key,
   it may use that S key for all transactions even if the client's
   configuration changes; e.g., if the client is assigned a new network
   address.

   Each DHCP server must have held know the shared secret key from keys for all authorized clients.  If
   all clients use the value of f(K, MD5(message - ('giaddr'
   and 'hops') + counter))

Applicability same key, clients can perform both entity and Specification

   This scheme is equally applicable
   message authentication for all messages received from servers.
   Servers will be able to perform message authentication.  To
   authenticate the identity of individual clients, each client must be
   configured with a unique key.  Appendix A describes a technique for
   key management.

5. Definition of new authentication protocols

   The author of both DHCPv4
   and DHCPv6 messages.  If this mechanism is adopted a new DHCP option will follow these steps to obtain
   acceptance of the option as a part of the DHCP Internet Standard:

   1. The author devises the new authentication protocol.
   2. The author documents the new protocol as an Internet Draft.
   3. The author submits the Internet Draft for review through the IETF
      standards process as part of defined in "Internet Official Protocol
      Standards" (STD 1).  The new protocol will be submitted for
      eventual acceptance as an Internet Standard.
   4. The new protocol progresses through the
   DHCPv4 or DHCPv6 specification, IETF standards process;
      the authentication data new option will be
   encoded reviewed by the Dynamic Host Configuration
      Working Group (if that group still exists), or as an option. Internet
      Draft not submitted by an IETF working group.

   This procedure for defining new authentication protocols will ensure
   that:

   * new options are reviewed for technical correctness and
     appropriateness, and
   * documentation for new options is complete and published.

DRAFT               Authentication for DHCP Messages       November 1996

6. References

   [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541,
       Bucknell University, October 1993.

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

   [3] Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for
       Message Authentication" <draft-ietf-ipsec-hmac-md5-01.txt> (work in
       progress), August 1996.

   [4] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March
       1992.

7. Acknowledgments

   Jeff Schiller and Christian Huitema developed this scheme during a
   terminal room BOF at the Dallas IETF meeting, December 1996. 1995.  The
   editor of this document
   author transcribed the notes from that discussion. discussion, which form the
   basis for this document.  The editor appreciates Jeff's and
   Christian's patience in reviewing this document and its earlier
   drafts.

   Thanks also to John Wilkins, Ran Atkinson and Thomas Narten Shawn Mamros for
   reviewing
   a draft of this proposal, document, and to Shawn Mamros for noticing that the
   original draft neglected to account Thomas Narten for the 'hops' field.

References

   [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541,
       Bucknell University, October 1993. reviewing earlier
   drafts of this document.

8. Security Considerations considerations

   This memo document describes authentication and verification mechanisms
   for DHCP

Editor's Address DHCP.

9. Author's address

   Ralph Droms
   Computer Science Department
   323 Dana Engineering
   Bucknell University
   Lewisburg, PA 17837

   Phone: (717) 524-1145
   EMail: droms@bucknell.edu

DRAFT               Authentication for DHCP Messages       February       November 1996

   EMail: droms@bucknell.edu

   Appendix A - Key Management Technique

   To avoid centralized management of a list of random keys, suppose K for
   each client is generated from the pair (client identifier, subnet
   address), which must be unique to that client.  That is, K = MD5(MK,
   unique-id), where MK is a secret master key and MD5 is some encoding
   function.

   Without knowledge of the master key MK, an unauthorized client cannot
   generate its own key K.  The server can quickly validate an incoming
   message from a new client by regenerating K from the client-id.  For known
   clients, the server can choose to recover the client's K dynamically from
   the client-id in the DHCP message, or can choose to precompute and cache
   all of the Ks a priori.