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,

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