Summary

  • Classic RADIUS never made its one-octet Identifier a globally unique transaction name. A client matched it to a pending request, then verified a Response Authenticator calculated with that request's 16-octet Request Authenticator and the hop's shared secret.
  • An unchanged retry to the same server preserved Identifier, Request Authenticator and source port. RFC 5080 required the server to recognize that duplicate and replay its cached response without repeating the authentication; changed Attributes instead began a new request.

A namespace that wraps before the queue is forgotten

The RADIUS packet header looks almost too small for its job. After the Code comes an Identifier of eight bits. At most 256 values exist, yet a network access server may handle many concurrent logins, retry lost datagrams, consult alternate servers and conduct several rounds of challenge and response.

The standards did not solve this by pretending the counter would never wrap. They gave the byte a local and temporary meaning. RFC 2865 says the Identifier helps match requests and replies. A client must not reuse an Identifier for the same source address and UDP port while the earlier request remains pending. RFC 5080 recommends least-recently-used allocation, spreading reuse as far apart as the little namespace allows.

This is the first boundary. Identifier 37 is not “authentication transaction 37” for the world, or even for one machine forever. It means the currently pending use of 37 in a particular exchange context. Once a valid response arrives or the request times out, the number may return with a different meaning.

That economy was present from the first RADIUS RFC, RFC 2058, in January 1997, through its April replacement, RFC 2138, and the June 2000 revision that became RFC 2865. The small identifier was never the whole design.

Sixteen unpredictable octets completed the question

An Access-Request contains a 16-octet Request Authenticator. RFC 2865 requires it to change whenever a new Identifier is used and says it should be unpredictable and unique over the lifetime of the shared secret. Those properties do more than add capacity. If a request value repeats with the same secret, a captured response may become useful again; if a future value is predictable, an attacker may prepare a false answer before the genuine exchange occurs.

The response copies the one-byte Identifier, but it does not merely echo the 16 bytes. For Access-Accept, Access-Reject and Access-Challenge, the server calculates a Response Authenticator over the response Code, Identifier, Length and Attributes, the original request's Request Authenticator, and the secret shared with the client.

On reception, the client first uses the Identifier to find a candidate pending Access-Request. It then verifies the Response Authenticator against that exact request. A late packet bearing the right eight bits but derived from an earlier Request Authenticator will fail. It is silently discarded.

The division of labour is elegant. The cheap field narrows a lookup. The larger unpredictable value binds the answer to a particular question. The shared secret supplies hop authentication. Pending state supplies time. None of the pieces alone bears the whole meaning.

The same request had to remain recognizably the same

RADIUS used UDP because its access decision had an unusual deadline. A user could tolerate seconds, but a transport that finally delivered old data minutes later would not be useful. The client therefore retained a copy above the transport layer, ran its own timer and could retry or select an alternate server.

That freedom created a semantic choice. Is the next datagram another delivery attempt for the same decision, or a changed request that deserves a new decision?

RFC 2865 drew a hard line. When a network access server retransmits unchanged Attributes to the same server, it must keep the Request Authenticator, Identifier and source port. Alter any of those, and the server may no longer recognize continuity. Change any Attribute, and the client must use a new Request Authenticator and Identifier.

An unchanged retransmission is therefore not a second login attempt merely because it is a second packet. It is the same request seeking delivery again. Conversely, adding a timestamp, replacing a password response or modifying requested service is not “the same packet with fresher detail.” It is a new question, even if the username and human intention appear unchanged.

A duplicate response was safer than a duplicate decision

Early specifications suggested duplicate detection, but field experience exposed the consequence of ambiguity. RFC 5080 made the server behavior explicit. A RADIUS server must detect duplicate Access-Requests and cache the Access-Accept, Access-Reject or Access-Challenge it produced.

If the duplicate arrives after the server has answered, the server resends the original response without processing the request again. If it arrives while the original is still being processed, the duplicate is silently discarded. The server does not launch a parallel authentication and does not invent an interim verdict.

The distinction is operationally important. A backend may increment counters, record a login, consume a one-time value or trigger expensive work. Reprocessing the same request can create two effects from one attempt. Replaying a cached response repairs probable packet loss while preserving one decision.

RFC 5080 gives the cache a compound key: source address, source port, RADIUS Identifier, receiving socket and Request Authenticator. Entries normally live only five to thirty seconds. A request matching the first four elements but carrying a different Request Authenticator invalidates the old cache entry. The visible Identifier did not acquire authority merely because other coordinates happened to line up.

Changed content revoked the standing of an earlier answer

