[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 06 07 08 09 10 11 12 13 14 15 RFC 3118

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


                    Authentication for DHCP Messages
                 <draft-ietf-dhc-authentication-02.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 of
   this proposal is to suggest a technique through which authorization
   tickets can be easily generated and newly attached hosts with proper
   authorization can be automatically configured from an authenticated
   DHCP server.

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.




Droms                                                           [Page 1]

DRAFT               Authentication for DHCP Messages       February 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 network administrators may wish to provide
   authentication of DHCP messages from DHCP servers.  In some
   environments, 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 of this proposal is to suggest a technique through which
   authorization tickets can be easily generated and newly attached
   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 of DHCP messages.  Each
   authenticated DHCP message will include an encrypted value generated
   by the source as a message authentication code (MAC), and will
   contain a message digest confirming that the message contents have
   not been altered in transit.

   There is one "feature" of DHCP that complicates the authentication of
   DHCP messages.  DHCP clients use limited broadcast for all messages.
   To allow for delivery of DHCP messages to servers that are not on the
   same subnet, a DHCP relay agent on the same subnet as the client
   receives the initial message and forwards the message on to the DHCP
   server.  The relay agent changes the contents of two fields -
   'giaddr' and 'hops' - in the DHCP message.  Thus, the message digest,
   which is to be computed by the client and confirmed by the server,
   cannot include the 'giaddr' and 'hops' fields.

Message authentication

   Suppose the sender, S, and receiver, R, share a secret key, K, where
   K is unique to any messages exchanged between S and R.  S and R are a
   DHCP client/server pair.  S forms the MAC by encoding a counter value
   with K.  This counter should be monotonically increasing and large
   enough 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 in the DHCP message generated by S.  Encoding function f



Droms                                                           [Page 2]

DRAFT               Authentication for DHCP Messages       February 1996


   must have the characteristics that K cannot be deduced from the MAC
   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 the
   danger of replay attacks.

Key management

   Assume that the shared key, K, is distributed to 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 the Ks for
   all authorized clients.

   To avoid centralized management of a list of random keys, suppose K
   for each client is generated from some value unique to that client.
   That is, K = f(MK, unique-id), where MK is a secret master key and f
   is an encoding function as described above.

   Each DHCP client must have a unique "client-id" through which its
   interactions with the DHCP server (specifically, the address
   currently allocated to the client) can be identified.  This client-id
   may be a MAC address or a manufacturer's serial number; the specific
   choice of client-id is left to the network administrator.  The
   client-id meets the requirements of the unique-id used to generate K
   in the previous paragraph.

   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.

Selection 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
   in the message.  The identifier then selects no encoding, a default
   encoding (using the Public Key Cryptographic Standard as specified in
   DNSSEC) which must be provided, or one of several other optional
   encodings.

Message contents verification

   MD5 is a well-known mechanism for generating a digest that can
   confirm the the contents of a message have not been altered in
   transit.  The only modification to MD5 for use in DHCP is to require
   that the 'giaddr' and 'hops' fields be set to all 0s for the MD5



Droms                                                           [Page 3]

DRAFT               Authentication for DHCP Messages       February 1996


   computation.

Message contents

   Putting all of this together, S builds:

      DHCP message, counter, f(K, MD5(message - ('giaddr' and 'hops') +
   counter))

   where K is the client's key.  R can then verify the contents of the
   message from the MD5 digest value, and verify that S must have held
   the shared secret key from the value of f(K, MD5(message - ('giaddr'
   and 'hops') + counter))

Applicability and Specification

   This scheme is equally applicable to authentication of both DHCPv4
   and DHCPv6 messages.  If this mechanism is adopted as part of the
   DHCPv4 or DHCPv6 specification, the authentication data will be
   encoded as an option.

Acknowledgments

   Jeff Schiller and Christian Huitema developed this scheme during a
   terminal room BOF at the Dallas IETF meeting, December 1996.  The
   editor of this document transcribed the notes from that discussion.
   Thanks to John Wilkins, Ran Atkinson and Thomas Narten for reviewing
   a draft of this proposal, and to Shawn Mamros for noticing that the
   original draft neglected to account for the 'hops' field.

References

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

Security Considerations

   This memo describes authentication and verification mechanisms for DHCP

Editor's Address

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

   Phone: (717) 524-1145



Droms                                                           [Page 4]

DRAFT               Authentication for DHCP Messages       February 1996


   EMail: droms@bucknell.edu


















































Droms                                                           [Page 5]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/