diff options
Diffstat (limited to 'doc/rfc/rfc3118.txt')
| -rw-r--r-- | doc/rfc/rfc3118.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc3118.txt b/doc/rfc/rfc3118.txt new file mode 100644 index 0000000..223976e --- /dev/null +++ b/doc/rfc/rfc3118.txt @@ -0,0 +1,955 @@ + + + + + + +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. + +Abstract + + This 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. Introduction + + DHCP [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 + + + +Droms & Arbaugh Standards Track [Page 1] + +RFC 3118 Authentication for DHCP Messages June 2001 + + + 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. + +1.1 DHCP threat model + + The threat to DHCP is inherently an insider threat (assuming a + properly configured network where BOOTP ports are blocked on the + enterprise's perimeter gateways.) Regardless of the gateway + configuration, however, the potential attacks by insiders and + outsiders are the same. + + The attack specific to a DHCP client is the possibility of the + establishment of a "rogue" server with the intent of providing + incorrect configuration information to the client. The motivation + for doing so may be to establish a "man in the middle" attack or it + may be for a "denial of service" attack. + + There is another threat to DHCP clients from mistakenly or + accidentally configured DHCP servers that answer DHCP client requests + with unintentionally incorrect configuration parameters. + + The threat specific to a DHCP server is an invalid client + masquerading as a valid client. The motivation for this may be for + "theft of service", or to circumvent auditing for any number of + nefarious purposes. + + The threat common to both the client and the server is the resource + "denial of service" (DoS) attack. These attacks typically involve + the exhaustion of valid addresses, or the exhaustion of CPU or + network bandwidth, and are present anytime there is a shared + resource. In current practice, redundancy mitigates DoS attacks the + best. + +1.2 Design goals + + These are the goals that were used in the development of the + authentication protocol, listed in order of importance: + + 1. Address the threats presented in Section 1.1. + 2. Avoid changing the current protocol. + + + + + +Droms & Arbaugh Standards Track [Page 2] + +RFC 3118 Authentication for DHCP Messages June 2001 + + + 3. Limit state required by the server. + 4. Limit complexity (complexity breeds design and implementation + errors). + +1.3 Requirements Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [5]. + +1.4 DHCP 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 or "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: + + 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 | Protocol | Algorithm | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RDM | Replay Detection (64 bits) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Replay cont. | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Replay cont. | | + +-+-+-+-+-+-+-+-+ | + | | + | Authentication Information | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The code for the authentication option is 90, and the length field + contains the length of the protocol, RDM, algorithm, Replay Detection + fields and authentication information fields in octets. + + + +Droms & Arbaugh Standards Track [Page 3] + +RFC 3118 Authentication for DHCP Messages June 2001 + + + 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 [4]) can reduce the danger of replay attacks. This method + MUST be supported by all protocols. + +3. Interaction with Relay Agents + + 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 be set to zero for the computation of any hash function over the + message header. Additionally, a relay agent may append the DHCP + relay agent information option 82 [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. + +4. Configuration token + + If the protocol field is 0, the authentication information field + holds a simple configuration token: + + + + + + + + + + + + + + +Droms & Arbaugh Standards Track [Page 4] + +RFC 3118 Authentication for DHCP Messages June 2001 + + + 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. + +5. Delayed authentication + + If the protocol field is 1, the message is using the "delayed + authentication" mechanism. In delayed authentication, the client + requests authentication in its DHCPDISCOVER message and the server + replies with a DHCPOFFER message that includes authentication + information. This authentication information contains a nonce value + generated by the source as a message authentication code (MAC) to + provide message authentication and entity authentication. + + This document defines the use of a particular technique based on the + HMAC protocol [3] using the MD5 hash [2]. + + + + +Droms & Arbaugh Standards Track [Page 5] + +RFC 3118 Authentication for DHCP Messages June 2001 + + +5.1 Management Issues + + The "delayed authentication" protocol does not attempt to address + situations where a client may roam from one administrative domain to + another, i.e., interdomain roaming. This protocol is focused on + solving the intradomain problem where the out-of-band exchange of a + shared secret is feasible. + +5.2 Format + + The format of the authentication request in a DHCPDISCOVER or a + DHCPINFORM message for delayed authentication is: + + 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 1| Algorithm | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RDM | Replay Detection (64 bits) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Replay cont. | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Replay cont. | + +-+-+-+-+-+-+-+-+ + + The format of the authentication information in a DHCPOFFER, + DHCPREQUEST or DHCPACK message for delayed authentication is: + + 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 1| Algorithm | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RDM | Replay Detection (64 bits) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Replay cont. | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Replay cont. | Secret ID (32 bits) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | secret id cont| HMAC-MD5 (128 bits) .... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The following definitions will be used in the description of the + authentication information for delayed authentication, algorithm 1: + + + + + + + +Droms & Arbaugh Standards Track [Page 6] + +RFC 3118 Authentication for DHCP Messages June 2001 + + + 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 [3] + and the MD5 hash function [2]. 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. + +5.3 Message validation + + To validate an incoming message, the receiver first checks that the + value in the replay detection field is acceptable according to the + replay detection method specified by the RDM field. Next, the + receiver computes the MAC as described in [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). + + + + + + +Droms & Arbaugh Standards Track [Page 7] + +RFC 3118 Authentication for DHCP Messages June 2001 + + +5.4 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 SHOULD be + initially distributed to the client through some out-of-band + mechanism, and SHOULD be stored locally on the client for use in all + authenticated DHCP messages. Once the client has been given its key, + it SHOULD 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, or be able to obtain in a secure manner, + 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. However, the sharing of keys is + strongly discouraged as it allows for unauthorized clients to + masquerade as authorized clients by obtaining a copy of the shared + key. 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.5 Client considerations + + This section describes the behavior of a DHCP client using delayed + authentication. + +5.5.1 INIT state + + When in INIT state, the client uses delayed authentication as + follows: + + 1. The client MUST include the authentication request option in its + DHCPDISCOVER message along with a client identifier option [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. + + + + +Droms & Arbaugh Standards Track [Page 8] + +RFC 3118 Authentication for DHCP Messages June 2001 + + + 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. + +5.5.2 INIT-REBOOT state + + When in INIT-REBOOT state, the client MUST use the secret it used in + its DHCPREQUEST message to obtain its current configuration to + generate authentication information for the DHCPREQUEST message. The + client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages + if no authenticated messages were received. The client MUST treat + the receipt (or lack thereof) of any DHCPACK/DHCPNAK messages as + specified in section 3.2 of [1]. + + + + + + +Droms & Arbaugh Standards Track [Page 9] + +RFC 3118 Authentication for DHCP Messages June 2001 + + +5.5.3 RENEWING state + + When in RENEWING state, the client uses the secret it used in its + initial DHCPREQUEST message to obtain its current configuration to + generate authentication information for the DHCPREQUEST message. If + client receives no DHCPACK messages or none of the DHCPACK messages + pass validation, the client behaves as if it had not received a + DHCPACK message in section 4.4.5 of the DHCP specification [1]. + +5.5.4 REBINDING state + + When in REBINDING state, the client uses the secret it used in its + initial DHCPREQUEST message to obtain its current configuration to + generate authentication information for the DHCPREQUEST message. If + client receives no DHCPACK messages or none of the DHCPACK messages + pass validation, the client behaves as if it had not received a + DHCPACK message in section 4.4.5 of the DHCP specification [1]. + +5.5.5 DHCPINFORM message + + Since the client already has some configuration information, the + client may also have established a shared secret value, K, with a + server. Therefore, the client SHOULD use the authentication request + as in a DHCPDISCOVER message when a shared secret value exists. The + client MUST treat any received DHCPACK messages as it does DHCPOFFER + messages, see section 5.5.1. + +5.5.6 DHCPRELEASE message + + Since the client is already in the BOUND state, the client will have + a security association already established with the server. + Therefore, the client MUST include authentication information with + the DHCPRELEASE message. + +5.6 Server considerations + + This section describes the behavior of a server in response to client + messages using delayed authentication. + +5.6.1 General considerations + + Each server maintains a list of secrets and identifiers for those + secrets that it shares with clients and potential clients. This + information must be maintained in such a way that the server can: + + * Identify an appropriate secret and the identifier for that secret + for use with a client that the server may not have previously + communicated with + + + +Droms & Arbaugh Standards Track [Page 10] + +RFC 3118 Authentication for DHCP Messages June 2001 + + + * 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 [1]. + +5.6.2 After receiving a DHCPDISCOVER message + + The server selects a secret for the client and includes + authentication information in the DHCPOFFER message as specified in + 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. + +5.6.3 After receiving a DHCPREQUEST message + + The server uses the secret identified in the message and validates + the message as specified in 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. + +5.6.4 After receiving a DHCPINFORM message + + The server MAY choose to accept unauthenticated DHCPINFORM messages, + or only accept authenticated DHCPINFORM messages based on a site + policy. + + + + + +Droms & Arbaugh Standards Track [Page 11] + +RFC 3118 Authentication for DHCP Messages June 2001 + + + 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. + +6. IANA Considerations + + 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 [8]. + + 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. + +7. References + + [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March + 1997. + + [2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April + 1992. + + + + +Droms & Arbaugh Standards Track [Page 12] + +RFC 3118 Authentication for DHCP Messages June 2001 + + + [3] Krawczyk H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for + Message Authentication", RFC 2104, February 1997. + + [4] Mills, D., "Network Time Protocol (Version 3)", RFC 1305, March + 1992. + + [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", RFC 2219, March 1997. + + [6] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor + Extensions", RFC 2132, March 1997. + + [7] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, + January 2001. + + [8] Narten, T. and H. Alvestrand, "Guidelines for Writing and IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + +8. Acknowledgments + + Jeff Schiller and Christian Huitema developed the original version of + this authentication protocol in a terminal room BOF at the Dallas + IETF meeting, December 1995. One of the editors (Droms) transcribed + the notes from that discussion, which form the basis for this + document. The editors appreciate Jeff's and Christian's patience in + reviewing this document and its earlier drafts. + + The "delayed authentication" mechanism used in 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. + + + + + + + + +Droms & Arbaugh Standards Track [Page 13] + +RFC 3118 Authentication for DHCP Messages June 2001 + + +9. Security Considerations + + This document describes authentication and verification mechanisms + for DHCP. + +9.1 Protocol vulnerabilities + + The configuration token authentication mechanism is vulnerable to + interception and provides only the most rudimentary protection + against inadvertently instantiated DHCP servers. + + The delayed authentication mechanism described in this document is + vulnerable to a denial of service attack through flooding with + DHCPDISCOVER messages, which are not authenticated by this protocol. + Such an attack may overwhelm the computer on which the DHCP server is + running and may exhaust the addresses available for assignment by the + DHCP server. + + Delayed authentication may also be vulnerable to a denial of service + attack through flooding with authenticated messages, which may + overwhelm the computer on which the DHCP server is running as the + authentication keys for the incoming messages are computed. + +9.2 Protocol limitations + + Delayed authentication does not support interdomain authentication. + + A real digital signature mechanism such as RSA, while currently + computationally infeasible, would provide better security. + + + + + + + + + + + + + + + + + + + + + + +Droms & Arbaugh Standards Track [Page 14] + +RFC 3118 Authentication for DHCP Messages June 2001 + + +10. Editors' Addresses + + Ralph Droms + Cisco Systems + 300 Apollo Drive + Chelmsford, MA 01824 + + Phone: (978) 244-4733 + EMail: rdroms@cisco.com + + + Bill Arbaugh + Department of Computer Science + University of Maryland + A.V. Williams Building + College Park, MD 20742 + + Phone: (301) 405-2774 + EMail: waa@cs.umd.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Droms & Arbaugh Standards Track [Page 15] + +RFC 3118 Authentication for DHCP Messages June 2001 + + +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 [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. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Droms & Arbaugh Standards Track [Page 16] + +RFC 3118 Authentication for DHCP Messages June 2001 + + +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. + + + + + + + + + + + + + + + + + + + +Droms & Arbaugh Standards Track [Page 17] + |