Limitations of wpa_disable_eapol_key_retries option to work around key reinstallation attacks

[Timo Sigurdsson]

Hi Jouni,

Thank you for your quick response and for the clarifying comments. I have one
followup question, though, please see my comments and question inline below:

Jouni Malinen schrieb am 20.10.2017 12:34:

> 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).

Sorry for the mixup and thanks for the clarification.


> 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.

Thanks for the hint.

> 
>> 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.

Fair enough!

> 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).

Would the existing option wnm_sleep_mode that is mentioned in the example
hostapd configuration[1] cover this scenario (if set to 0) or is that
unrelated?

Regards,

Timo

[1] https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf