It’s more than two years since the 802.11i draft started doing the rounds but it’s nearly there. 802.11i provides for extra security for WEP, which, as we know all too well from all the scare stores we see every time we open an IT journal, has some serious security weaknesses.

Various additional authentication and encryption protocols have been developed (see

TKIP
802.11i includes two encryption enhancements: AES and TKIP. Let me come back to AES in a moment.

TKIP, the Temporal Key Integrity Protocol, is a set of software-based enhancements to RC4, the cipher written by RSA and used by WEP (and many other protocols, including SSL). Basically, TKIP is made up of two components, Per-Packet Keying (PPK) and the Message Integrity Check (MIC).

PPK is the resolution to the problem that WEP uses weak initialisation vectors when calculating its keys, so that eavesdroppers can quite easily recover the key and decrypt the data. PPK specifies a way of using a different key for every packet. The initialisation vector and WEP key are hashed to produce a unique packet key (called a temporal key), which is then combined with the initialisation vector and run through a mathematical function. PPK on its own isn’t perfect though, as you really still need to change the base key regularly to mitigate against the reuse of initialisation vectors, which can be done using EAP mechanisms.

The MIC is designed to protect wireless frames being captured, tampered with and replayed. It’s basically a better check than the CRC-32 checksum used in standard WEP, which can be pretty easily tweaked to make a modified message appear to still have the correct checksum. The MIC algorithm is more sophisticated and is included within, and therefore protected by, the encrypted payload. It’s not the strongest integrity checker available but it is one that can be added to existing equipment without the need for hardware upgrades.

In fact, although pre-standard, Cisco, for one, offers TKIP functionality on its EAP and derivative (LEAP, PEAP) protocols. And a subset of 802.11i (as close as can be approximated to a non-finalised standard) is what makes up the Wi-Fi Alliance’s WPA (Wi-Fi Protected Access), which requires 802.1X with EAP for authentication and TKIP PPK plus MIC for encryption for compliance.

AES
Also part of the 802.11i specification, though, will be AES (See PDF file
here, the US official encryption standard, set by the National Institute of Standards and Technology, (NIST), as successor to the DES/3DES algorithms. AES is a stronger alternative to WEP’s RC4, with 128, 192 or 256 bit keys. 128 bits has been selected for use in 802.11i.

However, since AES is more resource-intensive, you may find that if you want full 802.11i compliance, you will have to replace your existing wireless hardware. AES is a more long term plan - with WPA and individual vendors’ own implementations of TKIP/EAP satisfying most of our security worries. It’s unlikely everyone’s going to rush to start implementing AES if it means they need to buy new access points, which probably won’t be available till some time after the .11i standard is published anyway.

A bit like the Power Over Ethernet story, it looks like we’ll be using close-to-but-not-quite-standard hardware for quite a while until the next generation of kit is released. Maybe if it hadn’t taken almost two and a half years to get the standard out the door, everyone wouldn’t have come out with their own alternatives that seem to do the job pretty nicely, right now, thank you.

Oh, and one other thing - although 802.11i doesn’t specifically define a version of EAP to use along with TKIP, it’s looking like EAP-TLS is its preferred version. Remembering that EAP-TLS requires digital certificates to be installed, not just on your AAA server but also every client device that requires access, this may be one idea from the standards body that won’t get that far.