The original DecoyAuth implementation only supported a handful of passwords, and we have extended it to hundreds of passwords using fragmentation. Are you looking for more passwords than that? If so, DecoyAuth could be combined with Password
Identifiers to allow for thousands of individual apartments to have their own Identifier, and then multiple non-guest and guest DecoyAuth passwords under the parent Password Identifier. In that case you’d only need a handful of DecoyAuth passwords.
As it stands with DecoyAuth alone, I wouldn’t recommend more than 500 passwords, but I did discuss some ways that it could be extended further than that with 1) interpolation matrix caching (included in our hostap implementation changeset),
2) purpose-built DecoyAuth hardware accelerators, but those are out of the scope of this project, though it is important to know what the limits of DecoyAuth are.
From what I know, the password identifier of 802.11bi is always sent in-the-clear for the first authentication. I do have concerns with Rogue APs causing a STA to reset back to a first authentication state (think of a user being unable
to join the Rogue AP, then eventually forgetting and re-connecting), and send the cleartext identifier again.
On Oct 12, 2026, at 5:10 AM, TaoChun Lee (李道軍) <TaoChun.Lee@xxxxxxxxxxxx>
wrote:
Hi Jeff,
It seems this approach might have scalability issues for large password sets (avoid fragmentation), also with 11bi privacy enhancement, password identifiers are
no longer cleartext over the air.
For separate authorization, probably we can give it more thoughts.
--
Tao Chun Lee | Tech Manager, Standards | Communication System Design, MediaTek Inc.
Email: TaoChun.Lee@xxxxxxxxxxxx |
Phone: +886 3 560 0868 | Website: www.mediatek.com
-----Original Message-----
From: Jeff Hansen <0000650aeb4ec973-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Friday, October 9, 2026 11:52 PM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGM] DecoyAuth for TGmf
External email : Please do not click links or open attachments until you have verified the sender or the content.
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hello all,
Thank you for the opportunity to present DecoyAuth to TGmf. I would appreciate technical feedback on the presentation and proposed normative changes:
• 11-26/1971r0: DecoyAuth: Password-only multi-password SAE
• 11-26/1982r0: DecoyAuth changeset
The proposal enables a station to authenticate using one of several AP-configured passwords without transmitting a password identifier. Our implementation has been exercised
with 512 passwords, password-specific VLAN selection, PMKSA caching, MLO, and FT-SAE roaming.
I am particularly seeking review of:
• The cryptographic construction and password-selection procedure.
• The fragmented exchange, state transitions, and denial-of-service considerations.
• Capability negotiation, fallback behavior, and completeness of the proposed normative text.
I also see potential complementary uses alongside password identifiers: multiple credentials under one tenant/account identifier could support owner/guest access, individually
revocable device passwords, or overlapping old/new passwords during rotation. That extension is not included in the current changeset.
Specific clause references, suggested corrections, or pointers to existing mechanisms that address these requirements would be especially helpful. Guidance on the appropriate
next step within TGmf would also be appreciated.
Thank you,
Jeff Hansen
Alta Labs
_______________________________________________________________________________
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand.
SELF SERVICE OPTION:
Point your Browser to - https://urldefense.com/v3/__http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM__;!!CTRNKA9wMg0ARbw!h3n6EjOId6NmoWwp2ErmRFoepi31ND7MTTc1LhzMs3T7_WDuAVMt-UtXNq6ZS44XLJ_legHvr11VjjgoYFglNnokHHhvRa-Xju9V$
and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button.
Further information can be found at: https://urldefense.com/v3/__http://www.ieee802.org/11/Email_Subscribe.html__;!!CTRNKA9wMg0ARbw!h3n6EjOId6NmoWwp2ErmRFoepi31ND7MTTc1LhzMs3T7_WDuAVMt-UtXNq6ZS44XLJ_legHvr11VjjgoYFglNnokHHhvRT5x-tiV$
_______________________________________________________________________________
************* MEDIATEK Confidentiality Notice ********************
The information contained in this e-mail message (including any
attachments) may be confidential, proprietary, privileged, or otherwise
exempt from disclosure under applicable laws. It is intended to be
conveyed only to the designated recipient(s). Any use, dissemination,
distribution, printing, retaining or copying of this e-mail (including its
attachments) by unintended recipient(s) is strictly prohibited and may
be unlawful. If you are not an intended recipient of this e-mail, or believe
that you have received this e-mail in error, please notify the sender
immediately (by replying to this e-mail), delete any and all copies of
this e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. Thank you!