Tunneled EAP for Embedded Wi-Fi: Keep Outer Identity and Inner Authentication Separate

A tunneled EAP profile contains several identities with different jobs. The outer identity helps route the authentication exchange; the server certificate identifies the tunnel endpoint; the inner identity authenticates the device or user inside that tunnel. Mixing them can produce a connection that works while exposing an unintended identity or trusting the wrong server.

This guide focuses on EAP-TTLS version 0 as described by RFC 5281 and configured in wpa_supplicant 2.11. It does not generalize every detail to PEAP, TEAP or EAP-TLS. Production behavior also depends on the compiled TLS backend, authentication server and profile manager. Certificate enrollment and rotation are outside scope; the deliverable here is a tested identity-and-method contract.

Give each identity a single purpose

TTLS permits an anonymous outer EAP identity, optionally retaining a routing realm, while the real authentication identity is exchanged inside the TLS tunnel. The initial outer identity is visible before tunnel protection. RFC 5281 also warns that allowing other methods can undermine identity privacy if those methods disclose the real identity. Method selection therefore belongs in the privacy contract. RFC 5281, sections 7.3 and 14

Field or decision	Intended role	Qualification question
Outer anonymous identity	Routing without revealing the inner account	Does the visible exchange contain only the approved value and realm?
Trusted CA and server-name constraint	Authenticate the tunnel server	Are unrelated and wrongly named servers rejected?
Inner identity and credential	Authenticate the intended principal	Does the server evaluate the expected account inside the tunnel?
Outer and inner method choice	Bound the permitted protocol exchange	Does an unsupported or disallowed method fail clearly?
Authorization result	Grant the intended network access	Is the applied role tied to the intended authenticated principal?

A pseudonymous outer value is still potentially linkable. If privacy matters, document what the visible realm reveals and whether the value changes between deployments. Do not replace a usable routing realm with an arbitrary string without agreement from the authentication-network operator.

Map the contract to the exact supplicant settings

In wpa_supplicant 2.11, anonymous_identity supplies the outer identity and identity supplies the method’s user identity. Pinning eap=TTLS avoids an accidentally broad list of accepted outer methods. The profile’s ca_cert or ca_path establishes trust anchors; the configuration explicitly warns that omitting both leaves server-certificate verification disabled. Do not treat an encrypted tunnel without verified server identity as sufficient credential protection. wpa_supplicant 2.11, wpa_supplicant.conf EAP parameters

Use the server-name constraint agreed with the network operator. The release documents domain_suffix_match as a domain-label-aware suffix match and domain_match as an exact domain match. A broad organizational suffix may intentionally trust more servers than one exact authentication-service name. Choose that scope explicitly; a successful certificate-chain check alone does not answer whether the server is the intended endpoint.

TTLS inner method strings are not interchangeable. For example, phase2="auth=PAP" selects a non-EAP inner authentication form, while phase2="autheap=MSCHAPV2" selects inner EAP-MSCHAPv2. Even auth=MSCHAPV2 and autheap=MSCHAPV2 represent different TTLS encodings. Match the server’s provisioned method instead of cycling through strings until one connects. The parser and method selection are visible in wpa_supplicant 2.11, src/eap_peer/eap_ttls.c.

These are field-level examples, not a complete deployable profile. Use a protected credential source and the actual server trust configuration. If a manager generates the supplicant profile, inspect its effective mapping; a settings screen called “username” may not make the outer/inner distinction obvious.

Do not copy historical TLS guidance uncritically

RFC 5281 dates from 2008 and contains historical TLS-version interoperability guidance. TLS 1.0 and 1.1 were subsequently deprecated by RFC 8996. Qualify the TLS versions and algorithms supported by the actual TTLS client/server combination against current deployment policy. Do not enable obsolete versions merely because an old TTLS example mentions them. RFC 8996

Also distinguish a full TTLS authentication from resumption. RFC 5281 permits session resumption without a new phase-two exchange. A short successful reconnect can therefore fail to exercise a changed inner credential or method. Use the supported client/server controls and method traces to establish a full-authentication case before judging those changes. RFC 5281, section 7.6

Run negative tests that identify the failed boundary

1. Baseline the intended contract. With a dedicated test account, record the visible outer value, selected outer method, server identity verification, full versus resumed exchange, inner method and resulting role. Keep credentials and decrypted authentication payloads out of the shared report.
2. Reject the wrong trust anchor. Present an authorized test server whose certificate is outside the configured trust set. Pass only if the client stops before disclosing the inner credential to that server.
3. Reject the wrong server name. Use a test certificate that chains to the trusted CA but does not satisfy the chosen name constraint. This isolates name checking from chain validation.
4. Exercise inner-account failure. With the correct trusted server and a proven full exchange, use an invalid test credential. Expect an inner-authentication failure, not a misleading certificate error or an unauthorized successful role.
5. Exercise method mismatch. Offer a disallowed outer method, then separately configure an incompatible inner method on the test server. Record each rejection at its actual stage. Do not solve either case by allowing every method.
6. Check visibility and recovery. Confirm that the approved outer identity appears before the tunnel and the real account does not unexpectedly escape through fallback. Restore the baseline and verify unattended recovery without an interactive trust-acceptance prompt.

In a hypothetical field terminal, an anonymous routing identity works, but a server-name mismatch is accepted. The privacy-looking outer value does not compensate for that trust failure. Conversely, a correctly rejected inner password does not establish that the server-name negative test was ever exercised. Keep each result in its own row.

Evidence boundary

A host fixture built official wpa_supplicant 2.11 with a no-radio driver and inert layer-two stub. Disabled TTLS profiles containing the PAP and inner-EAP strings above parsed successfully. This tests configuration acceptance only. It does not validate a certificate, negotiate TLS, authenticate an account or prove privacy on air.

Release the integration only with target traces for the positive case, both server-trust negatives, inner-account and method failures, and the resumption distinction. That bundle explains which identity was exposed, which server was trusted, which principal authenticated and which access was granted.