From: Ted Lemon Date: Sat, 2 Sep 2000 01:02:08 +0000 (+0000) Subject: This is out of date. X-Git-Tag: V3-BETA-2-PATCH-1~2 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=8189c3946c6c65f7cf376be331703aa4aa6747ad;p=thirdparty%2Fdhcp.git This is out of date. --- diff --git a/doc/draft-ietf-dhc-authentication-03.txt b/doc/draft-ietf-dhc-authentication-03.txt deleted file mode 100644 index 5be035841..000000000 --- a/doc/draft-ietf-dhc-authentication-03.txt +++ /dev/null @@ -1,446 +0,0 @@ - -Network Working Group R. Droms, Editor -INTERNET DRAFT Bucknell University -Obsoletes: draft-ietf-dhc-authentication-02.txt November 1996 - Expires May 1997 - - - 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 - authentication of the source and contents of DHCP messages. This - document defines a new DHCP option through which authorization - tickets can be easily generated and newly attached hosts with proper - authorization can be automatically configured from an authenticated - DHCP server. - -1. 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 November 1996 - - - Some network administrators may wish to provide authentication of the - source and contents of DHCP messages. For example, 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. Network administrators may wish to - constrain the allocation of addresses to authorized hosts to avoid - denial of service attacks in "hostile" environments where the network - medium is not physically secured, such as wireless networks or - college residence halls. - - This document defines a technique that can provide both entity - authentication and message authentication. - -1.1 Requirements - - Throughout this document, the words that are used to define the - significance of particular requirements are capitalized. These words - are: - - o "MUST" - - This word or the adjective "REQUIRED" means that the - item is an absolute requirement of this specification. - - o "MUST NOT" - - This phrase means that the item is an absolute prohibition - of this specification. - - o "SHOULD" - - This word or the adjective "RECOMMENDED" means that there - may exist valid reasons in particular circumstances to ignore - this item, but the full implications should be understood and - the case carefully weighed before choosing a different course. - - o "SHOULD NOT" - - This phrase means that there may exist valid reasons in - particular circumstances when the listed behavior is acceptable - or even useful, but the full implications should be understood - and the case carefully weighed before implementing any behavior - described with this label. - - - - - - - - -Droms [Page 2] - -DRAFT Authentication for DHCP Messages November 1996 - - - o "MAY" - - This word or the adjective "OPTIONAL" means that this item is - truly optional. One vendor may choose to include the item - because a particular marketplace requires it or because it - enhances the product, for example; another vendor may omit the - same item. - -1.2 Terminology - - This document uses the following terms: - - o "DHCP client" - - A DHCP client or "client" is an Internet host using DHCP to obtain - configuration parameters such as a network address. - - o "DHCP server" - - A DHCP server of "server"is an Internet host that returns - configuration parameters to DHCP clients. - -2. Format of the authentication option - - The following diagram defines the format of the DHCP - authentication option: - - - +----------+----------+----------+ - | Code | Length | Protocol | - +----------+----------+----------+-----------+--- - | Authentication information ... - +----------+----------+----------+-----------+--- - - - The code for the authentication option is TBD, and the length field - contains the length of the protocol and authentication information - fields in octets. The protocol field defines the particular - technique for authentication used in the option. - - This document defines two protocols in sections 3 and 4, encoded with - protocol field values 0 and 1. Protocol field values 2-254 are - reserved for future use. Other protocols may be defined according to - the procedure described in section 5. - -3. Protocol 0 - - If the protocol field is 0, the authentication information field - - - -Droms [Page 3] - -DRAFT Authentication for DHCP Messages November 1996 - - - holds a simple authentication token: - - - +----------+----------+----------+ - | Code | n+1 | 0 | - +----------+----------+----------+-----------+------ - | Authentication token (n octets) ... - +----------+----------+----------+-----------+------ - - - The authentication token is an opaque, unencoded value known to both - the sender and receiver. The sender inserts the authentication token - in the DHCP message and the receiver matches the token from the - message to the shared token. If the authentication option is present - and the token from the message does not match the shared token, the - receiver MUST discard the message. - - Protocol 0 may be used to pass a plain-text password and provides - only weak entity authentication and no message authentication. This - protocol is useful for rudimentary protection against, e.g., - inadvertently instantiated DHCP servers. - - DISCUSSION: - - The intent here is to pass a constant, non-computed token such as - a plain-text password. Other types of entity authentication using - computed tokens such as Kerberos tickets or one-time passwords - will be defined as separate protocols. - - -4. Protocol 1 - - If the protocol field is 1, the authentication information contains - an encrypted value generated by the source as a message - authentication code (MAC) to provide message authentication and - entity authentication. - - This technique is based on the HMAC protocol [3] using the MD5 hash - {2]. - - - - - - - - - - - - -Droms [Page 4] - -DRAFT Authentication for DHCP Messages November 1996 - - -4.1 Format - - The format of the authentication information for protocol 1 is: - - - +----------+----------+----------+ - | Code | n | 1 | - +----------+----------+----------+----------+- - | Counter (8 octets) ... - +----------+----------+----------+----------+- - | MAC ... - +----------+----------+----------+----------+- - - The following definitions will be used in the description of the - authentication information for protocol 1: - - K - a secret value shared between the source and destination - of the message - Counter - the value of a 64-bit monotonically increasing counter - HMAC-MD5 - the MAC generating function as defined by [3] and [2] - - The sender computes the MAC as described in [3]. The 'counter' field - of the authentication option MUST be set to the value of a - monotonically increasing counter and the 'MAC' field of the - authentication option MUST be set to all 0s for the computation of - the MAC. Because a DHCP relay agent may alter the values of the - 'giaddr' and 'hops' fields in the DHCP message, the contents of those - two fields MUST also be set to zero for the computation of the - message digest. Using a counter value such as the current time of - day (e.g., an NTP-format timestamp [4]) can reduce the danger of - replay attacks. - - DISCUSSION: - - Protocol 1 specifies the use of HMAC-MD5. Use of a different - technique, such as HMAC-SHA, will be specified as a separate - protocol. - -4.2 Message validation - - To validate an incoming message, the receiver checks the 'counter' - field and computes the MAC as described in [3]. If the 'counter' - field does not contain a value larger than the last value of - 'counter' used by the sender, the receiver MUST discard the incoming - message. The receiver MUST set the 'MAC' field of the authentication - option to all 0s for computation of the MAC. Because a DHCP relay - agent may alter the values of the 'giaddr' and 'hops' fields in the - DHCP message, the contents of those two fields MUST also be set to - - - -Droms [Page 5] - -DRAFT Authentication for DHCP Messages November 1996 - - - zero for the computation of the MAC. If the MAC computed by the - receiver does not match the MAC contained in the authentication - option, the receiver MUST discard the DHCP message. - -4.3 Key utilization - - Each DHCP client has a key, K. The client uses its key to encode any - messages it sends to the server and to authenticate and verify any - messages it receives from the server. The client's key must be - initially distributed to the client through some out-of-band - mechanism, and must be stored locally on the client for use in all - authenticated DHCP messages. Once the client has been given its key, - it may use that key for all transactions even if the client's - configuration changes; e.g., if the client is assigned a new network - address. - - Each DHCP server must know the keys for all authorized clients. If - all clients use the same key, clients can perform both entity and - message authentication for all messages received from servers. - Servers will be able to perform message authentication. To - authenticate the identity of individual clients, each client must be - configured with a unique key. Appendix A describes a technique for - key management. - -5. Definition of new authentication protocols - - The author of a new DHCP option will follow these steps to obtain - acceptance of the option as a part of the DHCP Internet Standard: - - 1. The author devises the new authentication protocol. - 2. The author documents the new protocol as an Internet Draft. - 3. The author submits the Internet Draft for review through the IETF - standards process as defined in "Internet Official Protocol - Standards" (STD 1). The new protocol will be submitted for - eventual acceptance as an Internet Standard. - 4. The new protocol progresses through the IETF standards process; - the new option will be reviewed by the Dynamic Host Configuration - Working Group (if that group still exists), or as an Internet - Draft not submitted by an IETF working group. - - This procedure for defining new authentication protocols will ensure - that: - - * new options are reviewed for technical correctness and - appropriateness, and - * documentation for new options is complete and published. - - - - - -Droms [Page 6] - -DRAFT Authentication for DHCP Messages November 1996 - - -6. References - - [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541, - Bucknell University, October 1993. - - [2] Rivest, R., "The MD5 Message-Digest Algorithm", - RFC-1321, April 1992. - - [3] Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for - Message Authentication" (work in - progress), August 1996. - - [4] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March - 1992. - -7. Acknowledgments - - Jeff Schiller and Christian Huitema developed this scheme during a - terminal room BOF at the Dallas IETF meeting, December 1995. The - author transcribed the notes from that discussion, which form the - basis for this document. The editor appreciates Jeff's and - Christian's patience in reviewing this document and its earlier - drafts. - - Thanks also to John Wilkins, Ran Atkinson and Shawn Mamros for - reviewing this document, and to Thomas Narten for reviewing earlier - drafts of this document. - -8. Security considerations - - This document describes authentication and verification mechanisms - for DHCP. - -9. 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 7] - -DRAFT Authentication for DHCP Messages November 1996 - - - Appendix A - Key Management Technique - - To avoid centralized management of a list of random keys, suppose K for - each client is generated from the pair (client identifier, subnet - address), which must be unique to that client. That is, K = MD5(MK, - unique-id), where MK is a secret master key and MD5 is some encoding - function. - - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Droms [Page 8] -