EAP (wifi/dot1x authentication)

Quick security notes

• Disable TKIP (use CCMP or GCMP): uses (broken) RC4
  • Optional TKIP on AP will result in TKIP as group (multicast/broadcast) cipher! Should be disabled as well.
• Disable PMKID with PSK based authentication: enables another offline PSK brute-force attack
• Use high-entropy PSK (or WPA3-SAE)
• Disable WPA1: uses RC4 in EAPOL key management

EAP methods

Useful links:

• https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap-numbers-4
• http://deployingradius.com/documents/protocols/compatibility.html
• https://salsa.debian.org/debian/wpa/-/blob/debian/unstable/wpa_supplicant/eap_testing.txt

Basic protocol see RFC 3748.

The authenticator (AP) sends an Identity Request to the supplicant (client); the response can contain an identity (“username”); this is sent as plaintext. Afterwards method are tried; a supplicant can reject a method (and announce methods it supports), otherwise the method is used until authentication succeeds or fails.

In the most outer EAP-session (certain methods below support nested EAP sessions) this identity is the “outer” or “anonymous” identity and is often used for routing purposes - e.g. “anonymous@example.com” indicates the client wants to authenticate against a server responsible for example.com. It should not contain the actual username, which should only be transmitted in an TLS-protected channel later.

From RFC 3748 5.1:

EAP Methods SHOULD include a method-specific mechanism for obtaining the identity, so that they do not have to rely on the Identity Response.

WPA-Enterprise requires EAP methods that derive shared key material from the authentication; not all methods support this.