Limitations of wpa_disable_eapol_key_retries option to work around key reinstallation attacks

[Jouni Malinen]

On Fri, Oct 20, 2017 at 12:03:50PM +0200, Timo Sigurdsson wrote:
> commit 6f234c1e (Optional AP side workaround for key reinstallation attacks)
> introduced the new option wpa_disable_eapol_key_retries to help mitigate the
> key installation attacks from the access point side in case some clients
> cannot be patched.
> 
> This option has also been quickly adopted by some distributions such as LEDE.
> In their release announcement for the 17.01.4 release, the LEDE team notes[1]:
> 	As some client devices might never receive an update, an optional AP-side
> 	workaround was introduced in hostapd to complicate these attacks, slowing
> 	them down. Please note that this does not fully protect you from them,
> 	especially when running older versions of wpa_supplicant vulnerable to
> 	CVE-2017-13086, which the workaround does not address.
> 
> Now, I understand that an attack against the PeerKey handshake (CVE-2017-13086)
> cannot be addressed with this new hostapt workaround. Yet, as the researchers
> who found those vulnerabilities also noted in their paper, the impact of this
> specific attack is rather low since not many devices seem to support this
> particular feature in the first place[2].

Please note that CVE-2017-13086 is related to TDLS, not PeerKey (which
is covered in CVE-2017-13084 and not known to be deployed in any
device).

As far as TDLS is concerned, I'm not sure anyone has yet shown that it
can be attacked in practice with the currently deployed devices, but it
is at least theoretically possible that such attacks could be performed.
If one wants to complicate that possibility at the AP side, the
tdls_prohibit=1 configuration parameter makes hostapd advertise to the
stations that use of TDLS is not allowed in the BSS. That said, this
advertisement is not fully protected, so if an attacker can attract both
STAs using TDLS into a fake AP and the STAs do not see Beacon/Probe
Response frames from the real AP, it would be possible to bypass this
protection.

> This leaves me wondering, what other limitations the hostapd workaround
> wpa_disable_eapol_key_retries might have with regards to mitigating the key
> reinstallation attacks. Are there any other known limitations aside from the
> PeerKey attack and the fact that the workaround might cause interoperability
> issues with clients? Can anybody elaborate what "slowing them down" (LEDE
> release notes) as opposed to "work around key reinstallation attacks" (original
> commit message[3]) might mean?

I'm not familiar with the reason behind that "slowing them down"
language, so I cannot comment on that part. As far as the hostapd
wpa_disable_eapol_key_retries=1 configuration option is concerned, it
should prevent an attacker from being able to obtain more than a single
valid EAPOL-Key frame (msg 3/4 or group msg 1/2) and with that, prevent
the particular attacks that used delayed EAPOL-Key frame delivery to the
station. That said, it should be noted that so far there has not been
sufficient review to be able to fully claim that this prevents all these
attacks and that there is no way for an attacker to make hostapd
retransmit a suitable frame in this configuration with the current
implementation.

Changes in EAPOL-Key functionality do not have impact on WNM Sleep Mode
behavior, so if there are station devices that use this capability (I'm
not sure whether any such device has been deployed), this AP-only
workaround with wpa_disable_eapol_key_retries=1 would not prevent
potential attacks there. Another hostapd-only change could be done to
those, though, to prevent use of WNM Sleep Mode or to not allow the
GTK/IGTK to be included in the WNM Sleep Mode Response. I'm open to
adding such a change if someone can confirm that there are actually
deployed station devices that use WNM Sleep Mode behavior and are
vulnerable to CVE-2017-13087 (and/or -13088).

-- 
Jouni Malinen                                            PGP id EFC895FA