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

Re: [STDS-802-11-TGM] 11me/D0.0 CID 193 (per-whatness of RCs)

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

Hello,

 

I am quite bewildered by all this procedural wibbling.  However, to try to

move past it and focus on substance, let me try again with a preamble and

further details in the Discussion section:

 

Below is my proposed resolution for CID 193, which was assigned to me on

Monday 23 August.  It is a copy from the draft of 21/0829 on my hard drive,

which is not yet on Mentor, but will be, and has "Submission" in the

bottom left corner of every page.  This post is made to gain a broader

audience, and is not intended to and does not replace discussion in a TGme

meeting, or incorporation of feedback and tracking of revisions on Mentor.

You are free to ignore this post if you do not find it useful/interesting

(similarly to how NOTEs in the 802.11 spec can just be ignored).

 

Mr Chair, please indicate when there will be agenda time for presentation

of the submission (from 21/0829 on Mentor, to be uploaded).

 

Identifiers

Comment

Proposed change

CID 193

Mark RISON

12.5.3.4.1

2577.30

"The decryption processing prevents replay of MPDUs by validating that the PN in the

MPDU is greater than the replay counter maintained for the session." should be ... "and TID" or "and AC" to allow for reordering across TIDs/ACs, where the receiver has indicated support for multiple replay counters (so maybe better as "(or the replay counter corresponding to the TID, if more than one replay counter is supported)"  Or actually, since in 802.11 (unlike WMM) you allocate TIDs up to the max num replay counters supported, maybe just say "replay counter maintained for the session for that TID"?)

Change to "The decryption processing prevents replay of MPDUs by validating that the PN in the

MPDU is greater than the replay counter maintained for the session for that TID."  Ditto at 2587.36.  At 2577.49 change "the PN in the CCMP

header is greater than the replay counter maintained for the session and TID/ACI." to "the PN in the MPDU is greater than the replay counter maintained for the session for that TID."

 

Discussion:

 

As the comment points out, in 802.11 (as opposed to WMM) for Data frames you use TIDs up to the max number of replay counters supported, at which point you can’t use any other TIDs for that SA (though this is clearer for CCMP than for GCMP):

 

12.5.3.3.7 CCM originator processing

 

A transmitter shall not use an IEEE 802.11 MSDU or A-MSDU priority if this would cause the total number of priorities used during the lifetime of the SA to exceed the number of replay counters supported by the receiver (for a pairwise SA) or all the receivers (for a group SA) for that SA.  The transmitter shall not reorder CCMP protected frames that are transmitted to the same RA within a replay counter, but may reorder frames across replay counters. One possible reason for reordering frames is the IEEE 802.11 MSDU or A-MSDU priority.

 

12.5.5.3.6 GCM originator processing

 

A transmitter shall not use IEEE 802.11 MSDU or A-MSDU priorities without ensuring that the receiver supports the required number of replay counters.  The transmitter shall not reorder GCMP protected frames that are transmitted to the same RA within a replay counter, but may reorder frames across replay counters. One possible reason for reordering frames is the IEEE 802.11 MSDU or A-MSDU priority.

 

The number of replay counters supported for each PTKSA and GTKSA is indicated in the RSN Capabilities field of the RSNE: it can be 1, 2, 4 or 16 (see Table 9-152—PTKSA/GTKSA replay counters usage).  Therefore as pointed out in the comment, the _expression_ “the replay counter maintained for the session” only works if the receiver is only capable of 1 RC per SA and requires further qualification otherwise (this is already done for PV1 (in 12.5.3.4.1.b).6)) but not for PV0 (whether CCMP or GCMP)).

 

In addition to this, there are replay counters for MFP (one for each of individually addressed robust Management and individually addressed robust PV1 Management) and for QMF (one for each ACI of individually addressed robust Management -- it’s not clear whether this is also used for individually addressed robust PV1 management or whether there’s a separate set of 4), when enabled:

 

12.5.3.4.4 PN and replay detection

 

If dot11RSNAProtectedManagementFramesActivated is true, the recipient shall maintain a single replay counter for received individually addressed robust Management frames that are received with the To DS subfield equal to 0, and a single replay counter for received individually addressed robust PV1 Management frames and shall use the PN from the received frame to detect replays. If dot11QMFActivated is also true, the recipient shall maintain an additional replay counter for each ACI for received individually addressed robust Management frames and robust PV1 Management frames that are received with the To DS subfield equal to 1. The QMF receiver shall use the ACI encoded in the Sequence Number field of the received frame to select the replay counter to use for the received frame, and shall use the PN from the received frame to detect replays.

 

