Summary

  • RFC 3118's delayed authentication depended on a shared secret provisioned out of band between a DHCP client and server within one administrative domain.
  • A client could still accept an unauthenticated offer if local policy allowed it; the RFC recommended a configurable default that declined unauthenticated messages.

The option did not create a universal identity

DHCP is usually remembered as the protocol that lets a host arrive on a network and receive an address and other configuration. That convenience also created a trust problem. A rogue or accidentally enabled server could offer a client an incorrect gateway, name server or address. A server could face a client pretending to be authorized or trying to exhaust a pool. RFC 3118, published in June 2001, set out to authenticate the source and contents of DHCP messages without redesigning the protocol.

Its option 90 made the mechanism explicit on the wire: a protocol selector, algorithm, replay-detection method, replay value and authentication information. The shape looked like one option, but it covered distinct questions. Which procedure was being used? How would an old message be recognized? Which secret and message authenticator tied the packet to a peer?

RFC 3118 distinguished a simple configuration token from delayed authentication. The token mode could offer weak entity authentication, but no message authentication; the RFC described it as rudimentary protection against a DHCP server started by mistake. The stronger delayed procedure used HMAC-MD5 and a shared secret. The article reports that historical choice, not a recommendation for new designs.

Authentication began before discovery

In delayed authentication, the client asked for authentication in DHCPDISCOVER. A server selected a secret and returned authentication information in DHCPOFFER. The client chose an offer and sent DHCPREQUEST using the corresponding secret; a subsequent authenticated acknowledgment had to validate. Replay detection accompanied the exchange, so a valid authenticator could not simply be copied from an earlier packet and treated as new.

That sequence required a relationship before the first packet. RFC 3118 says the client should receive its key through an out-of-band mechanism. The server had to know, or securely obtain, keys for authorized clients. If a single secret were shared broadly, anyone who obtained it could impersonate another holder; where individual client identity mattered, the RFC called for unique keys. Thus the on-wire exchange depended on a provisioning system that DHCP itself did not define.

The boundary was deliberate. RFC 3118 says delayed authentication did not address roaming between administrative domains. It focused on intradomain use, where exchanging a secret separately was feasible, and warned that the approach might scale poorly when clients connected to multiple domains. A MAC could confirm that a message matched a configured key; it could not manufacture a global identity, a roaming agreement or a right to use any network.

Relays and local acceptance remained part of the trust model

DHCP relays may change giaddr and hops, and can append relay-agent information. RFC 3118 specified how these fields were treated in the message-authentication calculation so legitimate relay processing would not invalidate the check. That preserved a defined path through intermediaries; it did not turn every relay into a trusted identity authority.

Most revealingly, the client was not forced into one universal outcome when authentication was absent. If no offer carried valid authentication, local client policy could permit an unauthenticated offer. The RFC required clients to be configurable to decline such messages and said they should default to declining them. If a client accepted one, the RFC advised informing the user and logging the event. Security therefore lived partly in the policy that chose whether to fall back, not only in the option's MAC.

This matters because a visible authentication option can be mistaken for a guarantee that every accepted configuration was authenticated. RFC 3118 warned against that inference. It specified a mechanism and a cautious default, while leaving administrators and client implementations responsible for their local trust choice.

The historical record does not show how widely option 90 was implemented or configured, nor does it document measured attack reduction. A standard defines possible behavior; deployment and outcome require separate evidence. RFC 3118's lasting design point is narrower: DHCP authentication remained a local trust arrangement, bounded by who provisioned the secret, which relays and servers were in scope, and whether the client accepted the unsigned alternative.

Sources

  1. https://www.rfc-editor.org/rfc/rfc3118.html
  2. https://www.rfc-editor.org/info/rfc3118
  3. https://datatracker.ietf.org/doc/rfc3118/
  4. https://www.rfc-editor.org/rfc/rfc2131.html
  5. https://www.rfc-editor.org/rfc/rfc2132.html
  6. https://www.rfc-editor.org/rfc/rfc3046.html
  7. https://www.rfc-editor.org/rfc/rfc2104.html
  8. https://www.rfc-editor.org/rfc/rfc1321.html
  9. https://www.rfc-editor.org/rfc/rfc2119.html
  10. https://www.rfc-editor.org/rfc/rfc951.html
  11. https://www.rfc-editor.org/rfc/rfc4361.html
  12. https://www.rfc-editor.org/rfc/rfc6842.html
  13. https://www.rfc-editor.org/rfc/rfc8415.html
  14. https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml