Incorrect key lengths and SHA algorithms for certain AKMs

[Jouni Malinen]

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