It would appear that the MFP/QMF counters are not subject to any maximum per SA limit, i.e. there are always 1/4 of them respectively per SA, irrespective of the number of replay counters support signalled in the RSN Capabilities field of the RSNE.

 

In addition to this, there are a bazillion replay counters for group addressed robust Management frames under MFP and under QMF, when enabled; see 12.5.4.6 BIP reception.

 

So the replay counters are per-ACI for QMFs under MFP, per-TID for Data frames (but up to maximum total number per SA) and a singleton for non-QMF robust Management frames under MFP and (if individually addressed) not sent to an AP.

 

Also note the subtle “the PN in the CCMP header” for PV1, cf. “the PN in the MPDU” for PV0.  This is because for PV1 the CCMP header is constructed locally, not actually carried in the MPDU:

 

12.5.3.2 CCMP MPDU format

 

The CCMP header is not included in secure PV1 MPDUs, but constructed locally at the STA as defined in 12.5.3.3.6 (Construct CCMP header for PV1 MPDUs).

 

12.5.3.3.6 Construct CCMP header for PV1 MPDUs

 

The CCMP header is not present in secure PV1 MPDUs, but constructed locally at the STA as follows:

 

The proposed change from “in the CCMP header” to “in the MPDU” missed this point; it would be helpful to be more explicit about this.

 

Note PV1 is not supported with GCMP, so we don’t need to worry about that.  [Having said that, I can’t find the specific statement in the spec!]

 

Proposed changes:

 

Change 12.5.5.3.6 GCM originator processing as follows:

 

A transmitter shall not use an IEEE 802.11 MSDU or A-MSDU priorities without ensuring that the receiver supports the required number of replay countersy if this would cause the total number of priorities used during the lifetime of the SA to exceed the number of replay counters supported by the receiver (for a pairwise SA) or all the receivers (for a group SA) for that SA.  The transmitter shall not reorder GCMP protected frames that are transmitted to the same RA within a replay counter, but may reorder frames across replay counters. One possible reason for reordering frames is the IEEE 802.11 MSDU or A-MSDU priority.

 

Change 12.5.3.4.1 General (under 12.5.3.4 CCMP decapsulation) as follows:

 

5) The decryption processing prevents replay of MPDUs by validating that the PN in the MPDU is greater than the replay counter maintained for the session, and TID (for Data frames) or ACI (for QMFs).

 

            […]

 

6) The decryption processing prevents replay of MPDUs by validating that the PN in the locally constructed CCMP header (see 12.5.3.3.6) is greater than the replay counter maintained for the session, and TID/ (for Data frames) or ACI (for QMFs).

 

Change 12.5.5.4.1 General (under 12.5.5.4 GCMP decapsulation) as follows:

 

e) The decryption processing prevents replay of MPDUs by validating that the PN in the MPDU is greater than the replay counter maintained for the session, and TID (for Data frames) or ACI (for QMFs).

 

Change “TID/ACI” to “TID (for Data frames) or ACI (for QMFs)” at:

 

·         2571.47 (“1) When the sequence number of the MPDU is less than the previous sequence number and satisfies the BPN update conditions in 12.5.3.3.6 (Construct CCMP header for PV1 MPDUs) for that TID/ACI, increment the base PN so that the PN never repeats for the same temporal key and TID/ACI.” in 12.5.3.3(.1) CCMP cryptographic encapsulation)

·         2572.37 (“For PV1 MPDUs, the PN shall never repeat for a series of encrypted MPDUs using the same temporal key and TID/ACI.” in 12.5.3.3.2 PN processing)

·         2575.59 (“The locally stored BPN shall be incremented by 1 when the sequence number of the MPDU is less than the previous sequence number for that TID/ACI if any of the following two conditions is satisfied:” in 12.5.3.3.6 Construct CCMP header for PV1 MPDUs)

 

Proposed resolution:

 

REVISED

 

Make the changes shown under “Proposed changes” for CID 193 in <this document>, which address the issues raised by the commenter.  Note to the commenter: there is no PN in PV1 MPDUs; instead the PN is generated locally.

 

Thanks,

 

