EAP Authentication

As mentioned in the authentication blog, the Authentication Server (AS) and the Supplicant need to talk to each other with the same EAP protocol. The AS has also a server certificate which is used for two purposes. First it is used to show the supplicant that this server is the right server to send your credentials to, and the second is to build the encrypted TLS tunnel. This certificate is created by your PKI or purchased from a trusted root certificate authority (CA).

You can also install a client certificate. This is not for validating the server but another option to authenticate. As mentioned in the authentication blog, you can use client certificate for authentication instead of username password. 

There are different types of EAP protocols. All the EAP messages are encapsulated in EAP over LAN frames (EAPOL). There are five major types of EAPOL messages.

0000 0000 – EAP Packet
This is a standard encapsulated EAP frame. Most of the EAP frames use this EAP packet.
0000 0001 – EAPOL Start
This is an optional frame that indicates the start of the EAP process.
0000 0010 – EAPOL Logoff
This is the frame that terminates the EAP session. This can be misused by hackers for DOS attacks.
0000 0011 – EAPOL Key
This frame is used during the 4-way handshake to exchange dynamic key information.
0000 0100 – EAPOL Encapsulation ASF Alert
This is the frame that sends alerts like SNMP traps.

The EAP process is as follows:
– The client (supplicant) associates with the access point. Both the controlled and uncontrolled ports are blocked at this moment.
– Depending on the EAP type, an EAPOL-start frame will be transmitted by the client.
– The authenticator transmits an EAP-request frame—this is a mandatory frame.
– The supplicant transmits EAP-response frame with the identity (username or bogus username) in clear text. The uncontrolled port opens to let through the EAP traffic. The controlled port is still blocked.
– The EAP-response frame is encapsulated by the authenticator in a RADIUS packet. And the authenticator forwards this to the RADIUS server
– The AS looks at the identity from the user and checks this in the database. AS creates a password challenge.
– The authenticator transmits the EAP challenge request to the supplicant.
– The supplicant replies with an EAP-challenge response. This has the hashed password with an algorithm such as MD5 or MS-CHAP.
– The authenticator forwards this message to the AS.
– The AS validates the username and password challenge in the database and replies with a success frame or failure frame.
– The authenticator forwards this message to the supplicant.
– When it is a success-frame, the 4-way handshake starts between the authenticator and the supplicant.
– After the 4-way handshake, the controlled port will open.

EAP Types

Some of the EAP types, I discussed in the blog “Legacy Security.” We are talking about EAP-MD5. This was one of the first EAP that was used in WLAN environments. MD5 hash is very weak, it was considered secure in the time that it was used for PPP networks, but not secure enough for WLAN networks. With EAP-MD5 only the supplicant is validated, the server is not. MD5 use WEP encryption or no encryption at all and the username is in clear text. So, all together not a secure EAP type after all.

EAP LEAP
Also, EAP-LEAP is discussed short in the “Legacy Security” blog. EAP-LEAP uses MSCHAP hash, what is more secure than MD5 hashing. Nowadays, MSCHAP and MSCHAPv2 are also considered as weak hashing and vulnerable for dictionary attacks. Like MD5, LEAP also uses username in clear text. The last thing is not a security reason, but LEAP is Cisco proprietary protocol, so in mixed environments LEAP is not a good choice after all.

With both EAP types (EAP-MD5 and EAP-LEAP) clear text username is used. With the stronger EAP types, it uses a bogus username to initialize and this one is in clear text. The standard is, if you use a protocol analyzer, you will see anonymous as clear text username. Later in the authentication process the supplicant sends the official username and this is at that moment encrypted. This is called the outer identity (anonymous) and inner identity (the real username).

EAP-PEAP
Protected Extensible Authentication Protocol creates an encrypted tunnel (TLS-tunnel) after the authentication is initialized. The first phase looks like a general EAP request.
– After the EAP starts, the authenticator asks for the identity
– The supplicant replies with a bogus username as identity response
– The authenticator forwards this bogus username (outer identity) to the AS.
– AS cannot validate this, since this username doesn’t exist, so instead of the challenge request, it sends its server certificate.
– Supplicant validates the server and the TLS tunnel will be established.
After the tunnel is established, phase 2 will start.
– The AS requests now the real identity
– The supplicant responds with the real identity (inner identity)
– The AS replies with the challenge
The challenge is using EAP-MS-CHAP. Earlier I said that this is a weak hashing algorithm, but at this point all the information goes through the TLS tunnel and is secure. Before the AS replies with an accept or failure, the tunnel will be shut down and the 4-way handshake can start.

