WPA2-Enterprise 802.1X/EAP Authentication Process

WPA2-Enterprise 802.1X/EAP Authentication Process

In WPA and WPA2 PSK all clients share a common security key. Potential security issues arise because all stations in the wireless network share the same security key. Although WPA and WPA2 PSK offer many advantages, it should not be used for an enterprise wireless network. The recommended solution for most corporate environments is WPA2 Enterprise. The three primary authentication components of WPA2-Enterprise are: Remote Authentication Dial-In User Service (RADIUS), IEEE 802.1X (port based access control), and Extensive Authentication Protocol (EAP). RADIUS allows for centralized authentication services and acts as the authentication server. In the enterprise, RADIUS is used to query an external user database, such as Active Directory (AD). IEEE 802.1X is the standard that defines port-based access control, which specifies the following three components:

• The supplicant (Client device seeking authentication)
• The authenticator (The AP or wireless controller, which provides the wireless connection)
• The authentication server (The RADIUS server that validate the user credentials)

In addition to improved encryption and integrity algorithms, the 802.1X/EAP provide user authentication and dynamic key distribution. EAP is a Layer 2 authentication protocol that can be applied to wired and wireless networks. The 802.1X/EAP Authentication Process consists of the following steps:

The first step for a client is to become 802.11 authenticated and associated, during which each station receives the other’s capabilities and requirements. An Open System Authentication must take place first, without this association, 802.1X/EAP cannot start. Open System Authentication is like connecting an Ethernet cable between a switch and a PC to confirm physical link.

The second step is for the client (supplicant) and authentication server (AS) to complete the mutual 802.1X/EAP authentication and for the AS to pass the Pairwise Master Key (PMK) to the Authenticator.

The third step is for the two stations to have matching PMK. The PMK will be used to generate the pairwise transient key (PTK) for encryption purposes. The shared PMK by the stations is obtained during the 802.1X/EAP authentication process.

The fourth step is the 4-way handshake. The 4-way handshake is the final step used to generate pairwise transient keys (PTK) for encryption of unicast transmissions and a group temporal key (GTK) for encryption of broadcast/multicast transmissions. Each station in the wireless network will have a unique PTK. Upon a successful 4-Way handshake, the authenticator and supplicant have authenticated each other and traffic will be allowed to flow.

EAP is an authentication framework, and does not mandate the use of a specific authentication method. For this reason, multiple EAP types can be used in a WLAN security deployment. The following list shows the most common types of EAP types:

• EAP-TLS (Client and server certificates required)
• TTLS (EAP-MSCHAPv2 – only server certificate is required)
• PEAPv0 (EAP-MSCHAPv2 – only server certificate is required)
• PEAPv0 (EAP-TLS – Client and server certificates required)
• PEAPv1 (EAP-GTC – used with token card and directory-based authentication systems)

The EAP types such as EAP-TLS and PEAP (EAP-TLS) require the use of a digital certificate on both the authentication server and the clients, which can become expensive and increase management overhead. The most common EAP type use is PEAP (EAP-MSCHAPv2) because it is included in the Windows operating system, and doesn’t require the validation of the supplicant certificate.

The following images show the steps in the 802.1X/EAP authentication flow:

Step 1: 802.11 Authentication and Association

 

 

Step 2/3: PEAP General Authentication Flow

Step 4: 4-way handshakeThe following explains the main points during the 802.1X/EAP Authentication:   

1. The supplicant sends an authentication request to the authenticator.
2. The authenticator sends an authentication success to the supplicant.
3. The supplicant sends an association request to the authenticator.
4. The authenticator sends an association success to the supplicant.
5. EAP Start message.
6. The authenticator sends an EAP frame requesting the identity of the supplicant.
7. The supplicant responds with an EAP frame with the clear-text outer identity that is not the real username. At this point, the authenticator forwards the outer identity to the authenticator server (AS). All other traffic remains blocked. The outer identity simply informs the AS that a supplicant wants to be validated.
8. The AS sends the server certificate to the supplicant. The supplicant validates the server-side certificate and therefore authenticates the authentication server.
9. An encrypted point-to-point TLS tunnel is created between the supplicant and the authentication server.
10. Once the TLS tunnel is established, the AS requests the real identity of the supplicant. The supplicant responds with the inner identity, which is the real credential. The credential is now hidden because it is encrypted inside the TLS Tunnel.
11. The AS server sends a RADIUS Accept or Failure message to the authenticator.
12. The authenticator will send an EAP Success or Failure message to the supplicant. If the supplicant credentials were valid, then a 4-way handshake is conducted to generate the pairwise transient key (PTK) for encryption purposes.
13. The authenticator sends an EAPoL-Key frame containing an ANonce to the supplicant. The supplicant derives the PTK from the PMK, ANonce, SNonce, and MAC addresses.
14. The supplicant send an EAPoL-Key frame SNonce to the authenticator with a message integrity code (MIC). The authenticator derives a PTK from the PMK, ANonce, SNonce, and MAC addresses. At this point, both the supplicant and authenticator have a PTK that can be used to encrypt unicast traffic.
15. If necessary, the authenticator send EAPoL-Key frame containing the GTK. The GTK is used to encrypt broadcast/multicast traffic.
16. The supplicant sends a final EAPoL-Key frame to confirm to the authenticator that the temporal keys were installed.

Finally, the supplicant can send encrypted unicast traffic to the destination. The authentication and encryption key generation processes are necessary to provide data privacy, as well as protection when connecting to the WLAN.