HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 01:44:07 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 21 Feb 1996 23:00:00 GMT ETag: "2ed6d3-2454-312ba3f0" Accept-Ranges: bytes Content-Length: 9300 Connection: close Content-Type: text/plain Network Working Group R. Droms (Editor) INTERNET DRAFT Bucknell University Obsoletes: draft-ietf-dhc-authentication-00.txt February 1996 Expires August 1996 Authentication for DHCP Messages 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 Author'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]