[RFC PATCH v1 00/13] SAE DecoyAuth multi-password authentication with FT/MLO support

[Jeff Hansen]

Jouni,

Thank you for acknowledging that this is a critical deployment problem.

I’m not convinced we can dismiss privacy and provisioning UX as barriers to password identifiers. Their limited adoption does not establish why vendors have held back, but it warrants asking what those barriers are rather than assuming the identifier model will eventually be accepted.

I agree that a station can refuse to disclose its identifier. But if that means it cannot connect or recover, we have shifted the privacy-versus-connectivity decision to the client rather than resolved it. That requires an interoperable industry solution, not just a station policy.

DecoyAuth also requires client changes, but preserves the existing SSID-and-password provisioning experience. That is a meaningful difference from requiring an additional identifier, even if that identifier is subsequently protected.

Regarding PQC, which proposals establish that a separate user-provisioned identifier will be necessary? Is that a requirement of particular designs, or a fundamental constraint? I would not want us to rule out password-only approaches prematurely.

I understand the “small audience” to mean STA-platform implementers. What would convince that audience, and is their commitment a prerequisite for upstream consideration, or a separate deployment challenge? Are there specific technical objections to DecoyAuth that we can address now?

-Jeff

> On Oct 3, 2026, at 2:37 AM, Jouni Malinen <j at w1.fi> wrote:
> 
> On Fri, Oct 02, 2026 at 09:51:55AM -0600, Jeff Hansen wrote:
>> My understanding was that password identifiers were intended to address this gap in WPA3-SAE. From my perspective, they still leave a couple of challenges for this use case:
>> 1. Password identifiers are still sent in the clear for the first connection, so the identity is not anonymous. Even with the PID encryption enhancements, my understanding is that a rogue AP can force the client to divulge the clear-text PID again.
> 
> I don't really think that would be a real showstopper for deployment..
> And in any case, it is up to the station to decide whether it would
> expose the cleartext identifier again.
> 
>> 2. It's a different user experience from the existing PPSK/MPSK solution, especially for MDUs. There is no backward compatibility, and station OS vendors appear hesitant to add another field for joining a network.
> 
> That is much more likely concern. However, there is also common
> understanding that the new model of a separate identifier (username) is
> going to be needed in future for PQC and today for WPA3-Enterprise, so
> it is not like this is going to be something that can be avoided
> indefinitely and the question is really on when to do that change in
> user experience.
> 
>> There is considerable interest from MDU managed-Wi-Fi operators: https://www.linkedin.com/feed/update/urn:li:activity:7282773188655095809/ That interest may not be well represented in IEEE conversations yet.
>> 
>> I know of MSPs that are not installing 6 GHz, or are disabling it for the time being, because of this gap in WPA3-SAE.
>> 
>> I'll be presenting to TGmf next week to work toward a path for integration into the 802.11 spec, as you've suggested.
>> 
>> Would feedback from those operators help demonstrate deployment interest? I recognize that station OS vendor support is a separate piece we still need to establish.
> 
> IMHO, this issue is known and critical to address and I see no need for
> any additional justification to address it. It is the STA side
> deployment of support for a new capability that needs convincing towards
> a very small audience..
> 
> -- 
> Jouni Malinen                                            PGP id EFC895FA