Mark

 

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223  434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223  434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

 

From: Jon Rosdahl <jrosdahl@xxxxxxxx>
Sent: Wednesday, 25 August 2021 05:08
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] 11me/D0.0 CID 193 (per-whatness of RCs)

 

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

Mark,

The reflector is for the technical discussion.

Mentor is where we post the submissions.

the lower left corner of the document has the word "submission"...

The reason for "posting" to the reflector is to gain a broader audience than those on the teleconference.

so I don't see any conflict in his request.

Jon

 

-----------------------------------------------------------------------------

Jon Rosdahl                             Engineer, Senior Staff
IEEE 802 Executive Secretary   Qualcomm Technologies, Inc.
office: 801-492-4023                  10871 North 5750 West
cell:   801-376-6435                   Highland, UT 84003


A Job is only necessary to eat!
A Family is necessary to be happy!!

 

 

On Tue, Aug 24, 2021 at 1:25 PM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

OK, so on Monday you complained that I hadn't posted something to

the reflector and now you're complaining that I have posted something

to the reflector.  What is the rule for what should and shouldn't

be posted to the reflector, and when?

 

Thanks,

 

Mark

 

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223  434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223  434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

 

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Wednesday, 25 August 2021 04:19
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx; Jouni Malinen (jouni@xxxxxxxxxxxxxxxx) <jouni@xxxxxxxxxxxxxxxx>; mark.hamilton2152@xxxxxxxxx
Subject: Re: 11me/D0.0 CID 193 (per-whatness of RCs)

 

Hey Mark,

 

One thing I would also like to clarify is that a submission means a document posted to a mentor. In that way, we can incorporate feedback and track revisions properly.

 

Thanks,

 

Mike

 

On Tue, Aug 24, 2021 at 3:10 PM M Montemurro <montemurro.michael@xxxxxxxxx> wrote:

Hey Mark,

 

You are the commenter. Your discussion in your previous email on this thread goes beyond what is in  the Comment and Proposed Resolution fields for the comment. Given that this comment is a Security adhoc comment, I am assigning it back to the commenter and marking it "Submission Required". 

 

With respect to the scope of the comment, I'm assigning it to you so that you can solicit feedback from the group. We haven't had an initial LB yet so personally I don't see whether it matters whether we try to do things before or after D1.0.  

 

Cheers,

 

Mike

 

 

 

On Tue, Aug 24, 2021 at 2:44 PM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

Hello Mike,

 

> Based on your response below, I'm going to mark this comment "Submission Required" and assign it to you.

 

Err, this was assigned to me on Monday, and this is my submission!

What more are you expecting from me?

 

> My personal opinion based on this analysis is that your suggested resolution goes way beyond the scope of the comment or the proposed resolution. 

 

I suppose it goes slightly beyond in part.  I would say the stuff I now

highlight in green and cyan below is within the scope of the comment,

and in yellow arguably not.  But why wait until D1.0 to sort out the

stuff in yellow?

 

Thanks,

 

Mark

 

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223  434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223  434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

 

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Wednesday, 25 August 2021 02:20
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx; Jouni Malinen (jouni@xxxxxxxxxxxxxxxx) <jouni@xxxxxxxxxxxxxxxx>; mark.hamilton2152@xxxxxxxxx
Subject: Re: 11me/D0.0 CID 193 (per-whatness of RCs)

 

Hi Mark,

 

Based on your response below, I'm going to mark this comment "Submission Required" and assign it to you.

 

My personal opinion based on this analysis is that your suggested resolution goes way beyond the scope of the comment or the proposed resolution. 

 

Cheers,

 

Mike

 

 

 

On Tue, Aug 24, 2021 at 11:31 AM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

Hello,

 

This turned out to be a bit worse than I expected!  Please tell me of

any mistakes or omissions in the following.

 

Identifiers

Comment

Proposed change

CID 193

Mark RISON

12.5.3.4.1

2577.30

"The decryption processing prevents replay of MPDUs by validating that the PN in the

MPDU is greater than the replay counter maintained for the session." should be ... "and TID" or "and AC" to allow for reordering across TIDs/ACs, where the receiver has indicated support for multiple replay counters (so maybe better as "(or the replay counter corresponding to the TID, if more than one replay counter is supported)"  Or actually, since in 802.11 (unlike WMM) you allocate TIDs up to the max num replay counters supported, maybe just say "replay counter maintained for the session for that TID"?)

