Hi Mike,
I second Thomas’ comments.
Thanks,
Duncan
From: Yongho Seok <yongho.seok@xxxxxxxxx>
Sent: Friday, October 7, 2022 2:28 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Security comment resolutions on OCVC
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
I have a similar comment with Thomas.
Rathern the Beacon protection, the operating channel validation through the pairwise key is more robust.
For example, if an attacker has a valid secure association with an AP, it can generate the protected Beacon frame having a fake operation channel information in the RNR for other links. It can make the victim operate on the fake channels
for the specific link.
More robust way is to carry the OCI KDE for the other links during a 4-way handshake.
Thanks for looking into this. I have a few comments as follows:
The purpose of OCVC was to verify that an ongoing exchange was taking place on the channel that both parties believed to be the same
To my understanding, OCV is not *only* intended to ensure that the “current” (aka ongoing) exchange occurs on a channel that both parties believe are the same.
It is intended to ensure that all exchanges between those peers during the association (or until another OCI exchange occurs) occur on a channel that both parties believe are the same.
Specifically, 12.2.9 (REVme D1.4) refers to matching the “current operating channel parameters” by (to give one example) “verifying that the maximum bandwidth used by the STA to transmit or receive PPDUs to/from the peer STA … is no greater
than the bandwidth of the operating class … in OCI”.
So in a simple pre-EHT example where 160M AP and 80M STA are associated, that bandwidth being validated would be the primary 80M of the BSS, even if the actual “ongoing exchange” (e.g. 4-way) is only sent on the primary 20M.
Or to give another example of 80+80, both segments are validated even if the “ongoing exchange” is only on (part of) one of the segments.
Given that for MLO, the exchanges take place on the same link, existing OCVC procedures will work as specified in the baseline. There is no need to include link ID information in the OCI KDE.
So now extending this to the MLO case, it is necessary to validate all the links, not just the link on which the 4-way occurs.
If this is not done, and therefore one of the links is not validated, then OCV would not protect against a multi-channel attack on the link that the 4-way was not sent on.
Furthermore, the requested links provided in the reassociation request, and the links advertised links included beacons and probe responses are both validated as part of the 4-way handshake.
To my understanding, the 4-way contains KDEs that indicate the MLO Link IDs and MAC addresses, but does not contain the actual channels information for those links.
Also (although it is not mentioned in your mail), I have seen some discussion about the Beacon Protection mechanism being an alternative to OCV since the AP’s channel information for each link can be verified in the beacons of each link.
However I think there are some limitations of that approach compared with OCV, including the following:
-
Beacon Protection uses a group key (BIGTK) for integrity protection whereas OCVC uses pairwise key; therefore the latter is not vulnerable to insider attack
-
Beacon Protection allows one-way validation (i.e. STA can validate the AP’s advertisement of operating channels against the STA’s own understanding), whereas OCV provides mutual validation (i.e. AP can also validate the peer STA’s advertisement against the
AP’s own understanding).
Given the context under which the OCV feature was developed, it seems we should assess these relative security properties if we are considering BP as a “replacement” for OCV.
Hello all,
I took a second look at the following comments on OCVC, which were deferred (see bottom if email)
The purpose of OCVC was to verify that an ongoing exchange was taking place on the channel that both parties believed to be the same. Given that for MLO, the exchanges take place on the same link, existing OCVC procedures will work as specified
in the baseline. There is no need to include link ID information in the OCI KDE.
Furthermore, the requested links provided in the reassociation request, and the links advertised links included beacons and probe responses are both validated as part of the 4-way handshake.
I'm inclined to reject these CIDs unless somebody can provide some explanation on what the problem is and why providing operating channel information for links addresses the issue.
Comment
|
CID
|
Clause
|
Page
|
Line
|
Comment
|
Proposed Change
|
|
11071
|
12.7.6.1
|
355
|
45
|
The description implies that OCI KDE can be used for MLO. However, OCI KDE needs to be redesigned to include link ID and information for 320 MHz verification because 320 MHz
may have 320 MHz-1 or 320 MHz-2.
|
Define MLO OCI KDE. Ideally, follow the format of OCI KDE to include link ID and change "Frequency Segment 1
Channel Number" to simply "Channel center frequeny of 320 MHz", which is set to channel center frequency of 320 MHz when 320 MHz is used and 0 otherwise.
|
|
10678
|
12.7.6.3
|
358
|
46
|
For MLO, OCI verification should occur on all the links. Will need to make sure OCI works correctly for MLO. e.g., we should include the OCI KDE for each requested link in msg
2 for the AP MLD to verify the operating channels of the STAs corresponding to the requested links
|
As in the comment
|
|
10679
|
12.7.6.4
|
361
|
11
|
For MLO, OCI verification should occur on all the links. Will need to make sure OCI works correctly for MLO. e.g., we should include the OCI KDE for each requested link in msg
3 for the non-AP MLD to verify the operating channels of the APs corresponding to the requested links
|
As in the comment
|
|
14100
|
12.7.2
|
351
|
5
|
OCI KDE should have a corresponding MLO KDE defined because RNR in ML probe response is not protected
|
As in comment
|
To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
|