Using WPA/WPA2 for authentication and encryption

The original security mechanism of the IEEE 802.11 standard wasn't designed to be strong and has proven to be insufficient for most networks that require some kind of security.

Task group I (Security) of the IEEE 802.11 working group ( has worked to address the flaws of the base standard and has in practice completed its work in May 2004. The IEEE 802.11i amendment to the IEEE 802.11 standard was approved in June 2004 and published in July 2004.

The Wi-Fi Alliance used a draft version of the IEEE 802.11i work (draft 3.0) to define a subset of the security enhancements, called Wi-Fi Protected Access (WPA), that can be implemented with existing WLAN hardware. This has now become a mandatory component of interoperability testing and certification done by Wi-Fi Alliance. Wi-Fi provides information about WPA at its website,

The IEEE 802.11 standard defined a Wired Equivalent Privacy (WEP) algorithm for protecting wireless networks. WEP uses RC4 with 40-bit keys, a 24-bit initialization vector (IV), and CRC32 to protect against packet forgery. All these choices have proven to be insufficient:

WPA is an intermediate solution for these security issues. It uses the Temporal Key Integrity Protocol (TKIP) to replace WEP. TKIP is a compromise on strong security, and it's possible to use existing hardware. It still uses RC4 for the encryption as WEP does, but with per-packet RC4 keys. In addition, it implements replay protection and a keyed packet-authentication mechanism.

Keys can be managed using two different mechanisms; WPA can use either of the following:

An external authentication server (e.g. RADIUS) and EAP, just as IEEE 802.1X is using.
Pre-shared keys without the need for additional servers.

Both mechanisms generate a master session key for the Authenticator (AP) and Supplicant (client station).

WPA implements a new key handshake (4-Way Handshake and Group Key Handshake) for generating and exchanging data encryption keys between the Authenticator and Supplicant. This handshake is also used to verify that both Authenticator and Supplicant know the master session key. These handshakes are identical regardless of the selected key management mechanism (only the method for generating master session key changes).