What problem is being solved by these changes? Yes, I've read the comment, I still have that question. At the moment that you're reading this there are billions of devices
around the world interoperating with code from this portion of the spec. So I'm wondering what the problem is.
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
On 8/24/21, 8:31 AM, "Mark Rison" <m.rison@xxxxxxxxxxx> wrote:
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
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 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
|
|
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