skip to content

In RADIUS, what does a pass-through authenticator do with an EAP conversation it cannot interpret?

level: juniorimportance: must knowfreq 52%

answer

  1. the device relays, it does not decide
  2. three parties, one of them blind
  3. RFC 3748 pass-through authenticator
  4. EAP rides in EAP-Message (79) attributes
  5. Access-Accept carries EAP Success (EAP Code 3)

basics

~20 s

A pass-through authenticator copies every EAP packet between the peer and the RADIUS server inside EAP-Message (79) attributes without parsing the method, so the server terminates EAP-TLS or a tunnelled method and the access device only applies the verdict it gets back.

solid answer

~50 s

RFC 3748 calls the access device a **pass-through authenticator**: it relays EAP but never interprets the method inside it. Each EAP packet from the peer is copied, unread, into one or more `EAP-Message` (79) attributes of an `Access-Request (Code 1)`; each EAP packet the server sends back arrives in an `Access-Challenge (Code 11)` and is handed to the peer. Only the RADIUS server runs the method — it validates the certificate in EAP-TLS (EAP Type 13) or terminates a tunnelled method — and it ends the conversation with `Access-Accept (Code 2)` carrying EAP Success (EAP Code 3) or `Access-Reject (Code 3)` carrying EAP Failure (EAP Code 4). The device acts on that single verdict. The pay-off is operational: a new method is usually a change on the peer and the server, not on the fleet of access devices.

go deeper

for a junior

Remember the three parties and which one is blind: peer, pass-through authenticator, RADIUS server. The device carries EAP; the server runs the method and sends one verdict.

for a middle

Explain the encapsulation leg by leg: EAP Response into EAP-Message (79) in an Access-Request, EAP Request back in an Access-Challenge, and Success or Failure inside the final accept or reject.

for a senior

Show what the model buys in an estate: one policy point, method changes that do not touch the field, and a relayed request that a partner's server can answer. Name what the device still has to carry.

for a principal

The trade-off to weigh is centralisation against reachability: every login in the estate now depends on a hop to a server, so where those servers sit and how many of them there are becomes an availability decision, not a protocol one.

## The conversation, and the courier in the middle **EAP** — the Extensible Authentication Protocol, RFC 3748 — is a strictly lock-step conversation between two parties: the **peer**, the machine trying to get on the network, and the **authentication server**, which decides. EAP carries no credential of its own. It is a container in which a *method* runs: EAP-TLS (EAP Type 13), EAP-TTLSv0 (EAP Type 21), TEAP (EAP Type 55) and others. Each method defines its own messages, its own proofs and its own number of exchanges. Between those two parties sits the box the peer actually attached to — a wireless access device or a switch. RFC 3748 gives that role a name that is also its definition: a **pass-through authenticator**. It relays EAP packets it does not interpret. It reads the EAP header enough to move the packet along, and nothing in the method's payload means anything to it. RADIUS is what the pass-through authenticator speaks to the server, and the encapsulation is deliberately dumb. The device takes the octets of the EAP packet it received and copies them into one or more `EAP-Message` (79) attributes of a RADIUS packet. It does not summarise, translate or validate them. ## What crosses the RADIUS hop | Leg | RADIUS packet | What it carries | |---|---|---| | device → server, mid-conversation | `Access-Request (Code 1)` | the peer's EAP Response in `EAP-Message` (79), `User-Name` (1), `Message-Authenticator` (80), and the `State` (24) the server last sent | | server → device, mid-conversation | `Access-Challenge (Code 11)` | the server's next EAP Request in `EAP-Message` (79), plus a fresh `State` (24) | | server → device, success | `Access-Accept (Code 2)` | EAP Success (EAP Code 3) plus the session attributes the device is to apply | | server → device, failure | `Access-Reject (Code 3)` | EAP Failure (EAP Code 4), and no attributes to apply | The first EAP Response the device relays is normally an Identity (EAP Type 1) response, and the device also copies that identity into `User-Name` (1) so that RADIUS itself has something to route and log on. If the server proposes a method the peer will not run, the peer answers with a Nak (EAP Type 3) naming what it would accept instead — and the device forwards that refusal without knowing it was one. ## What the device does, and what it never does - It **moves octets**: EAP in, `EAP-Message` (79) out, and the reverse. - It **adds circumstances** the server cannot see: `User-Name` (1), `Calling-Station-Id` (31), `NAS-Port-Type` (61), `Framed-MTU` (12). - It **protects the hop**: `Message-Authenticator` (80) is mandatory on every EAP-bearing RADIUS packet. - It **never validates a certificate**, checks a chain, or terminates a tunnel. No method state machine runs on it. - It **never reads an inner identity or credential** inside a tunnelled method; it holds no key to that tunnel. - It **never decides**. The single RADIUS reply is the decision, and the device applies it. ## What the pass-through model buys 1. **One decision point.** Every access device in an estate asks the same server, so the policy and the credential store live in one place instead of on hundreds of boxes. 2. **Method independence.** Because the device forwards a method it does not parse, moving from one certificate-based or tunnelled method to another is usually a change on the peers and the server. The device still has to carry whatever size of EAP packet the new method produces, so the change is not always free — but it is not a per-device protocol upgrade. 3. **Federation for free.** A forwarding server between the device and the home server relays the same `Access-Request` onward, which is how a visiting peer's login can be answered by an organisation that owns none of the hardware in the room. ## Where the model stops Two limits are worth naming. First, **the path is not blind to everything**: the outer EAP Identity response and `User-Name` (1) are readable by every forwarding server on the way, which is exactly what makes realm-based routing work, while the inner exchange of a tunnelled method is readable only by the server that terminates it. Second, **the pass-through device is still a party to the result**. When a method derives keying material — a Master Session Key (MSK) — that material has to reach the access device so the link can be protected; what the link then does with it is the wireless specifications' business, not RADIUS's. The device's blindness is about the *method*, not about the outcome.

  • What can a RADIUS forwarding server in the middle of the path read from an EAP conversation it relays?
    Whatever is outside the tunnel: `User-Name` (1), the other attributes, and the outer EAP Identity (EAP Type 1) response. That is what it routes on — typically the realm suffix of the Network Access Identifier — and what it can log. An inner identity or credential inside a tunnelled method is closed to it, because only the server that terminates the method holds the tunnel's keys.
  • Why does introducing a new EAP method usually not change the access device?
    Because the device only copies EAP packets into `EAP-Message` (79) and back; the method's type byte means nothing to it, so there is no per-method code to update. It is not entirely free: a method with larger messages needs the device to carry larger EAP packets, which is what `Framed-MTU` (12) tells the server about.
  • Which RADIUS packet ends an EAP conversation, and what does it carry?
    `Access-Accept (Code 2)` with an `EAP-Message` (79) holding EAP Success (EAP Code 3), or `Access-Reject (Code 3)` with EAP Failure (EAP Code 4). The accept also carries the session attributes the device applies, and any keying material the method derived, so the device can protect the link it just authorised.

A courier who carries a sealed envelope between two people and is told only 'delivered' or 'refused' at the end: the contents were never the courier's to read, and a change of language inside the envelope does not retrain the courier.

saying these in an interview costs you the question

  • Thinks the access device validates the peer's certificate chain.
  • Says RADIUS itself defines the EAP-TLS handshake.
  • Calls the user's laptop or vehicle the RADIUS client.
  • Assumes every access device needs code for each EAP method.
  • Believes the access device can read the inner identity in a tunnel.