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

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

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

 

 


 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”?  Otherwise what does it mean (assuming no time-travel)?


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