WPA/WPA-2 Enterprise
Notes from Pentester Academy Wireless Bootcamp
The WPA/WPA2 Enterprise implies a a Radius server (also known as AAA server - Authentication, Authorization and Accounting). When supplicants wants to connect to a WPA2 Enterprise network, they have to authenticate themselves previously to the Radius server.
EAP - Extended Authentication Protocol
EAP is a large authentication framework and its use is going far beyond authentication for wireless network. However, a small fraction of EAP is used for the 802.11 protocol.
As we can see in the image below, the EAP protocol involves three parties: the AP, the supplicant and the Authentication server. In the image below we see that the Radius server and AP are communicating through a wired connection. Both the AP and the Radius server share a secret to valid the identity of the other parties.
EAP Authentication scheme flow
The image below is an overview of the exchanges that occur between parties when the EAP authentication scheme is used in a WPA/WPA2-Enterprise network. The dot lines represents a wireless communication while the full line represents a wired communication.
In the WPA2-Enterprise, the Authentication and Association exchanges are not followed by the 4-way handshake and the encrypted data exchanges such as in WPA/WPA2 PSK network. Instead, a EAP packets are exchanges between parties for authentication. In the EAP authentication framework the AP is not responsible for authenticating the supplicant. This role is dedicated to the Radius server. The AP plays as an intermediate between the supplicant and the Radius server.
In the WPA/WPA2-Enterprise, the supplicant will ask the AP to start the EAPoL (Extended Authentication Protocol overlap) with a EAP-Start request.
The AP will ask for the identity (username) of the supplicant through an EAP Request Identity
The supplicant will send the EAP Response identity to the AP.
The Access Point transferred the EAP Response identity to the Radius server.
The Radius Server will send EAP packets to the AP
The AP will forward the EAP packets to the supplicant.
The Radius server will verify the credentials of the supplicant through an end-to-end tunnel with the supplicant.
The Radius server will tell the AP that the authentication of the supplicant is valid.
The Radius will send challenges packets and will verify whether the client's response is valid. If it the authentication is valid the Radius server will send a random PMK to the client and the same PMK to the AP.
The 4 way-handshake between the AP and the supplicant occurs and the PTK is generated.
The PTK is used to encrypt the data.
Advantages of WPA/WPA2-Enterprise ✅
Now that we have a briefly covered the exchanges between the three parties in the 802.1x protocol, we can better figure out why WPA/WPA2-Enterprise is more secure than the WPA/WPA2-PSK scheme.
Each users have their own credentials (usually AD credentials).
The PMK is random for each client and is generated by the Radius server. It is impossible to derived the PMK based on a passphrase.
Impossible to retrieve the credentials using a dictionary attack since the PMK is too random.
802.1x Authentication Methods
Different methods are used in the EAP framework to authenticate the others parties. Here are list some of the methods (not an exhaustive list):
EAP-MD5
The EAP-MD5 authentication method is very simple and help to understand the concept beneath the EAP supplicant authentication process. However, this authentication method is deemed insecure and should not be used anymore.
The supplicant send the EAPoL-Start request to the AP.
The AP send to the supplicant the EAP-Request/ID which is the username.
The supplicant respond to the AP with its ID and the AP forward the response to the Radius server.
The Radius server is issuing to the AP a 16 bytes MD5 challenge. Then. the AP forwards this challenge to the supplicant.
The supplicant will send back to the AP a response which corresponds to the MD5 hash of the Response ID, the password, and the challenge that has been issued. The Response is then forwards from the AP to the Radius server.
Receiving the response from the supplicant, the Radius server can validate the identity of the supplicant. Because the Radius server knows the password of the client, the Request ID and the issued challenge, the server can calculated the response and compares it with the response sent by the supplicant. If both responses match, the identity of the client is validated. If the response of the supplicant and the Radius server don't match this means that the passphrase provided by the supplicant is wrong.
The Radius server will send a EAP-Failure or EAP-Success message to the AP which will be forward to the supplicant.
Insecure: This method of authentication is vulnerable to MITM attack. An attacker could sniff the traffic between the parties and capture the MD5 challenge. Since he can also have access to the Response ID and the MD5 response hash, a dictionary attack is possible to recover the client's passphrase.
Others Authentication Methods
EAP-MSCHAPv2 (Microsoft protocol - the most secure if used in combination with encapsulation)
EAP-PAP (send username and password in plain text)
EAP-GTC
EAPCHAP
Encapsulation
All authentication method previously covered (EAP-MD5, EAP-MSCHAPv2, EAP-PAP, etc.) are not secure enough if used directly. Indeed, an attacker could sniff the traffic and intercept the challenges and responses and others information that are used to authenticate the parties. Thus, encapsulation is a method to secure the communication by creating an encrypted tunnel between parties. This will prevent MITM attacks and eyesdropping.
Examples of encapsulation methods: EAP-PEAP, EAP-TTLS
EAP-PEAP
General considerations
Use server side certificate
Supplicants authenticate by providing an username and password.
Mostly used with EAP-MSCHAPv2, but can also used GTC, CHAP, MSCHAP to authenticate the supplicant.
Native support on Windows
Authenticate supplicant through an encrypted tunnel
EAP-PEAP with EAP-MSCHAPv2
The Authentication and Association packets are exchanged between the supplicant and the AP.
The authentication process starts by the supplicant sending a EAPoL-Start request to the AP.
The AP request the identity of the supplicant.
The supplicant respond to the AP with its identity (might be a fake identity at this step) and the AP forwards the identity response to the Radius server.
The radius server sends EAP-PEAP Start packet to the supplicant to start a secured end-to-end TLS tunnel between the Radius server and the supplicant. During this step, the server will send to the supplicant its certificate to validate its identity. If the certificate from the server is not valid, the user will be displayed a warning message and prompt to accept or reject the certificate. If the client validate the server certificate, a TLS tunnel can be established between the supplicant and the Radius server.
Once the TLS tunnel is established, the Radius server will request for the identity of the supplicant. The supplicant will then provide its real identity (real username) to the Radius server. Then, will start the challenge and response exchanges between the supplicant and the Radius server. Since the exchanges are performed inside a TLS tunnel, no one (including the AP) could read the communication that occurs between the parties.
The Radius server will calculate, based on the MSCHAPv2 method of calculation, the response and compare its response with the response send back by the supplicant (similar to the MD5 authentication methods previously covered). Then, if both responses of the supplicant and server matches, the Radius server will send a EAP-Success packet to the supplicant. Upon valid authentication, the Radius server will also provides to the AP and the supplicant the key (PMK).
Both the supplicant and the AP having the PMK provided by the radius server, they can operate the 4 way-handshake to generate the PTK which will be used to encrypt the communication.
Security considerations
The encapsulation via a TLS tunnel protects the communication between the Radius server and the supplicant from being intercepted via a MITM attack or eyesdropping. However, this scheme of authentication is not without any danger. Since the TLS tunnel is established following the acceptance of the radius certificate by the supplicant, an unadvised user could validate a certificate from an untrusted Radius server and establish a TLS tunnel with an attacker. The attacker could then read all exchanged packets with the supplicant and recover the password of the client. See Evil Twin attack.
EAP-TTLS
Very similar to PEAP
Stands for EAP-Tunneled Transport Layer Security
Server authenticates with Certificate
Optional certificate for client (what distinguish PEAP from EAP-TTLS).
Versions
EAP-TTLSv0
EAL-TTLSv1
Inner Authentication: PAP (send clear text password), CHAP, MSCHAP, MSCHAPv2
EAP-TLS
Requires the use of both a client and server certificate.
A lot of workload is associated to the management of clients certificates.
Last updated