+++ /dev/null
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-DRAFT Authentication for DHCP Messages February 1996
-
-
- EMail: droms@bucknell.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Droms [Page 5]
-\f
--- /dev/null
+
+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
+ <draft-ietf-dhc-authentication-03.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
+ 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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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" <draft-ietf-ipsec-hmac-md5-01.txt> (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]
+\f
+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]
+\f
projects / thirdparty / dhcp.git / commitdiff
