802.11i Strengthens Wi-Fi Security

802.11i is ready to bring new security to wireless computing, but the costs of retrofitting legacy hardware might make for an uneasy migration.

With the recent ratification of 802.11i, and the certification and availability of products enabled for the wireless security specification, the time seems right for enterprises to feel safe in adopting wireless networking en masse. However, eWEEK Labs has found that issues ranging from incompatible legacy hardware to uneven migration strategies may slow adoption of 802.11i technology.

To be sure, 802.11i is a huge step forward—its the first standardized wireless security solution with which government and businesses can be comfortable.

/zimages/5/28571.gifClick here for suggested migration strategies.

Built upon strong AES-CCMP (Advanced Encryption Standard-Counter Mode/ CBC-MAC Protocol)-based encryption, 802.11i avoids the IV (initialization vector) and MIC (Message Integrity Check) flaws that doomed the WEP (Wired Equivalent Privacy) security standard. By relying on AES-CCMP, a block cipher, 802.11i ensures not only that the packet data payload is encrypted but also that selected packet header fields are protected.

802.11i includes a complex series of communications and key exchanges designed to mutually authenticate wireless clients and access points and to reduce as much as possible the impact on back-end authentication systems.

In response to a requesting clients probe, an 802.11i-enabled access point responds with an RSN (Robust Secure Network) Information Element that advertises the networks enabled authentication suites and ciphers. The client then selects a mutually compatible setting and initiates an open system authentication to the access point, which verifies the compatible settings and completes the association request. At this time, 802.1x authentication begins.

Similar to WPA (Wi-Fi Protected Access)—a stopgap solution based on Draft 3 of the 802.11i specification—802.11i provides port-based authentication to a RADIUS server to provide user authentication. However, 802.11i streamlines WPAs key exchange process among the client, access point and authorization server by requiring fewer messages.

Once a user has successfully authenticated to the RADIUS server, the authentication server creates a PMK (pairwise master key) that is moved to the access point and then exchanged with the client. This key controls both devices access to the 802.11 channel (no matter which band) and is used to derive the PTK (pairwise transient key), which is actually a collection of keys that help mutually identify the devices and secure the data traffic.

The PMK is unique to the client/access point conversation, so the 802.1x authentication process must occur again when a client roams to a new access point. Because the authentication process causes some latency, devices running time-sensitive applications may falter during a roam.

/zimages/5/28571.gifClick here to read about PKC, which lets clients roam among access points using a single master key in order to prevent secure wireless LANs from getting sluggish.

The 802.11r task group is working on a fast-roaming amendment to the 802.11 wireless specification, but the 802.11i security specification also includes some optional components that may alleviate roaming latency.

For example, with PMK caching, clients and access points may indicate that they have cached a PMK from a previous association. If both the access point and client have the PMK cached, the client may skip a full 802.1x authentication.

Another optional 802.11i component for alleviating roaming dropouts is pre-authentication, where a client authenticates to access points within range in the background while maintaining an association with another access point. However, vendor support may be limited.

802.11i also offers scaled-down security for small networks without a RADIUS server. Based on a preshared key that must be configured identically on the client and access points, this method is potentially vulnerable to offline dictionary attacks if the key is too short or is not changed often enough, and there is no provision for user-level authentication.

Next page: Slow adoption.