Network Working Group R. Droms (Editor)
INTERNET DRAFT Bucknell University
Obsoletes: February 1996
Expires August 1996
Authentication for DHCP Messages
<draft-ietf-dhc-authentication-00.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 one field - 'giaddr'
- 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' field.
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' field be set to all 0s for the MD5 computation.
Droms [Page 3]
DRAFT Authentication for DHCP Messages February 1996
Message contents
Putting all of this together, S builds:
DHCP message, counter, f(K, MD5(message - 'giaddr' + 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' +
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.
References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1531,
Bucknell University, October 1993.
Security Considerations
This memo describes authentication and verification mechanisms for DHCP
Author's Address
Ralph Droms
Computer Science Department
323 Dana Engineering
Bucknell University
Lewisburg, PA 17837
Phone: (717) 524-1145
EMail: droms@bucknell.edu
Droms [Page 4]
