Which EAP types do you need for which identity projects?

The more interaction I have with customers who are getting started with Identity projects, the more I realize that a simple explanation and comparison of the differences between EAP types is needed.

For example, the general opinion that I get from customers is that EAP-TLS is the most secure EAP type to use, since it is X.509 certificate-based. Ok, I can accept that opinion; but did you realize that EAP-TLS might also be used as the Inner-Method of PEAP or EAP-FAST? No, not a cut-down version, but the SAME EAP-TLS protocol that can be used in isolation may also be used within a PEAP or EAP-FAST tunnel.

So, for this blog entry, I would like to examine the main (most-common) EAP types and their uses.

EAP is an authentication framework that defines the transport and usage of identity credentials. EAP encapsulates the usernames, passwords, certificates, tokens, OTPs, etc. that a client is sending for purposes of authentication. In fact, did you know that 802.1X is really “just” defining EAP over LAN?

There are many different EAP types, each one has its own benefit and downside.

Aaron Woland

• EAP-MD5: Uses a “Message Digest algorithm” to hide the credentials in a HASH. The HASH is sent to the server where it is compared to a local hash to see if the credentials were accurate. However, EAP-MD5 does not have a mechanism for mutual authentication. That means the server is validating the client, but the client does not authenticate the Server (i.e.: does not check to see if it should trust the server). EAP-MD5 is common on IP Phones, and it is also possible that some switches will send MAC Authentication Bypass (MAB) requests using EAP-MD5.
• EAP-TLS: An EAP type that uses TLS (Transport Layer Security) to provide the secure identity transaction. This is very similar to SSL and the way encryption is formed between your web browser and a secure website. EAP-TLS has the benefit of being an open IETF standard, and is considered “universally supported.” EAP-TLS uses X.509 certificates and provides the ability to support mutual authentication, where the client must trust the server’s certificate, and vice-versa. It is considered among the most secure EAP Types, since password capture is not an option; the endpoint must still have the private-key. Note: EAP-TLS is quickly becoming the EAP type of choice when supporting BYOD in the Enterprise.

Tunneled EAP Types

The EAP types above transmit their credentials immediately. These next two EAP types form encrypted tunnels first and then transmit the credentials within the tunnel.

Aaron Woland

• PEAP: Protected EAP. Originally proposed by Microsoft, this EAP Tunnel type has quickly become the most popular and widely deployed EAP method in the world. PEAP will form a potentially encrypted TLS tunnel between the client and server, using the x.509 certificate on the server in much the same way the SSL tunnel is established between a web browser and a secure website. After the tunnel has been formed, PEAP will use another EAP type as an “inner method” – authenticating the client using EAP within the outer tunnel.
  • EAP-MSCHAPv2: Using this inner method, the client’s credentials are sent to the server encrypted within an MSCHAPv2 session. This is the most common inner method, as it allows for simple transmission of usernames and passwords, or even computer-name and computer-passwords, to the RADIUS server, which in turn will authenticate them to Active Directory.
  • EAP-GTC: EAP Generic Token Card (GTC). This inner method was created by Cisco as an alternative to MSCHAPv2 that allows generic authentications to virtually any identity store, including One-Time-Password (OTP) token servers, LDAP, Novell E-Directory and more.
  • EAP-TLS: While rarely used, and not widely known, PEAP is capable of using EAP-TLS as an inner method.

EAP-FAST: Flexible Authentication via Secure Tunnel (FAST) is very similar to PEAP. FAST was created by Cisco Systems as an alternative to PEAP that allows for faster re-authentications and supports faster wireless roaming. Just like PEAP, FAST forms a TLS outer-tunnel and then transmits the client credentials within that TLS tunnel. Where FAST differs from the PEAP is the ability to use Protected Access Credentials (PACs). A PAC can be thought of like a secure “cookie,” stored locally on the host as “proof” of a successful authentication.

• EAP-MSCHAPv2: Using this inner method, the client’s credentials are sent to the server encrypted within an MSCHAPv2 session. This is the most common inner method, as it allows for simple transmission of username and password, or even computer-name and computer-passwords to the RADIUS server, which in-turn will authenticate them to Active Directory.
• EAP-GTC: EAP-Generic Token Card (GTC). This inner method was created by Cisco as an alternative to MSCHAPv2 that allows generic authentications to virtually any identity store, including One-Time-Password (OTP) token servers, LDAP, Novell E-Directory and more.
• EAP-TLS: EAP-FAST is capable of using EAP-TLS as an inner method. This has become quite popular with EAP-Chaining.

EAP Chaining with EAP-FASTv2: As an enhancement to EAP-FAST, a differentiation was made to have a User PAC and a Machine PAC. After a successful machine-authentication, ISE will issue a Machine-PAC to the client. Then, when processing a user-authentication, ISE will request the Machine-PAC to prove that the machine was successfully authenticated, too. This is the first time in 802.1X history that multiple credentials have been able to be authenticated within a single EAP transaction, and it is known as “EAP Chaining.” The IETF is creating a new open standard based on EAP-FASTv2 and at the time I wrote this blog post, it was to be referred to as “EAP-TEAP” (tunneled EAP), which should eventually be supported by all major vendors.