Re: [STDS-802-11-TGM] Security CIDs from REVme CC

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

Hello Mike,

For 507, the comment is suggesting:

- Say that it contains a PMKID KDE (not just a PMKID) -- Jouni to

confirm that was the point raised in Vienna

- Have a general statement that the "Key Data ="" information in

the 4-way and group handshake message subclauses gives a list

of what shall be included, but that other KDEs (such as VS KDEs)

may be included too

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

589 is Thomas' comment, but I think he's suggesting that for M1

and M2, where it says that the Key Data field "need not be encrypted"

this be replaced by a clearer statement of when it shall/may/shall not

be encrypted.

[Looking at the other messages, it might be worth clarifying whether

for M3 it may or shall not be encrypted if a GTK is not included,

and for M4 and G2 whether it shall/may/shall not be encrypted if

it is present.]

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, 21 April 2021 18:05
To: Mark Rison <m.rison@xxxxxxxxxxx>; stds-802-11-tgm <STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>
Cc: Jouni Malinen (jouni@xxxxxxxxxxxxxxxx) <jouni@xxxxxxxxxxxxxxxx>; mark.hamilton2152@xxxxxxxxx
Subject: Re: Security CIDs from REVme CC

Hi Mark,

With respect to the other CIDs you mentioned, I can deal with CID 190 but its not clear what you want for a resolution to 507 and 589.

507 says "as it says in the comment" for a proposed resolution

589 says "see comment"

I did not see a "Proposed Change" in either of those comments.

Cheers,

Mike

On Wed, Apr 21, 2021 at 10:08 AM M Montemurro <montemurro.michael@xxxxxxxxx> wrote:

Hey Mark,

I added you to the agenda and left you about 30 minutes in the first hour.

On Wed, Apr 21, 2021 at 3:59 AM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

Hello Mike,

OK, well could I request time in the first hour of next week's teleconf

please to go through the

I think the following need nothing more and can just be Accepted:

I'd like group consensus on the direction before I produce a submission:

need some discussion in TGme with security SMEs

I need a group direction before I produce a submission:

sections of https://www.ieee802.org/11/email/stds-802-11-tgm/msg02118.html ?

Also, it occurred to me that 190 and 507 (and 589) could be dealt with by

whoever deals with 548 (you?).

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 22:14
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: stds-802-11-tgm <STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>; Jouni Malinen (jouni@xxxxxxxxxxxxxxxx) <jouni@xxxxxxxxxxxxxxxx>
Subject: Re: Security CIDs from REVme CC

Hi Mark,

Thanks for the summary. These CIDs are assigned to you so if you want agenda time to present some of them in REVme, let me know and I'll schedule you in. You need a document that you can present to get the feedback from the TG and capture resolutions.

Cheers,

Mike

On Tue, Apr 20, 2021 at 4:35 PM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

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 capitalisation

Change 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 either

Clarify 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 = CCMP

Add 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

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