Incorrect key lengths and SHA algorithms for certain AKMs

[Jouni Malinen]

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.

> 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.

> Its probably not something that can be changed at this point, but I just was
> hoping for an answer either way in order to handle it properly on the
> supplicant side.

If there are some real mismatches, those should be considered and it
might be possible to change the implementation if the particular AKM has
not yet been deployed in practice. However, I could not find any
misbehavior based on the items identified here.

-- 
Jouni Malinen                                            PGP id EFC895FA