Re: [STDS-802-11-TGBN] DoS attack on MAPC ---26/1145 bug fixed part 2

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Hi Giovanni, Mike,

Thanks for the response.

@Giovanni, I think you confused the different operations between the infrastructure BSS and MAPC. In the infrastructure BSS, each associated STA has the BIGTK to verify the received Beacon frame, but MAPC APs do not. As Beacon protection is a mandatory feature in the infrastructure BSS since 11be, I can't live with any fall back when we define new features in 11bn from a security perspective.

Hope the explanation above can help you.

802.11 shall not encourage or remind the implementation of any insecure operation, even if it is in the NOTE. It is insecure behavior for the whole 802.11 SPEC.

The means outside of 802.11 scope is enough, which means 802.11 does not take any responsibility for any insecure implementation. The implementation can adopt any insecure approach if they want, but it is nothing relevant to 802.11 SPEC. Instead, if you really want a NOTE, the NOTE should be something like "An AP can obtain the TSF of another AP by receiving its protected MAPC frames", it's a secure reminder to the implementation. Unfortunately, we do not include any TSF information in current protected MAPC frames at this moment.

To move forward, I will take Mike's suggestion, to remove the text "An AP can obtain the TSF of another AP by receiving its Beacon frames, Probe Response frames." from the cited note.

Make sense to everyone?

Thanks

Best Regards

Jay Yang (杨志杰)

Original

From: GiovanniChisci <00002b657bbbbed7-dmarc-request@xxxxxxxxxxxxxxxxx>

To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>;

Date: 2026年07月04日 03:56

Subject: Re: [STDS-802-11-TGBN] DoS attack on MAPC ---26/1145 bug fixed part 2

Hi Jay, Mike,

I am of the same advise as Mike, and I do not believe that there is any security issue added by a reminder in a note.

Beacon is normally used for time synchronization and TSF is there (nothing new), and for Co-RTWT these issues are actually out of scope of the standard. The note text was added as a reminder of something that is already possible (get TSF from Beacon).

On the other hand I am not sure that a) a timestamp added in a MAPC frame is a reliable timing information, b) that we need to open new spec work for group key and group addressed frame security (the scope of MAPC security was protecting negotiation/unicast frames).

I do not see issues with the current draft on these aspects, and I would be concerned to add spec work in this late stage for group addressed frames security in MAPC.

Best,

Giovanni

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Friday, July 3, 2026 07:46
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] DoS attack on MAPC ---26/1145 bug fixed part 2

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Jay,

I disagree that the standard exposes a DoS attack on MAPC.

My position on co-RTWT is that the synchronization of TSF between peer APs is out of scope (i.e. there are multiple ways that this can be implemented).

So, I agree with resolving this issue by, as you propose, deleting the second sentence of the note "An AP can obtain the TSF of another AP by receiving its Beacon frames, Probe Response frames." from the cited note.

Nothing else needs to be done.

Thanks,

Mike

On Fri, Jul 3, 2026 at 12:12 AM Jay Yang <yang.zhijie@xxxxxxxxxx> wrote:

Hi All,

Based on Alfred's suggestion, I am initiating this mail thread to discuss the serious security issue on MAPC.

The door of DoS attack on MAPC was opened by some members suddenly in draft11bn 1.5 via NOTE3 as below:

NOTE 3—TSF synchronization between a Co-RTWT coordinating(#6406)(#7969) AP and a Co-RTWT coordinated AP, if performed, is out of the scope of this standard.(#11008) An AP can obtain the TSF of another AP by receiving its Beacon frames ,Probe Response frames.

The problem lies in the fact that a MAPC AP has no way to determine whether a Beacon or Probe Response frame originates from a legitimate AP or a fake AP. Thus, an adversary has the opportunity to impersonate a legitimate AP and provide incorrect TSF information via the Beacon and Probe Response frame, which could disrupt the Co-rTWT TSF synchronization function.
On the other hand, once a MAPC AP can obtain the TSF from a Beacon frame, other information (such as CSA, ECSA,etc.) in that Beacon can also be retrieved. This leads to other known security issue. (Refer to the paper: “Attacking WPA3: New Vulnerabilities & Exploit Framework”, page 25)

To address this issue, one temporary approach to prevent a DoS attack is to remove the text: "An AP can obtain the TSF of another AP by receiving its Beacon frames, Probe Response frames." from the quoted NOTE3.

An alternative approach is to include the TSF in the protected MAPC frames. The individually addressed protected MAPC negotiation frame is already defined in the baseline. The missing component is the protected group addressed MAPC Discovery request/response frame, assuming an AP is allowed to overhear the TSF from a group addressed MAPC Discovery request/response frame.
For the latter, what is needed is to add BIP protection to the group addressed MAPC Discovery request/response frame. The two APs can then exchange their MAPC IGTK via the MAPC negotiation frame exchange.

Anyway, the bottom line in 11bn is that we shall not proactively open any known security issue in MAPC. Once we do that, it will not be ready for the coming letter ballot.

Welcome the further insight from our group.

杨志杰10343608

Thanks

Best Regards

Jay Yang (杨志杰)

To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1

To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1