Convential wisdom says wireless LAN access to an enterprise adds enormous risk because the broken security model at the heart of Wi-Fi networking allows crackers to break encryption, snoop traffic, insert packets, and associate at will. WLAN access points must be outside the firewall, with VPN connections tunneling through. No exceptions.
Enter the Wi-Fi Alliance, with members that include Microsoft, Intel, Cisco and Apple. Seeking to quell consumer and enterprise concerns about Wi-Fi security holes, the group has essentially lifted the construction engineer’s drawings for the work-in-progress IEEE 802.11i security draft and started to pour and smooth the macadam that leads to the golden city on the hill: full 802.11i completion and ratification. This ad hoc engineering project comes with member approval; the move isn’t as radical as it seems.
The alliance’s new Wi-Fi Protected Access (WPA) standard uses most of the current 802.11i draft to repair problems in Wired Equivalent Privacy (WEP), the first line of defense for Wi-Fi networks. WEP’s goal was to encrypt packets in transit at the data link layer to deter unauthorised network access. WEP failed in its attempt, however, through several cryptographic flaws that resulted in rapid key reuse. These flaws leave the link layer unprotected by Wi-Fi and thus banished it outside the firewall where protection is provided at higher network layers by VPN, SSH, or other tunneled encryption methods.
WPA solves the problem by abandoning WEP in favour of 802.11i’s vastly improved TKIP (Temporal Key Integrity Protocol). WPA ensures that TKIP keys vary for each packet through key mixing. WPA also increases part of the keyspace and adds encrypted packet integrity to reject inserted packets.
Current Wi-Fi puts weak integrity outside the encrypted payload.
WPA includes full support for server-based authentication using the 802.1x protocol and Extensible Authentication Protocol (EAP), both part of the interim 802.11i draft.
802.1x defines the roles of a client (called the supplicant), the authentication pass-through component of an access point (the authenticator) and a back-end authentication server. EAP is a generic architecture for passing messages among parties that don’t necessarily need to understand the contents; in this case, the authenticator passes through some messages and interprets others.
A wireless supplicant first associates with an access point that has an integral authenticator or a connection via a LAN to a Radius-like system. The authenticator only allows access to itself via a single port; the supplicant has no access to the rest of the network. The authenticator challenges the supplicant for credentials — that could be a digital certificate or a username and password — and passes this information to an authentication server.
If access is approved, the authenticator hands over a unique per-supplicant master key from which the supplicant’s network adapter derives the TKIP key, the packet integrity key, and other cryptographic necessities. After a user has been authenticated, EAP is used to frequently refresh the master key, reducing the window of opportunity for intercepting packets for cracking. This rekeying process cleverly has perhaps more to do with the cryptographic future than the present.
Although EAP lacks a built-in encryption method — it’s merely a generic messaging method — three overlays that embed EAP inside an encrypted tunnel have emerged to solve different parts of the problem.
An early version, EAP-TLS (Transport Layer Security), required a client side public key certificate to be preinstalled before the first wireless session. Although this was the method that Microsoft uses for its campuswide WLAN, EAP-TLS is complicated because an enterprise must establish a PKI.
Instead, vendors are focusing on two methods: Extensible Authentication Protocol Tunneled TLS (EAP-TTLS) and Protected EAP (PEAP), both of which build a tunnel within a tunnel. The outer tunnel is entirely anonymous, allowing a second tunnelled session to begin inside it, which itself encapsulates EAP or other protocols. This approach avoids client certificates but still allows for them.
Microsoft and Cisco have backed PEAP. Although virtually identical in principle to EAP-TTLS, PEAP handles only EAP and MS-CHAP V2. Microsoft has offered PEAP clients for Windows XP and 2000 for free and plans a full Win32 rollout for Windows 98, NT 4, and Me.
Neither company representatives nor industry observers can explain the necessity for both EAP-TTLS and PEAP, the main difference between the two being the latter’s lack of legacy authentication support. It’s easy to assume that Microsoft and Cisco’s agenda was to push enterprises to upgrade to newer authentication servers, but PEAP could wind up as widely available as EAP-TTLS.
Both EAP-TTLS and PEAP are passing through the Internet Engineering Task Force (IETF) process toward hopeful reconciliation or at least standardisation. During this process, two man-in-the-middle attacks have been theorised that must be addressed before the standards can be deployed with absolute security.
One attack relies on supplicants performing authentication in the clear when asked to do so; the other attack lies in a lack of cryptographic binding between network layers. This allows a man-in-the-middle to spoof a network identity without detection.
All current support for 802.1x/EAP, tunneled or not, still relies on WEP as the link encryption method which means that a VPN is still required for definitive link security until WPA with TKIP starts appearing in access points and clients.
As we survey the road ahead, it’s clear that the arrival of WPA and eventually 802.11i will reduce the administrative burden of WLANs, integrating them with existing authentication mechanisms and making the security issue disappear.
Glenn Fleishman is author of The Wireless Networking Starter Kit and is based in the US. Contact him at firstname.lastname@example.org