Sometimes we are just asked for assistance to configure a secure WLAN doing authentication against a “server” (most of the time trying to simulate what they already have on wired, normally for authentication of the domain users), but having no idea that an EAP method is required to deploy this type of security on WLANs.
None of the EAP methods available is “better” to be recommended, but the best method is the one that meets customer’s requirements and security policies (or even sometimes limitations as well; for example, the only one or more secure EAP method that your only RADIUS Server or your specific wireless clients support).
Therefore, we could at least guide/help the customers (and ourselves) by giving a quick summary of the EAP methods mostly deployed on WLANs, so people can take the decision of which EAP method is the best for their needs so they can configure it (on the wireless client -Supplicant- and RADIUS Server -Authentication Server-):
*** LEAP ***
This is the easiest EAP method to setup, but not all RADIUS Servers and wireless clients support it as this is a Cisco proprietary method, so this is the first thing you check: If your clients’ supplicant and RADIUS server support it. The wireless clients are authenticated with username/password credentials doing an MS-CHAPv2 handshake, so this is why it is not considered strongly secure: Credentials are not really protected as the username is sent in cleartext and the password is checked with MS-CHAPv2 handshake so it can be vulnerable to dictionary attacks. Therefore, as with any other authentication method validating username/password credentials, strong password security policies are required to deal with those types of attacks.
*** EAP-FAST ***
This EAP method was developed by Cisco to overcome LEAP vulnerabilities and to have multiple-flexible options to validate the client’s credentials, while protecting the credentials on a secure tunnel without the need of certificates if you don’t have a CA (Certificate Authority). Just like LEAP, not all RADIUS Servers and wireless clients support EAP-FAST as this is a Cisco method (submitted as an IETF informational draft), so this is the first thing you check: If your wireless clients and RADIUS Server support EAP-FAST and what flavors of EAP-FAST. What do I mean with “flavors”? EAP-FAST is very flexible so you can authenticate the wireless clients with different type of credentials depending on the “flavor”, such as:
1) EAP-FAST/MSCHAPv2: Clients are authenticated with username/password credentials doing an MS-CHAPv2 handshake. This is the most used EAP-FAST flavor, mainly because it doesn't need any certificate installation (hence no CA needed).
2) EAP-FAST/TLS: Clients are authenticated with certificates as their credentials. This will require a CA to generate the client certificates and server certificate.
3) EAP-FAST/GTC: GTC means Generic Token Card, so the wireless clients are authenticated with username/password credentials and tokens if using a token server.
In summary, EAP-FAST has basically three phases during the authentication process:
- Phase Zero: An optional phase to provide a PAC (Protected Access Credentials, which are strong secrets unique to users) to the wireless clients, which is used to build the TLS tunnel between the client and RADIUS Server to protect the client credentials handshake. This is normally for Automatic PAC provisioning, as the PAC can also be provided manually to the clients (so phase zero doesn’t really happen in that case). The RADIUS servers that support EAP-FAST as an authentication method are basically the ones that generate these PACs for Automatic (in-band) or Manual (out-of-band) PAC provisioning to the clients.
- Phase One: RADIUS Server and client establish the TLS tunnel based on the user’s PAC.
- Phase Two: The client credentials are exchanged and validated securely within the TLS tunnel, using any of the flavors mentioned above.
*** EAP-PEAP ***
Also known as just PEAP, this is not an authentication method by itself, but one that handles other authentication methods inside a TLS tunnel to protect clients' credentials exchange, using a server device certificate installed at the Authentication Server (hence the P on PEAP, for Protected EAP). Similar to EAP-FAST, there are three major versions of PEAP flavors:
1) EAP-PEAPv0/EAP-MSCHAPv2: Also known as PEAP-MSCHAPv2, this is the most widely deployed EAP method of all the 802.1X/EAP methods available for WLANs. This is mainly because:
--- Most wireless clients and RADIUS Servers support it.
--- Clients are authenticated with username/password credentials doing an MS-CHAPv2 handshake, which is what most deployments already have on their wired infrastructure based on their AD or current network domain username/passwords.
--- It protects the client credentials doing a TLS tunnel between the RADIUS server and clients using a server certificate (so it is very secure).
--- The downside for some people is that, even though you are authenticating the clients with just username/password credentials, you still need a CA to generate the server side certificate (used to protect the client credentials).
2) EAP-PEAPv0/EAP-TLS: Also called PEAP-TLS, here clients are authenticated with certificates as their credentials, but the certificates from the clients are exchanged with the Authentication Server within the TLS tunnel that was built using the server device certificate.
3) EAP-PEAPv1/EAP-GTC: There is another flavor of PEAP, also called PEAP-GTC, which is basically similar to EAP-PEAPv0/EAP-MSCHAPv2 and clients can be authenticated using username/password credentials but using tokens if there is a token server and security policies demand it. The downside is that very few wireless clients and RADIUS Servers actually support PEAP-GTC.
*** EAP-TLS ***
This is a very secure EAP method where the wireless clients are authenticated using client certificates as their credentials (instead of username/password), so there must be a CA generating the client certificates and also the RADIUS server certificate, which is required for this method (both client and server certificates from the same CA so they can be properly validated).
Most wireless clients and RADIUS Servers support this method, so if your security policies demand for secure client credentials using certificates, this is probably the best way to go.
Note about CAs: Whenever a CA (Certificate Authority) is needed for any of the EAP methods, you can surely use Self-Signed Certificates, a home-based CA (for example, their own Windows Server CA service), or a known/public third-party CA. Customer will need to take the decision on what type of CA they actually want/need if they will deploy an EAP method that requires it due to certificates.
