TEAP
acronymStands for: Tunnel Extensible Authentication Protocol (RFC 7170, EAP Type 55)
The Tunnel Extensible Authentication Protocol of RFC 7170, EAP Type 55: the standards-track tunnel method that runs zero or more inner EAP methods inside a mutually authenticated TLS tunnel, binds them cryptographically to it, and can provision credentials along the way.
RFC 7170 (Zhou, Cam-Winget and Salowey of Cisco and Hanna of Infineon, May 2014, Standards Track) defines TEAP version 1 as "a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel". Inside the tunnel, type-length-value objects carry "zero or more EAP methods", which is the feature the market calls EAP chaining: a machine certificate and a user credential can be authenticated in one conversation, so a policy can distinguish a corporate laptop with a logged-in employee from either alone. The tunnel can also provision a Protected Access Credential or a certificate to the peer, and it can carry a password. Two protections are built in rather than optional: a Crypto-Binding TLV that ties each inner method's result to the outer tunnel, defeating the tunnel man-in-the-middle, and EAP channel binding, which lets the peer and server confirm they agree about the network they are on. TEAP is the IETF's successor to PEAP, EAP-TTLS and EAP-FAST, and the RFC records that EAP-FAST was the basis the working group started from.
By 2014 the IETF had three tunnelled EAP methods in wide use, two of them never published as standards, and a list of things all three lacked. RFC 7170, published in May 2014 by Zhou, Cam-Winget and Salowey of Cisco and Hanna of Infineon as a Standards Track document, is the result of the EMU working group's effort to replace them with one. It defines TEAP version 1 at EAP Type 55 as "a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel". The RFC itself names its ancestry: EAP-FAST "has been widely adopted" and was "adopted by the EMU working group as the basis for the standard tunnel-based EAP method". Readers of the EAP-FAST entry will recognise the shape, a TLS tunnel followed by TLVs.
What happens inside the tunnel is where TEAP goes further than its predecessors. The RFC allows "zero or more EAP methods within the protected tunnel", run in sequence, each with its own result. That sequence is what vendors sell as EAP chaining: a device can prove it is a managed machine, with a certificate, and then the user can prove who they are, with a password or a second certificate, in a single 802.1X conversation, and the server can authorise on the combination. Before TEAP the two facts had to be established in separate authentications and correlated by inference, which is why policies that said "corporate device and known user" were so hard to write honestly.
The tunnel is also a provisioning channel. TEAP can provision a Protected Access Credential, the PAC inherited from EAP-FAST, or a certificate, inside the tunnel, so that a device which arrives with only a password can leave with a stronger credential for next time. Passwords themselves can be carried, which keeps the directory-only back end in play. And two protections that were optional or absent in the earlier methods are built in. The Crypto-Binding TLV binds the result of each inner method to the tunnel that carried it, so an attacker cannot relay an inner exchange between a victim and a server while holding the outer tunnel with each; the earlier generation's exposure to that man-in-the-middle was one of the motivations for the work. EAP channel binding lets the peer and the server check that they agree about the network the peer is attached to, which closes a class of attacks in which a rogue network relays a legitimate authentication.
Adoption has followed the usual curve for a method that needs both supplicants and servers: operating-system supplicants and the major AAA servers added it, with the chaining feature as the draw, and estates with existing PEAP or EAP-FAST deployments have moved as their clients allowed. For a designer the decision is now between EAP-TLS for devices that can hold certificates and TEAP where chaining, provisioning or a password back end is required; PEAP and EAP-TTLS remain for compatibility, and the method matrix in the 802.1X and EAP methods article sets the four side by side.
Also known as: tunnel eap, eap chaining, teap v1