a.
Document 11-21/871 – Dan (HPE) – Rejected Groups in SAE
I have the following comments on this submission:
- Is the "shall" going to result in any existing devices becoming
noncompliant?
I believe this was addressed on the call.
Yes.
- "Each rejected group shall be represented
as an unsigned 16-bit integer using the bit ordering conventions of 9.2.2 (Conventions)."
does not belong in Clause 12, and is already covered in Clause 9
(specifically 9.4.2.246->9.4.1.42->9.2.2). The correct place is
Clause 9 because Clause 9 is for format/encoding and other clauses
are for behaviour.
Since there was additional support by other people on the call to leave this language here. So I believe this has been addressed and you
accept no change will be made.
I will raise this as a comment in the next round.
- I think "in response to rejection of a
previous SAE Commit message with status code set to UNSUPPORTED_FINITE_CYCLIC_GROUP"
is unclear. Is it the previous SAE Commit message that carries that SC,
or is it the rejection of that SAE Commit message that carries that SC?
And what does “a previous” mean here? Does it mean “the immediately previous”?
Again, this text is not unclear to the many people who have implemented this protocol. The issue at hand is a different part of the paragraph.
This text, from the standpoint of people who implement the standard, is fine. Of course you are free to comment on this in the next round of balloting of this draft.
I will raise this as a comment in the next round.
- 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[MR1] ,
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.
"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.
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
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