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—it's the first standardized wireless security solution with which government and businesses can be comfortable.

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 client's probe, an 802.11i-enabled access point responds with an RSN (Robust Secure Network) Information Element that advertises the network's 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 WPA's 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.

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.

802.11i technology is attracting much interest, but few companies have embarked on widespread deployments at this time. With myriad deployment complexities and the hardware costs involved with deploying 802.11i, actual adoption of the technology may crawl before it walks, despite the marketing claims we hear that wireless security is "solved" with 802.11i.

Many vendors began shipping AES-capable products intended to work with 802.11i well before the specification was approved by the IEEE. However, the Wi-Fi Alliance only started 802.11i certification testing in September, with the first products bearing WPA2 certification—the Wi-Fi Alliance moniker for interoperability certification for a subset of 802.11i features—in October.

However, the computational overhead from AES encryption means many legacy access points and client hardware devices may not be upgradable to 802.11i. As a rule of thumb, we've found that access points that currently support 802.11g and 802.1x will likely be firmware-upgradable to 802.11i. Administrators should check with their vendors' Web site for more information.

For client hardware, we focused our investigation on Wi-Fi clients embedded in laptop computers, a model that has become increasingly common during the last few years.

Intel Corp.'s 802.11b/g and a/b/g adapters (Intel Pro/Wireless models 2200 and 2915) will support WPA2. Dell Inc. and Hewlett-Packard Co. offer 802.11i-enabled drivers for these adapters on their support Web sites, and IBM expects to add WPA2 via its Access Connections software this quarter. However, it appears unlikely that Intel's 802.11b-only embedded adapters (Intel Pro/Wireless 2100) will be upgradable to 802.11i.

We've also found only a limited number of client supplicants that will work with 802.11i. Funk Software Inc.'s Odyssey client and the Intel ProSet application both work well, but Microsoft has not announced when its WPA2 supplicant will be available.