Re: [STDS-802-11-TGBE] Security comment resolutions on OCVC

[M Montemurro <montemurro.michael@xxxxxxxxx>]

Thanks for all of your comments. 

Unfortunately I respectfully disagree. The purpose of OCVC is to ensure that both parties in a security negotiation verffy that they are communicating on the same channel. Once the security association has been established, there may be some implicit notion that the two parties are communicating on the same channel, but OCVC does not provide this assurance. Furthermore, the PTKSA is established between an AP MLD and non-AP MLD and secure communication should be able to work over any link, analogous to how a VPN tunnel can work over multiple IP subnets.

If there is a requirement to somehow cryptographically verify the operating channel of each link negotiated during MLO establishment, I'd like to understand the vulnerability and the proposal for how it would be mitigated.

Cheers,

Mike

On Wed, Oct 12, 2022 at 6:01 PM Duncan Ho <dho@xxxxxxxxxxxxxxxx> wrote:

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.

Hi  Mike, 

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, 

Yongho 

 

2022년 10월 7일 (금) 오전 8:56, Thomas Derham <00000ad2eabc2931-dmarc-request@xxxxxxxxxxxxxxxxx>님이 작성:

Hi Mike

 

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.

 

Thanks

Thomas

 

 

On Oct 7, 2022 at 8:22:20 AM, M Montemurro <montemurro.michael@xxxxxxxxx> wrote:

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.  

 

Thanks,

 

Mike

 

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

---

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