However, some are also warning that 802.11i is not an all-purpose security guarantee that covers all the bases. This may depend on security needs, which vary between different users and usage scenarios, but the bottom line is this: 802.11i isn’t the last word in securing a WLAN. Enterprises in particular need to be aware of other security issues not covered by 802.11i, like viruses, DoS attacks and Rogue Access Points – the latter of which allegedly can be used to thwart 802.11i.

Implementation issues

802.11i addresses a specific part of the Wi-Fi network: the link between the terminal and the access point. Specifically, 11i addresses two key security issues within that link: over-the-air encryption and mutual authentication between the client and the network. The new standard uses AES (Advanced Encryption Standard) encryption and 802.1x, an IEEE standard for port-based authentication. The Wi-Fi Alliance’s WPA solution, based on a draft of 802.11i, addressed the same two issues, but did so with TKIP (temporal key integrity protocol), which uses the comparatively weaker RC4 encryption algorithm rather than AES, which to date has yet to be successfully attacked.

802.11i also includes lesser-known features such as key caching, which allows an authenticated device to leave and return to an AP without having to reauthenticate itself by storing authenticated key info on the network. Devices can also be pre-authenticated on a different access point, which allows users to roam from one AP to another without having to go through the authentication process every time.

However, for all the new features 802.11i brings to Wi-Fi, it does come with certain implementation issues. For one thing, there’s interoperability. The Wi-Fi Alliance plans to certify 802.11i-compliant products under the moniker WPA2, but the program just started in September 2004, and interoperability testing typically takes several months.

Interoperability will be a major issue in how quickly 802.11i is adopted.  WPA2 will guarantee that products from multiple vendors will interoperate.

That may not be easy. One of the downsides of using 802.1x for authentication is that it’s used in conjunction with EAP (extensible authentication protocol), which is flexible enough to support a number of alternate authentication types over 802.1x. This lack of a single standard could mean interoperability problems for 802.11i in the near term.

There’s also a question of upgrades for existing WLANs. WPA was a software upgrade; WPA2 is too, but only if your legacy Wi-Fi hardware can handle AES.

The product has to be able to support AES, and not all of existing deployed WLANs can do that.  So the migration path depends on what the legacy equipment can support. If you have a legacy device that doesn’t support AES, you can upgrade to WPA, which is a software upgrade. If your device can support AES, you can upgrade to WPA2.

The hardware issue is likely to affect mainly early adopters. Vendors like Cisco, Proxim and Trapeze already sell Wi-Fi equipment that can support AES.

Bridging the 802.11i gap

Another issue that enterprises must keep in mind is that certain security issues extend beyond 802.11i’s mandate.  For example

802.11i covers encryption and authentication, but it doesn’t cover things like RF jamming or denial-of-service attacks.

802.11i also does not address other issues like, is the authenticated user on a corporate laptop that has virus control, or are they on some random laptop that is infected with all sorts of things.

Rogue (i.e. unauthorized) access points as another security issue that 802.11i doesn’t address. This is typically done by employees who just want to get access to wireless capability, but aren’t aware of the serious security risks they create for their company as these APs typically have no security mechanisms turned on.

No one is arguing that 802.11i should be able to deal with all these things, just that there is more to WLAN security than replacing WEP, and that enterprises should keep this in mind when they upgrade to 802.11i.

Fortunately for enterprises, security countermeasures exist for each of the above examples. Even before 802.11i was ratified, enterprises have already employed a number of security strategies to protect their WLANs.

Among larger enterprises, security strategies currently consist of VPNs, personal firewalls, and wireless demilitarized zones.

Service providers like iPass also offer additional security strategies for enterprises worried about WLAN security issues at hot spots outside the office.

For example, an IT manager might specify that they want to make sure the firewall and the VPN are running, and the anti-virus software is up to date before the employee is allowed to connect, and to tear down the connection if it’s not.

Where to keep the keys

But while 802.11i fits nicely into the overall security chain, some argue that it’s not entirely foolproof.

While 802.11i delivers the strong encryption previously missing from wireless LANs, it isn’t the holy grail that the wireless industry has been desperately seeking.  Serious concerns still exist regarding the exchange of encryption keys that are flying around corporate networks, completely unprotected.

The concerns revolve around whether the encryption keys should be stored in the APs or in a central WLAN switch – which 802.1x doesn’t dictate.

802.1x tells you how to do authentication on a LAN, but it doesn’t tell you where.

Some favor of a centralized approach, to get around the problem of AP upgrades.

A central programmable controller and switching system that provides services to multiple APs provides investment protection to early adapter as well as giving increasing time-to-market with new features such as 802.11i.  This is because manufactures don’t need to wait for radio suppliers to release new drivers.

Keeping the keys in the AP is a potential security risk if an access point is lost or stolen, or if the encryption keys are otherwise intercepted or redirected.

Centralized architectures add an extra margin of safety no matter what security policy and technologies an enterprise adopts.

Controversially, this point was illustrated further by a demonstration at a Internet Engineering Task Force (IETF) meeting in San Diego in August 2004 that a way to beat 802.11i by targeting the RADIUS server has already been found .

The attack would require someone to attach a rogue AP to the internal LAN, sniff traffic between the AP and the gateway, and then send a deauthentication packet to a client. When the client reauthenticates – during which the access point sends a request to the RADIUS server, which passes the encrypted keys back to the AP – the hacker can perform an offline dictionary attack to get the shared secret from the RADIUS server.

Such an attack could be thwarted by storing the encryption keys centrally rather than on the APs.

Fighting the rogues

However, while such an attack is possible, it exploits a fault in the RADIUS server, not 802.11i itself.

There are existing ways to protect against rogue APs, which is required for the attack to work.

Wi-Fi gear today has the ability to detect rogue APs.

The software in Proxim AP-4000 access point automatically scans both the 2.4 and 5 GHz RF spectrum for all Wi-Fi clients and access points and reports this back to our wireless LAN network management system, which can then compare the reported clients and APs with an authorized list, adding that the management system can also check the wired portion of the LAN to locate rogue APs – which is handy if the enterprise doesn’t have a Wi-Fi network in the first place.

The same technique can also determine if a suspicious AP is rogue or foreign, she adds. “A rogue AP is plugged into the enterprise’s network, versus a foreign AP which is typically in a neighboring building or floor.”

802.11’s use of 802.1x can help protect against rogue APs.

Requiring 802.1x everywhere – wired as well as wireless – would help with the rogue access point problem as no one would be able to put their own AP into the wired network, it wouldn’t be able to authenticate.