WPA3-192-bit mode

This year, I presented the topic WPA3-192-bit mode at the WLAN Klassentreffen (in German) and WLPC in Prague as a 10Talk.

This is the video recording from WLPC:

Here is the presentation from WLPC 2024 in Prague:

And the German version from the WLAN Klassentreffen 2024 in Hamburg:

Some more information on this exciting topic:

The long journey to WPA3

It took a long time after WPA2 was released in 2004 to see some new security with WPA3. But security still evolved in the IEEE 802.11 Standard:

IEEE Std 802.11-2012 added a couple of new AKMs:

• AKM suite 3 and 4 with SHA-256 from 802.11r
• AKM suite 5 and 6 as an improvement of AKM 1 and 2 with a key-derivation of SHA-256

IEEE Std 802.11-2016 again added new AKMs:

• AKM suite 8 with SAE authentication with SHA-256 (the main AKM in WPA3-Personal)
• AKM suite 9 FT authentication over SAE
• AKM suite 11 with SHA-256 key derivation and Suite B compliant EAP method (now deprecated in 802.11-2020)
• AKM suite 12 is similar to AKM 11, but the key derivation is done with SHA-384, this is what we are using in WPA3-192
• AKM suite 13 as the FT method of AKM 12
• This standard also added the optional Management Frame Protection from 802.11w

Quite a lot of options to choose from. But with WPA3 Enterprise, the less secure options are gone:

• No more AKM1 (Key derivation with SHA-1)
• Management Frame Protection is mandatory

WPA3 Enterprise 192-bit mode raises the bar to a new level with restrictions for the EAP exchange between the Supplicant and the Authentication Server, which needs a 192-bit security level, SHA-384 and GCMP-256.

Security Level – Recommendations

These are the recommendations from BSI, ECRYPT, and a Wikipedia page for CNSA:

BSI TR-02102-1: “Cryptographic Mechanisms: Recommendations and Key Lengths” Version: 2024-1

ECRYPT – CSA: D5.4 Algorithms, Key Size and Protocols Report (2018)

Wikipedia: Commercial National Security Algorithm Suite

Security Level – Encryption

The security level of WEP/TKIP, based on RC4, is difficult to describe. But it is easy to state that it is far away from the general recommendation of 128 Bit security.

The Security Level of AES-128 is sometimes described as lower than 128-bit as attacks can break it in 2¹²⁶ calculations. However, this is still irrelevant if an attack needs 2⁸⁸ chosen plaintexts.

Security Level – Key Derivation

The Security Level of Hash algorithms is not really easy to describe in the context of Wireless LANs. A Hash algorithm is considered cryptographically strong if it is resistant to all of the following:

• Collision attacks: Finding two inputs with the same hash value is impossible. Here the Security strength (Security Level) is typically half the hash output length.
• Pre-image attacks: It is impossible to find an input to a given random hash value. The security strength is typically the hash output length.
• 2nd pre-image attacks: It is impossible to find a second input to a given input that produces the same hash value. The security strength is the hash output length minus a component dependent on the input length.

The collision resistance is not important for key-generating functions and HMACs. However, all actual recommendations suggest using only cryptographically strong hash functions.

Security Level – Authentication

Stating that the security level of personal mode authentication is “somewhere between zero and very low” sounds slightly strong. But how secure is it?

The following is stated in the IEEE 802.11-2020 standard:

12.7.6.8 4-way handshake analysis

The following is an analysis of the 4-way handshake.

This subclause makes the trust assumptions used in this protocol explicit. The protocol assumes the following:
— The PMK is known only by the Supplicant’s STA and the Authenticator’s STA.

and

If any of these assumptions are broken, then the protocol fails to provide any security guarantees.

Especially with WPA2, where the PMK is only dependent on the passphrase and the SSID, and given that the passphrase is often known to the employees (not pushed through an MDM) this assumption is definitely broken.

For WPA3-192, the relevant part is that all certificates in the chain and endpoint certificates provide a 192-bit security level. We must use RSA-3072 (or higher) or EC-384 (or higher).

The WPA3 Specification

The WPA3 specification is far away from being specific enough. The early versions didn’t even specify the AKM suite that should be used. This is from the specification v1.0 from 2018:

3 WPA3-Enterprise 192-bit Mode

WPA3-Enterprise 192-bit Mode may be deployed in sensitive enterprise environments to further protect Wi-Fi networks with higher security requirements such as government, defense, and industrial.

3.1 WPA3-Enterprise 192-bit Mode requirements

1. When WPA3-Enterprise 192-bit Mode is used by an AP, PMF shall be set to required (MFPR bit in the RSN Capabilities field shall be set to 1 in the RSNE transmitted by the AP).
2. When WPA3-Enterprise 192-bit Mode is used by a STA, PMF shall be set to required (MFPR bit in the RSN Capabilities field shall be set to 1 in the RSNE transmitted by the STA).
3. Permitted EAP cipher suites for use with WPA3-Enterprise 192-bit Mode are:
   ▪ TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
   – ECDHE and ECDSA using the 384-bit prime modulus curve P-384
   ▪ TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
   – ECDHE using the 384-bit prime modulus curve P-384
   – RSA ≥ 3072-bit modulus
   ▪ TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
   – RSA ≥ 3072-bit modulus
   – DHE ≥ 3072-bit modulus

Version 3.3 from 2024 is a little bit more specific:

3.5 WPA3-Enterprise 192-bit mode

WPA3-Enterprise 192-bit mode is well suited for deployments in sensitive enterprise environments to further protect WiFi ® networks with higher security requirements such as government, defense, and industrial.

When operating in WPA3-Enterprise 192-bit mode:

1. An AP’s BSS configuration shall enable AKM suite selector 00-0F-AC:12 (Suite B 192b) and shall not enable any other AKM suite selector.
   Note: WPA3-Enterprise 192-bit mode does not interoperate with any other security mode.
2. A STA’s Network Profile shall allow AKM suite selector 00-0F-AC:12 (Suite B 192b) and shall not allow any other AKM suite selector.
3. An AP’s BSS configuration shall be PMF Required, i.e., AP sets MFPC to 1 and MFPR to 1 in beacons and probe responses of the BSS.
4. A STA’s Network Profile shall be PMF Required, i.e., STA sets MFPC to 1 and MFPR to 1 in all (re)association requests to APs in that network.
5. Permitted EAP cipher suites for use with WPA3-Enterprise 192-bit mode are:
   ▪ TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
   – ECDHE and ECDSA using the 384-bit prime modulus curve P-384
   ▪ TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
   – ECDHE using the 384-bit prime modulus curve P-384
   – RSA ≥ 3072-bit modulus
   ▪ TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
   – RSA ≥ 3072-bit modulus
   – DHE ≥ 3072-bit modulus

I have used EC certificates on my RADIUS servers for quite some time. Because of that, the cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 is the one I see most often in the RADIUS server logs, also for standard WPA2/WPA3-Enterprise.

With RADIUS servers that support TLS 1.3 (for example, ISE 3.3 Patch 2), I often see the TLS 1.3 cipher TLS_AES_256_GCM_SHA384. Although not “allowed” by the WPA3-192 specification, this is even more secure.

The relevant RFCs:

The EAP-TLS Authentication Protocol
EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier

The role of the RADIUS server

One question that comes up sometimes is if the RADIUS-Server has to be WPA3-192-bit compliant. Many bright people say “yes”, but I tend to say “no” (I might be wrong). This is mainly because of two reasons:

1. To my knowledge, the Wi-Fi Alliance doesn’t certify RADIUS servers. But they certify clients and with that, I see the responsibility on the client side (and we’ll see later how bad this can be). For sure, the RADIUS server has to support the needed TLS cipher suits. But with WPA3 not being a standard but an industry certification it doesn’t have to be WPA3 compliant.
2. The WPA3 specification does not address the transport of the MSK to the Authenticator. This is plain RADIUS, which heavily depends on MD5. Because of that, the security level of this transport is far away from a 192-bit level. We should consider securing the RADIUS transport with RADsec, RADIUS over DTLS, or other security measures for a secure system.

For the RADIUS attributes, I wrote about this in a previous blog-post:
Tuning the Cisco ISE for Meraki Networks

The impact of Quantum Computers

For the transition to algorithms that are secure against quantum computers, there is a timeline in the CNSA 2.0 specification:

Commercial National Security Algorithm Suite 2.0

The year 2030 “feels” far away, but for a transition to entirely new algorithms for asymmetric cryptography, six years is not too much time.

The roaming problem

IEEE 802.11-2020 not only specifies AKM 12 for 192-bit security, there is also AKM 13 with FT mode:

