Tunnel Extensible Authentication Protocol (TEAP) Version 1
obsoleted by
- rfc-9930 — Tunnel Extensible Authentication Protocol (TEAP) Version 1
updated by
- rfc-9427 — TLS-Based Extensible Authentication Protocol (EAP) Types for Use with TLS 1.3
Extracted elements (31)
Outer TLVs are restricted to the first two TEAP messages (before the TLS tunnel is established) so they can assist tunnel establishment without exposing unprotected data thereafter. All subsequent TLV exchanges occur as Inner TLVs within the protected tunnel.
Server Unauthenticated Provisioning Mode was designed to bootstrap peers that cannot authenticate the TEAP server during Phase 1 (e.g., no trusted root certificate). The Crypto-Binding TLV exchange at Phase 2 completion still guards against man-in-the-middle because the inner method must provide mutual authentication and key derivation.
TEAP is based on EAP-FAST (RFC 4851) with minor changes to satisfy the RFC 6678 requirements for a standards-track tunnel-based EAP method. EAP-FAST was selected because it had already been widely adopted across devices and platforms, giving TEAP a proven deployment base.
EAP implementations compliant with this specification MUST support TLV exchanges and correct mandatory/optional TLV processing. A NAK TLV MUST NOT be sent in response to a message containing a Result TLV; instead, a failure Result TLV accompanied by an Error TLV of Unexpected TLVs Exchanged should be used.
A TEAP implementation MUST provide its own support for fragmentation and reassembly of TLS messages. A TEAP server implementing TLS conversation restart capability SHOULD impose a limit on the number of restarts to protect against denial-of-service attacks.
Anonymous ciphersuites are REQUIRED only when the inner authentication method provides mutual authentication, key generation, and resistance to man-in-the-middle and dictionary attacks. TLS renegotiation indications defined in RFC 5746 MUST be supported.
Implementations of TEAP version 1 MUST use a Version field set to 1. Because the TEAP version is not protected by TLS and can be modified in transit, peers MUST exchange the version number received during negotiation using the Crypto-Binding TLV, and the receiver MUST verify it matches the version the receiver sent.
Peers implementing TEAP MUST NOT accept a cleartext EAP Success or EAP Failure packet prior to the peer and server reaching synchronized protected result indication through the inner Result TLV exchange.
Phase 2 EAP methods used in Server Unauthenticated Provisioning Mode MUST provide mutual authentication, key generation, and resistance to dictionary attacks. Example qualifying inner methods include EAP-pwd (RFC 5931) and EAP-EKE (RFC 6124).
Phase 2 MUST NOT occur if the Phase 1 TLS handshake fails, as that would mean the tunnel was not successfully established. Phase 2 MUST always end with a Crypto-Binding TLV exchange and a protected termination exchange.
TEAP implementations MUST support the RFC 5077 TLS SessionTicket mechanism for distributing a PAC-Opaque. It is RECOMMENDED that implementations also support distributing the PAC ticket and secret key within the TEAP Phase 2 tunnel.
TEAP peers MUST authenticate the server before using peer services such as PAC provisioning, certificate provisioning, or channel binding. Peers MUST have a configuration where authentication fails if server authentication cannot be achieved.
The Crypto-Binding TLV MUST be exchanged and verified before the final Result TLV exchange regardless of whether an inner EAP method was run. When multiple EAP methods are executed in sequence, an Intermediate-Result TLV MUST accompany the Crypto-Binding TLV after each successful method.
The PAC-Key is a secret and MUST be treated accordingly; if leaked it could compromise user credentials transmitted inside a tunnel established using that PAC-Key. The PAC-Key MUST be stored securely by the peer and MUST have its confidentiality and integrity protected if provisioned by an out-of-band mechanism.
The TLS version offered by the peer and server MUST be TLS 1.2 or later. Implementations MUST support TLS_RSA_WITH_AES_128_CBC_SHA and TLS_DHE_RSA_WITH_AES_128_CBC_SHA; SHOULD support TLS_RSA_WITH_AES_256_CBC_SHA. TLS ciphersuites that do not provide confidentiality MUST NOT be used.
The use of EAP-FAST-GTC is NOT RECOMMENDED with TEAPv1 because it is not compliant with EAP-GTC (RFC 3748). Implementations should use the password authentication TLVs (Basic-Password-Auth-Req TLV and Basic-Password-Auth-Resp TLV) defined in this specification instead.
TEAP authentication occurs in two phases: Phase 1 uses TLS to establish an authenticated and protected tunnel; Phase 2 uses TLV objects within the tunnel to carry inner authentication, result indications, and channel-binding information between the EAP peer and server.
The Basic-Password-Auth-Req TLV (type 13) and Basic-Password-Auth-Resp TLV (type 14) enable password-based authentication within the TEAP tunnel as an alternative to inner EAP methods. The peer may reject the request with a NAK TLV; the server uses an Intermediate-Result TLV to signal success or failure.
The Crypto-Binding TLV (type 12) cryptographically binds inner EAP method(s) to the outer TLS tunnel, proving that both peer and server participated in tunnel establishment and the inner authentication sequence. It also verifies the TEAP type, negotiated version, and Outer TLVs exchanged before tunnel establishment.
The EAP Session-Id is constructed as: teap_type || tls-unique, where tls-unique is taken from the Phase 1 outer tunnel at the beginning of Phase 2 as defined by RFC 5929 Section 3.1.
The Error TLV (type 5, mandatory) carries error codes: 1–999 are informative, 1000–1999 are warnings, and 2000–2999 are fatal. Fatal Error TLVs MUST accompany a failure Result TLV. Error code 1031 (User account credentials incorrect) usage is NOT RECOMMENDED as it enables username enumeration by attackers.
The Protected Access Credential (PAC) consists of: PAC-Key (a minimum 48-octet pre-shared key used as the TLS master secret), PAC-Opaque (a variable-length server-interpreted ticket derived from RFC 5077 SessionTicket semantics), and optional PAC-Info (authority identity and lifetime metadata). The PAC-Opaque may be presented in the clear but must not reveal useful information to attackers.
The Result TLV (type 3, mandatory) carries acknowledged success or failure for protected termination. Status values are 1 (Success) and 2 (Failure). A failure Result TLV MUST NOT be accompanied by a NAK TLV, EAP-Payload TLV, or Crypto-Binding TLV.
RFC 7170 establishes IANA registries for: TEAP TLV types (values 1–17 defined, expert review for new assignments), PAC attribute types, PAC-Type TLV values, and TEAP error codes (ranges 1–999 informative, 1000–1999 warning, 2000–2999 fatal). EAP Type 55 is assigned to TEAP.
Server certificate validation is required: peers must validate the server certificate to a trust anchor and confirm that the entity named in the certificate is the intended server before trusting any peer services. Failure to validate the server certificate enables impersonation and PAC theft.
TEAP mitigates man-in-the-middle attacks through the Crypto-Binding TLV, which cryptographically binds the inner EAP authentication to the outer TLS tunnel. An attacker who hijacks the outer tunnel cannot produce a valid Crypto-Binding TLV without access to the inner method keying material.
The TEAP tunnel protects peer identity from disclosure during Phase 2. Implementations wishing to provide identity privacy must carefully consider what is disclosed outside the tunnel prior to Phase 2, and SHOULD support TLS renegotiation to shield the peer's identity when TLS client authentication is used.
TLS session resumption transition: if ChangeCipherSpec follows the ServerHello, the server accepted abbreviated handshake; otherwise a full handshake proceeds. If session resumption fails, the server gracefully falls back to full TLS handshake. A peer SHOULD NOT request a new PAC after an abbreviated handshake.
Version negotiation: server sends its highest supported version; if peer supports it, that version is used; if peer supports only a lower version, it proposes its highest; if the server cannot support the peer's counter-proposal, it MUST terminate with EAP Failure or negotiate a different EAP type. The agreed version is later verified via the Crypto-Binding TLV.
The general TLV format is: M bit (1=mandatory, 0=optional), R bit (reserved), TLV Type (14 bits, values 1–17 currently defined), Length (2 octets, length of Value field in octets), and variable-length Value. If a peer does not support a mandatory TLV, it MUST send a NAK TLV in response.
The TEAP Request/Response packet contains: Code (1 octet), Identifier (1 octet), Length (2 octets), Type=55 (1 octet), Flags|Ver byte (L/M/S/O/R bits plus 3-bit version), optional Message Length (4 octets, if L set), optional Outer TLV Length (4 octets, if O set), TLS Data, and Outer TLVs.