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

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

Thanks Mike for the feedback.

Regarding your specific comment, I do not think OCV is only intended to verify a given security negotiation exchange occurs over a common channel.

As mentioned earlier in the thread, OCI indicates the “maximum bandwidth” - not just the bandwidth of the current exchange. This is also clarified by the requirement in the final sentence of 12.2.9 - i.e. the STA discards any frame that is received from a peer it has negotiated OCV with, if that frame is not on the same primary channel or exceeds the maximum bandwidth it is using for receiving frames from the peer (the values of which have been validated against the received OCI per the rules in that subclause). This requirement is not limited to reception of frames during a specific security exchange.

In addition, note that OCI is sent during SA Query exchange (see 11.13), which is required after a channel switch (see 11.9.3.2). This is because the channel is changed and the new OCI is needed to validate subsequent frames sent by the peer. If OCV were limited to validating only specific security exchanges, then this would not be necessary and the design would have simply just included OCI in each security exchange.

To my understanding, the side-channel aka multi-channel attacks that OCV is designed to mitigate are not necessarily performed on security exchanges (even if the most high-profile example of such attack is); there are a number of references in the literature that can be referred to.

That said, I can see the standard would benefit from a short introductory paragraph that outlines the security properties of OCV, maybe we should work on that.

Finally, I don’t have a strong opinion on the design here (e.g. whether to include additional KDE in OCI, or some other mechanism); but I think it is important there are no regressions in the security properties wrt operating channel validation (lower case) when ML is enabled.

Thanks
Thomas


On Oct 12, 2022 at 3:07:41 PM, M Montemurro <montemurro.michael@xxxxxxxxx> wrote:
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

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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature