Hello Mike,
OK, well I think the following need nothing more and can just be Accepted:
> 360
For AAD construction, what is the difference between "not modified" and "not masked"? How does "masked to <n>" differ from "set to <n>" anyway?
In 12.5.3.3.3, 12.5.4.3, 12.5.3.3.1, 12.5.3.3.6, 12.5.4.5, 12.5.4.6, 12.5.5.3.1 change "masked to" to "set to" and "unmasked" to "not modified" (case-preservingly)
> 213
The Length field in Figure 12-36--GTK KDE format is not defined. I suspect it's the Length in Figure 12-35--KDE format but then the formula doesn't work, because the OUI and Data Type fields already consume 4 octets from the Length
Change - 4 to -6 in F12-36, change the hyphen to a minus, and where F12-36 is referred to add " (where Length is the Length field in the KDE)"; ditto where F12-42 is referred to and where Figure 12-47 is referred to (and the hyphen->minus there)
> 179
"Message 3 differs from message 2 by
not asserting the Ack bit and from message 4 by asserting the Ack Bit." -- asserting bits is not defined, the field is called Key Ack and Bit has the wrong capitalisationChange to "Message 3 differs from message 2 by
having the Key Ack bit of the Key Information field set to 0 and from message 4 by having the Key Ack bit set to 1." In 12.7.6.6 change "in which the Ack bit is 1" to "in which the Key Ack bit of the Key Information field is 1". In 12.7.10.3 change "have the Ack bit set to 1" to "have the Key Ack bit of the Key Information field set to 1" and "the Ack bit is 0" to "the Key Ack bit is 0"
> 223
"b) The AP's RSNE indicates that WEP-40 (OUI 00-0F-AC:1) or WEP-104 (OUI 00-0F-AC:5) are
enabled as either pairwise or group cipher suites; [...]
Violation of any of these cases would cause the TPK handshake to leak the TPK." -- if the issue is that WEP is no longer secure, then the same is true for TKIP (and indeed TKIP is explicitly banned in 12.7.8.4.2)Add TKIP (00-0F-AC:2) to the list in b)
I will need some discussion in TGme with security SMEs for the ones I don't know the answer to:
> 208
Why is the UP in both the AAD and the nonce? See e.g. 12.5.3.3.3 Construct AAD and 12.5.3.3.4 Construct CCM nonce
> 214
It's not clear why the CCM nonce includes UP but the GCM nonce doesn't. Maybe it's because "the priority value of the MPDU" as used in CCM is a wide concept that covers e.g. 11ae? But then why isn't the UP needed in GCM too?
> 395
Is the MIC really always 16 octets for GCMP? For CCMP it's "variable" (compare the "Encapsulated GCMP/CCMP MPDU" figures)
> 45
I'm not sure which section to make this comment. PV1 frame security does not cater for protected QoS management frames for a number of reasons: 1. There doesn't seem to be a default QMF policy for PV1 management frames, but I may have missed it.
2. The Packet Number creation/management for encrypted PV1 frames assumes a 12 bit sequence number. The sequence number for QMF is 10 bits and is a separate number space for each AC.
3. Base packet numbers for PV1 encryption are associated with keyid and PTID/ACI so it appears that two separate sequence number spaces, i.e. PV1 data and PV1 QMF at the same priority, could end up using the same BPN which I assume voids the security properties of the underlying cipher.We can either address the points raised in the comment or put a note somewhere that PV1 management frames do not support QoS.
> 356
If "GCM also requires a unique nonce value for each frame protected by a given temporal key.", then then how does the GCM nonce achieve this? It just has the A2 and the PN, and doesn't have e.g. the TID+Management bits that ensure uniqueness in the CCM nonce
> 190
If the Key Data is empty then the length is 0 and there's no meaning to saying it's encrypted
Either add a NOTE to explain what might be included even though Key Data is "none required" (and that the Encrypted Key Data = 1 is ignored in that case) or change line 17 to say Encrypted Key Data = "" line 30 to say Key Data Length = 0 and line 31 to say Key Data = "">
> 180
"Message 3 differs from message 2 by not asserting the Ack bit and from message 4 by asserting the Ack Bit." -- wait, what, how can M3 differ from M2 by not asserting something and also from M4 by asserting the same thing?
> 335
"the EAP-Initiate/Reauth data" is not defined
> 418
"The PTKSA is used to
protect the subsequent reassociation transaction, including the optional RIC-Request." is not clear. Is it suggesting that the Reassociation Request/Response frames are encrypted or MICked? That's not possible, because they're not robust and they don't carry an MME eitherClarify what "protect" means here
For the following I'd like group consensus on the direction before I produce a submission:
> 240
A Mesh TKSA is pairwise and bidirectional, just like a PTKSA. So it would be better to call it a Mesh PTKSA
Change "esh TKSA" to "esh PTKSA" throughout
> 200
[12.6.19] talks of "associated STA" but MFP can be used with IBSS and TDLS too
Change "associated STA" to "associated or peer STA" throughout this subclause
> 239
The replay detection/protection subclauses don't cover MBSS links (that use a Mesh TKSA and a Mesh GTKSA rather than a PTKSA and a GTKSA)
Extend 12.5.3.4.4 PN and replay detection [CCMP] and 12.5.5.4.4 PN and replay detection [GCMP] to mention Mesh TKSA and GTKSA together with PTKSA and GTKSA
> 387
REVmd CID 4049 resolution directs use of both 1 and 2 if pairwise is "use group" and group is CCMP. Jouni suggested during teleconf on 2020-06-12 that (a) that combination should not be allowed and (b) the 2 option should not allow "or group cipher" in the condition
> 432
There are references to "enhanced data cryptographic encapsulation mechanisms" but this term is never actually defined. The examples seem to suggest it means "non-WEP". If so, just say that. If not, define
Change "enhanced data cryptographic encapsulation" case-insensitively to "RSNA" (4x in C4, 8x in C12)
> 406 (see also 387)
"i) The value 1 shall be used for all EAPOL-Key frames to a STA when the negotiated AKM
is 00-0F-AC:1 or 00-0F-AC:2 and the pairwise cipher is TKIP or "Use group cipher
suite". In this case, the "Deprecated" row in Table 12-10 (Integrity and key wrap algo-
rithms) is used.
ii) The value 2 shall be used for all EAPOL-Key frames to a STA when the negotiated AKM
is 00-0F-AC:1 or 00-0F-AC:2 and either the pairwise or the group cipher is an enhanced
data cryptographic encapsulation mechanism other than TKIP. In this case, the matching
row in Table 12-10 (Integrity and key wrap algorithms) is used." means you have to use both value 1 and value 2 if pairwise = "use group" and group = CCMPAdd a statement to say that the pairwise = "use group" and group = CCMP combination is not allowed
> 186
It's not clear what to do in the handshakes if a verification fails. E.g. in 12.7.7.2 Group key handshake message 1 the e) might imply that you respond in any case. Should say ignore the received message if any verification step fails
Add an "Otherwise," at 2641.60, 2644.18, 2644.26. Also add some escape/otherwise words to the lettered list processes at the end of 12.7.6.4, 12.7.6.5, 12.7.7.2, 12.7.7.3
For the following I need a group direction before I produce a submission:
> 535
It is not clear whether the SME picks the Key ID for transmission of encrypted frames (using the Key ID parameter of the MLME-SETKEYS.request) or whether the MAC does so
> 225
Can non-QoS Data frames be encrypted with CCMP/GCMP (and TKIP) and if so what value is used for the priority (e.g. in the nonce/MIC), since at the MA SAP it might be "Contention"?
Miscellaneous:
> 206
I need someone to tell me whether it's the places in the spec that say the
PN has to never repeat are wrong, or whether it's the places in the spec that
say just the {PN+nonce} or {PN+TID/ACI} has to never repeat are wrong:
In some places the spec suggests it's sufficient for PN+nonce to differ, e.g.:
CCM requires a fresh temporal key for every session. CCM also requires a unique nonce value for each frame protected by a given temporal key. Reuse of a nonce value with the same temporal key voids all security guarantees.
increment the base PN so that the PN never repeats for the same temporal key and TID/ACI
the PN shall never repeat for a series of encrypted MPDUs using the same temporal key and TID/ACI.
but in other places it suggests the PN must never be reused, e.g.:
Each transmitter shall maintain a single PN (48-bit counter) for each PTKSA and GTKSA(#59).
Increment the PN, to obtain a fresh PN for each MPDU, so that the PN never repeats for the same temporal key.
Is it just PN+nonce (or PN+nonce+AAD) that have to be unique, or strictly the PN itself? The former would allow a PN per UP on tx, for example, since the nonce contains the UP.
> 507
Hoping Jouni can help with this:
Message 1 uses the following values for each of the EAPOL-Key frame fields:" -- "Key Data = "" for the PMK being used during PTK generation" -- Jouni said in Vienna that it can contain other stuff, and that it should be referring to PMKID KDE. Also, should have general statement for all the Key Data = "" to say this is the minimum set of things that need to be included in the message, but other stuff (e.g. VS) may also be included
> 260
Hoping Jouni can help with this:
"The TPKSA consists of the following:
-- MAC addresses of the TDLS initiator STA and the TDLS responder STA
-- Pairwise cipher suite selector
-- TPK Lifetime
-- TPK" but TPK stands for TDLS PeerKey in Clause 3 rather than TDLS peer key, so it's not clear what TPK means here. Jouni has suggested by email that it consists of TPK-KCK and TPK-TK, which means it's a transient key like the PTK (so maybe it should be a TDLS PeerKey transient key = TPTK), but the fact that it's a transient key doesn't seem to be stated anywhere
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: Tuesday, 20 April 2021 21:13
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: stds-802-11-tgm <STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>
Subject: Re: Security CIDs from REVme CC
Hey Mark,
I've assigned these comments to you unless there is somebody else willing to volunteer to provide resolutions.
If you have specific resolutions, changes, or need clarification from the group, please create a submission and we can discuss during one of the teleconferences.
Thanks,
Mike
On Tue, Apr 20, 2021 at 3:36 PM Mark Rison <m.rison@xxxxxxxxxxx> wrote:
Hello Mike,
> 240
I'm happy to identify the locations where "mesh TKSA" appears, if that's what you're after.
> 200
I'm happy to propose specific changes if there is consensus on the direction.
> 206
I need someone to tell me whether it's the places in the spec that say the
PN has to never repeat are wrong, or whether it's the places in the spec that
say just the {PN+nonce} or {PN+TID/ACI} has to never repeat are wrong.
> 208
I don't know the answer.
> 214
I don't know the answer.
> 239
I'm happy to propose specific changes if there is consensus on the direction.
> 507
I need some input from Jouni here.
> 387
I'm happy to propose specific changes if there is consensus on the direction.
> 360
I think the proposed change is specific and explicit.
> 535
I'm happy to propose specific changes if there is consensus on a direction.
> 432
I'm happy to propose specific changes if there is consensus on the direction.
> 225
I'm happy to propose specific changes if there is consensus on a direction.
> 395
I don't know the answer.
> 45
I don't know the answer.
> 356
I don't know the answer.
> 260
I need some input from Jouni here.
> 406
I'm happy to propose specific changes if there is consensus on the direction.
> 213
I think the proposed change is specific and explicit.
> 190
I don't know the answer.
> 179
I think the proposed change is specific and explicit.
> 180
I don't know the answer.
> 186
I'm happy to propose specific changes if there is consensus on the direction.
> 223
I think the proposed change is specific and explicit.
> 335
I don't know the answer.
> 418
I don't know the answer.
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: Tuesday, 20 April 2021 15:46
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: stds-802-11-tgm <STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>
Subject: Security CIDs from REVme CC
Hey Mark,
I reviewed the comments assigned to the Security adhoc and I'm assigning a number of your comments back to you with Submission Required.
The CIDs are 240, 200, 206, 208, 214, 239, 507, 387, 360, 535, 432, 225, 395, 45, 356, 260, 406, 213, 190, 179, 180, 186, 223, 335, 418.
They can be found in: https://mentor.ieee.org/802.11/dcn/21/11-21-0690-00-000m-revme-cc35-sec-comments.xlsx
Cheers,
Mike