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
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
