PMKSA caching for the FT initial mobility domain association was fully
defined in IEEE Std 802.11-2020. The state before that was unclear and
there has been interoperability issues in this area, so use of PMKSA
caching with FT-EAP has been disabled in wpa_supplicant by default.
The wpa_supplicant and hostapd implementation of PMKSA caching for FT
ended up using an earlier default mechanism (SHA-1) for deriving the
PMKID when using the FT-EAP. This does not match what got defined in
IEEE Std 802.11-2020, 12.11.2.5.2 (SHA256). It is not really desirable
to use SHA-1 for anything with FT since the initial design of FT was
based on SHA256. Furthermore, it is obviously not good to differ in
behavior against the updated standard. As such, there is sufficient
justification to change the implementation to use SHA256 here even
though this ends up breaking backwards compatibility for PMKSA caching
with FT-EAP.
As noted above, this is still disabled in wpa_supplicant by default and
this change results in PMKSA caching not working only in cases where it
has been enabled explicitly with ft_eap_pmksa_caching=1. Those cases
recover by falling back to full EAP authentication.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
static inline int wpa_key_mgmt_sha256(int akm)
{
- return !!(akm & (WPA_KEY_MGMT_PSK_SHA256 |
+ return !!(akm & (WPA_KEY_MGMT_FT_IEEE8021X |
+ WPA_KEY_MGMT_PSK_SHA256 |
WPA_KEY_MGMT_IEEE8021X_SHA256 |
WPA_KEY_MGMT_SAE |
WPA_KEY_MGMT_FT_SAE |
* @akmp: Negotiated key management protocol
*
* IEEE Std 802.11-2016 - 12.7.1.3 Pairwise key hierarchy
- * AKM: 00-0F-AC:5, 00-0F-AC:6, 00-0F-AC:14, 00-0F-AC:16
+ * AKM: 00-0F-AC:3, 00-0F-AC:5, 00-0F-AC:6, 00-0F-AC:14, 00-0F-AC:16
* PMKID = Truncate-128(HMAC-SHA-256(PMK, "PMK Name" || AA || SPA))
* AKM: 00-0F-AC:11
* See rsn_pmkid_suite_b()