Incorrect key lengths and SHA algorithms for certain AKMs

[James Prestwood]

Hi Jouni,

On 4/28/23 8:19 AM, Jouni Malinen wrote:
> On Tue, Apr 11, 2023 at 08:06:12AM -0700, James Prestwood wrote:
>> I noticed a few inconsistencies between hostapd/wpa_supplicant and the
>> 802.11 spec with respect to the key size and hash algorithm used for certain
>> AKMs when generating the PMKID or other keys.
>>
>> First being that wpa_key_mgmt_sha256() does not include WPA_KEY_MGMT_FT_PSK
>> which it should according to 12.7.1.6.3:
>>
>> If the negotiated AKM is 00-0F-AC:4, then Q = 256 and
>> — MPMK = PSK
>> — PMKID = Truncate-128(HMAC-SHA-256(MPMK, “PMK Name” || AA || SPA))
> 
> Which operation would not use SHA-1 in this case? Both hostapd and
> wpa_supplicant use SHA256 with FT-PSK in my tests for deriving PMK-R0,
> PMK-R1, PMKR1Name, PTK. Would you be able to share a debug log that
> shows incorrect hash algorithm being used? In particular, I'd like to
> see the "FT: Derive PMK-R0 using KDF-SHA256" style messages showing
> unexpected behavior with rest of the details showing how exactly the
> association got negotiated.
> 
> Please note that wpa_key_mgmt_sha256() is not a direct mapping of how
> some operations are performed, so it on its own cannot really be
> compared against the rules in 12.7.1.6.3 without checking other
> conditions separately.

Ok, and I didn't go checking every single instance where a key is 
derived. I just assumed this helper would be used anywhere needing to 
determine the SHA size for a given AKM.

> 
>> The second issue I noticed had to do with the portion of the PMK used for
>> SHA384 AKMs. This code passes the PMK length directly but 802.11 defines the
>> portion of the PMK used. For example WPA_KEY_MGMT_FT_IEEE8021X_SHA384
>> expects 48 bytes, not the entire PMK which could be 64 potentially.
> 
> Can you please be more specific on that "SHA384 AKMs" part? Are you
> indicating that there are issues with all AKMs that might be somehow
> using SHA384 or have you only checked this 00-0F-AC:13 case? A debug log
> showing misbehavior would be highly appreciated was this type of
> reports.
> 
> What exactly are you referring to with "this code" here?
> 
>> If the negotiated AKM is 00-0F-AC:13, then Q = 384 and
>> — MPMK = L(MSK, 0, 384), i.e., the first 384 bits of the MSK (which is
>> derived from the
>> IEEE 802.1X authentication)
>> — PMKID = Truncate-128(HMAC-SHA-384(MPMK, “PMK Name” || AA || SPA))
> 
> As far as this 00-0F-AC:13 case is concerned, pmk_len to rsn_pmkid()
> seems to be set to 48 (= 384 bits) in my tests. Do you have logs from an
> example that is actually really using 64 octets instead of 48 octets?
> Please note that while the MSK might be (and commonly is) 64 octets, the
> PMK is of different length for most cases.

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.

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.

Thanks for taking a look at this
- James