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]
|
|||
|
|