Recent reports of a flaw in the WPA standard have spawned a flurry of articles. Unfortunately, many of these reports are completely wrong (or at least deeply flawed.)
The TKIP vulnerability discovered by Erik Trews and Martin Beck is very different from the previous, well-known attacks against WPA-PSK. Previous attacks targeted the method WPA-PSK uses to generate the initial key from the passphrase and network SSID, by brute forcing possible passwords and generating a table of the results. The new attack targets the TKIP data exchange itself, and can affect both PSK and EAP/Dot1X (enterprise) networks. It does not affect networks which use AES encryption (such as WPA2-AES). WPA1 networks using AES encryption are not affected, and WPA2 networks which still use TKIP are vulnerable.
TKIP itself was designed as a stopgap measure, with a planned secure lifetime of approximately five years. As this standard was adopted in 2003, a discovery of this type is not entirely unexpected.
This attack is not a complete failure of the WPA mechanism, but it does open the door for more complex and more problematic attacks, and heralds the end of TKIP; All users of TKIP should strongly consider switching to AES-CCM as soon as is practical. The current attack does not compromise the key itself, but can allow packet injection attacks, which may compromise secondary security features, such as firewalls, by forging packets which cause the firewall to think connections originated from inside the LAN.
By exploiting the fact that packets in QoS queues may arrive out of order, an attacker can defeat the replay protection in TKIP and reuse a captured frame. Applying an older WEP attack known as "chopchop", the plaintext of the packet can be revealed byte-by-byte. However, the maximum rate at which the attacker can guess each byte is limited by the TKIP message integrity check (MIC). If two invalid MIC events occur within 60 seconds, the station will shut down for 60 seconds, and then reassociate with new keys.
If switching to AES is not possible, stop-gap measures may temporarily extend the lifetime of the network, but will not solve the fundamental flaw. By setting the TKIP rotation interval to a short value, the amount of time an attacker can conduct the attack and the length of time a successful attack is useful are curtailed. The current attack requires one minute per byte, so setting the TKIP rotation value to an interval of 120 seconds should prevent an attacker from making significant gains. On an Aruba controller, this can be set by:
enable
configure terminal
aaa authentication dot1x
multicast-keyrotation
unicast-keyrotation
timer mkey-rotation-period 120
timer ukey-rotation-period 120
Not all clients support key rotation (notably, some VOIP handsets and hand-held devices), so always test network changes before deployment.
Early indications were that disabling QoS support on the network could mitigate this attack, however recent information released by the researchers shows this is not the case.
Aruba is currently implementing additional workarounds for customers with networks which cannot be upgraded to AES. These workarounds will be available in future versions of AOS.
When upgrading your network to AES, be sure to disable TKIP fallback or compatibility (if offered by your vendor). On an Aruba controller, this is controlled by the opmode values for the SSID, and should be one (or more, depending on the configuration) of: "wpa-psk-aes" "wpa-aes" "wpa2-psk-aes", and "wpa2-aes". For example, for a preshared-key network to use AES:
enable
configure terminal
wlan ssid-profile default
opmode wpa2-psk-aes
Because this break in WPA-TKIP is not complete, there is a brief grace period. It is strongly recommended that all customers capable of migrating away from TKIP begin doing so immediately; Typically, once a crack is found in the armor of a security protocol, a full break is not far behind.
Additional reading can be found at:
http://arstechnica.com/articles/paedia/wpa-cracked.ars/1