On Fri, Apr 28, 2023 at 08:34:27AM -0700, James Prestwood wrote: > I don't have logs, this is purely looking at the code. I just know that > certain EAP methods export a 64 byte MSK, and I assumed this was mapped to > pmk_len. All modern EAP methods are going to be exporting a 64 octet MSK, but the PMK length is defined by the AKM (and some other parameters for SAE/OWE/DPP), so pmk_len in the implementation should be accurate and match what the standard uses in this type of cases. > This all started after updating hostapd past b6d3fd05e3 and some of the IWD > tests started failing since the PMKID derivation changed. I noticed that > FT-PSK was not in the list, so I started poking around and noticed some of > the above concerns. Sounds like its all fine though, I just wanted to make > sure of it because sometimes these things can fall though the cracks since > wpa_supplicant/hostapd share common key derivation code. There was indeed a real issue and change in this for FT-EAP. The IEEE Std 802.11-2020 cleanup for the PMKID derivation ended up defining something for FT that was not defined appropriately before and would have used the default "otherwise" case of SHA-1. PMKSA caching for FT is really a problematic area in practice due to various implementation issues in deployed devices which is why this is still disabled in wpa_supplicant by default.. Sure, I would have wanted to notice that particular AKM 00-0F-AC:3 difference earlier when we worked on the IEEE 802.11 maintenance changes, but it did come up only later when reviewing some other related areas. Anyway, it was something that justified an implementation change at that point. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