Change to "The decryption processing prevents replay of MPDUs by validating that the PN in the

MPDU is greater than the replay counter maintained for the session for that TID."  Ditto at 2587.36.  At 2577.49 change "the PN in the CCMP

header is greater than the replay counter maintained for the session and TID/ACI." to "the PN in the MPDU is greater than the replay counter maintained for the session for that TID."

 

Discussion:

 

As the comment points out, in 802.11 (as opposed to WMM) you use TIDs up to the max number of replay counters supported, at which point you can’t use any other TIDs for that SA (though this is clearer for CCMP than for GCMP):

 

12.5.3.3.7 CCM originator processing

 

A transmitter shall not use an IEEE 802.11 MSDU or A-MSDU priority if this would cause the total number of priorities used during the lifetime of the SA to exceed the number of replay counters supported by the receiver (for a pairwise SA) or all the receivers (for a group SA) for that SA.  The transmitter shall not reorder CCMP protected frames that are transmitted to the same RA within a replay counter, but may reorder frames across replay counters. One possible reason for reordering frames is the IEEE 802.11 MSDU or A-MSDU priority.

 

12.5.5.3.6 GCM originator processing

 

A transmitter shall not use IEEE 802.11 MSDU or A-MSDU priorities without ensuring that the receiver supports the required number of replay counters.  The transmitter shall not reorder GCMP protected frames that are transmitted to the same RA within a replay counter, but may reorder frames across replay counters. One possible reason for reordering frames is the IEEE 802.11 MSDU or A-MSDU priority.

 

The number of replay counters supported for each PTKSA and GTKSA is indicated in the RSN Capabilities field of the RSNE: it can be 1, 2, 4 or 16 (see Table 9-152—PTKSA/GTKSA replay counters usage).

 

In addition to this, there are replay counters for PMF (one for each of individually addressed robust Management and individually addressed robust PV1 Management) and for QMF (one for each ACI of individually addressed robust Management -- it’s not clear whether this is also used for individually addressed robust PV1 management or whether there’s a separate set of 4), when enabled:

 

12.5.3.4.4 PN and replay detection

 

If dot11RSNAProtectedManagementFramesActivated is true, the recipient shall maintain a single replay counter for received individually addressed robust Management frames that are received with the To DS subfield equal to 0, and a single replay counter for received individually addressed robust PV1 Management frames and shall use the PN from the received frame to detect replays. If dot11QMFActivated is also true, the recipient shall maintain an additional replay counter for each ACI for received individually addressed robust Management frames and robust PV1 Management frames that are received with the To DS subfield equal to 1. The QMF receiver shall use the ACI encoded in the Sequence Number field of the received frame to select the replay counter to use for the received frame, and shall use the PN from the received frame to detect replays.

 

It would appear that the PMF/QMF counters are not subject to any maximum per SA limit.

 

In addition to this, there are a bazillion replay counters for group addressed robust Management frames under PMF and under QMF, when enabled; see 12.5.4.6 BIP reception.

 

Also note the subtle “the PN in the CCMP header” for PV1, cf. “the PN in the MPDU” for PV0.  This is because for PV1 the CCMP header is constructed locally, not actually carried in the MPDU:

 

12.5.3.2 CCMP MPDU format

 

The CCMP header is not included in secure PV1 MPDUs, but constructed locally at the STA as defined in 12.5.3.3.6 (Construct CCMP header for PV1 MPDUs).

 

12.5.3.3.6 Construct CCMP header for PV1 MPDUs

 

The CCMP header is not present in secure PV1 MPDUs, but constructed locally at the STA as follows:

 

The proposed change missed this point; it would be helpful to be more explicit about this.

 

Note PV1 is not supported with GCMP, so we don’t need to worry about that.  [Having said that, I can’t find the specific statement in the spec!]

 

Proposed changes:

 

Change 12.5.5.3.6 GCM originator processing as follows:

 

A transmitter shall not use an IEEE 802.11 MSDU or A-MSDU priorities without ensuring that the receiver supports the required number of replay countersy if this would cause the total number of priorities used during the lifetime of the SA to exceed the number of replay counters supported by the receiver (for a pairwise SA) or all the receivers (for a group SA) for that SA..  The transmitter shall not reorder GCMP protected frames that are transmitted to the same RA within a replay counter, but may reorder frames across replay counters. One possible reason for reordering frames is the IEEE 802.11 MSDU or A-MSDU priority.

 

