Network Working Group R. Droms, Editor Request for Comments: 3118 Cisco Systems Category: Standards Track W. Arbaugh, Editor University of Maryland June 2001 Authentication for DHCP Messages Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved.
AbstractThis document defines a new Dynamic Host Configuration Protocol (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. DHCP 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. 1] 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. 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. The current protocol combines the original Schiller-Huitema-Droms authentication mechanism defined in a previous work in progress with the "delayed authentication" proposal developed by Bill Arbaugh. Section 1.1. 2. Avoid changing the current protocol.
The protocol field defines the particular technique for authentication used in the option. New protocols are defined as described in Section 6. The algorithm field defines the specific algorithm within the technique identified by the protocol field. The Replay Detection field is per the RDM, and the authentication information field is per the protocol in use. The Replay Detection Method (RDM) field determines the type of replay detection used in the Replay Detection field. If the RDM field contains 0x00, the replay detection field MUST be set to the value of a monotonically increasing counter. Using a counter value such as the current time of day (e.g., an NTP-format timestamp ) can reduce the danger of replay attacks. This method MUST be supported by all protocols. 7] as the last option in a message to servers. If a server finds option 82 included in a received message, the server MUST compute any hash function as if the option were NOT included in the message without changing the order of options. Whenever the server sends back option 82 to a relay agent, the server MUST not include the option in the computation of any hash function over the message.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Length |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0| Replay Detection (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Replay cont. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Replay cont. | | |-+-+-+-+-+-+-+-+ | | | | Authentication Information | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The configuration token is an opaque, unencoded value known to both the sender and receiver. The sender inserts the configuration token in the DHCP message and the receiver matches the token from the message to the shared token. If the configuration option is present and the token from the message does not match the shared token, the receiver MUST discard the message. Configuration token may be used to pass a plain-text configuration token and provides only weak entity authentication and no message authentication. This protocol is only useful for rudimentary protection against 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. 3] using the MD5 hash .
Replay Detection - as defined by the RDM field K - a secret value shared between the source and destination of the message; each secret has a unique identifier (secret ID) secret ID - the unique identifier for the secret value used to generate the MAC for this message HMAC-MD5 - the MAC generating function [3, 2]. The sender computes the MAC using the HMAC generation algorithm  and the MD5 hash function . The entire DHCP message (except as noted below), including the DHCP message header and the options field, is used as input to the HMAC-MD5 computation function. The 'secret ID' field MUST be set to the identifier of the secret used to generate the MAC. DISCUSSION: Algorithm 1 specifies the use of HMAC-MD5. Use of a different technique, such as HMAC-SHA, will be specified as a separate protocol. Delayed authentication requires a shared secret key for each client on each DHCP server with which that client may wish to use the DHCP protocol. Each secret key has a unique identifier that can be used by a receiver to determine which secret was used to generate the MAC in the DHCP message. Therefore, delayed authentication may not scale well in an architecture in which a DHCP client connects to multiple administrative domains. 3]. The receiver MUST set the 'MAC' field of the authentication option to all 0s for computation of the MAC, and 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 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. Section 3 provides additional information on handling messages that include option 82 (Relay Agents).
Appendix A describes a technique for key management. 6] to identify itself uniquely to the server. 2. The client MUST perform the validation test described in section 5.3 on any DHCPOFFER messages that include authentication information. If one or more DHCPOFFER messages pass the validation test, the client chooses one of the offered configurations. Client behavior if no DHCPOFFER messages include authentication information or pass the validation test is controlled by local policy in the client. According to client policy, the client MAY choose to respond to a DHCPOFFER message that has not been authenticated.
The decision to set local policy to accept unauthenticated messages should be made with care. Accepting an unauthenticated DHCPOFFER message can make the client vulnerable to spoofing and other attacks. If local users are not explicitly informed that the client has accepted an unauthenticated DHCPOFFER message, the users may incorrectly assume that the client has received an authenticated address and is not subject to DHCP attacks through unauthenticated messages. A client MUST be configurable to decline unauthenticated messages, and SHOULD be configured by default to decline unauthenticated messages. A client MAY choose to differentiate between DHCPOFFER messages with no authentication information and DHCPOFFER messages that do not pass the validation test; for example, a client might accept the former and discard the latter. If a client does accept an unauthenticated message, the client SHOULD inform any local users and SHOULD log the event. 3. The client replies with a DHCPREQUEST message that MUST include authentication information encoded with the same secret used by the server in the selected DHCPOFFER message. 4. If the client authenticated the DHCPOFFER it accepted, the client MUST validate the DHCPACK message from the server. The client MUST discard the DHCPACK if the message fails to pass validation and MAY log the validation failure. If the DHCPACK fails to pass validation, the client MUST revert to INIT state and returns to step 1. The client MAY choose to remember which server replied with a DHCPACK message that failed to pass validation and discard subsequent messages from that server. If the client accepted a DHCPOFFER message that did not include authentication information or did not pass the validation test, the client MAY accept an unauthenticated DHCPACK message from the server. section 3.2 of .
section 4.4.5 of the DHCP specification . section 4.4.5 of the DHCP specification . section 5.5.1.
* Retrieve the secret and identifier used by a client to which the server has provided previous configuration information Each server MUST save the counter from the previous authenticated message. A server MUST discard any incoming message which fails the replay detection check as defined by the RDM avoid replay attacks. DISCUSSION: The authenticated DHCPREQUEST message from a client in INIT-REBOOT state can only be validated by servers that used the same secret in their DHCPOFFER messages. Other servers will discard the DHCPREQUEST messages. Thus, only servers that used the secret selected by the client will be able to determine that their offered configuration information was not selected and the offered network address can be returned to the server's pool of available addresses. The servers that cannot validate the DHCPREQUEST message will eventually return their offered network addresses to their pool of available addresses as described in section 3.1 of the DHCP specification . section 5, above. The server MUST record the identifier of the secret selected for the client and use that same secret for validating subsequent messages with the client. section 5.3. If the message fails to pass validation or the server does not know the secret identified by the 'secret ID' field, the server MUST discard the message and MAY choose to log the validation failure. If the message passes the validation procedure, the server responds as described in the DHCP specification. The server MUST include authentication information generated as specified in section 5.2.
When a client includes the authentication request in a DHCPINFORM message, the server MUST respond with an authenticated DHCPACK message. If the server does not have a shared secret value established with the sender of the DHCPINFORM message, then the server MAY respond with an unauthenticated DHCPACK message, or a DHCPNAK if the server does not accept unauthenticated clients based on the site policy, or the server MAY choose not to respond to the DHCPINFORM message. Section 2 defines a new DHCP option called the Authentication Option, whose option code is 90. This document specifies three new name spaces associated with the Authentication Option, which are to be created and maintained by IANA: Protocol, Algorithm and RDM. Initial values assigned from the Protocol name space are 0 (for the configuration token Protocol in section 4) and 1 (for the delayed authentication Protocol in section 5). Additional values from the Protocol name space will be assigned through IETF Consensus, as defined in RFC 2434 . The Algorithm name space is specific to individual Protocols. That is, each Protocol has its own Algorithm name space. The guidelines for assigning Algorithm name space values for a particular protocol should be specified along with the definition of a new Protocol. For the configuration token Protocol, the Algorithm field MUST be 0. For the delayed authentication Protocol, the Algorithm value 1 is assigned to the HMAC-MD5 generating function as defined in section 5. Additional values from the Algorithm name space for Algorithm 1 will be assigned through IETF Consensus, as defined in RFC 2434. The initial value of 0 from the RDM name space is assigned to the use of a monotonically increasing value as defined in section 2. Additional values from the RDM name space will be assigned through IETF Consensus, as defined in RFC 2434.  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
 Krawczyk H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.  Mills, D., "Network Time Protocol (Version 3)", RFC 1305, March 1992.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2219, March 1997.  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.  Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.  Narten, T. and H. Alvestrand, "Guidelines for Writing and IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. section 5 is due to Bill Arbaugh. The threat model and requirements in sections 1.1 and 1.2 come from Bill's negotiation protocol proposal. The attendees of an interim meeting of the DHC WG held in June, 1998, including Peter Ford, Kim Kinnear, Glenn Waters, Rob Stevens, Bill Arbaugh, Baiju Patel, Carl Smith, Thomas Narten, Stewart Kwan, Munil Shah, Olafur Gudmundsson, Robert Watson, Ralph Droms, Mike Dooley, Greg Rabil and Arun Kapur, developed the threat model and reviewed several alternative proposals. The replay detection method field is due to Vipul Gupta. Other input from Bill Sommerfield is gratefully acknowledged. Thanks also to John Wilkins, Ran Atkinson, Shawn Mamros and Thomas Narten for reviewing earlier drafts of this document.
6], subnet address, e.g., 192.168.1.0), which must be unique to that client. That is, K = MAC(MK, unique-id), where MK is a secret master key and MAC is a keyed one-way function such as HMAC-MD5. 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. By deriving all keys from a single master key, the DHCP server does not need access to clear text passwords, and can compute and verify the keyed MACs without requiring help from a centralized authentication server. To avoid compromise of this key management system, the master key, MK, MUST NOT be stored by any clients. The client SHOULD only be given its key, K. If MK is compromised, a new MK SHOULD be chosen and all clients given new individual keys.
Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.