jeltz/hostap
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Clarify the TODO comment regarding PMKID KDE in EAPOL-Key msg 1/4

Browse source 
Make it clear that the consideration should be only for the IBSS case
and in infrastructure BSS case, PMKID KDE should not be added due to
risks involved with exposing this to stations that do not know the
passphrase.

Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This commit is contained in:
Jouni Malinen 2018-08-10 13:51:04 +03:00 committed by Jouni Malinen
parent c773c7d5dd
commit c6e1a9a0b3
1 changed files with 12 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
src/ap/wpa_auth.c
View file

@ -2026,8 +2026,18 @@ SM_STATE(WPA_PTK, PTKSTART)
wpa_auth_logger(sm->wpa_auth, sm->addr, LOGGER_DEBUG, wpa_auth_logger(sm->wpa_auth, sm->addr, LOGGER_DEBUG,
"sending 1/4 msg of 4-Way Handshake"); "sending 1/4 msg of 4-Way Handshake");
/* /*
* TODO: Could add PMKID even with WPA2-PSK, but only if there is only * For infrastructure BSS cases, it is better for the AP not to include
* one possible PSK for this STA. * the PMKID KDE in EAPOL-Key msg 1/4 since it could be used to initiate
* offline search for the passphrase/PSK without having to be able to
* capture a 4-way handshake from a STA that has access to the network.
*
* For IBSS cases, addition of PMKID KDE could be considered even with
* WPA2-PSK cases that use multiple PSKs, but only if there is a single
* possible PSK for this STA. However, this should not be done unless
* there is support for using that information on the supplicant side.
* The concern about exposing PMKID unnecessarily in infrastructure BSS
* cases would also apply here, but at least in the IBSS case, this
* would cover a potential real use case.
*/ */
if (sm->wpa == WPA_VERSION_WPA2 && if (sm->wpa == WPA_VERSION_WPA2 &&
(wpa_key_mgmt_wpa_ieee8021x(sm->wpa_key_mgmt) || (wpa_key_mgmt_wpa_ieee8021x(sm->wpa_key_mgmt) ||