From: Ted Lemon Date: Wed, 5 Mar 1997 04:32:11 +0000 (+0000) Subject: New draft X-Git-Tag: DHCP-970305~21 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=02c588bbb387e624fd81484fc1efbb9275079365;p=thirdparty%2Fdhcp.git New draft --- diff --git a/doc/draft-ietf-dhc-authentication-02.txt b/doc/draft-ietf-dhc-authentication-02.txt deleted file mode 100644 index e6134472f..000000000 --- a/doc/draft-ietf-dhc-authentication-02.txt +++ /dev/null @@ -1,278 +0,0 @@ - -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 - - -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] - diff --git a/doc/draft-ietf-dhc-authentication-03.txt b/doc/draft-ietf-dhc-authentication-03.txt new file mode 100644 index 000000000..5be035841 --- /dev/null +++ b/doc/draft-ietf-dhc-authentication-03.txt @@ -0,0 +1,446 @@ + +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] +