Authentication for DHCP Messages
Extracted elements (30)
Algorithm 1 specifies HMAC-MD5 specifically because HMAC-SHA or other alternatives would need to be defined as a separate protocol value, keeping the core mechanism simple and extensible without versioning conflicts.
The delayed authentication protocol is intentionally restricted to intradomain use because it requires each client to have a pre-shared key on every DHCP server it may contact. This does not scale well across administrative domains, and interdomain roaming was explicitly out of scope.
The key management technique in Appendix A derives each client key as K = MAC(MK, unique-id) from a master key, so the DHCP server needs no centralized authentication server and stores no clear-text passwords, while still preventing unauthorized clients from generating valid keys without MK.
The authenticated DHCPREQUEST from a client in INIT-REBOOT state can only be validated by servers that used the same secret in their DHCPOFFER. Servers that cannot validate the DHCPREQUEST will eventually reclaim their offered addresses per the standard DHCP timeout mechanism.
A client MUST be configurable to decline unauthenticated DHCP messages, and SHOULD be configured by default to decline unauthenticated messages. If a client does accept an unauthenticated message, it SHOULD inform local users and SHOULD log the event.
A client's key SHOULD be initially distributed through an out-of-band mechanism and SHOULD be stored locally. Once given its key, the client SHOULD use that key for all transactions even if its configuration changes (e.g., new network address).
After receiving a DHCPREQUEST, if the message fails validation or the server does not know the secret identified by the 'secret ID' field, the server MUST discard the message and MAY log the failure.
Because a DHCP relay agent may alter the 'giaddr' and 'hops' fields, those two fields MUST be set to zero for computation of any hash function over the message header.
Each DHCP server MUST know, or be able to obtain in a secure manner, the keys for all authorized clients. Each client MUST be configured with a unique key to authenticate individual client identities; sharing keys is strongly discouraged.
Each server MUST save the counter from the previous authenticated message and MUST discard any incoming message that fails the replay detection check as defined by the RDM field.
For delayed authentication MAC computation, the receiver MUST set the 'MAC' field of the authentication option to all zeros, and MUST set the 'giaddr' and 'hops' fields to zero. If the computed MAC does not match the received MAC, the receiver MUST discard the DHCP message.
If a server finds relay agent option 82 included in a received message, the server MUST compute any hash function as if option 82 were NOT included in the message without changing the order of other options. When sending option 82 back to a relay agent, the server MUST NOT include option 82 in hash computation.
If the client authenticated the DHCPOFFER it accepted, the client MUST validate the DHCPACK. If the DHCPACK fails validation, the client MUST revert to INIT state. The client MUST discard the DHCPACK and MAY log the failure.
If the configuration token option is present and the token from the message does not match the shared token, the receiver MUST discard the message.
In INIT-REBOOT state, the client MUST use the same secret it used in its DHCPREQUEST message to obtain its current configuration when generating authentication information for the new DHCPREQUEST.
In INIT state, the client MUST include the authentication request option in its DHCPDISCOVER message along with a client identifier option to uniquely identify itself to the server.
In the Appendix A key management scheme, the master key MK MUST NOT be stored by any clients. Clients SHOULD only be given their individual derived key K. If MK is compromised, a new MK SHOULD be chosen and all clients re-keyed.
Since a client in BOUND state has an established security association with the server, the client MUST include authentication information with any DHCPRELEASE message.
When a client includes the authentication request in a DHCPINFORM message, the server MUST respond with an authenticated DHCPACK message if it has a shared secret established with the client.
When RDM field is 0x00, the Replay Detection field MUST be set to the value of a monotonically increasing counter. Using a current time-of-day value such as an NTP-format timestamp can reduce the danger of replay attacks.
In delayed authentication, the DHCPDISCOVER/DHCPINFORM request format omits the Secret ID and HMAC-MD5 fields; those are only present in server replies (DHCPOFFER, DHCPREQUEST, DHCPACK).
Protocol 0 (configuration token) carries an opaque, unencoded shared token in the Authentication Information field. The receiver matches the token from the message to its locally configured shared token; mismatches cause the message to be discarded.
The Protocol field identifies the authentication technique: value 0 is the configuration token protocol and value 1 is the delayed authentication protocol. New protocol values are assigned via IETF Consensus.
The Replay Detection Method (RDM) field specifies the type of replay protection. RDM value 0x00 requires a monotonically increasing counter (e.g., an NTP-format timestamp) in the 64-bit Replay Detection field, and this method MUST be supported by all protocols.
IANA creates three new name spaces for the DHCP Authentication Option (code 90): Protocol, Algorithm (per-protocol), and RDM. Initial Protocol values are 0 (configuration token) and 1 (delayed authentication). Initial RDM value is 0 (monotonically increasing counter). New values require IETF Consensus per RFC 2434.
Delayed authentication does not support interdomain authentication; it is limited to intradomain scenarios where an out-of-band exchange of a shared secret is feasible. A real digital signature mechanism such as RSA would provide better security but was computationally infeasible at time of writing.
The configuration token protocol is vulnerable to interception and provides only rudimentary protection against inadvertently instantiated DHCP servers. It cannot authenticate message contents and is not suitable for hostile environments.
The delayed authentication mechanism is vulnerable to DoS attacks through flooding with unauthenticated DHCPDISCOVER messages (exhausting addresses or server CPU) and also through flooding with authenticated messages (requiring key computation for each). Redundancy is the best mitigation.
The delayed authentication (protocol 1) authentication information in DHCPOFFER/DHCPREQUEST/DHCPACK includes: Code, Length, Protocol=1, Algorithm (8 bits), RDM (8 bits), Replay Detection (64 bits), Secret ID (32 bits), and HMAC-MD5 (128 bits).
The DHCP Authentication Option (code 90) contains: Code (8 bits), Length (8 bits), Protocol (8 bits), Algorithm (8 bits), RDM (8 bits), Replay Detection (64 bits), and a variable-length Authentication Information field. The length field counts all fields after Code and Length.