07. WPA WPA2 Enterprise (MGT)

802.1X Authentication Mechanism

• WPA/WPA2-Enterprise uses 802.1X Authentication Mechanism.
• Allow for credentials different for each user (instead of unique passphrase shared among all clients).
• IEEE 802.1X is the standard for passing EAP over a wired or wireless LAN.
• The encapsulation of EAP over IEEE 802.1x is known as "EAP over LAN" or EAPOL.

802.1X Terminology

• Supplicant = The user or client device that wants to be authenticated and given access to the network.
• Authentication server = The actual server doing the authentication, typically a RADIUS server.
• Authenticator = The device in between the Supplicant and Authentication Server (i.e. AP in wireless network).
• RADIUS = Remote Authentication Dial-In User Service. Server that can be used to query either a local user database, or an external database via LDAP protocol.
• EAP (Extensible Authentication Protocol) = Authentication framework, not a specific authentication mechanism. It provides various authentication methods. Some methods also support the encapsulation of an "inner method".

EAP Encapsulated Client Authentication Common Methods

EAP can use various methods to authenticate clients, also referred as "Inner EAP/Authentication Protocol". Usually, one of the following methods is used after the establishment of a TLS tunnel between Client & Authentication Server, during the EAP Handshake.

PAP (Password Authentication Protocol)

Simple Authentication mechanism where client sends his credentials directly to the server.

CHAP (Challenge-Handshake Authentication Protocol)

1. Server sends a challenge to the client.
2. Client encrypts the server's challenge using his credential, and sends it as response to the server.
3. Server performs the same operation on its side and checks if response from client is correct.

MSCHAPv2

