In a tunnelled EAP exchange, what does an anonymous outer identity hide, and from whom?
answer
- sent before any tunnel exists
- hides the who, not the what
- useless against whoever terminated the tunnel
- the realm still has to route
- failed sessions log as anonymous
basics
~20 sIt hides the real username from anyone listening to the air, because the outer identity is sent in clear before the TLS tunnel exists. It hides nothing from a rogue access point that terminated the tunnel itself.
solid answer
~50 sIn a tunnelled EAP method the supplicant answers the first identity request in clear, before any encryption. Sending something like `[email protected]` there keeps real usernames off the air, which matters where neighbouring radios overlap yours and a passive listener can otherwise build a staff directory from association attempts. The realm part still has to be routable, because RADIUS proxying keys on it. What it does not do is protect the credential: the inner identity and inner exchange are protected only by the tunnel, and a rogue access point that the client failed to validate *is* the tunnel endpoint, so it reads both. The operational price is correlation — RADIUS logs and controller sessions that fail at the outer stage show `anonymous`, so helpdesk triage and per-user auditing get harder, and the setting itself must be pushed to every supplicant profile.
code
text · 10 linesAP -> STA EAP-Request/Identity
STA -> AP EAP-Response/Identity: [email protected] <- in clear, any radio in range reads it
...
AP -> STA TLS handshake: server Certificate
subject: CN=radius.corp.example
issuer: CN=Corp Issuing CA
STA [client-side check: issuer in profile's trusted CAs? name in profile's server list?]
profile checks neither -> tunnel completes to whoever answered
...
STA -> AP <inner identity + inner authentication exchange, inside the tunnel>go deeper
Know that the first identity a device sends over Wi-Fi is readable by anyone nearby, and that a placeholder value keeps real usernames off the air.
Explain the split between outer and inner identity, why the realm must still route, and why the tunnel is what protects the inner exchange.
Show you have paid the troubleshooting cost: failed sessions attribute to nothing, so name the pivots you use and where the setting sits in your rollout.
Be able to say which of the two profile settings is load-bearing and which is hygiene, and resist a proposal that treats the cheap one as the control.
## Two identities, two different exposures Tunnelled EAP methods carry two identities. The **outer identity** is the answer to the first EAP identity request, sent before any tunnel exists, and it is therefore readable by any radio in range. The **inner identity** is sent inside the TLS tunnel, together with the inner authentication exchange. Configuring the outer identity as something non-identifying — commonly `[email protected]` — is what people mean by an anonymous outer identity. ## What it genuinely buys On a shared office floor or a retail high street, neighbouring radios overlap yours, and anyone with a card in monitor mode can log identity responses. Without an anonymous outer identity, that listener harvests a live staff directory: usernames, roughly when each person arrives, and which site they are at. That is reconnaissance value with no credential involved, and it is cheap to remove. The realm portion cannot be arbitrary, because RADIUS proxies route on it. If your authentication is proxied, `[email protected]` routes correctly while `anonymous` alone may not. ## What it does not buy, and this is the point of the question The inner identity and the inner authentication exchange are protected **by the tunnel and only by the tunnel**. A rogue access point in the car park announcing your SSID does not need to break the tunnel — if the client never validated the server certificate, the rogue is the endpoint that negotiated it. It decrypts by construction. The anonymous outer identity is one directory entry it fails to learn, and everything valuable arrives one message later. So the honest ordering is: server-certificate validation is the control; the anonymous outer identity is hygiene layered on top of it. A candidate who offers the anonymous outer identity as the defence against an evil twin has inverted them, and that inversion is common enough to be worth probing for. ## What holding it costs - **Correlation.** Sessions that fail before the tunnel completes carry only `anonymous` in RADIUS and controller records. A helpdesk trying to answer *which user could not get on Wi-Fi at the Leeds branch this morning* has lost the easy join, and must work from the device's MAC address, the access point, and timing instead. Accounting records for *successful* sessions normally carry the inner identity, so the loss falls on failures — which is exactly the population you are troubleshooting. - **Fleet coverage.** It is another line in a supplicant profile. Devices onboarded by hand, or by a user following a screenshot, will not have it, and you cannot read back whether they do. - **Support friction.** Some supplicants and some older platforms handle the setting inconsistently, so an estate spanning many device types will have exceptions. ## The wrong answers to be ready for *The outer identity is encrypted* — it is not; it precedes the tunnel. *It protects the password* — it does not; the tunnel does, and against a rogue endpoint the tunnel protects nothing. *It can be any string* — the realm has to route. *It hides the user from the RADIUS server* — the server sees the inner identity; that is how the session is authorised and logged. ## What it means for the deliverable On this estate — one corporate SSID replicated across branches and a shared multi-tenant floor — the written statement handed to the fleet owner should say plainly: enabling an anonymous outer identity removes passive username harvesting from the air. It does not stop a device that never checks who answered from handing its inner exchange to whoever answered. The two settings sit in the same profile, they are pushed by the same mechanism, and only one of them is load-bearing.
- If the outer identity is anonymous, how does the RADIUS server know which user to authorise?It authorises on the inner identity, which arrives inside the tunnel once the tunnel is up. The outer value is used only to route the request — a proxy needs the realm to pick the right server. Successful sessions therefore still log a real user; it is the failures before tunnel completion that carry nothing useful.
- A branch reports intermittent Wi-Fi failures and RADIUS shows only anonymous rejects. How do you triage?Pivot off what is still identifying: the client MAC in the controller and RADIUS records, the access point and radio, and the timestamps. Correlate with device inventory to name the user, and look for a common platform or a certificate anchor that recently changed. This extra hop is the standing cost of the setting, so it belongs in your runbook rather than in a debate about turning it off.
saying these in an interview costs you the question
- Says the outer identity is encrypted
- Offers it as the defence against a rogue access point
- Thinks it hides the user from the RADIUS server
- Believes any arbitrary string works as an outer identity
- Ignores that failed sessions become hard to attribute