If you are concerned about wireless LAN security, you should become familiar with 802.1X. This IEEE standard provides a framework for Ethernet switches, Wi-Fi access points, and other layer 2 bridges to control access to LAN ports and attached networks. In enterprise WLANs, 802.1X is the keystone that supports more robust airlink security measures.
For those anticipating 802.1X deployment, recent news is both good and bad. During the past month, broader product support has emerged for 802.1X. Unfortunately, new vulnerabilities have also been identified.
802.1X in a nutshell
For those new to 802.1X, here's a primer:
The 802.1X framework lets a "supplicant" (software running on an Ethernet or Wi-Fi station) request access from an "authenticator" (a switch or access point). The AP sends the station's identity to an authentication server in a RADIUS Access Request. Communicating through the AP, the RADIUS server and station negotiate and carry out authentication until the server accepts or rejects the Access Request. Only accepted stations are permitted to send data through the AP to the attached network (and vice versa). These authentication messages are carried by the Extensible Authentication Protocol (EAP). EAP was designed to replace PAP, CHAP and other specific dial authentication protocols with a flexible envelope that supports just about any kind of authentication. The 802.1X standard describes how to send and receive EAP over IEEE 802 LANs (EAPoL). To deploy 802.1X, you'll need to select an authentication method to be carried inside this EAPoL envelope. For example:
- EAP-MD5 is functionally similar to CHAP and should only be used over links where eavesdropping is unlikely. Because WLAN sniffing is rather easy, EAP-MD5 is inappropriate for use over Wi-Fi.
- EAP-TLS uses the Transport Layer Security (TLS) protocol to create an encrypted channel for negotiation and mutual authentication using digital certificates. TLS (the standard version of SSL) provides confidentiality and integrity, so using EAP-TLS over Wi-Fi is safe.
The IEEE 802.1X framework standard is complete, but EAP methods remain a hotbed of vendor innovation, Internet draft proposals, and vulnerability analysis. As a result, the tricky part of using 802.1X today is making sure that your stations, APs, and RADIUS servers all support a common EAP method.
Using 802.1X to deliver 802.11 crypto keys
The IEEE is developing 802.11i MAC security enhancements to the 802.11 base standard. 802.1X plays a crucial role in 802.11i. In addition to controlling BSS access at the AP, 802.1X provides a carrier for delivering crypto keys to authenticated stations.
Dynamic key delivery overcomes a gaping hole in the 802.11 base standard. Without a mechanism for key delivery, the crypto keys used by 802.11 Wired Equivalent Privacy (WEP) must be statically configured into all stations connected to the same AP. Because stations use these shared keys directly for encryption, every station can decrypt every other station's data. Considerable traffic gets encrypted with the same key over long periods of time, making the WLAN vulnerable to lost or cracked keys.
802.11i uses 802.1X to deliver session keys from the AP to the station. If encryption keys were simply sent over an unencrypted airlink, security would be compromised. Therefore, 802.1X supplies keying material that the station and AP use to derive encryption keys. According to presentations by Dorothy Stanley (Agere) at the December 802.11-Planet conference, two master keys are delivered to the station:
- A Pairwise Master Key is used to derive base keys that provide confidentiality and integrity for data sent and received between this station and AP only.
- A Group Master Key is used to derive base keys that provide confidentiality and integrity for broadcast frames. All stations share the AP's Group Master Key.
- Depending upon the EAP method, the PMK may be delivered over an encrypted TLS tunnel. In addition to deriving keys for data protection, the PMK is used to derive base keys that protect EAPOL Key messages.
- For data encryption, per-packet keys are generated by mixing the base key with the transmitter's MAC address and an initialization vector in two phases. With this method, over 500 trillion frames can be sent without reusing the same key.
The 802.11i draft specifies a Temporal Key Integrity Protocol (TKIP) and a Message Integrity Code (MIC) used for encrypting data and detecting forgery. These techniques are only as secure as the crypto keys they use. This is why it is so important to use 802.1X with an EAP method that provides for secure key delivery.
So what happens when 802.1X is absent? Shared secrets can still be used as master key inputs to the mixing functions described above. Shared secrets do not provide the same scalable, robust security as dynamic session keys, but they can be a practical alternative in small WLANs that lack 802.1X RADIUS infrastructure. Unlike shared WEP keys, shared secrets are not used directly for encryption -- this is a big improvement. However, they must still be kept secret, in much the same way that you guard your passwords.
PEAPing into the future
When Windows XP was released in the fall of 2001, it included support for wireless LANs. Among other things, XP contained an 802.1X supplicant that implements EAP-MD5 and EAP-TLS. Since EAP-MD5 is of little use in WLANs, focus on EAP-TLS. Because EAP-TLS requires mutual certificate authentication, using it means issuing certificates to every Windows XP station in your WLAN.
For large enterprises that already issue certificates to every employee/laptop, EAP-TLS can be a strong solution to prevent unauthorized WLAN access. For the rest of us, deploying client-side certificates may require more effort and expense than desired. Fortunately, there are EAP methods that support other client-side credentials:
- Last year, Cisco shipped 802.1X with the Lightweight EAP (LEAP). This proprietary protocol provides easy-to-deploy mutual password authentication. Unfortunately, it is also vulnerable to dictionary attack. A "man in the middle" can capture traffic, identify your password, and then use it to access your WLAN.
- To eliminate this risk but still avoid client certificates, Funk and Certicom proposed EAP-TTLS (Tunneled TLS). With this method, the Authentication Server uses a certificate to establish the TLS tunnel. Existing client credentials (for example, Windows login/password) can then be sent to over the encrypted tunnel to authenticate the station. Authentication protocols like PAP, CHAP, and EAP are carried as RADIUS attribute/value pairs over TLS.
- Microsoft, Cisco and RSA proposed another alternative called Protected EAP (PEAP). PEAP is conceptually very similar to EAP-TTLS, but sends only EAP over the TLS tunnel. Phase 1 PEAP creates the TLS tunnel, then Phase 2 PEAP uses the tunnel to carry out a complete EAP authentication. PEAP can be used with any kind of authentication carried by EAP, including mutual certificate authentication and client-side password authentication.
These methods are attractive from an ease-of-deployment perspective. The catch is that each method requires supplicant software that is compatible with the client's operating system and wireless network adapter. Most companies need to support a mixed bag of wireless laptops and PDAs. EAP-TTLS clients from Funk and Meetinghouse can be installed on Win32 platforms -- but what if you need *NIX or Mac OS clients? EAP-TLS has been around longer and has been more broadly implemented. You could deploy multiple EAP methods -- but this could quickly become nasty tangle of administrative complexity.
Ubiquity is the key
A decade ago, getting on-line required installing third-party software on every desktop and server. When vendors started bundling TCP/IP as a core operating system service, the floodgates opened. Small business and residential users started jumping onto the World Wide Web without IT staff or networking expertise.
This same ubiquity is necessary to kick-start widespread 802.1X deployment. An 802.1X supplicant must be included in every OS, along with broadly interoperable EAP methods that support the kinds of credentials required by business WLANs.
There are promising signs that ubiquity is coming. This summer, Microsoft added PEAP to Windows XP in Service Pack 1. In December, it released a Windows 2000 (Service Pack 3) 802.1X Authentication Client that supports both EAP-TLS and PEAP. Microsoft also announced 802.1X Authentication Client packages for Windows 98, ME, and NT 4.0 Workstation, available to customers with support contracts. Along with planned 802.1X support in .NET, this pretty much covers Windows desktops and laptops used by businesses today.
Microsoft has not yet issued a statement about 802.1X for Windows CE (Pocket PC) PDAs. However, Socket announced that its Low-Power Wireless LAN CompactFlash card for Pocket PC will support 802.1X with EAP-TLS and PEAP in software to become available in January.
What about non-Windows clients? Meetinghouse has announced PEAP support for its AEGIS clients on Win32 platforms, but methods are more limited for Linux (EAP-TLS and MD5) and Mac OS X (EAP-MD5 only). Cisco's client supports PEAP on Windows XP, but supports only LEAP on Windows CE, Mac OS, Linux, and MS-DOS. Open1x, an open source implementation of 802.1X for FreeBSD, OpenBSD, and Linux, only supports EAP-TLS at this time. Clearly, you can find 802.1X for these platforms, but OS integration seems further away than for non-Windows platforms.
Of course, you'll also need compatible APs and RADIUS Servers. Microsoft IAS and Cisco ACS RADIUS servers both support PEAP today. RADIATOR is available in early release with PEAP support. In October, Interlink released Secure.XS with support for EAP-TLS, TTLS, and LEAP, with "soon to be shipped" PEAP. In November, Meetinghouse announced plans to support PEAP in addition to current support for EAP-TLS, TTLS, and LEAP. Once PEAP is present on every Win32 desktop, market pressure will probably lead other RADIUS vendors to support it.
Not so fast
Of course, that's assuming the market converges on PEAP for WLAN authentication. Vendors may be scrambling to release PEAP, but debate over EAP methods is far from over.
New EAP methods are still being proposed. For example, EAP-SIM uses the GSM Subscriber Identity Module (SIM) and standard GPRS Security and Mobility Management (GMM) messages. This method would be used within a secure tunnel established using another EAP method like EAP-TTLS or PEAP. If another EAP method must be used, what does EAP-SIM add? Consistent authentication for devices that roam between wireless LANs (802.11) and wireless WANs (GPRS/UMTS). Network usage could be accounted for and billed by carrier systems that use SIMs to identify wireless devices, independent of the access method used.
Additional EAP methods now being debated include EAP-GSS (integration with authentication mechanisms using the GSS API) and EAP-AKA (another EAP method for use in UMTS environments). It is not completely clear where EAP methods should be standardized. The IEEE is responsible for specifying 802.1X, but not EAP. The IETF EAP working group is responsible for specifying extensions to EAP itself (for example, an EAP state machine and keying framework) but is not currently chartered to standardize EAP methods. At least for now, vendors and consumers are left to sort through various proposals, evaluate security claims, and try to make informed decisions about which EAP method(s) to adopt.
This debate has prompted rigorous analysis of EAP method proposals, helping to bring vulnerabilities to light before products can be exploited in the field. For example, new reports surfaced this fall about vulnerabilities in EAP-TTLS and PEAP. These methods (and several others) create a secure tunnel, then use that tunnel to protect a legacy authentication protocol. The breach occurs if the client is tricked into starting phase two and sending its identity or credentials without the protection of the TLS tunnel. Another man-in-the-middle vulnerability has been identified when the Authentication Server is not the TLS endpoint (i.e., when EAP is proxied from an 802.1X-enabled authentication server to another legacy server). To learn more about these risks and potential solutions, see research published in October and November by Nokia, Intel and Microsoft.
802.1X and EAP may still be evolving, but that doesn't mean you should wait to use it. Despite known risks, 802.1X can provide your WLAN with stronger access control and dynamic key delivery. When used to enable new privacy and integrity measures like TKIP and MIC, 802.1X can help you build wireless LANs that are far more secure.
Enterprise WLAN operators should begin 802.1X trials now. For example, identify network segments and user communities that are at greatest risk, enabling 802.1X as an option. You may be able to combine limited deployment with VLAN tags to give 802.1X-enabled WLAN users broader privileges than other users. Start small, gain experience to plan for broader deployment, and keep a sharp eye out for new EAP methods and software/firmware patches. Don't expect 802.1X and EAP to be a silver bullet – but you might as well add this weapon to your growing WLAN security arsenal.
Do you have comments about this article, or suggestions for Lisa to write about in future columns? Let us know!