Understanding the updated WPA and WPA2 standards

If the challenge of securing a wireless LAN wasn’t already confusing enough, things have just gotten worse.  The confusion started last month when the Wi-Fi Alliance changed the WPA and WPA2 standards from supporting a single EAP (Extensible Authentication Protocol) standard to five EAP standards.  Although this has broadened the WPA/WPA2 standards to be more inclusive, the decision of the Wi-Fi Alliance to not rename the updated WPA and WPA2 standards is causing mass confusion within the IT industry.  This could have been avoided if the Wi-Fi Alliance had named the updated standards "WPA + Extended EAP" and "WPA2 + Extended EAP" because it would make it easy to differentiate between old WPA/WPA2 certified products from the newer WPA/WPA2 certified products that will support five EAP types instead of one.  In my previous story, where Gartner issued a false alarm on Microsoft’s new WPA2 patch that led to a rash dire warnings from the press, I tried to provide some proper context to the situation.  Because the story touched on the complex topic of EAP (Extended Authentication Protocol) standards, it raised more questions than answers for the average reader who wanted to know what the heck are all these EAP standards in relation to the WPA/WPA2 standard.  This article provides an in-depth look at the WPA/WPA2 standard and the five EAP standards currently certified by the Wi-Fi Alliance.
The WPA and WPA2 standards were created by the Wi-Fi Alliance industry group that promotes interoperability and security for the wireless LAN industry.  The Wi-Fi Alliance WPA and WPA2 standards closely mirrors the official IEEE 802.11i wireless LAN security standards group but incorporates additional IETF EAP standards that the Wi-Fi Alliance considers secure.  The WPA and WPA2 standards have two components (encryption and authentication) that are crucial to a secure wireless LAN.  The encryption piece of WPA and WPA2 mandates the use of TKIP or, because it’s considered to be more secure than TKIP, preferably AES encryption.  From an encryption standpoint, WPA leaves AES optional while WPA2 mandates both TKIP and AES capability.  The authentication piece of WPA and WPA2 before the Extended EAP update called for the use of a PSK (Pre-Shared Key) for personal mode and EAP-TLS for enterprise mode.  After the Extended EAP update, there are now five EAP standards to choose from in WPA and WPA2 enterprise mode.

Note:  Besides the stricter encryption requirements, WPA2 also adds two enhancements to support fast roaming of wireless clients moving between wireless access points.  PMK (Pair-wise Master Key used for each session between an access point and wireless client) caching support in WPA2 allows you to reconnect to an access point that you’ve recently connected to without the need to re-authenticate.  Pre-authentication support in WPA2 allows a client to pre-authenticate with the access point toward which it is moving, while maintaining a connection to the access point it’s moving away from.  This new capability allows the roaming to occur in less than 1/10th of a second while a traditional roam without PMK caching and pre-authentication would take more than one second.  Timing-sensitive applications like Citrix, video, or VoIP will all break without fast roaming.

To give you some historical context on some significant EAP types, EAP-TTLS and PEAP were primarily created because the original EAP-TLS standard was deemed too difficult to deploy because of the need for a server-side x.509 digital certificate on the RADIUS authentication server and a client-side x.509 digital certificate on each and every client computer that needed to connect to the wireless LAN.  While the server-side certificate requirement wasn’t so bad because there are usually only a few RADIUS servers that need certificates, the client-side requirement was cause for major concern due to their sheer numbers.  Because the client-side certificate required a PKI server infrastructure (rare for most organizations) to be in place ahead of time or expensive third-party certificates, it automatically excluded EAP-TLS as a feasible option for most organizations and forced them into using less secure forms of EAP such as Cisco’s proprietary LEAP.  EAP-TTLS and PEAP were created to eliminate the need for client-side certificates but still leverage the server-side certificate to create a secure TLS tunnel to protect the "inner authentication methods" such as EAP-MSCHAPv2 and EAP-GTC from eavesdropping and offline dictionary and brute force attacks.  Conceptually, this works just like e-commerce security with SSL-enabled web sites where a web server’s server-side certificate is leveraged to create a secure SSL tunnel even though the visitors to the secure web site don’t have client-side digital certificates.
The current WPA/WPA2 certified EAP standards are:

• EAP-TLS (originally certified protocol)
• EAP-TTLS/MSCHAPv2
• PEAPv0/EAP-MSCHAPv2
• PEAPv1/EAP-GTC
• EAP-SIM

EAP-TLS is the original wireless LAN EAP authentication protocol.  Although it’s rarely implemented due to a steep deployment curve, it is still considered one of the most secure EAP standards available and is universally supported by all manufacturers of wireless LAN hardware and software including Microsoft.  The requirement for a client-side certificate, however unpopular it may be, is what gives EAP-TLS its authentication strength.  A compromised password is not enough to break into EAP-TLS enabled systems because the hacker still needs to have the client-side certificate.  When the client-side certificates are housed in smartcards, this offers the most secure authentication solution available because there is no way to steal a certificate from a smartcard without stealing the smartcard itself.  Any physical theft of a smartcard would be immediately noticed and revoked and a new smartcard would be issued.  Up until last month, this was the only EAP type vendors needed to certify for a WPA or WPA2 logo.  There are client and server implementations of it in Microsoft, Cisco, Apple, Linux, and open source.  EAP-TLS is natively supported in MAC OS 10.3 and above, Windows 2000 SP4, Windows XP, Windows Mobile 2003 and above, and Windows CE 4.2.

Note:  Although Windows 2000 supports EAP-TLS and PEAPv0/EAP-MSCHAPv2 authentication, it does not support WPA or WPA2 encryption, while all of the other newer operating systems mentioned support WPA.  Windows XP with Service Pack 2 and the new WPA2 patch is currently the only operating system that natively supports WPA2.

