279 lines
9.1 KiB
Plaintext
279 lines
9.1 KiB
Plaintext
|
||
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]
|
||
|