I'm not seeing a clear answer.
I'll raise this on D1.0.
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:
Harkins, Daniel <daniel.harkins@xxxxxxx>
Sent: Wednesday, 7 July 2021 19:29
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] Teleconference reminder: June 14 @ 10am ET, re 21/0871 (Rejected Groups in SAE)
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
On 7/7/21, 10:26 AM, "Mark Rison" <m.rison@xxxxxxxxxxx> wrote:
> Can one side try a group more than once, and if so does the group get added to the Rejected Groups
element more than once?
> What do you think?
I think that nothing in the spec forbids one side from trying the same
group more than once, and I think that the current and proposed spec
wording would both result in the group getting added to the Rejected Groups
element more than once. I say this based on searching the spec for
"rejected group" (30 hits; might have missed one, e.g. one that was
split across pages), not on having read all of the 4608 pages of the
spec, so I might have missed some "shall not" somewhere.
What do you think?
Well how does the protocol work? One statelessly rejects offers. And compiles groups the peer rejected. If one side tries the same group
over and over and sends a list with multiple instances of one, or more, groups then what happens? Each of those offers would be statelessly rejected. Processing of the commit message says to check whether each group in the list would've been rejected. If the
list says 19, 19, 19, 19, 26 and both 19 and 26 are groups that would've been rejected then what happens? Well, the list of rejected groups would be included as salt in the order determined by MAC addresses. And since both sides are including the same lists,
even though one of those lists is excessively duplicative, then what do you think happens in the "crypto hash"?
This highlights something that I think is at the root of our communications difficulties. Searching the spec for language snippets to make
"consistent" instead of addressing the behavior of the protocol as a whole is not, IMHO, the right way to go about improving the spec.
Dan.
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:
Harkins, Daniel <daniel.harkins@xxxxxxx>
Sent: Wednesday, 7 July 2021 18:11
To: Mark Rison <m.rison@xxxxxxxxxxx>;
STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] Teleconference reminder: June 14 @ 10am ET, re 21/0871 (Rejected Groups in SAE)
On 7/7/21, 7:30 AM, "Mark Rison" <m.rison@xxxxxxxxxxx> wrote:
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Regarding the sentence:
“If the status code is set to SAE_HASH_TO_ELEMENT and any groups have been rejected during the current SAE
session, a Rejected Groups element (see 9.4.2.246 (Rejected Groups element)) shall be included, otherwise it shall not be included.”
from Mark Rison
Or
“If an SAE Commit message with status code set to SAE_HASH_TO_ELEMENT is being sent
and any groups have been rejected during the current SAE session, the Rejected Groups element shall be present, otherwise it shall not be present.” from Dan Harkins
Is the meaning/intent of the updated sentence :
“An SAE Commit message with status code SAE_HASH_TO_ELEMENT shall include the Rejected Groups element containing all groups rejected during
the current SAE session, if no groups have been rejected the Rejected Groups element shall not be present.”
Note/question: I have removed “set to” as I don’t think its use is consistent with the style guide:
“The verb “set” should only be used when describing how a field obtains a value, e.g. “The Measurement Duration field is set to the preferred or mandatory duration of the requested measurement, expressed in units of TUs.” Where the value of the field is
read or referenced, (e.g., in the context of a condition), “is set to” shall not be used.” If this works for you and others I suggest this “new” wording (which follows the style guide) be used throughout clause 12 as an editorial change.
This sentence is about transmission not about reception, so it seems to me that "set" conforms to the style guide.
Right! It's about transmission. Which is why I say that the commit message "is being sent" not just that there
happens to be in memory somewhere a commit message with a particular status code.
Other examples in the draft:
[snipped]
Regarding the sentence:
“If an SAE Commit message with status code set to SAE_HASH_TO_ELEMENT is being sent in response to rejection
of a previous SAE Commit message with status code set to UNSUPPORTED_FINITE_CYCLIC_GROUP ,
the group that was rejected shall be appended, after the rejected groups from previous attempts if any, to the Rejected Groups field of the Rejected Groups element.” from Mark Rison
Or
If an SAE Commit message with status code set to SAE_HASH_TO_ELEMENT is being sent
in response to rejection of a previous SAE Commit message with status code set to UNSUPPORTED_FINITE_CYCLIC_GROUP[MR1] ,
the group that was rejected shall be appended, after the rejected groups from previous attempts if any, to the Rejected Groups field of the Rejected Groups element (see 9.4.2.246 (Rejected Groups element)).
Each rejected group shall be represented as an unsigned 16-bit integer using the bit ordering conventions of 9.2.2 (Conventions).
from Dan Harkins
Is the meaning/intent of the updated sentence :
“An SAE Commit message with status
code SAE_HASH_TO_ELEMENT sent in response to an SAE Commit message with status code UNSUPPORTED_FINITE_CYCLIC_GROUP shall append the unsupported group to the groups in the Rejected Groups element, the group is appended following the groups rejected during
the current SAE session, if any.”
I have some confusion regarding the ordering of these requirements. Also why is there a need specify that the rejected group is append? It
is my understanding that the Rejected Groups element is defined to contain all groups rejected during the current SAE session, which should include the specified group, hence no need to call for it to be appended. Is the “real” requirement that an SAE Commit
message with status code SAE_HASH_TO_ELEMNT must be sent in response to the reception of an SAE Commit message with status code UNSUPPORTED_FINITE_CYCLIC_GROUP? If so, then this should be stated and the requirement to append the group is not necessary and
should be removed.
Yes, that's right. So if you get a response for UNSUPPORTED_FINITE_CYCLIC_GROUP you append the group that is
being rejected onto your list of groups. The thing to keep in mind, though, is that what if you get a response asking for an anti-clogging token? Well, in that case you include a list of all the groups that have been rejected during this current SAE connection
attempt. I'm not sure why you are against saying the specified group, which was rejected, is appended to the list of rejected groups. If you think that such behavior should be self-evident due to the fact that the Rejected Groups IE contains all rejected
groups (including the current one) then I point you to the reason why we are laboring over this paragraph in the first place—people do not do the self-evident thing always and everywhere.
I think the order matters because it's an input into a crypto hash, so you need to specify that it's appended
(rather than, say, maintained in numerical order):
12.4.5.4 Processing of a peer’s SAE Commit message
While the rejected groups are appended to the Rejected Groups element as they are
rejected (see 12.4.7.4 (Encoding and decoding of SAE Commit messages)) there is no inherent order to the
groups in the list. The order in which they are sent and received shall be retained when deriving keys.
If both SAE Commit
messages indicated a status code of SAE_HASH_TO_ELEMENT, a salt consisting of the concatenation of the
rejected groups from each peer’s Rejected Groups element shall be passed to the KDF
I have a different question, which I was going to bring up on D1.0, but since you've raised it now…
Can one side try a group more than once, and if so does the group get added to the Rejected Groups
element more than once?
What do you think?
Dan.
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:
Harkins, Daniel <daniel.harkins@xxxxxxx>
Sent: Tuesday, June 29, 2021 1:05 PM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] Teleconference reminder: June 14 @ 10am ET, re 21/0871 (Rejected Groups in SAE)
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
On 6/16/21, 2:51 AM, "Mark Rison" <m.rison@xxxxxxxxxxx> wrote:
[snip]
- I suggest the wording could be made more straightforward and
consistent as follows:
12.4.7.4 Encoding and decoding of SAE Commit messages
An SAE Commit message shall
consist ofinclude a Finite Cyclic Group field (see
9.4.1.42 (Finite Cyclic Group field)) indicating a group, a Scalar field (see
9.4.1.39 (Scalar field)) containing the scalar, and an FFE field containing the element (see
9.4.1.40 (FFE field)). If the SAE Commit message is in response to an Anti-Clogging Token field request (see 12.4.7.6 (Status codes)),
the
an
Anti-Clogging Token field is
presentshall be included (see 9.4.1.38 (Anti-Clogging Token
field)). When the PWE is derived using the hash-to-element method, the Anti-Clogging Token field is encapsulated in an Anti-Clogging Token Container element; otherwise, the Anti-Clogging Token field is included in the frame outside of an element as described
in Table 9-41 (Presence of fields and elements in Authentication frames). If a password identifier is used in generation of the password element (PWE)
the
a
Password identifier element shall be presentincluded and
the identifier shall be encoded as a UTF-8 string in the Identifier portion of the element (see 9.4.2.216 (Password Identifier element)). If an SAE Commit message with status code set to SAE_HASH_TO_ELEMENT is being sent
in response to rejection of a previous SAE Commit message with status code set to UNSUPPORTED_FINITE_CYCLIC_GROUP[MR2] ,
the group that was rejected shall be appended, after the rejected groups from previous attempts if
applicableany, to the Rejected Groups field of the Rejected Groups element
(see 9.4.2.246 (Rejected Groups element)).
Each rejected group shall be represented as an unsigned 16-bit integer using the bit ordering conventions of 9.2.2 (Conventions). If
the status code of thean
SAE Commit message with status code set tois
SAE_HASH_TO_ELEMENT
is being sent
and
if
any groups have been rejected
during the current SAE session, the Rejected Groups element
shall
be present, otherwise it shall not be present.
[The first change has been made in 21/0871r1 but I can't work out how
to edit it in this email!]
Yes, this edit in email thing seems to be part of the problem. That said, I think what you're asking is that
the final sentence go from:
I was and still am asking for the other changes shown in red, too (where
not already incorporated in 21/0871), modulo the discussion re the final
sentence, below.
Well it seems the changes in red get lost in email, sigh. I will note that many of these have already been addressed
in r1 which is on mentor and has been for a while. Maybe we can clear the slate of red and blue email changes based on r0 which we have been debating and proceed with the latest-and-greatest. Maybe send a new email based on r1 if I have violated a capitalization
rule or some such trifle.
"If the status code of the SAE Commit message is SAE_HASH_TO_ELEMENT and if any groups have been rejected during
the current SAE session, the Rejected Groups element shall be present, otherwise it shall not be present."
to"
"If an SAE Commit message with status code set to SAE_HASH_TO_ELEMENT is being sent and any groups have been
rejected during the current SAE session, the Rejected Groups element shall be present, otherwise it shall not be present."
Correct? So this is "consistent" in the sense that it now talks about "a Commit Message with status code FOO
being sent" as a previous sentence does. But that sentence is using that construction to refer to the current message being a response to an immediately previous attempt. This text just says that if there had been any previous rejections, regardless of what
your current response is for (again, it could be an anti-clogging token), then you include the Rejected Groups element. So I think the text in the submission is still better and more clear. If you have an additional suggestion for this sentence to increase
clarity I'd like to hear it. Probably better to just send the whole sentence instead of attempting this highlight/crossout thing in email. How would you feel about:
"If the status code of the SAE Commit message being sent is SAE_HASH_TO_ELEMENT and any groups have been rejected
during the current SAE session, the Rejected Groups element shall be present, otherwise it shall not be present."
Can you live with that?
I suggest the following for this round, which consistently enumerates the conditions
for the not-always-included things:
An SAE Commit message shall include a Finite Cyclic Group field (see 9.4.1.42 (Finite Cyclic Group field)) indicating a group, a Scalar field
(see 9.4.1.39 (Scalar field)) containing the scalar, and an FFE field containing the element (see 9.4.1.40 (FFE field)).
If the SAE Commit message is in response to an Anti-Clogging Token field request (see 12.4.7.6 (Status codes)), an Anti-Clogging Token field
shall be included (see 9.4.1.38 (Anti-Clogging Token field)). When the PWE is derived using the hash-to-element method, the Anti-Clogging Token field is encapsulated in an Anti-Clogging Token Container element; otherwise, the Anti-Clogging Token field is included
in the frame outside of an element as described in Table 9-41 (Presence of fields and elements in Authentication frames).
If a password identifier is used in generation of the password element (PWE) a Password identifier element shall be included and the identifier
shall be encoded as a UTF-8 string in the Identifier portion of the element (see 9.4.2.216 (Password Identifier element)), otherwise it shall not be included.
If the status code is set to SAE_HASH_TO_ELEMENT and any groups have been rejected during the current SAE session, a Rejected Groups element
(see 9.4.2.246 (Rejected Groups element)) shall be included, otherwise it shall not be included.
If an SAE Commit message with status code set to SAE_HASH_TO_ELEMENT is being sent in response to rejection of a previous SAE Commit message
with status code set to UNSUPPORTED_FINITE_CYCLIC_GROUP ,
the group that was rejected shall be appended, after the rejected groups from previous attempts if any, to the Rejected Groups field of the Rejected Groups element.
Again, the previous text, whose construction you seem to be feverishly working to match, is discussing how to
generate this present new request, the message currently being worked assembled, based on the immediate response you just got. The new text which is the final sentence I'm adding is not about construction of a new request based on the immediate response. In
fact, the behavior depends on potentially many previous responses you had gotten. And the way you know, presently, what to do is whether "any groups have been rejected during the current SAE session." That's the key. That's why your text not satisfactory.
Let me try, again, to describe it.
Alice Bob
group 19 --->
<--- reject, bad group
group 20, 19 rejected --->
<--- reject, anti-clogging token
And here we are! Now your text is somewhat unclear about what to do. The SAE Commit message with status set
to SAE_HASH_TO_ELEMENT is being sent in response to an anti-clogging token. But your text says "a previous SAE Commit message." But this current SAE Commit message is not being sent in response to a previous one, it's being sent in response to the most recent
one, the anti-clogging token request. One does not send messages in response to previous messages. What we need the message to look like is:
token, group 20, 19 rejected --->
And that is exactly what my text says one should do! This message is being sent in response to an anti-clogging
token rejection so the text that says if this message is being sent in response to an anti-clogging token rejection to include the token. Also, since there have been rejections during the current SAE session the rejected groups element is there.
So the text is not symmetric and each sentence is not constructed identically. So what. It makes sense and
that's what matters. Your text, which having a "consistency" in sentence construction throughout the paragraph is confusing and will likely result in more people doing the wrong thing.
Again, the issue is that someone was including an empty Rejected Groups element so I am attempting to retain
description of the correct behavior (see the handshake above) while mandating that if no bad group rejections have been received "during the current SAE session" then you don't include the Rejected Groups element.
regards,
Dan.
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
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