skip to content

After a RADIUS Access-Challenge carrying a State attribute, what exactly does the access device send back?

level: middleimportance: must knowfreq 50%

answer

  1. not a retransmission
  2. the server remembered nothing
  3. something travels out and comes back
  4. a fresh Identifier each round
  5. State (24) echoed unchanged

basics

~20 s

A brand-new Access-Request, not a retransmission: a new Identifier, a new Request Authenticator, the extra input the user supplied, and the State (24) value from the challenge echoed back unchanged so the server can rejoin the conversation.

solid answer

~40 s

The device sends a **fresh** `Access-Request` — a new packet with a **new Identifier** and a new Request Authenticator — carrying whatever the user supplied in answer to the challenge, plus the `State` (24) attribute copied back **unchanged** from the `Access-Challenge`. That echo is the whole mechanism: RADIUS keeps no connection and each packet is judged on its own, so `State` is the only thing tying round two to round one. The value is opaque to the device, which must not parse or alter it. The server may then accept, reject, or challenge again, each round costing another request/reply pair with a new Identifier. If the device drops `State`, the server sees an unrelated first attempt.

code

pseudocode · 14 lines
pseudocode
Access-Request    Identifier = 17
    User-Name = deck-crew-04
    <credential attributes>

Access-Challenge  Identifier = 17            # answers request 17
    Reply-Message = Enter the code from your token
    State         = 0x4F3A...B1              # opaque to the device

Access-Request    Identifier = 18            # NEW request, NEW Identifier
    User-Name = deck-crew-04
    State     = 0x4F3A...B1                  # echoed back unchanged
    <the code the user typed>

Access-Accept     Identifier = 18

go deeper

for a junior

Remember that a challenge is answered with another Access-Request, and that something the server sent — the State attribute — has to be sent straight back with it.

for a middle

Explain the mechanics: new Identifier, new Request Authenticator, State echoed unchanged. Say why, in one line — RADIUS keeps no connection, so State is the only thread between the two packets.

for a senior

Diagnose the failures: a dropped or edited State that produces a second-step rejection, a reused Identifier that loops, an expired State on a slow link, and a device with no challenge support turning challenges into plain login failures.

for a principal

The trade-off is round trips. Every challenge round is another request and reply across whatever link the device sits behind, so a method's number of rounds, not its cryptography, decides whether it is usable on a high-latency estate.

## Why a second round is needed at all An `Access-Request` is a single packet containing what the device already had when the user arrived. If the server needs something the device has not yet asked for — a one-time code, the answer to a prompt, the next step of a multi-step method — it has no way to obtain it inside that one exchange. **`Access-Challenge` (Code 11)** is the protocol's answer: a reply that is not a verdict, but a request for more input. It is the only multi-step shape RADIUS has. ## What the challenge carries A server's `Access-Challenge` typically carries two things: - **`Reply-Message` (18)** — text for the device to display, which is how the user learns what is being asked for. - **`State` (24)** — an opaque value of the server's own choosing. It is not meaningful to the device; it may be an index into a table, or a sealed blob the server can reopen. Its only contract is that it comes back. ## What the device must send back 1. A **new `Access-Request`** — a new packet on the same port, not a retransmission of the first one. 2. A **new Identifier**, because this is a new request and not a repeat. Reusing the old Identifier invites the server's duplicate-detection logic to answer from its cache instead of processing the new input. 3. A **new Request Authenticator**, which is what makes the packet a fresh request rather than a copy. 4. The **`State` attribute echoed back unchanged**, if one was present in the challenge. RFC 2865 requires this, and the device must not edit, truncate or regenerate it. 5. The **extra input** the user supplied in response to the prompt. The server answers that request with `Access-Accept`, `Access-Reject`, or another `Access-Challenge`. The specification sets no limit on how many rounds may occur; servers bound it themselves, usually by expiring the `State` value after a short interval. ## Why State exists: there is no connection RADIUS runs over UDP and holds no connection between packets. The device may even send round two from a different point in time, after the user has typed something, and a server behind a load-sharing arrangement may not be the same process that issued the challenge. Nothing about the second `Access-Request` looks special: same username, same device, new Identifier. `State` is therefore the only link between the two halves of the conversation. Everything about continuity — which challenge this answers, what was already proved, how many attempts remain — hangs off that single echoed value. | Field on round two | Same as round one? | Why | |---|---|---| | `Identifier` | **No** — new value | It is a new request, not a retransmission | | Request Authenticator | **No** — new value | A repeat of both would make it a duplicate | | `State` (24) | **Yes** — echoed unchanged | The server's only handle on the conversation | | `User-Name` (1) | Normally yes | The subject of the attempt has not changed | ## Where this goes wrong in practice - **The device omits `State`.** The server receives what looks like a brand-new attempt containing only a one-time code and no first factor, and refuses it. The user sees a rejection with no clue that the two packets were meant to be one conversation. - **The device reuses the Identifier.** The server may treat the packet as a duplicate of round one and resend the challenge, producing a login that loops. - **The device modifies `State`.** Any normalisation, re-encoding or truncation of an opaque value breaks the server's lookup, with the same symptom as dropping it. - **The device cannot challenge at all.** A network access server that does not implement challenge/response is required to treat `Access-Challenge` as `Access-Reject`. Nothing is broken on the wire and nothing is logged as an error; logins simply fail whenever the server decides to ask a second question. - **The challenge is answered too late.** Servers expire `State` values; a user who takes several minutes to read a code may return after the server has forgotten the conversation. ## What to say in an interview The compact answer is: *a new `Access-Request` with a new Identifier, carrying `State` back unchanged*. The sentence that shows understanding rather than recall is the reason — RADIUS remembers nothing between packets, so the conversation exists only because the device carries the server's own handle back to it.

  • What happens if the device answers the challenge but omits the State attribute?
    The server has nothing tying the packet to the challenge it issued, so it processes an unrelated new attempt — typically one carrying a one-time code and no first factor — and refuses it. The symptom is a login that fails at the second step with no error visible on either side.
  • May the access device inspect or shorten the State value?
    No. `State` is opaque: the device stores the octets it received and returns them unchanged. A server may pack a lookup key, a sealed conversation record or a nonce into it, so any re-encoding or truncation breaks the server's lookup exactly as dropping the attribute would.
  • How many challenge rounds may an exchange take?
    The protocol sets no limit; each round is another `Access-Request`/`Access-Challenge` pair with a new Identifier. In practice servers bound it by expiring the `State` value after a short interval, and each round costs a full round trip across the network — which is what makes challenge-heavy methods painful on a slow link.

State is the numbered slip a counter clerk hands you when they cannot finish your case on the spot. The next window continues your case because you hand the slip back, not because anyone remembered your face.

saying these in an interview costs you the question

  • Resends the original Access-Request with the same Identifier.
  • Thinks the server remembers the conversation without State.
  • Treats an Access-Challenge as a transient failure to retry later.
  • Says the device may parse or shorten the State value.
  • Believes the answering request reuses the first Request Authenticator.