Microsoft implementation of CHAP where the response is computed by client by DES encrypting [ server challenge + client challenge + client's username ], using his NTLM hash as DES key.

Where GenerateNTResponse is working as follows:

Ref: http://esec-pentest.sogeti.com/challenge-vpn-network/decipher-mppe-breaking-ms-chap-v2

Important Note: By design, MSCHAPv2 also provide some kind of server authentication to the client, because the server must know the client's password in order to send a valid Authentication Response :

GTC (Generic Token Card)

1. Server sends a challenge to the client.
2. Client uses token card to generate one-time token.
3. Client uses this one-time token to generate a response to the challenge, and sends it (in cleartext) to the server.
4. Server checks validity of response.

Client Certificate

• Client authentication can be performed using a client certificate that is sent to the server.
• This method is natively implemented inside EAP-TLS.
• Most difficult to deploy on a corporate network because require the use of a PKI.

EAP Handshakes

• EAP Handshake occurs after 802.11 Auth/Association handshake.
• After successful EAP Handshake, classic WPA/WPA2 4-way Handshake (based on PMK)follows.

General case of EAP Handshake

EAP-MD5

• Deprecated method.
• Old and very weak implementation.
• Client authentication is done via MD5 hashing challenge/response, in cleartext.
• Identity (client's username) is sent in cleartext too.
• Authentication server is never authenticated by the client.
• Actually only an authentication method, do not provide encryption (no way to generate per-session encryption key).

LEAP

• Deprecated method.
• Cisco Proprietary EAP type.
• Client authentication is done via MSCHAPv2 challenge/response protocol
• MSCHAPv2 challenge/response are transmitted in cleartext
• Identity (client's username) is sent in cleartext too.

Ref: https://mrncciew.com/2014/08/24/cwsp-eap-leap/

EAP-TLS

• Require the use of client certificates (in addition to server certificate).
• Most secure method.
• Requires a PKI, can be very complex to set up (poor adoption rate).
• Identity (client's username) should not be sent in cleartext, only an "anonymous" identity should be sent to server before TLS tunnel establishment.

Ref: https://mrncciew.com/2014/08/26/cwsp-eap-tls/

EAP-FAST

• Cisco replacement for LEAP.
• Server certificate is optional. Instead, a PAC (Protected Access Credentials) can be used to authenticate server when establishing a TLS tunnel.
• PAC can be seen as a "secure cookie", stored on the client, as "proof" of successful authentication (client compares identity presented by server with identity stored inside his PAC).
• With PAC distributed to clients, the full TLS handshake does not need to be used to set up the TLS tunnel.
• Client credentials are sent within the TLS tunnel.
• Common "Inner EAP/Authentication Protocol" to authenticate clients inside the TLS tunnel:
  • MSCHAPv2 (most common)
  • GTC
• In EAP-FAST (also in EAP-TTLS & PEAP), we can distinguish 2 phases during handshake:
  • Phase 1 = Secure tunnel creation.
  • Phase 2 = Client authentication using one of supported "Inner EAP/Authentication Protocol".
• Identity (client's username) should not be sent in cleartext, only an "anonymous"/"bogus" identity should be sent to server before TLS tunnel establishment.

Ref: https://mrncciew.com/2014/08/26/cwsp-eap-fast/

EAP-TTLS

• EAP with Tunneled TLS.
• EAP-TTLS is different from EAP-TLS because it excludes requirement of a client-side certificate. Only the authentication server component requires a certificate.
• Similar to EAP-FAST & PEAP.
• Support almost any "Inner EAP/Authentication Protocol" to authenticate client:
  • PAP
  • CHAP
  • MSCHAPv2
  • GTC
  • Certificate
• Identity (client's username) should not be sent in cleartext, only an "anonymous" identity should be sent to server before TLS tunnel establishment.

PEAP

• Developed by Microsoft, Cisco & RSA Security.
• Referred as EAP within EAP.
• 3 major versions of PEAP:
  • EAP-PEAPv0(EAP-MSCHAPv2) => most widely used
  • EAP-PEAPv0(EAP-TLS)
  • EAP-PEAPv1(EAP-GTC)
• PEAPv0 & PEAPv1 refer to the outer authentication method and are the mechanism that create the secure TLS tunnel to protect subsequent authentication transaction.
• EAP protocol inside parenthesis (i.e. MSCHAPv2, TLS & GTC) is the Inner Authentication/EAP Protocol.
• Identity (client's username) should not be sent in cleartext, only an "anonymous" identity should be sent to server before TLS tunnel establishment.

Comparison of EAP Methods

Feature	EAP-MD5	LEAP	EAP-TLS	EAP-FAST	EAP-TTLS	PEAPv0 (EAP-MSCHAPv2)	PEAPv0 (EAP-TLS)	PEAPv1 (EAP-GTC)
Server Certificate	No	No	Yes	Optional (can use PAC instead)	Yes	Yes	Yes	Yes
Client Certificate	No	No	Yes (also supports smartcard)	No	Optional	No	Yes	Optional
Supported Client Authentication	MD5 hash challenge response	MSCHAPv2 challenge/response	Via Certif./Smartcard	MSCHAPv2, GTC	PAP, CHAP, MSCHAPv2, GTC, Certif.	MSCHAPv2	Certif	GTC
Mutual Authentication	No	Yes	Yes	Yes	Yes	Yes	Yes	Yes
User Identity Protection	No	No	Yes (anonymous)	Yes (bogus username)	Yes (TLS encryption)	Yes (TLS encryption)	Yes (TLS encryption)	Yes (TLS encryption)
Client Auth in cleartext	Yes (sniffing possible)	Yes (sniffing possible)	No	No	No	No	No	No
Client Auth Handhshake offline cracking	Tool eapmd5pass	Tool Asleap	No	Tool Asleap (for MSCHAPv2)	Tool Asleap (for MSCHAPv2)	Tool Asleap	No	Cleartext (inside TLS tunnel)
Evil Twin Attack Possible ?	Yes	Yes	No	Yes if no server's PAC validation	Yes if no server's certif validation	Yes if no server's certif validation	No	Yes if no server's certif validation

Most commonly used EAP implementations = PEAP & EAP-TTLS.

Note: User Identity Protection is not always enforced when it should be (depending on the configuration). It might happen to sniff real usernames before TLS tunnel establishment even in EAP-TLS, EAP-TTLS, PEAP...

Summary on EAP Theory

To simplify, we can distinguish 2 big types of EAP methods:

• EAP with Client Certificate Authentication (e.g. EAP-TLS, PEAPv0(EAP-TLS)):

• EAP with Credentials Authentication (e.g. LEAP, PEAPv0(MSCHAPv2), EAP-TTLS(MSCHAPv2)...).
  EAP handshake can be splitted in 2 phases:

  • Phase 1: Server authenticates itself using certificate (or PAC in EAP-FAST), and a secure TLS tunnel is created.
  • Phase 2: Client authenticates itself using one credentials-based "Inner authentication method" such as MSCHAPv2, CHAP, PAP, GTC...