Hi, 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]. 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 have asked this on the LEDE forums before, btw, and it was suggested to take this question to the hostapd mailing list.) I appreaciate any clarification someone might have on these questions. Thanks, Timo [1] https://lede-project.org/releases/17.01/notes-17.01.4 [2] https://papers.mathyvanhoef.com/ccs2017.pdf [3] https://w1.fi/cgit/hostap/commit/?id=6f234c1e2ee1ede29f2412b7012b3345ed8e52d3 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap