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

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.






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

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