EAP-PEAPv0 (EAP-MSCHAP2) uses EAP-MSCHAPv2 within the tunnel. EAP-MSCHAPv2 is the same algorithm method as MSCHAPv2, but it is considered to be two different protocols.
EAP-PEAPv0 (EAP-TLS) doesn’t use a real username/password as discussed in the example. It uses a client certificate to validate the client. So, it starts with the bogus username and sets up the TLS tunnel. After this is established, the supplicant sends its client certificate to validate. For this there needs to be a PKI for the client certificate. As mentioned, this is an expensive solution.
EAP-PEAPv1 (EAP-GTC) EAP-Generic Token Card is the inner tunnel authentication that is used by Cisco. This is a One Time Password mechanism that is used for inner authentication.

EAP-TTLS
EAP-Tunneled Transport Layer Security looks like EAP-PEAP. It uses a bogus username to initialize the authentication and also uses the server certificate to set up the TLS tunnel. The difference between EAP-PEAP and EAP-TTLS is that EAP-TTLS can use all kinds of authentication methods. EAP-PEAP uses EAP-MSCHAPv2, while EAP-TTLS can use PAP, CHAP, MS-CHAP, and MS-CHAPv2 as well a client certificate.

EAP-TLS
EAP Transport Layer Security is, up to this point, one of the most secure EAP types for the WLAN environment. It needs client certificates on all the clients, so also a secure enterprise PKI is needed to deploy the client side certificates. Security is as strong as the weakest link, so in this case if the PKI is not secure, the whole EAP-TLS link will collapse.

After the server certificate is validated there is not a tunnel established like it is with EAP-PEAP and EAP-TTLS, but the client sends the client certificate directly. The AS validates the client certificate and sends the accept or reject to the supplicant.

EAP-FAST
EAP Flexile Authentication via Secure Tunneling is not a faster EAP protocol. It started out as a Cisco proprietary but recently became a standardize EAP protocol. EAP-FAST was the secure replacement of EAP-LEAP. EAP-FAST doesn’t use the X.509 digital certificate like PEAP and TTLS, it uses PAC files.

The Protected Access Credential is a shared secret key, a key between the client and the AS. In the PAC file is an Opaque element that is used by the AS to validate the supplicant identity. As well, there is some other information in the PAC Info element.

Like with the X.509 digital certificate the first phase is the provisioning of the PAC file to all the supplicants. The advantage with this certificate or the X.509 is you don’t need a PKI. The PAC file are created on the RADIUS server. Deploying the PAC file can also be manually done. In the second phase (Phase 1), the supplicant sends the bogus identity to initialize the authentication. After the request of the AS, the supplicant sends its PAC file to the AS and the AS will validate it using the data in the PAC-Opaque date element. An encrypted TLS tunnel will be established. In the last phase (Phase 2) the inner identity will be exchanged. Since it is a Cisco proprietary it can use EAP-GTC like EAP-PEAP, but also client certificate or other inner authentication methods.

Other EAP protocols are EAP-POTP (Protected One-Time Password), EAP-TEAP (Tunneled Extensible Authentication Protocol) or EAP-SIM and EAP-AKA. EAP-POTP uses One-Time Passwords for authentication, EAP-TEAP is an enhancement of EAP-FAST that uses tunneled authentication and multiple inner authentications are supported within EAP-TEAP. With TEAP you can use multiple credentials within a single EAP transaction and TEAP has the ability to link those credentials together.

EAP-SIM (Subscriber Identity Module) is the little card that you put into your mobile phone from your carrier. It is the identification for mobile phones. EAP-AKA (Authentication and Key Agreement) is also for the mobile industry, more specifically, 3G (EAP-SIM is for the 2G networks), is used in the Universal Mobile Telecommunication Systems (UTMS), and runs in the SIM module. So, EAP-SIM and EAP-AKA are used in SIM modules for cellular devices. Hotspot 2.0 is a Wi-Fi Alliance program (Passpoint program) that uses the SIM card for authentication. EAP-SIM and EAP-AKA can be used as protocol to authenticate for Hostpot 2.0.