Thus, the main hope of the international 802.11 community and network administrators lies with the 802.11i standard development. Sometimes 802.11i is referred to as the Robust Security Network (RSN) as compared to traditional security network (TSN). The "i" IEEE task group was supposed to produce a new wireless security standard that should have completely replaced legacy WEP by the end of 2003. In the meantime, some bits and pieces of the incoming 802.11i standard have been implemented by wireless equipment and software vendors to alleviate known 802.11 vulnerabilities before 802.11i is out. Wireless Protected Access (WPA) Certification promoted by the Wi-Fi Alliance (http://www.wi-fialliance.org/OpenSection/Protected_Access.asp) is a subset of the current 802.11i draft and is technically very similar to the current 802.11i advancements. Some of the 802.11i developments not included in the current WPA specification include secure ad-hoc networking, secure fast handoff, secure deauthentication and deassociation, and to use of the AES encryption algorithm. As the 802.11i standard gets released, WPA will be upgraded to WPA2, implementing the final 802.11i security features.

802.11i architecture can be divided into two "layers": encryption protocols enhancements and 802.11x port-based access control protocol.

Introducing the Sentinel: 802.1x

The 802.1x standard (http://standards.ieee.org/getieee802/download/802.1X-2001.pdf) was initially designed to provide Layer 2 user authentication on switched wired networks.

On WLANs, 802.1x has the additional functionality of dynamic key distribution. Such functionality is supplied by the generation of two key sets. The first set is session or pairwise keys that are unique for each association between a client host and the access point. Session keys provide for the privacy of the link and remove the "one WEP for all" problem. The second set is group or groupwise keys. Groupwise keys are shared among all hosts in a single 802.11 cell and are used for multicast traffic encryption. Both session and pairwise keys are 128 bits in length. Pairwise keys are derived from the 256-bit-long pairwise master key (PMK). The PMK is distributed from the RADIUS server to each participating device using the RADIUS MS-MPPE-Recv-key attribute (vendor_id=17). In a similar manner, groupwise keys are derived from the groupwise master key (GMK). When deriving these keys, the PMK or GMK is used in conjunction with four EAPOL handshake keys, also referred to as the pairwise transient key.

In SOHO environments or home networks the deployment of a RADIUS server with an end-user database is an unlikely event. Thus, only the preshared (manually entered) PMK is used to generate the session keys. This is similar to the original WEP use.

Because there are no physical ports on 802.11 LANs, the association between the wireless client device and the access point is considered to be a network access port. The wireless client is designated as the supplicant (peer) and the AP as the authenticator. Thus, in 802.1x standard definitions, the access point takes the position of an Ethernet switch on the wired LANs. Obviously, there is a need for an authentication server on the wired network segment to which an access point is connected. Such functionality is commonly delivered by a RADIUS server integrated with some form of user database, including native RADIUS, LDAP, NDS, or Windows Active Directory. High-end commercial wireless gateways can implement both authentication server and authenticator functionalities. The same applies to custom-built Linux gateways, which can support 802.1x with HostAP as described and have RADIUS server installed.

802.1x user authentication is provided by Layer 2 Extensible Authentication Protocol (EAP; RFC 2284,) developed by the Internet Engineering Task Force (IETF). EAP is an advanced replacement for CHAP used by PPP, developed to run over LANs. EAP over LAN (EAPOL) defines how EAP frames are encapsulated within 802.3, 802.5, and 802.10 frames.

There are multiple EAP types designed with the participation of various vendor companies. This diversity adds to 802.1x implementations' compatibility problems and makes the selection of appropriate equipment and software for your WLAN a more difficult task.

The EAP types you are likely to encounter when configuring user authentication for your wireless network include the following:

• EAP-MD5 is the mandatory baseline level of EAP support by the 802.1x standard and the first EAP type to be developed. In terms of its operation, EAP-MD5 duplicates CHAP. We do not recommend using EAP-MD5 for three reasons. First of all, it does not support dynamic WEP key distribution. It is also vulnerable to the man-in-the-middle rogue AP or authentication server attack because only the clients are authenticated. Besides, during the authentication process the attacker can sniff out both the challenge and the encrypted response and launch a known plaintext or ciphertext attack.

• EAP-TLS (Transport Layer Security, experimental RFC 2716) supplies mutual certificate-based authentication. EAP-TLS is based of the SSLv3 protocol and requires a deployed certificate authority.

• EAP-LEAP (Lightweight EAP or EAP-Cisco Wireless) is a Cisco Systems proprietary EAP type, implemented of Cisco Aironet access points and wireless clients. A full EAP-LEAP method description was posted to http://lists.cistron.nl/pipermail/cistron-radius/2001-September/002042.html and remains the best source on LEAP functionality and operations. LEAP was the first (and for a long time the only) 802.1x password-based authentication scheme. As such, LEAP gained tremendous popularity and is even supported by Free-RADIUS despite being a proprietary Cisco solution. LEAP is based on a straightforward challenge-password hash exchange. The authentication server sends a challenge to the client, which has to return the password after first hashing it with the challenge string issued by the authentication server. Being a password-based authentication method, EAP-LEAP has the strength of user and not device-based authentication. At the same time, the vulnerability to dictionary and brute-forcing attacks absent in the certificate-based EAP methods becomes apparent.

Very detailed information on hands-on configuration of EAP-LEAP is provided by Cisco at http://www.cisco.com/warp/public/707/accessregistrar_leap.html.

Less commonly implemented types of EAP include PEAP (Protected EAP, an IETF draft standard) and EAP-TTLS (Tunneled Transport Layer Security EAP, developed by Certicom and Funk Software). That situation might soon change, because these EAP methods are both powerful and have strong support from the manufacturers, such as Microsoft and Cisco.

EAP-TTLS requires only an authentication server certificate, so the need for the supplicant certificate is eliminated and deployment becomes more straightforward. EAP-TTLS supports a variety of legacy authentication methods, including PAP, CHAP, MS-CHAP, MS-CHAPv2, and even EAP-MD5. To use these methods securely, EAP-TTLS builds an encrypted TLS tunnel, inside of which the less secure legacy authentication protocol runs. An example of practical EAP-TTLS implementation is the Odyssey WLAN access control software solution from Funk Software (Windows XP/2000/98/Me). EAP-PEAP is very similar to EAP-TTLS, although it does not support legacy authentication methods like PAP and CHAP. Instead it supports PEAP-MS-CHAPv2 and PEAP-EAP-TLS inside the secure tunnel created in a similar manner to the EAP-TTLS tunnel. EAP-PEAP support is implemented by the Cisco Wireless Security Suite and incorporated into the Cisco Aironet Client Utility (ACU) and Windows XP Service Pack 1. It is actively promoted by Cisco, Microsoft, and RSA Security.

Two other EAP types are EAP-SIM and EAP-AKA for SIM and USIM-based authentication. Both are IETF drafts at the moment and are not reviewed here because they are mainly used for authentication on GSM, but not 802.11 wireless networks. Nevertheless, EAP-SIM is supported by Cisco Aironet access points and client devices.

Patching the Major Hole: TKIP and CCMP

The second layer of 802.11i defense is cryptographic improvements of the original WEP that should finally result in a complete WEP replacement. Temporal Key Integrity Protocol (TKIP) and Counter Mode with CBC-MAC Protocol (CCMP) are the new 802.11i encryption implementations, designed to eliminate the flawed WEP from 802.11 LANs. TKIP is an upgrade to WEP, which is supposed to address all known WEP vulnerabilities. Current WPA cryptographic security is based on TKIP use. TKIP employs 48-bit IVs to avoid the IV reuse exploited by the FMS attack. The estimated weak IV frames appearance interval with TKIP is about a century, so by the time a cracker collects the necessary 3,000 or more interesting IV frames, he or she would be 300,000 years old.

Unfortunately, what is easy in theory can be hard to implement in practice. Legacy hardware that still dominates the market won't go away in a week and cannot understand 48-bit IVs. To bypass this problem, 48-bit TKIP IV is split into 16-bit and 32-bit parts. The 16-bit part is padded to 24 bits to produce a traditional IV. The padding is done in a way that avoids the possibility of weak IV generation. Interestingly, the 32-bit part is not used for the transmitted IV generation; instead, it is utilized in the TKIP per-packet key mixing.

TKIP performs per-packet key mixing of the IVs to introduce additional key confusion. The per-packet key generation process consists of two phases and utilizes several inputs, such as the transmitting device MAC address, the 32 bits of the IV already mentioned, the first 16 bits of the IV, and the temporal session key. The first phase involves mixing the temporal session key, 32 IV bits, and the transmitter's MAC. In the second phase the output of the first phase is mixed with the temporal session key and 16 bits of the IV. Phase 1 eliminates the use of the same key by all connections, and the second phase reduces the correlation between the IV and per-packet key. Note that the key mixing results in different keys for each direction of communications over each link.

Another novel implementation of the IV in TKIP is using it as a sequence counter. Recall that there are replay attack tools that use traffic reinjection to accelerate WEP cracking or even portscan wireless hosts (reinj, WEPWedgie). There is nothing in the traditional WEP to stop these attacks from succeeding, as there is no standard defining how the IVs should be selected. In the majority of cases this selection is (pseudo?) random. On the contrary, the TKIP IV is incremented sequentially with all out-of-sequence IV packets discarded. This mitigates the replay attacks but introduces a problem with some quality of service enchancements introduced by IEEE 802.11 task group "e." In particular, ACKing every received frame as defined by the original CSMA/CA algorithm is inefficient. Thus, an improvement called burst-ACK was proposed. In accordance with this improvement, not every single frame, but a series of 16 frames is ACKed. If one of the frames out of the 16 sent didn't reach the destination, selective ACKing (similar to the selective ACK in TCP options) is applied to retransmit the lost frame and not all 16 in a row. Of course, a TKIP sequence counter would reject the retransmitted frame if frames with higher IV numbers were already received. To avoid such inconvenience, TKIP employs a replay window that keeps track of the last 16 IV values received and checks if the duplicate frame fits into these values. If it does and it wasn't received already, it is accepted.

TKIP also provides a message integrity code (MIC or Michael) checksum instead of the basic and insecure WEP integrity check vector (ICV) computation. Introducing you to the foundations of applied cryptography is necessary before discussing the structure of this particular hash. TKIP is not mandatory for the planned final 802.11i standard, but it is backward compatible with old WEP and does not require wireless hardware upgrades.

On the contrary, CCMP will be compulsory when 802.11i eventually is implemented. CCMP employs the Advanced Encryption Standard (AES (Rijndael)) cipher in a counter mode with cipher block chaining and message authenticating code (CBC-MAC) implementation. The counter mode (CCM) was created for use in 802.11i but later submitted to NIST for general use of the AES cipher. The AES key size defined by the 802.11i standard is 128 bits, and we wonder why the 256-bit key was not chosen instead. In a way similar to TKIP, CCMP employs a 48-bit IV (called a packet number or PN) and a variation of MIC. The use of the strong AES cipher makes creating per-packet keys unnecessary, thus CCMP does not implement per-packet key derivation functions. CCMP uses the same per-association key for both data encryption and checksum generation. The 8-octet message integrity checksum provided by CCMP is considered to be much stronger than TKIP's Michael.

Because the separate chip hardware implementation of AES is planned to reduce the burden of encryption on 802.11, network speed, and throughput, a complete 802.11 hardware overhaul is expected when CCMP-supporting products hit the market. Besides, there are still some issues not covered by the 802.11i standard at present. These issues include securing ad-hoc networks, fast handoff, and deauthentication and deassociation processes. Thus, the practical widespread implementation of 802.11i is not going to be an easy task, and WEP (hopefully, in the improved form of TKIP) will be with us for a long time. This might prompt wireless network managers to search for reliable, version and vendor independent security solutions on the OSI layers above the data link layer.