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,MikeOn 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 priorit
ies without ensuring that the receiver supports the required number of replay countersyif 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 agenda document is posted here: https://mentor.ieee.org/802.11/dcn/21/11-21-1214-04-000m-july-august-teleconference-agenda.docx
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