In the past month, I received questions about a configuration option I'm not sure I heard of before: Hash-to-encryption (H2E) for WPA3-SAE. Those questions led me to a Cisco configuration guide (1) that outlines:
This only concerns SAE/passphrase-based WLANs in WPA3
H2E is required for 6 GHz
H2E adds an offline intermediary element (PT) for password derivation. The actual Password Element (PWE) derivation happens in real-time still.
Most importantly, the client falls back to Hunting-and-Pecking (HnP) if it does not support H2E
🐦⬛ Hunting-AND-PECKING🦜? Oh, I see another strange acronym with avian connotations. My feathered crusade begins here to figure out why H2E and HnP exist.
Sometime after the IEEE ratified 802.11-2020, they released a revision called 802.11REVmd. This revision added H2E for two reasons (2) :
1. HnP loops many times, rendering it inefficient
2. The new intermediary key (PT) in H2E reduces potential attack vectors
Interestingly enough, the Wi-Fi Alliance decided to immediately require H2E and Transition Disable for a device to be "Wi-Fi CERTIFIED WPA3". Transition Disable is another WPA3 quirk that I do not like nor have the energy today to discuss, but understand why it exists.
As the Cisco configuration guide points out, an issue arrises because of the delayed released; early WPA3-capable clients do not necessarily support H2E. Hence, the vendors had to build a configuration option in for this corner case. It feels reminiscent of the challenges today with early 6 GHz clients supporting Lower Power Indoor mode, but not Standard Power.
So, how does H2E look on the AP within a beacon frame? The "SAE Hash to element" attribute in the RSN eXtenstion tag will have a "1" if the BSSID supports H2E.
What about cases where the AP does not allow HnP-only clients? Oddly enough, that setting is in the Supported Rates tag, after the rates. I do not have my own example, but I found one from a company called Infineon. (3)
I wondered why this setting is located here and in the 802.11 standard, the Supported Rates and BSS Membership Selectors share the same field; 802.11REVmd specifically adds "SAE Hash to Element " as a BSS membership selector value. (4) Generally, the APs use this BSS membership selector field for cases where the AP absolutely mandates a certain PHY for clients. I have not noticed the BSS membership selector values in captures, but will keep my eyes peeled now.
As more clients have H2E support enabled while vendors may often just enabled both H2E and HnP, this quirk may become more of a footnote than a notable design consideration. Still, it's nice to know now why it exists and how it came about.
Sources:
Comentários