EAP: Extensible Authentication Protocols

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?

EAP has two primary features: It provides a segregated message exchange, which ties into the second feature, extensibility. EAP is a common Layer 2 security framework in which many different authentication mechanisms can be used. These authentication mechanisms are dynamically selected, based on the negotiation between the supplicant and authenticator; the authentication mechanism negotiation and selection occurs separately from any other action being performed on the data, such as network protocol encapsulation. 

All flavors of EAP use a three-party model: the party requesting access (the supplicant); the party requesting authentication (the authenticator); and the authentication server (AS), which contains authorised user databases and issues permissions. In wireless applications, the most common supplicant is a mobile device wishing to access a network. The authenticator is usually a wireless access point (AP). The AS is a dedicated server, often referred to as the network access server. The most common designation is remote access dial-in user service (RADIUS). In many installations, one device, usually a wireless AP, handles the authenticator and AS tasks. The authenticator controls two virtual ports: the controlled and uncontrolled ports. The initial exchanges between the supplicant and authenticator take place over the uncontrolled port; upon successful authentication, the authenticator opens the controlled port to the supplicant.

The main purpose of EAP is to authenticate the supplicant and authorise it to use network resources. The basic EAP framework follows: The supplicant requests access after Open System Authentication. An exchange of EAP messages over the uncontrolled port ensues; upon successful authentication, the supplicant is allowed access to the controlled port. Subsequently, encryption keys are generated and distributed over the secure channel (controlled port); secure communication is achieved. All EAP mechanisms follow this same basic protocol of identity exchange, verification, and key distribution; some mechanisms authenticate only one party.

EAP Messages are encapsulated in EAP over LAN (EAPOL) frames. There are five types of EAPOL frames:

• EAP-Packet: The most common type, used in request/response frame exchanges
• EAPOL-Start: Used by the supplicant to start the EAP process; optional
• EAPOL-Logoff: Used to terminate the EAP session and shut down the secure port
• EAPOL-Key: Used during the 4-way handshake to exchange dynamic encryption keys
• EAPOL-Encapsulated-Alert: Used to send alerts to the virtual ports.

The generic supplicant-authenticator-authentication server EAP process is illustrated in Figure 1:

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

    Figure1 - Native EAP Types

• 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.

Figure2 - Tunneled EAP Types

·        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.

o   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.

o   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.

o   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.       

Type of Network Access for 802.1X
Available EAP Methods
         802.1X authentication to an authenticating switch (wired)
         EAP-MD5 CHAP, PEAP-MS-CHAP v2, EAP-TLS, PEAP-TLS

         802.1X authentication to a wireless AP

         PEAP-MS-CHAP v2, EAP-TLS, PEAP-TLS