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 and Jouni for the good discussion.

Maybe it’s useful to list a few references and cross-references from Mentor which describe the types of attacks OCV is intended to mitigate.

Reference [1] in 17-1807r12 describes use of a “channel-based MiTM” position to facilitate attacks on the 4-way handshake that (for vulnerable devices) result in nonce reuse.

Reference [5] in 17-1807r12 (sections 5.1 and 5.2) contains some additional background on the class of channel-based attacks - essentially any attack that is facilitated by the MiTM attacker posing as the peer of both devices on different channels, so that the attacker can selectively suppress/forward/modify/replay frames between the peers without them being able to hear each other directly.

Section 6 of that same paper describes another example of a channel-based attack. In that case, the attack is not on the 4-way handshake but rather on other frames sent during data transfer (TKIP MIC Failure report EAPOL-Key frames in that particular case).

The 2nd reference in 21-0816r3 (the Mentor doc itself is not about OCV explicitly, but the referenced paper discusses it in sections 1 and 2.4) describes several attacks facilitated by a channel-based MiTM position, which are not on a 4-way handshake (or any other security exchange) but rather involve (to give one example) manipulation of unprotected MAC headers of data frames that (for vulnerable devices) results in ability to inject packets.

To my understanding, OCV is not intended as the primary resolution to those specific vulnerabilities, but it is intended as a hardening for (as yet unknown) future attacks that are facilitated by the channel-based MiTM position.
In baseline (non-ML) OCV, I believe this whole class of attacks is mitigated by the text in subclause 12.2.9, in particular the final sentence:
If a STA with OCVC capability receives a frame from (#1414)a peer STA that is not on the same primary channel (or frequency segment 1 channel number) used by the STA to receive PPDUs from the peer STA, or has bandwidth that exceeds the maximum bandwidth used by the STA to receive PPDUs from the peer STA, the frame is discarded.
(where the STA’s understanding of the “channel [and maximum bandwidth]… used by the STA to receive PPDUs form the peer STA” is validated against OCI in the preceding paragraph) 

However, with the behavior currently specified in 11be draft, in which an MLD STA only receives OCI on the link on which the 4-way is performed, one could interpret the text in 12.2.9 in different ways, none of which seem to have a good outcome:
(1) If it is interpreted that all links are used at the time the 4-way is performed (even if they are not active at that moment in time due to the “same link” rule for security exchanges), then OCI validation during 4-way would always fail because the STA is using channel(s) to transmit/receive PPDUs from the peer STA that are not present in the OCI
(2) Alternatively, if it is interpreted that the other links are not used until the 4-way has completed, then OCI validation during 4-way would succeed, but strictly speaking the text above would require the STA to discard all frames received on the other link(s), because the channels/bandwidths those frames are received on was not validated against the OCI
(3) Alternatively, if a looser interpretation of the text in 12.2.9 is taken (e.g. that the other links do not come into use until after the 4-way but that the channels of those links do not need to be validated against the OCI), then OCV would not protect against attacks of the class as described above, if those attacks are performed after the 4-way (or other security exchanges) on the other link(s).


Thanks
Thomas



On Nov 9, 2022 at 6:28:06 AM, M Montemurro <montemurro.michael@xxxxxxxxx> wrote:
HI Jouni,

Thanks for your detailed response. Here are my comments:

1. At this point, the Authentication Association, and 4-way handshake are required to be performed on the same channel (i.e. on a single link).

2. There have been non modifications at this point on re-keying. So, for the 4-way handshake,  the EAPOL-Key request message is encrypted. Would it be sufficient to ensure that the 4-way handshake includes the OCI and occurs on the same link as the EAPOL-key request message? The group key handshake can occur on any link. Wouldn't it be sufficient to require the OCI KDE for MLO?

3. I believe the channel switch is protected, is it not? I agree that any group key delivery after disabling a link temporarily and re-enabling the link needs to be protected. 

4. As I said, these comments don't identify an underlying issue that is not already addressed by OCV, beacon protection, and management frame protection. We need to identify the gap where existing mechanisms do not provide sufficient protection. Personally I'd like to see a new set of comments in the next round of balloting to identify and address the gaps. 

I'm also willing to work offline to do this work in parallel with balloting and comment resolution.

Cheers,

Mike  

On Tue, Nov 8, 2022 at 5:26 PM Jouni Malinen <jkmalinen@xxxxxxxxx> wrote:
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.

- Jouni


On 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,

Mike

On 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.

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

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