EAP-TTLS was created by Funk software and Certicom and is primarily backed by Funk software and is supported by other third-party server and client software.  Although it’s a fine protocol and even better than PEAP in some ways, it isn’t supported natively in Microsoft Windows clients such as Windows 2000, XP, Mobile 2003, or CE.  Support on the server side is also lacking in Microsoft Windows 2003 server and Cisco ACS (Access Control Server).  Where EAP-TTLS shines over PEAP authentication is that the username is not revealed in clear-text, which might avoid some DoS (Denial of Service) attacks where someone can maliciously log-in repeatedly with the right username and wrong password to lock out that user’s account.  PEAP authentication only protects the password portion with a strong TLS tunnel but broadcasts the username in the clear.  I’ve seen tools that have implemented this form of attack, but have never seen it used in the wild since it would mostly just annoy people and bring unwanted attention to a hacker.
PEAPv0/EAP-MSCHAPv2 is the technical term for what people most commonly refer to as "PEAP".  Whenever the word PEAP is used, it almost always refers to this form of PEAP since most people have no idea there are so many flavors of PEAP.  Behind EAP-TLS, PEAPv0/EAP-MSCHAPv2 is the second most widely supported EAP standard in the world.  There are client and server implementations of it in Microsoft, Cisco, Apple, Linux, and open source.  PEAPv0/EAP-MSCHAPv2 is natively supported in MAC OS 10.3 and above, Windows 2000 SP4, Windows XP, Windows Mobile 2003 and above, and Windows CE 4.2.  The server side implementation of PEAPv0/EAP-MSCHAPv2, called IAS (Internet Authentication Service), is also included in Windows 2003 server.  PEAPv0/EAP-MSCHAPv2 enjoys universal support and is known as the PEAP standard.
PEAPv1/EAP-GTC was created by Cisco as an alternative to PEAPv0/EAP-MSCHAPv2.  It allows the use of an inner authentication protocol other than Microsoft’s MSCHAPv2.  Even though Microsoft (along with RSA and Cisco) co-invented the PEAP standard, Microsoft never added support for PEAPv1 in general, which means PEAPv1/EAP-GTC has no native Windows OS support.  Since Cisco has always favored the use of its own less secure proprietary LEAP and EAP-FAST protocols over PEAP and markets them as simpler certificate-less solutions, standardized PEAP is rarely promoted by Cisco.  Cisco stands to gain a monopoly in the access point market if LEAP or EAP-FAST is universally adopted.  As a result, most Cisco customers run the less secure and proprietary LEAP or EAP-FAST authentication protocols because they’ve swallowed the Cisco Kool-Aid.  With no interest from Microsoft to support PEAPv1 and little interest from Cisco to promote PEAP in general, PEAPv1 authentication is rarely used.  There is no native OS support for this EAP protocol.

Note: The PEAP standard was created by Microsoft, Cisco, and RSA after EAP-TTLS already had already come on the market.  Even with its late start, Microsoft’s and Cisco’s size allowed them to quickly overtake EAP-TTLS in the market.  Microsoft and Cisco parted ways when Microsoft only supported the PEAPv0 standard while Cisco supported both PEAPv0 and PEAPv1.  PEAPv0 and PEAPv1 both refer to the outer authentication method and is the mechanism that creates the secure TLS tunnel to protect subsequent authentication transactions while EAP-MSCHAPv2, EAP-GTC, and EAP-SIM refer to the inner authentication method which facilitates user or device authentication.  From Cisco’s perspective, PEAPv0 supports inner EAP methods EAP-MSCHAPv2 and EAP-SIM while PEAPv1 supports inner EAP methods EAP-GTC and EAP-SIM.  Since Microsoft only supports PEAPv0 and doesn’t support PEAPv1, Microsoft simply calls PEAPv0 PEAP without the v0 or v1 designator.  Another difference between Microsoft and Cisco is that Microsoft only supports PEAPv0/EAP-MSCHAPv2 mode but not PEAPv0/EAP-SIM mode.  However, Microsoft supports another form of PEAPv0 (which Microsoft calls PEAP-EAP-TLS) that Cisco and other third-party server and client software don’t support.  PEAP-EAP-TLS does require a client-side digital certificate located on the client’s hard drive or a more secure smartcard.  PEAP-EAP-TLS is very similar in operation to the original EAP-TLS but provides slightly more protection due to the fact that portions of the client certificate that are unencrypted in EAP-TLS are encrypted in PEAP-EAP-TLS.  Since few third-party clients and servers support PEAP-EAP-TLS, users should probably avoid it unless they only intend to use Microsoft desktop clients and servers.  Ultimately, PEAPv0/EAP-MSCHAPv2 is the only form of PEAP that most people will ever know.  PEAP is so successful in the market place that even Funk Software, the inventor and backer of EAP-TTLS, had no choice but to support PEAP in their server and client software for wireless networks.

EAP-SIM was created for the GSM mobile telecom industry, which favors the use of SIM cards for authentication.  The Wi-Fi Alliance is trying to broaden support beyond the conventional wireless LAN, but the typical IT director probably doesn’t care too much about it because it isn’t something they would use.  There is no native OS support for this EAP protocol.
The bottom line is that the current WPA2 standard is now fully mature and provides rock solid wireless LAN security.  WPA2 provides solid military grade encryption and a broad choice of strong to strongest authentication protocols.  EAP-TLS and PEAPv0/EAP-MSCHAPv2 with universal platform support are the de facto EAP standards in wireless LAN authentication.  PEAPv0/EAP-MSCHAPv2 provides strong single-factor security while EAP-TLS provides the strongest two-factor authentication scheme in wireless LAN security.