Forcerenew Nonce Authentication
updates
- rfc-3203 — DHCP reconfigure extension
Extracted elements (25)
HMAC-MD5 was chosen without providing an extensible HMAC mechanism because on-link attackers can trivially observe DHCP renewal traffic regardless of the algorithm, making stronger algorithms unnecessary; the only relevant threat is off-network attackers, for whom any HMAC with a secret nonce suffices.
The Forcerenew Nonce Authentication protocol was introduced because RFC 3118 authentication—mandatory for FORCERENEW per RFC 3203—requires out-of-band distribution of shared secrets to DHCP clients, which is operationally burdensome and has severely limited adoption of DHCP FORCERENEW. The nonce-based approach, mirroring RFC 3315 (DHCPv6), eliminates the out-of-band key distribution requirement.
The server selects and transmits a new Forcerenew Nonce only during Request/ACK exchanges (not on renew responses unless a new nonce is generated) to minimize nonce exposure over the network, reducing interception opportunities.
The Forcerenew Nonce Authentication protocol is used only when both client and server have negotiated it via the FORCERENEW_NONCE_CAPABLE (145) option exchange; if either party does not support it, the existing RFC 3118 authentication mechanism remains required for FORCERENEW messages.
A client that supports this mechanism MUST indicate Forcerenew nonce capability by including the FORCERENEW_NONCE_CAPABLE (145) option in all DHCP Discover and Request messages.
A DHCP client MUST NOT send DHCP messages with authentication options where the protocol value is Forcerenew Nonce Authentication; only servers may initiate that protocol value.
FORCERENEW messages failing authentication should be silently discarded by the client.
If a capable server receives a DISCOVER or REQUEST indicating a capable client and has no previous nonce recorded, it MUST generate a nonce and include it in the ACK.
If the server indicated Forcerenew Nonce Authentication capability in the DHCP OFFER and the subsequent ACK omits a valid authentication option, the client MUST discard the message and return to the INIT state.
The client MUST record the Forcerenew Nonce from any valid ACK it receives that contains one, for use in authenticating subsequent FORCERENEW messages.
The DHCP Discover or Request message from the client MUST contain the FORCERENEW_NONCE_CAPABLE (145) option if the Forcerenew Nonce Protocol is to be used by the server; the absence of this option means the server MUST NOT include a Forcerenew Nonce Protocol Authentication option in the DHCP ACK.
The FORCERENEW message MUST be authenticated using either RFC 3118 or the Forcerenew Nonce Authentication protocol defined in this document.
The Forcerenew nonce MUST be a 128-bit cryptographically strong random or pseudo-random number that cannot easily be predicted.
The server SHOULD NOT include the nonce in an ACK when responding to a renew unless a new nonce was generated, to minimize the number of times the nonce is sent over the wire.
When a client enters the REBINDING state and contacts a new server, the new server receiving the DHCP message MUST generate a new nonce.
The Authentication Information field has a Type byte that distinguishes two uses: Type 1 carries the 128-bit Forcerenew Nonce Value (sent in ACK messages) and Type 2 carries the HMAC-MD5 digest of the Forcerenew message.
The Forcerenew Nonce Authentication protocol reuses the DHCP Authentication option (code 90, RFC 3118) with Protocol set to 3 (Reconfigure Key), Algorithm set to 1 (HMAC-MD5), and RDM set to 0. The Authentication Information field carries either the nonce value or the HMAC-MD5 digest.
The FORCERENEW_NONCE_CAPABLE option (code 145) is used by clients to advertise support for the Forcerenew Nonce Authentication protocol in DHCP Discover and Request messages, and by servers to indicate preference in DHCP Offer messages. It carries a list of supported algorithm identifiers.
IANA assigned DHCPv4 option code 145 (Tag: 145, Name: FORCERENEW_NONCE_CAPABLE, Data length: 1) in the 'BOOTP Vendor Extensions and DHCP Options' registry for the Forcerenew Nonce Capable option defined by this document.
The Forcerenew Nonce Authentication protocol protects against off-network attackers triggering DHCP renewal via spoofed FORCERENEW messages; since the attacker lacks the nonce exchanged in the initial ACK, it cannot forge a valid HMAC-MD5 digest. However, an on-link attacker can observe the renewal exchange directly, making the nonce ineffective against on-link threats.
The protocol can be compromised by an attacker that intercepts the initial DHCP ACK in which the server sends the nonce to the client, enabling subsequent forgery of authenticated FORCERENEW messages.
The protocol is vulnerable to a denial-of-service attack through flooding a client with bogus FORCERENEW messages; the HMAC-MD5 computations required to authenticate each bogus message may overwhelm the client device.
During capability negotiation, the client includes FORCERENEW_NONCE_CAPABLE in DISCOVER and REQUEST; upon receiving an ACK with the nonce, the client stores it and enters the bound state. On receiving a FORCERENEW, the client validates the HMAC-MD5 using the stored nonce, then transitions back through REQUEST/ACK to obtain a new nonce, or discards the message and stays bound if validation fails. If the server fails to respond at T1, the client enters REBINDING and a new server MUST generate a fresh nonce.
The DHCP Authentication option (code 90) format used by this protocol: Code (8 bits), Length (8 bits), Protocol=3 (8 bits), Algorithm=1 (8 bits), RDM=0 (8 bits), Replay Detection (64 bits), Authentication Information (variable). The Authentication Information sub-field format is: Type (8 bits) + Value (128 bits).
The FORCERENEW_NONCE_CAPABLE option wire format is: Code=145 (1 octet), Length=n (1 octet), followed by n octets each identifying a supported algorithm (e.g., A1, A2, A3).