| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
17-1807r12 describes the desire to proactively protect against cases where an attacker can get into a position where the legitimate AP and non-AP STA operate on different channels, i.e., for the case where the attacker does not need to prevent the legitimate STAs from seeing frames from each other. Before MLO, it would be sufficient to confirm that the STAs are indeed on the same channel for the exchanges that are used for deriving or distributing keys and move to the same channel in case of a channel switch. It should be relatively straightforward to extend that to the MLO cases. The part about protecting a specific exchange (i.e., the exact frames used in that exchange) can be covered by the existing OCV design if those exchanges are required to occur on a single channel. Is that required for all cases in P802.11be now? As an example, is a 4-way handshake required to be performed on a single link? Even when this is used for rekeying PTK (i.e., not just the initial case at a beginning of an association)? If there is no such constraint on link selection, that might need to be added or this might need an extension in OCV.The more complex case with avoiding cases where the legitimate STAs might end up getting into different understanding on the links that the other end is listening to would include normal channel switch cases. Those per-link operations should already be covered by the existing OCV mechanism. However, this would also cover cases where either end of a link could stop using that link either temporarily or permanently, e.g., due to disabling a link temporarily for power saving purposes or whatever other reasons and mechanisms might be available in the protocol. If those exchanges are not protected, the existing proactive protection against multi-channel MITM attacks from OCV might be lost.The exact mechanisms for protection might be a combination of OCV, beacon protection, management frame protection, and something new, so this might indeed not need an extension of the OCI element. In any case, I'm not yet convinced that what is in the current draft is sufficient to maintain the properties that OCV was designed to provide and as such, while the comments describe the issue as a need to modify extend OCI to cover all the links which may not be the best way to approach this, the underlying issue seems to be present and should be addressed either with these comments or independently of them, if desired. If this is not addressed, I'd expect there to be need to revisit this once we get to the next ballot and the updated set of comments from it.- JouniOn Thu, Nov 3, 2022 at 3:51 PM M Montemurro <montemurro.michael@xxxxxxxxx> wrote:Hello Thomas,Thanks for your reply. According to the contribution that added OCV: https://mentor.ieee.org/802.11/dcn/17/11-17-1807-12-000m-defense-against-multi-channel-mitm-attacks-via-operating-channel-validation.docx. which you are co-author, OCV is designed to protect against multi-channel MITM attacks. I see nothing in this contribution that describes how OCV protects any communications other than the attack described in this contribution. Nor have you explained how this works other than an off-hand comment about "side channel"Furthermore, with MLO, the security association is established between the AP MLD and non-AP MLD so that encrypted traffic can be exchanged over any link. I do agree that beacon protection and management frame protection are important, but I don't see a need at this point to validate the channel and bandwidth information on each link.Before adding or extending requirements to P802.11be to extend protection, I would like to understand what we are trying to protect against. I'd be happy to help once that is understood.Cheers,MikeOn Wed, Nov 2, 2022 at 3:44 PM Thomas Derham <thomas.derham@xxxxxxxxxxxx> wrote: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.ThanksThomas
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,MikeOn 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
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