Fast and Secure Simultaneous Authentication of Equals for WPA3

What it is

An academic proposal (arXiv:2609.31519v1, Ferreira/Zúquete/Gomes, University of Aveiro, Sep 2026) for a modified WPA3-SAE handshake that removes the AP's CPU-exhaustion DoS exposure. It is implemented — the modified hostapd v2.10 code is public at https://github.com/joaopferreira01/fast-sae-wpa3. The design splits authentication into two paths: a Resource Intensive Initial Exchange (RIIE) and a Stateless Fast Track Resumption (SFTR).

How it works

The summary states that PE-discovery moves to the client; the page gives the mechanism that makes single-step AP verification possible. Instead of both peers iterating Hunting-and-Pecking, SAE_ctr is derived deterministically as SAE_ctr = HMAC_pwd_hash(s), where pwd_hash = H(PSK). The Supplicant iterates (incrementing p, recomputing s) until it finds a valid curve point; the AP recomputes the same SAE_ctr from the received s and its cached pwd_hash in one step.

This introduces a new weakness the authors acknowledge: because the AP no longer iterates, an eavesdropper can test PSK guesses directly against the observed s, collapsing the offline-attack cost. That is precisely why H must be a slow KDF (PBKDF2/Argon2) — the slow path is not just throttling, it replaces the brute-force resistance the iteration loop used to provide. Iteration count and salt are broadcast in a vendor-specific Beacon/Probe IE (16-byte salt + 2-byte iteration count; the captured example shows 4096 iterations).

Ticket resumption (SFTR) is signalled by overloading s in the Commit frame, which normally must exceed 1:

• Supplicant sends s = 0 plus the ticket in place of E.
• AP accepts → replies s = 0 with random E.
• AP rejects → replies s = 1 and terminates.

Tickets carry a sequential TID and a future random PMK, encrypted under a locally-held Secret Ticket Encapsulation Key (STEK) using Encrypt-Then-MAC. The AP stays stateless; replay is blocked by an IPSec-style sliding-window check on TIDs, and STEK refresh revokes all outstanding tickets (relevant after a PSK change meant to evict users).

flowchart TD
    A[SAE Commit received] --> B{s value}
    B -->|s=0 + ticket| C[Validate STEK-MAC, recover PMK']
    B -->|s>1| D[RIIE: recompute SAE_ctr from s, single-step PE verify]
    C -->|valid| E[Reply s=0, proceed to 4-Way HS]
    C -->|invalid| F[Reply s=1, terminate]
    D --> G[Issue new STEK-encrypted ticket]

Caveats

This is a proposal with experimental results asserted but no numbers in the fetched text — no benchmark figures, DoS thresholds, or comparison metrics are quoted beyond the qualitative claim that per-request AP load becomes constant. The security analysis section is truncated. Treat the s-overloading and STEK design as a research design to evaluate, not a standardised or independently reviewed mechanism; the shift of dictionary-attack resistance onto the KDF means the chosen iteration count (4096 in the demo) is now the load-bearing parameter.