Tunnel Extensible Authentication Protocol (TEAP) Version 1
obsoletes
- rfc-7170 — Tunnel Extensible Authentication Protocol (TEAP) Version 1
updates
- rfc-9427 — TLS-Based Extensible Authentication Protocol (EAP) Types for Use with TLS 1.3
Extracted elements (32)
The Protected Access Credential (PAC) defined in RFC 7170 (mirroring EAP-FAST) was deprecated in RFC 9930. Implementation experience determined the PAC was unnecessary; TEAP now uses TLS NewSessionTicket-based session resumption as defined in RFC 9190, simplifying the protocol and removing a complex state-management mechanism.
TLS-PSK is NOT RECOMMENDED for use with TEAP because TEAP was not designed to work with TLS-PSK and no use cases, security analyses, or implementations exist. Its behavior with TEAP is entirely implementation-dependent and therefore not useful to deploy.
Implementations SHOULD limit permitted inner EAP methods to EAP-TLS and EAP-FAST-MSCHAPv2, which are the most commonly supported and known-interoperable inner methods. Other EAP methods (EAP-pwd, EAP-SIM, EAP-AKA) may work but are untested; tunneled EAP methods MUST NOT be used.
Multiple implementations of RFC 7170 interpreted the cryptographic-binding text differently. These implementations are interoperable only for a subset of RFC 7170 functionality. RFC 9930 both corrects the specification and documents in Section 5 which subset of TEAPv1 is currently interoperable across implementations.
All TEAP implementations MUST support session resumption. If the server agrees to resume, Phase 2 is bypassed; if not, the server rejects resumption and both parties MUST proceed with Phase 2 after the full TLS handshake.
If using EAP-MSCHAPv2 as an inner EAP method, the EAP-FAST-MSCHAPv2 variant defined in RFC 5422, Section 3.2.3 MUST be used instead of the standard MSCHAPv2 derivation. The first and second 16-octet halves of the MSK are swapped when used as IMSKs for TEAP.
Implementations MUST NOT permit resumption for inner EAP methods such as EAP-TLS. If resumption is needed, the peer should rely on the outer TLS session. This restriction also applies to all TLS-based EAP methods that tunnel other EAP methods, and updates RFC 9427.
Peers implementing TEAP MUST NOT accept a cleartext EAP Success or Failure packet prior to the peer and server reaching synchronized protected result indication. The received cleartext EAP Success or Failure MUST match the status conveyed in the protected Result TLV.
Phase 2 MUST NOT occur if the Phase 1 TLS handshake fails, as an unestablished tunnel would compromise security. A successful TEAP Phase 2 conversation MUST always end with a Crypto-Binding TLV and Result TLV exchange.
Server certificates MUST include a subjectAltName extension with the dnsName attribute containing a Fully Qualified Domain Name (FQDN) string. Use of SubjectDN CN= for the FQDN is deprecated for TEAP and forbidden by RFC 9525, Section 2.
Servers MUST track the username across multiple password authentication rounds and reject authentication if the identity changes between Basic-Password-Auth-Resp TLVs. In subsequent rounds, the peer MUST NOT be prompted for a username and MUST copy the username from the first response.
TEAP implementations MUST NOT permit TLS restarts. Fatal TLS errors cause the TLS conversation to fail; non-fatal TLS errors can be ignored. When the TEAP server detects a TLS error, it SHOULD send a TLS alert; the peer MUST send a response and the server MUST terminate with EAP Failure.
The Crypto-Binding TLV MUST be validated before any Intermediate-Result TLV or Result TLV is examined. If validation fails for any reason, it is a fatal error handled as described in Section 3.9.3.
The EAP peer MUST validate the server certificate in most cases per RFC 9190 Section 5.3. Where the peer has an NAI, it MUST use the realm to perform DNS-ID validation per RFC 9525, Section 6. Implementations MUST support matching the realm against a SubjectAltName dnsName in the server certificate.
The TLS version offered by the peer and server MUST be TLS version 1.2 or later. TEAP implementations MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suites, and MUST implement recommended cipher suites per RFC 9325 (TLS 1.2) and RFC 8446 (TLS 1.3).
To detect bid-down attacks on TEAP version negotiation (which is not TLS-protected), peers MUST exchange the TEAP version number received during negotiation using the Crypto-Binding TLV. The receiver MUST verify that the version in the Crypto-Binding TLV matches the version the receiver sent during negotiation.
Tunneled EAP methods such as PEAP, EAP-TTLS, and EAP-FAST MUST NOT be used for inner EAP authentication. TEAP implementations MUST NOT permit inner EAP methods that fail to perform crypto-binding of the Inner Method to the TLS session.
When TLS 1.3 is used, the cryptographic derivations defined in RFC 9427 MUST be used instead of those given in this document. The derivations in RFC 9930 are only applicable for TLS 1.2.
Outer TLVs are optional TLVs outside the TLS tunnel, permitted only in the first two TEAP messages (first server-to-peer and first peer-to-server). Inner TLVs are sent exclusively within the TLS tunnel during Phase 2; no Outer TLVs are used in Phase 2.
TEAP authenticates in two phases after the initial EAP Identity exchange. Phase 1 uses TLS to establish an authenticated tunnel; Phase 2 performs tunneled authentication using TLV objects for inner methods, result indication, and channel binding. All inner data is encapsulated in TLV objects inside the TLS record.
The Crypto-Binding TLV proves that both peer and server participated in tunnel establishment and the full sequence of authentications; it also verifies the TEAP type, version negotiated, and Outer TLVs exchanged before tunnel establishment. It MUST be exchanged after each successful inner authentication and before the final Result TLV.
The Error TLV (type 5) allows peers to indicate errors. Error codes 1–999 are informative, 1000–1999 are warnings, and 2000–2999 are fatal. A fatal Error TLV MUST be accompanied by a Result TLV indicating failure, and the conversation is terminated per Section 3.9.3.
The Identity-Type TLV (type 2, mandatory, length 2) allows the server to hint which identity type to use. The Identity-Type field is 2 octets with values 1=User and 2=Machine. A server receiving a mismatched Identity-Type MUST fail unless the returned type is server-policy-permitted and was not already used for a successful authentication.
The NAK TLV (type 4, mandatory) signals that a received TLV type is unsupported. It contains Vendor-Id (4 octets), NAK-Type (2 octets identifying the unsupported TLV), and optional TLVs. A NAK TLV MUST NOT be sent in response to a message containing a Result TLV.
The Result TLV (type 3, mandatory, length 2) provides acknowledged success/failure messages for protected termination. The 2-octet Status field has values 1=Success and 2=Failure. A Result TLV indicating success MUST be accompanied by a Crypto-Binding TLV; one indicating failure MUST NOT be accompanied by NAK, EAP-Payload, or Crypto-Binding TLVs.
IANA maintains the TEAP Error TLV Error Codes registry (Section 7.2), the TLS Exporter Labels registry (Section 7.3), EMSK Parameters (Section 7.4), and an update to the EAP registry (Section 7.5). Error codes 1–999 are informative, 1000–1999 are warnings, and 2000–2999 are fatal.
IANA maintains the TEAP TLV Types registry (Section 7.1) with values 1–19 initially assigned: Authority-ID (1), Identity-Type (2), Result (3), NAK (4), Error (5), Channel-Binding (6), Vendor-Specific (7), Request-Action (8), EAP-Payload (9), Intermediate-Result (10), PAC (11, DEPRECATED), Crypto-Binding (12), Basic-Password-Auth-Req (13), Basic-Password-Auth-Resp (14), PKCS#7 (15), PKCS#10 (16), Trusted-Server-Root (17), CSR-Attributes (18), Identity-Hint (19).
TEAP provides mutual authentication and integrity protection via a TLS-protected tunnel. The Crypto-Binding TLV cryptographically binds inner authentication methods to the outer TLS tunnel, preventing on-path attacks that could otherwise substitute or replay inner method exchanges.
When a Phase 1 server and Phase 2 (Inner Method) server are separate entities, the Phase 1 server acts as an on-path attacker relative to the inner authentication. Deployments MUST ensure the Phase 2 server can trust the Phase 1 server, and implementations SHOULD be aware that separating these roles creates additional trust assumptions.
When no Inner Method provides an EMSK, the Crypto-Binding TLV offers little protection because it cannot tie the inner EMSK to the TLS session via the TLS-PRF. The TEAP session is then vulnerable to on-path active attacks; implementations SHOULD adopt mitigations from RFC 7029, Section 3.2, and implement the Inner Method ordering of Section 6.1.
The general TLV format is: M bit (1=mandatory, 0=optional), R bit (reserved, 0), TLV Type (14-bit field, values 0–19 assigned), Length (2 octets, length of Value field in octets), and Value. If a peer or server receives a TLV with an unknown mandatory type, it MUST send a NAK TLV and ignore all other TLVs in that message.
The TEAP Request/Response packet format is: Code (1 octet, 1=Request/2=Response), Identifier (1 octet), Length (2 octets), Type (1 octet, value 55), Flags (5 bits: L M S O R) and Ver (3 bits, value 1), optional Message Length (4 octets, present if L bit set), optional Outer TLV Length (4 octets, if O bit set), TLS Data, and Outer TLVs.