wpa_supplicant -- unauthenticated encrypted EAPOL-Key data

SO-AND-SO reports:

A vulnerability was found in how wpa_supplicant processes
EAPOL-Key frames. It is possible for an attacker to modify
the frame in a way that makes wpa_supplicant decrypt the Key
Data field without requiring a valid MIC value in the frame,
i.e., without the frame being authenticated. This has a
potential issue in the case where WPA2/RSN style of EAPOL-Key
construction is used with TKIP negotiated as the pairwise
cipher. It should be noted that WPA2 is not supposed to be
used with TKIP as the pairwise cipher. Instead, CCMP is
expected to be used and with that pairwise cipher, this
vulnerability is not applicable in practice.
When TKIP is negotiated as the pairwise cipher, the EAPOL-Key
Key Data field is encrypted using RC4. This vulnerability
allows unauthenticated EAPOL-Key frames to be processed and
due to the RC4 design, this makes it possible for an attacker
to modify the plaintext version of the Key Data field with
bitwise XOR operations without knowing the contents. This can
be used to cause a denial of service attack by modifying
GTK/IGTK on the station (without the attacker learning any of
the keys) which would prevent the station from accepting
received group-addressed frames. Furthermore, this might be
abused by making wpa_supplicant act as a decryption oracle to
try to recover some of the Key Data payload (GTK/IGTK) to get
knowledge of the group encryption keys.
Full recovery of the group encryption keys requires multiple
attempts (128 connection attempts per octet) and each attempt
results in disconnection due to a failure to complete the 4-way
handshake. These failures can result in the AP/network getting
disabled temporarily or even permanently (requiring user action
to re-enable) which may make it impractical to perform the
attack to recover the keys before the AP has already changes
the group keys. By default, wpa_supplicant is enforcing at
minimum a ten second wait time between each failed connection
attempt, i.e., over 20 minutes waiting to recover each octet
while hostapd AP implementation uses 10 minute default for GTK
rekeying when using TKIP. With such timing behavior, practical
attack would need large number of impacted stations to be
trying to connect to the same AP to be able to recover
sufficient information from the GTK to be able to determine
the key before it gets changed.