The WPA3 specification 3.3 explicitly only allows AKM 12. Josh Schmelzle from Aruba (you want to subscribe to his blog) provided the hint that the reason could be that the FT distribution process could not be 192-bit compliant.

But without Fast BSS Transition support we might see quite slow roams:

The legacy roam mechanism could still work. For example, Sticky Key Caching, which I saw in my Meraki Roaming Analysis:

AP support

My first tests with 192-bit mode didn’t work at all. Obviously, the Supplicant, Authenticator, and also the Authentication server need to support this. My Cisco ISE is fine, as all required EAP ciphers are supported. But when configuring it, the WPA3-192 SSID did not get announced.

The reason was stated in the Cisco WPA3 Deployment Guide:

Note: SuiteB192-1X is not supported in C9120/C9105/C9115 APs and in Flexconnect Mode.

I was using my C9120 in FlexConenct for this test.

Luckily, my mid-range Meraki MR36 and MR44 support 192-bit mode and also the CW916x does. But sadly, there is no visibility into the negotiated parameters in the Meraki-Dashboard. But still better than nothing.

My tests with Juniper Mist also failed. After reading the Product Updates from 2024-03-29, I updated my Mist APs to the required version and configured 192-bit mode, but the SSID was not announced. Later, I discovered that WPA3-192 is only supported on Wi-Fi 6E APs, but my APs are only Wi-Fi 6. Mist Support told me they plan to add support for WPA3-192 on Wi-Fi6 APs later.

The misbehaving clients

When I configured my first SSID for 192-bit mode, my iPhone, iPad, Mac Studio, and MS Surface with Windows 11 connected without problems. Only my Pixel 6a with Android (I think it was version 13 back then) refused to connect. The problem was that I reused my existing certificates. All of these (root, intermediate, server, and endpoints) used keys with 256-bit Elliptic Curves, which only gives a 128-bit security level. My Apple devices and Windows didn’t care. Only Android behaved correctly and refused the connection.

The next problem was the Key Exchange. The Apple devices all announce support for many cipher suits, which are not only disallowed by the WPA3 specification but also provide a security level far below 128 Bit:

My Xiaomi Mi11 was equally bad with the sent cipher suits, my Pixel 6a was much better, but was also not compliant with the WPA3 specification:

Although the supported group is right (and this is what practically matters), the WPA3 specification prohibits three of these cipher suits. I would not complain for practical reasons, as this selection of cipher suits is still highly secure.

PCAP or it didn’t happen

The only interesting frames for the 192-bit mode are:

The Beacon

Quite boring … This is the RSN Information:

The relevant parts are (based on the WPA3 specification and the 8002.11 standard):

• Only AKM 12 is included
• The Pairwise and Group Cipher Suite is GCMP-256
• Same as with “normal” WPA3, MFP is required and the used cipher suite is BIP-GMAC-256.

The EAP-Key Exchange

This is already covered above.

The 4-Way handshake

Here, only two elements are of interest as they change from “normal” WPA2/WPA3 to 192-bit-mode:

• The Key Descriptor Version
• The Key Length

This is Message one of the 4-Way Handshake with WPA3-Enterprise:

This is Message one of the 4-Way Handshake with WPA3-Enterprise in 192-bit-mode:

The Key length changes from 16 to 32 as we use AES-256 instead of AES-128.

The IEEE 802.11-2020 standard defines the Key Descriptor version:

Start Now! – The conclusion

192-bit mode is certainly not for everyone. The missing Fast BSS Transition is a huge drawback in times when people run around while doing Teams calls. Employees from Juniper and Meraki also told me that the adoption of the 192-bit mode is very low.

However, the first step in implementing WPA3-192 should be done regardless of the WPA3 security we plan to use: building a Public Key Infrastructure (PKI) that supports a 192-bit security level. I would go with EC-384 certificates as I consider RSA to be legacy. The recommendations referenced from BSI and ECRYPT see the security of RSA-3072 higher than that of EC-384; this should also be considered.

And this PKI will not only be the reqirement for the 192-bit mode of WPA3. This will also be a requirement for many advanced security challenges in the future.

Conclusion 2: IEEE 802.11-2024 introduces the new AKMs 22 and 23 with similar security. They also use SHA-384 and GCMP-256, and AKM 22 uses FT key management. This could be a better solution for high security in the future.

Have fun implementing the best security possible!