Re: [STDS-802-11-TGM] 11-26/0789r0: SAE group downgrade detection in mesh networks
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Unfortunately, I might have to miss the upcoming TGmf discussion on
this due to a conflict with TGbi. It looks like the updated 789r1 is
proposing mitigation #1 to be standardized. If that is the selected
direction, I would consider a different approach for downgrade
protection instead of continuing to use the somewhat complex use of
listing the rejected groups. The new option would be to include the
list of all supported groups in the SAE commit when both peers
indicate support for the new mechanism (which is done in option #1).
The lists of the supported groups from each peer would then be
concatenated into the salt (this can use an explicit length/delimiter
as well, but that is not as important for this case since each peer
know their own list of supported groups and it is obvious that
anything else is from the peer). This type of use of supported groups
instead of rejected groups is likely much more convenient to use and
less likely to result in strange corner cases since it is a static
list and does not depend in the order in which the various groups are
attempted in any particular instance of SAE authentication. In
addition, listing the supported groups in the first message would
allow optimization for group negotiation cases by removing need to
probe groups one by one multiple times.
PS.
Indicating the supported groups is also the way that P802.11bi ended
up getting extended to cover downgrade protection for SAE group
negotiation for cases where SAE is wrapped in PASN/EPPKE
Authentication frames.
- Jouni
On Sun, May 3, 2026 at 3:07 PM Mathy Vanhoef <mathy.vanhoef@xxxxxxxxxxx> wrote:
>
> --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
> Dear all,
>
> At the May Interim, I will present 11-26/0789r0, which discusses an issue with SAE group downgrade detection in mesh networks. This topic was previously presented during the teleconf on 20 April, where the recommendation was to also share it on the mailing list so that people can review it in advance.
>
> Arguably, the main question is which mitigation would be most appropriate. The document expresses a slight preference for mitigation #2 or #3, but it may also be worth considering mitigation #1 as the defence to standardize, since it appears to be the most proper solution and requires support from both STAs. Individual vendors could then still choose to implement mitigation #2 if they wish, as it can be adopted independently by a single STA.
>
> Best regards,
> Mathy
> ________________________________
>
> To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1
_______________________________________________________________________________
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 - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM 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: http://www.ieee802.org/11/Email_Subscribe.html
_______________________________________________________________________________