Discover EAP-TEAP

21/03/2022 · 10 min read · cybersecurity eap teap authentication networking nac  ·
Share on:

Translations

Overview

In this article, I introduce a network authentication protocol, namely Tunnel Extensible Authentication Protocol (TEAP), a method that allows multiple authentication mechanisms within a secure tunnel. The principle is to be able to combine authentication methods and thus increase the security level of a communication.

Introduction

TEAP is a protocol defined in 2014 as a continuation of the Extensible Authentication Protocol (EAP) protocol methods. The latter is a kind of framework allowing the definition of authentication means for communications on wired or wireless networks. We will first explain what EAP is before diving into TEAP.

EAP and its Methods

EAP is an extensible protocol that runs above the layer 2 of the OSI model to allow the implementation of authentication mechanisms between two elements: a peer and an authenticator. The peer is usually the one requesting authentication on a network, while the authenticator is the one authenticating the peer. For example, the peer could be a computer or a phone, while the authenticator would be a network access switch.
In EAP, the authenticator first optionally issues an identity request as EAP Identity-request to which the peer responds with an identity (a username, for instance) as Identity response. Then, the authenticator sends a Challenge Request to which the peer responds with a Challenge response to prove its identity. The authenticator can repeat the Challenge request multiple times. In the end, if authentication is successful, the authenticator issues an EAP Success message; otherwise, it issues an EAP Failure message.

EAP: an extensible authentication protocol

EAP is used in point-to-point connections using the Point-to-Point Protocol (PPP). It is also part of the 802.1X standard, defining authentication in Network Access Control for wired Local Area Networks (LAN) and Wireless LANs (WLAN). This is referred to as EAP over LAN (EAPoL). In 802.1X, the peer is called supplicant and an additional component supports the authenticator: the authentication server. This server is used to verify the identity of the supplicant during exchanges with the authenticator through another authentication protocol: Remote Authentication Dial-In User Service (RADIUS), handling Access-Request, Access-Challenge, Access-Accept, and Access-Reject messages.
Additionally, the supplicant sends extra messages, such as EAPOL-Start at the beginning to initiate the process, and EAPOL-Logoff at the end of network media usage to revert its access status to non-authenticated.

EAP for 802.1X

The 802.11i standard refines the specific requirements of EAP for authentication on wireless networks.

EAP is extensible, allowing many different methods to provide various means of authentication. The table below provides an overview of the main methods in use.

Method Authentication Method Session Key Generation for Encrypted Data Exchange Peer Authentication Authenticator Authentication
LEAP Uses a random number encrypted with 3 DES keys derived from an MD4 hash of the user’s password Yes Yes Yes
EAP-MD5 Uses an MD5 hash of the user’s identifier and password No Yes No
EAP-PWD Uses a password and a cryptographic suite to derive a shared secret No Yes No
EAP-PSK Uses a pre-shared key to derive subsidiary encryption keys for authentication and session key generation Yes Yes No
EAP-POTP Uses a One Time Password (OTP) for mutual authentication and session key generation Yes Yes Possible
EAP-MSCHAPv2 Uses the user’s password to calculate a hash for authenticating both the peer and the authenticator No Yes Yes
EAP-TLS Uses certificates for mutual authentication and session key generation via the TLS protocol Yes Yes Yes
EAP-TTLS Uses certificates to authenticate the authenticator and establish a TLS encrypted channel to authenticate the peer with another method (CHAP, PAP, MS-CHAP, MS-CHAPv2, EAP…) No Yes Yes
EAP-PEAP Uses certificates to authenticate the authenticator and establish a TLS encrypted channel to authenticate the peer with another EAP authentication method No Yes Yes
EAP-IKEv2 Uses asymmetric, symmetric encryption keys or a shared secret for mutual authentication Yes Yes Possible
EAP-FAST Uses a Protected Access Credential (PAC, including a shared secret) to establish a TLS encrypted channel to authenticate the peer with credentials Yes Yes Possible
EAP-SIM Uses a phone SIM card and the mobile network operator authentication center in 2G networks to derive a hash for peer authentication Yes Yes Possible
EAP-AKA Uses a phone SIM card and the mobile network operator authentication center in 3G networks to derive hashes and symmetric keys for authenticating both the peer and the authenticator No Yes Yes
EAP-AKA' A variant of EAP-AKA using a different derivation method and usable outside mobile networks Yes Yes Yes
EAP-GTC Uses cleartext tokens to authenticate the peer (to be used within a previously established tunnel with another method) No Yes No
EAP-EKE Uses a shared secret to derive a symmetric encryption key for authenticating both the peer and the authenticator No Yes Yes