Suppose the client sends a request, waits, then changes an Attribute and sends again. The first server may still be computing. Its later response might be perfectly authentic for the earlier packet. It is nevertheless no longer the response to the current request.

The client must discard responses to the old attempt and treat the response to the current request as definitive, even if the two servers or two moments disagree. Cryptographic validity is necessary but not sufficient; the question must still be pending.

Access-Challenge shows the same rule across a longer conversation. A valid Challenge may carry State and ask for another user response. The network access server then sends a new Access-Request with a new Identifier and Request Authenticator, echoes State as required, and includes the new answer. State connects rounds of a session. It does not collapse the rounds into one transaction.

This separation prevents a subtle category error. “Same user” is an application-level judgment. “Same RADIUS request” is a wire-level identity with exact Attributes and exact transaction material. The protocol cannot safely substitute one for the other.

The first valid response ended the pending claim

Retries and alternate servers can produce more than one response. RFC 5080 says the client processes the first response whose Response Authenticator is valid for the pending request. Later responses are treated as unsolicited and silently discarded because there is no longer a pending request for them to answer.

This does not guarantee that every server would choose the same policy. A primary might Reject while an alternate would Accept. Keeping user stores, configuration and policy coherent remains an operator responsibility. The transaction rule only prevents a late packet from reopening a decision already completed at the client.

Nor does Access-Accept command the impossible. RFC 2865 says that if the returned service cannot be provided, the network access server treats the result as a rejection. A valid response authenticates a packet and binds it to a request; it cannot manufacture a modem mode, VLAN, route or other capability the receiving system does not have.

A proxy terminated and recreated the proof

RADIUS often crosses proxies. The hop-local character of the Response Authenticator becomes unmistakable there. A forwarding server verifies the remote server's response with their secret, removes the Proxy-State it added, restores the Identifier expected by the earlier client, and calculates a new Response Authenticator with the secret for that earlier hop.

The network access server therefore does not possess one end-to-end signature from a home server. It possesses proof from the peer with which it shares a secret. Proxy-State helps the response retrace the chain and is opaque to systems that did not create it, but it is not access authority.

An audit record that stores only Identifier=37, Accept destroys the evidence needed to interpret the event. Useful records need the hop, client address and port, receiving socket, pending interval, a protected fingerprint of the Request Authenticator, proxy context, duplicate-cache action and the local service effect. Secrets and credential-bearing Attributes must stay out of ordinary logs.

Retries could synchronize into their own denial of service

The retry mechanism also created a collective risk. RFC 5080 describes clients using fixed timeouts of a second or less without congestive backoff. After a power failure, thousands of access devices can wake together, send together and retry together, overwhelming the authentication service just as users return.

Its recommended timer grows with each retransmission, includes jitter, and observes maximum delay, attempt and duration limits. That randomness is for desynchronization; it need not be cryptographically strong. Request Authenticator unpredictability serves a different purpose and must be generated to a security standard. Calling both values “random” does not make them interchangeable.

Overload policy can also favor conversations already under way. A server may prioritize requests carrying valid State, and a proxy may process home-server answers before accepting more new requests. This protects completion and reduces retry pressure. It does not give the affected user a greater entitlement to access.

TLS eventually moved the boundary, not the history

RFC 6614 put RADIUS inside TLS over TCP in 2012, but retained the historic packet-level MD5 machinery and used the fixed secret radsec for those calculations. The transport protected the connection while the old header rules continued inside it.

RFC 9765 revisited that compromise in 2025. When two peers negotiate RADIUS/1.1 with ALPN over TLS 1.3 or later, the shared-secret and MD5 packet mechanisms disappear. The former Authenticator space becomes a 16-octet opaque Token; the Token takes over request/reply correlation, and the old Identifier byte becomes reserved.

That change is the boundary to a different history already covered by BTW. It does not rewrite ordinary RADIUS/UDP, nor does one upgraded hop transform every hop in a proxy chain. Its relevance here is narrower: even after transport owns authenticity and confidentiality, request correlation still needs a sufficiently large, context-bound transaction value.

What the packet could never prove

Classic Response Authenticator is historical mechanism, not modern cryptographic advice. It does not make MD5 safe today. It does not identify the human independently of PAP, CHAP, EAP or another method carried in Attributes. It does not prove that server policy was wise, that accounting committed, that a proxy told the truth, or that service traffic flowed after acceptance.

The RFC record establishes the design and its corrections, not current deployment share or product conformance. Its durable lesson is about evidence granularity. A short name can be safe when its scope, lifetime and corroborating context are explicit. It becomes dangerous when a dashboard preserves the name and discards everything that made the name meaningful.