Another quick question for you. What is the most recommended EAP authentication mehtod for wireless security? thanks again,
This is a very good and common question, but the answer is also similar to the one about the RADIUS Server type of deployment:
None of the EAP methods available is “better” to be recommended, but the best method is the one that meets your 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, let me help on this question 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:
*** 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:
- EAP-FAST/MSCHAPv2: Clients are authenticated with username/password credentials doing an MS-CHAPv2 handshake.
- EAP-FAST/TLS: Clients are authenticated with certificates as their credentials. This will require a CA to generate the client certificates and server certificate.
- 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 here). 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.
*** PEAP-MSCHAPv2: This is probably the most widely deployed EAP method of all 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, hence the P on PEAP, for Protected EAP).
There is another flavor of PEAP, called PEAP-GTC, which is basically similar 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.
The following document has a very good EAP types comparisons chart (Table 1) for further details:
Note: This document is a bit outdated, so let me correct that Fast Secure Roaming is basically supported with all of the EAP methods (depending on the client).
Hope this helps to take good decisions based on security policies and what the clients-server support.
Hi Jeal, I am in the process of configuring flex connect local switching (5508 on 7.5). In the 7.5 config notes it states that:
"FlexConnect Access Points with Locally Switched WLAN cannot perform IP Source Guard and prevent
ARP spoofing. For Centrally Switched WLAN, the wireless controller performs the IP Source Guard
and ARP Spoofing."
However, I've noticed I can configure this option with the following cmd:
>config wlan flexconnect local-switching 17 enable
>config wlan flexconnect local-switching 17 ip-source-guard-dai enable
FlexConnect Local Switching................... Enabled
flexconnect local-switching IP-source-guar.... Enabled
Do you know if this is a feature that is going to work (I am wondering its in the code but maybe not supported yet), or should I still look to configure this on the swithport side and remove that config from the WLC.
Thanks for bringing that up! We actually have to correct our latest 7.5 configuration guide, as this security feature is now supported from 7.5 for FlexConnect local switching.
More likely they copied this section of the configuration guide (what you referenced stating this is not supported) from guides of previous releases where this was not supported, but this should be updated now on latest configuration guides. I will work on correcting that.
PS: Let me give you a tip.
If you ever find a feature that can be configured (over CLI or GUI), then this feature should be supported by the platform/software-version where you have the ability to use/enable it, unless the documentation (such as code release notes) clearly stays the feature is not supported on a specific platform, or not currently allowed/enabled but for future use.
Therefore, if you enable this feature on your 7.5 setup, and you notice that the security is not working as it should, then please open a TAC case so we can file a bug to get that fix, because the feature must work properly if you can enable it.