EAP Authentication Protocols
Posted by Chris on August 16, 2009
It looks like there could be a hefty dose of wireless on the CCNP ONT exam. In preparation for that I’ve spent the afternoon deep-diving into EAP authentication.
Cisco LEAP
We all know about the issues with WEP. In response to that, Cisco introduced LEAP. It overcame some of WEP’s vulnerabilities but was still highly susceptible to dictionary attack. (the publication of an LEAP exploit at DEFCON in 2003 didn’t help…)
Cisco’s response to that was to recommend the use of strong passwords (10 characters, alpha-numeric, mix of caps and lower-case, etc). Enforcing a strong password policy among end users is difficult at best so LEAP really wasn’t a good answer to WEP. (Not to mention the availability of a tool to exploit it’s vulnerability to dictionary attack) LEAP did have a number of benefits however and was fairly widely deployed.
EAP-FAST
In response to the vulnerabilities in LEAP, Cisco released EAP-FAST in 2004. Defined in RFC 4851, EAP-FAST offered a secure method to set up communication by using TLS to establish an authenticated tunnel.
While this mitigated most of the risk associated with LEAP, EAP-FAST had a vulnerability involving the interception of the PAC, which in turn could be used as the launching point for a dictionary attack.
EAP-TLS
Originally defined n RFC 2716 and updated in March of 2008 in RFC 5216, EAP-TLS is widely supported and offers excellent security. The downside of EAP-TLS is the client-side certificate requirement, making for a more labor intensive deployment, especially on a large scale.
PEAP
A joint proposal by Cisco, Microsoft and RSA Security, PEAP provides most of the security of EAP-TLS without the need for a client-side certificate. If you’ve deployed PEAP, it’s likely been PEAPv0/EAP-MSCHAPv2.
PEAPv1/EAP-GTC is an alternative offering token based authentication and is not supported in Windows.