Change “TID/ACI” to “TID (for frames other than QMFs) or ACI (for QMFs)” at:

 

·         2571.47 (“1) When the sequence number of the MPDU is less than the previous sequence number and satisfies the BPN update conditions in 12.5.3.3.6 (Construct CCMP header for PV1 MPDUs) for that TID/ACI, increment the base PN so that the PN never repeats for the same temporal key and TID/ACI.” in 12.5.3.3(.1) CCMP cryptographic encapsulation)

·         2572.37 (“For PV1 MPDUs, the PN shall never repeat for a series of encrypted MPDUs using the same temporal key and TID/ACI.” in 12.5.3.3.2 PN processing)

·         2575.59 (“The locally stored BPN shall be incremented by 1 when the sequence number of the MPDU is less than the previous sequence number for that TID/ACI if any of the following two conditions is satisfied:” in 12.5.3.3.6 Construct CCMP header for PV1 MPDUs)

 

Change 12.5.3.4.1 General (under 12.5.3.4 CCMP decapsulation) as follows:

 

5) The decryption processing prevents replay of MPDUs by validating that the PN in the MPDU is greater than the replay counter maintained for the session and TID (for frames other than QMFs) or ACI (for QMFs).

 

            […]

 

6) The decryption processing prevents replay of MPDUs by validating that the PN in the locally constructed CCMP header (see 12.5.3.3.6) is greater than the replay counter maintained for the session and TID/ (for frames other than QMFs) or ACI (for QMFs).

 

Change 12.5.5.4.1 General (under 12.5.5.4 GCMP decapsulation) as follows:

 

e) The decryption processing prevents replay of MPDUs by validating that the PN in the MPDU is greater than the replay counter maintained for the session and TID (for frames other than QMFs) or ACI (for QMFs).

 

Thanks,

 

Mark

 

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223  434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223  434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

 

From: Mark Rison
Sent: Monday, 23 August 2021 23:11
To: 'STDS-802-11-TGM@xxxxxxxxxxxxxxxxx' <STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>
Subject: FW: [STDS-802-11-TGM] Reminder: REVme teleconference on Aug 23 at 10am ET

 

Hello,

 

> The motions are slides 10-15 of this document: https://mentor.ieee.org/802.11/dcn/21/11-21-0758-07-000m-revme-motions.pptx 

 

A couple of things I've spotted, in the hope they can be patched up in advance

of the motions rather than going through all the pulling rigmarole:

 

- Stephen: I don't see the stuff highlighted in red in

 

“Motion-EDITOR1-D” tab (4 CIDs) in https://mentor.ieee.org/802.11/dcn/21/11-21-0738-04-000m-revme-wg-cc35-editor1-ad-hoc-comments.xlsx,

CID 571: On Page 2567 & 2568 $2569 of D0.1, upper box, change "Advertisement Server" to “"Advertisement server". 5 instances in figure 11-40, figure 11-41 figure 11-42, 11-43, and Figure11-44.  In those 5 figures, also change "Advertisement Server" to "advertisement server" in message flow boxes.

 

- Mike: two issues highlighted

 

“Security Motion C” tab (9 CIDs) in  https://mentor.ieee.org/802.11/dcn/21/11-21-0690-05-000m-revme-cc35-sec-comments.xlsx,

193 missing CCMP header -> MPDU at 2577.49.  [though on further reflection maybe this should refer to the "locally constructed CCMP header"]

Also, are both per-TID and per-ACI possible for both PV0 and PV1 for CCMP, but only TID for GCMP?

 

Thanks,

 

Mark

 

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223  434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223  434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

 

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Saturday, 21 August 2021 00:05
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] Reminder: REVme teleconference on Aug 23 at 10am ET

 

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

Now with corrected month. Sorry about that.:-)

 

On Fri, Aug 20, 2021 at 10:59 AM M Montemurro <montemurro.michael@xxxxxxxxx> wrote:

Hello everyone, 


I just wanted you remind you that we have a teleconference on Monday where we will be running motions:

 

 

The motions are slides 10-15 of this document: https://mentor.ieee.org/802.11/dcn/21/11-21-0758-07-000m-revme-motions.pptx 

 

Cheers,

 

Mike

To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1

 

 

To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1

To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1

To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1