[noup] hostap: Add WPA-PSK-SHA384 and FT-PSK-SHA384 key management

[kapbh]

Introduce WPA_KEY_MGMT_PSK_SHA384 and WPA_KEY_MGMT_FT_PSK_SHA384 and wire them through config parsing, RSN AKM mapping, and RSN IE generation for SHA-384 based PSK and fast-transition PSK suites.

Assisted-by: Claude:Auto

[Copilot]

Pull request overview

This PR introduces new WPA key management bitfields for SHA-384 based PSK suites (PSK-SHA384 and FT-PSK-SHA384) and wires them into config parsing, RSN AKM selector mapping, and RSN IE generation paths.

Changes:

• Add WPA_KEY_MGMT_PSK_SHA384 and WPA_KEY_MGMT_FT_PSK_SHA384 bit definitions and include them in PSK-related helper masks.
• Extend wpa_supplicant config parsing/writing to accept and emit WPA-PSK-SHA384 and FT-PSK-SHA384.
• Extend RSN AKM selector mapping and supplicant RSN IE generation to encode/decode the new SHA-384 PSK AKMs.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
wpa_supplicant/config.c	Parse and write new WPA-PSK-SHA384 / FT-PSK-SHA384 key_mgmt tokens (guarded by CONFIG_SHA384).
src/rsn_supp/wpa_ie.c	Add RSN IE AKM selector generation for PSK-SHA384 and FT-PSK-SHA384.
src/common/wpa_common.c	Map new RSN AKM selectors to bitfields and extend AKM-to-suite selection.
src/common/defs.h	Define new key mgmt bits and extend PSK helper bitmasks.

Comments suppressed due to low confidence (1)

src/common/defs.h:105

• wpa_key_mgmt_ft_psk() still only matches WPA_KEY_MGMT_FT_PSK. With the new WPA_KEY_MGMT_FT_PSK_SHA384 bit, this helper will return false and FT-PSK-specific code paths may not run for FT-PSK-SHA384 connections.

			 WPA_KEY_MGMT_PSK_SHA384 |
			 WPA_KEY_MGMT_FT_PSK_SHA384 |
			 WPA_KEY_MGMT_SAE |
			 WPA_KEY_MGMT_SAE_EXT_KEY |
			 WPA_KEY_MGMT_FT_SAE |
			 WPA_KEY_MGMT_FT_SAE_EXT_KEY));

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[krish2718]

Can you clarify the use case before this goes further? A couple of concerns:

1. Justification / [noup] rationale. The commit message describes what the patch does but not why — which feature, product, or AP interop scenario requires WPA-PSK-SHA384 / FT-PSK-SHA384? These are AKM suites 00-0F-AC:20 and :19. Upstream deliberately reserved the selector constants back in 2022 (5456b0f26, "Define new RSN AKM suite selector values", from IEEE P802.11-REVme/D1.3) but never wired them into key management — while implementing the siblings from that same commit that had real drivers (802.1X-SHA384 :23, SAE-EXT-KEY :24/:25). The reason there's no upstream implementation is that no Wi-Fi Alliance program uses PSK with SHA-384: WPA3-Personal is SAE, and the 192-bit/CNSA suite is EAP/802.1X-SHA384, not PSK. If upstream has no use case, we should have a concrete one documented in the commit before carrying a [noup]. What is it?

2. The patch is functionally incomplete — it will not actually work. It wires up AKM negotiation (config parse/write, RSN AKM ↔ bit mapping, RSN IE emission) but not the cryptography. Specifically:

• wpa_key_mgmt_sha384() in src/common/defs.h is not updated to include the two new bits (nor wpa_key_mgmt_sha256()).
• As a result, in wpa_pmk_to_ptk() these AKMs match neither the SHA-384 nor SHA-256 branch and fall through to the final else, deriving the PTK with sha1_prf(). The same wpa_key_mgmt_sha384(akmp) gate guards ~8 other sites (EAPOL-Key MIC, key-data encryption, PMKID/KDK derivation), all of which will take the wrong branch.
• The key-length tables wpa_kck_len() / wpa_kek_len() / wpa_mic_len() fall to their default: (16/16/16) instead of the SHA-384 sizes (24-byte KCK/MIC, 32-byte KEK).

Since Zephyr uses the software crypto path (MbedTLS, no offload), this code is actually exercised — a 4-way handshake with these AKMs would derive keys with SHA-1 and wrong lengths and fail MIC verification. So even for its stated purpose the patch is non-functional as written.

Given both points, I'd hold this until (a) the use case is documented in the commit message, and (b) if it's genuinely needed, the crypto side is completed to match. Happy to help scope (b) if the use case checks out.

[MaochenWang1]

This non-zephyr specific change which touches the supplicant core code, it should be push to supplicant upstream first