17d4b77472
PMKID derivation with the Suite B AKMs is a special case compared to other AKMs since that derivation uses KCK instead of PMK as an input. This means that the PMKSA cache entry can be added only after KCK has been derived during 4-way handshake. This also means that PMKID would change every time 4-way handshake is repeated even when maintaining the same PMK (i.e., during PTK rekeying and new associations even if they use PMKSA caching). wpa_supplicant was previously replacing the PMKSA cache entry whenever a new PMKID was derived. This did not match hostapd expectations on the AP side since hostapd did not update the PMKSA cache entry after it was created. Consequently, PMKSA caching could be used only once (assuming no PTK rekeying happened before that). Fix this by making wpa_supplicant behave consistently with hostapd, i.e., by adding the Suite B PMKSA cache entries with the PMKID from the very first 4-way handshake following PMK derivation and then not updating the PMKID. IEEE Std 802.11-2016 is somewhat vague in this area and it seems to allow both cases to be used (initial PMKID or any consecutive PMKID derived from the same PMK). While both cases could be supported that would result in significantly more complex implementation and need to store multiple PMKID values. It looks better to clarify the standard to explicitly note that only the first PMKID derived after PMK derivation is used (i.e., match the existing hostapd implementation). Signed-off-by: Jouni Malinen <jouni@codeaurora.org> |
||
|---|---|---|
| .. | ||
| Makefile | ||
| pmksa_cache.c | ||
| pmksa_cache.h | ||
| preauth.c | ||
| preauth.h | ||
| tdls.c | ||
| wpa.c | ||
| wpa.h | ||
| wpa_ft.c | ||
| wpa_i.h | ||
| wpa_ie.c | ||
| wpa_ie.h | ||