We will now detail another of these methods: TEAP.

TEAP

TEAP is an additional EAP method that is quite recent, being defined in 2014 and supported by the Windows 10 operating system since 05/27/2020 and not yet supported by many other systems used by the supplicant. TEAP proceeds first with a the establishment of an authenticated and encrypted tunnel using the Transport Layer Security (TLS) protocol, followed by a second phase of authentication within this tunnel. You might wonder how this differs from other EAP methods that follow the same principle (EAP-TTLS, EAP-PEAP, EAP-FAST…). In fact, these methods are often initially proposed by vendors, and one of the main motivations of TEAP is to provide a modular standard for performing multiple tunneled EAP methods.
After the EAP Identity-Request and Identity-Response messages, the first phase begins with an EAP-Request of type TEAP/Start containing a Type-Length-Value (TLV) object of type Authority-ID (described later in the article) sent by the authenticator. The peer responds with an EAP-Response initiating exchanges for the establishment of the secure TLS tunnel or TLS handshake. The TLS messages are thus encapsulated within EAP packets.
Once the TLS tunnel is established, the second phase of TEAP takes place with a series of encrypted messages (the first of which can be sent with the last message of the TLS handshake to reduce the total number of exchanges) in which TLV objects are exchanged. TLV is a format for representing data within a protocol, consisting of a field representing the data type, another representing the length, and another the value. For TEAP, there are 17 possible TLVs:

  • Authority-ID: used by the authenticator in the TEAP/Start message to indicate its identity to the peer to help it choose the correct credentials to use later on.
  • Identity-Type: used by the authenticator to indicate the expected identity type to the peer: user or machine.
  • Result: used to indicate the success or failure of TEAP authentication.
  • NAK: used to indicate unsupported TLVs.
  • Error: used to indicate an error during TEAP authentication. There are 39 possible error codes.
  • Channel-Binding: used to transmit EAP channel-binding metadata to exchange information about network properties.
  • Vendor-Specific: free for vendors to use specific attributes.
  • Request-Action: used by the authenticator or the peer to request a new EAP negotiation or to process additional TLVs.
  • EAP-Payload: used to encapsulate EAP packets and TLVs.
  • Intermediate-Result: used to share EAP Success (including a Crypto-Binding TLV) or EAP Failure messages between multiple EAP methods.
  • PAC: used to provide a Protected Access Credential (PAC), i.e. a shared secret generated by the authenticator for the peer.
  • Crypto-Binding: used to verify the negotiated TEAP type and version and to validate the participation of the peer and the authenticator in the EAP authentication.
  • Basic-Password-Auth-Req: used by the authenticator to request a username and password from the peer.
  • Basic-Password-Auth-Resp: used by the peer to respond to the Basic-Password-Auth-Req TLV with a username and password.
  • PKCS#7: used by the authenticator to deliver one or more certificates to the peer.
  • PKCS#10: used by the peer to make a Simple PKI request in order to obtain a certificate.
  • Trusted-Server-Root: used by the peer to request the trusted root certificate from the authenticator, which it can then transmit with a PKCS#7 TLV in a Trusted-Server-Root TLV.

The TEAP conversation then ends with an exchange of Crypto-Binding and Result TLV objects, proving the proper conduct of the exchanges and leading to EAP Success or EAP Failure messages.

Example of TEAP Usage

TEAP, as a fairly open standard due to the use of TLV, can vary in its implementation by different vendors and may be incomplete. At the time of writing this article, other EAP methods (notably EAP-TLS, EAP-TTLS, EAP-PEAP) are still predominantly used. However, in the era of Zero Trust, TEAP is supposed to easily provide dual machine and user authentication in network access control.

Conclusion

TEAP is part of the evolution of EAP as an authentication method that enables multiple authentication mechanisms within a secure tunnel. The primary need is to chain machine authentication and user authentication in network access control. It is still uncertain how quickly vendors will adopt this standard and what additional features will be offered.

Sources

Translations