--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Jouni,
Can you make a submission that has change bars showing what text changed? I like your paragraph but then I like Nehru's too. And while I'm not so fond of my original text I don't think it's as ambiguous as some are making it out to be.
So if we could see the changes being proposed it would help. These "replace the entire paragraph with this…" kinds of resolutions make me a little leery.
regards,
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
It would be unfortunate if we cannot address a comment that is identifying a clear ambiguous description of behavior in a security related subclause and comes with a proposed text to address the issue. If that minimal
change is not considered acceptable, I'd address this by changing the paragraph in question into following which is clearer on which steps apply to which condition with some duplication needed for doing that:
"Upon receipt of a Com event, the t0 (retransmission) timer shall be canceled. If the Status is nonzero, the frame shall be silently discarded, the t0 (retransmission) timer set, and the protocol instance shall
remain in the Confirmed state. If Sync is greater than dot11RSNASAESync, the protocol instance shall send the parent process a Del event and transitions back to Nothing state. If Sync is not greater than dot11RSNASAESync, and the finite cyclic group is the
same as the previously received SAE Commit message, the protocol instance shall increment Sync, increment Sc, transmit its SAE Commit message and its SAE Confirm message with the new Sc value, and shall set the t0 (retransmission) timer. Otherwise, the frame
shall be silently discarded."
And if there is support for more cleanup in the group (I doubt that, though), this could be moved to using active voice more consistently (with similar changes in other paragraphs not being part of this round; revisit
in a different LB if anyone wants that elsewhere):
"Upon receipt of a Com event, the protocol instance shall cancel the t0 (retransmission) timer. If the Status is nonzero, the protocol instance shall silently discard the frame, shall set the t0 (retransmission)
timer, and shall remain in the Confirmed state. If Sync is greater than dot11RSNASAESync, the protocol instance shall send the parent process a Del event and shall transition back to Nothing state. If Sync is not greater than dot11RSNASAESync, and the finite
cyclic group is the same as the previously received SAE Commit message, the protocol instance shall increment Sync, increment Sc, transmit its SAE Commit message and its SAE Confirm message with the new Sc value, and shall set the t0 (retransmission) timer.
Otherwise, the protocol instance shall silently discard the frame."
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hello everyone,
At this point, we've discussed CID 116 twice in sessions and its clear there is no consensus on a resolution on the reflector.
I will prepare a straw poll for this CID that we will run on the Oct 15 call. If there is no clear consensus on a resolution path, we will reject the comment. We have the entire LB and SA Ballot
process to address any underlying issues, if there are any.
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Mark,
You have no idea what you're talking about. You don't write code and I'm unaware of any significant feature you have authored in the standard (although you have scent-marked lots of other people's contributions). You should really tone down your criticisms
of other people, their opinions, and their work.
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
This is the kind of thinking that results in KRACK and FragAttacks and…
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
We probably should not expand the scope of the changes for the issue, for now.
Also, keeping in mind that there are many existing interoperable implementations of the feature in question, it would be reasonable to assume that the implementers are able to have a consistent (and hopefully correct)
interpretation of the current text, along with the corresponding state machine figures, and there would only be diminishing returns from any significant overhaul of the text.
Hello Nehru,
> The timer is already set in the bogus/invalid case - nothing needs to be done. My comment in the email 'set(again)' is a bit lax, but the proposed
text, which replaces the corresponding paragraph, is correct per my understanding (of course).
Ah, I see. Then I think
Upon receipt of a Com event, if the Status is nonzero, the frame shall be silently discarded, and the protocol instance shall remain in the Confirmed state. Otherwise, If Sync is greater than dot11RSNASAESync,
the protocol instance shall send the parent process a Del event and transitions back to Nothing state. If Sync is not greater than dot11RSNASAESync, the protocol instance shall verify that the finite cyclic group is the same as the previously received SAE
Commit message. If the verification fails, the frame shall be silently discarded. Otherwise, the protocol instance shall increment Sync, increment Sc, transmit its SAE Commit message and its SAE Confirm message with the new Sc value, and set the t0 (retransmission)
timer.
addresses (modulo small editorials, e.g. ", If" -> ", if",
"transitions" -> "transition", "same as" -> "same as in")
the "if … if … if not … verify … if not … if so … then …" confusion.
There are still the other issues with "the Status", "the frame" and
possible missing silent discard at the Del event step, but these can
be dealt with in D1.0.
How about 12.4.8.6.3? This has similar problems with unclear structuring,
I think:
Upon receipt of a Com event, the protocol instance shall check the Status of the Authentication frame. If the
Status code is not SUCCESS, the frame shall be silently discarded and a Del event shall be sent to the parent
process. Otherwise, the frame shall be processed by first checking whether a password identifier is present.
If so and there is no password associated with that identifier, BadID shall be set and the protocol instance
shall construct and transmit an Authentication frame with Status Code set to
UNKNOWN_PASSWORD_IDENTIFIER. If there is no password identifier present or if a password is
associated with that identifier, the frame shall be processed by next checking the finite cyclic group field to see
if the requested group is supported.
If not, BadGrp shall be set and the protocol instance shall construct and
transmit an Authentication frame with Status code UNSUPPORTED_FINITE_CYCLIC_GROUP indicating
rejection with the finite cyclic group field set to the rejected group, and shall send the parent process a Del
event. If the group is supported, the protocol instance shall zero the Sc and Rc counters and it shall generate the
PWE and the secret values according to 12.4.5.2 (PWE and secret generation). It shall then process the
received SAE Commit message (see 12.4.5.4 (Processing of a peer’s SAE Commit message)). If validation of
the received SAE Commit message fails, the protocol instance shall send a Del event to the parent process;
otherwise, it shall construct and transmit an SAE Commit message (see 12.4.5.3 (Construction of an SAE
Commit message)) followed by an SAE Confirm message (see 12.4.5.5 (Construction of an SAE Confirm
message)).
The Sync counter shall be set to 0 and the t0 (retransmission) timer shall be set. The protocol
instance transitions to Confirmed state.
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
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
The timer is already set in the bogus/invalid case - nothing needs to be done. My comment in the email 'set(again)' is a bit lax, but the proposed text, which replaces the corresponding paragraph, is correct per
my understanding (of course).
I agree it would be a good idea to bring a submission, during a conf. call or something - I was merely trying to provide my input to some of your proposed changes and comments related to the issue in the email thread.
p.s. FWIW the changes I proposed are no more complex than some of the other changes being discussed...
Hello Nehru,
OK, I thought we wanted to make minimal changes. I think it would be
a good idea to show a version with change tracking, so we can see the
substantive changes. In any case, I think it's not the case that
the retransmission timer needs to be set (again) in all cases which do not transition to the 'Nothing' state
because if a bogus/invalid Com event is received we don't transition
to Nothing but nor do we set (again) the timer.
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
If you notice, the original text canceled the timer upon reception of the Com event. My proposed text does not do that; it just resets the timer upon successful processing/response of the
Com(mit) event. So, the timer is operational and any retries will happen if a bogus/invalid Com event is received per original schedule...
Hello Nehru,
If
the retransmission timer needs to be set (again) in all cases which do not transition to the 'Nothing' state
then it seems to me that your latest text is not doing this in the
highlighted cases:
Upon receipt of a Com event, if the Status is nonzero, the frame shall be silently discarded, and the protocol instance shall
remain in the Confirmed state. Otherwise, If Sync is greater than dot11RSNASAESync, the protocol instance shall send the parent process a Del event and transitions back to Nothing state. If Sync is not greater than dot11RSNASAESync,
the protocol instance shall verify that the finite cyclic group is the same as the previously received SAE Commit message. If the verification fails, the frame shall be
silently discarded. Otherwise, the protocol instance shall increment Sync, increment Sc, transmit its SAE Commit message and its SAE Confirm message with the new Sc value, and set the t0 (retransmission) timer.
I really think all this needs to be structured more clearly.
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
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
The list server rejected my message because of a proprietary..disclaimer at the end - not sure if that was inserted by me/my mail server; I will delete it and try again in case it is an artifact of replying to someone
else's message with a disclaimer.
I think the retransmission timer needs to be set (again) in all cases which do not transition to the 'Nothing' state. As I noted separately, that is another issue with this text - but not sure if it is related to the
comment in question. Here is another take (which does not cancel the timer in the first place for the error conditions, assuming the timer has no meaning in the Nothing state and is automatically canceled as part of state transition)
Upon receipt of a Com event, if the Status is nonzero, the frame shall be silently discarded, and the protocol instance shall remain in the Confirmed state. Otherwise, If Sync is greater than dot11RSNASAESync,
the protocol instance shall send the parent process a Del event and transitions back to Nothing state. If Sync is not greater than dot11RSNASAESync, the protocol instance shall verify that the finite cyclic group is the same as the previously received SAE
Commit message. If the verification fails, the frame shall be silently discarded. Otherwise, the protocol instance shall increment Sync, increment Sc, transmit its SAE Commit message and its SAE Confirm message with the new Sc value, and set the t0 (retransmission)
timer.
Hello Nehru,
I think this is still ambiguous (in addition to the other issues I identified
in my previous post): what is the scope of the final sentence? Is the intent
{Upon receipt of a Com event, the t0 (retransmission) timer shall be canceled. If the Status is nonzero, the frame shall be silently discarded, the t0 (retransmission) timer set, and the protocol instance shall remain in the Confirmed
state. If Sync is greater than dot11RSNASAESync, the protocol instance shall send the parent process a Del event and transitions back to Nothing state. If Sync is not greater than dot11RSNASAESync, the protocol instance shall verify that the finite cyclic
group is the same as the previously received SAE Commit message. If the verification fails, the frame shall be silently discarded. Otherwise, the protocol instance shall increment Sync, increment Sc, and transmit its SAE Commit message and its SAE Confirm
message with the new Sc value.} AND {It then shall set the t0 (retransmission) timer.}
or is it
Upon receipt of a Com event, the t0 (retransmission) timer shall be canceled. If the Status is nonzero, the frame shall be silently discarded, the t0 (retransmission) timer set, and the protocol instance shall remain in the Confirmed
state. If Sync is greater than dot11RSNASAESync, the protocol instance shall send the parent process a Del event and transitions back to Nothing state. If Sync is not greater than dot11RSNASAESync, the protocol instance shall verify that the finite cyclic
group is the same as the previously received SAE Commit message. If the verification fails, the frame shall be silently discarded. Otherwise, {{ the protocol instance shall increment Sync, increment Sc, and transmit its SAE Commit message and its SAE Confirm
message with the new Sc value.} AND {It then shall set the t0 (retransmission) timer.}}
?
[In my indentation-based presentation I assumed the latter was the intent,
but maybe it was the former?]
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
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Some strikethrough and underlines do not seem to have made it through the email transport. Will try again - the below is the replacement I proposed
Upon receipt of a Com event, the t0 (retransmission) timer shall be canceled. If the Status is nonzero, the frame shall be silently discarded, the t0 (retransmission) timer set, and the protocol instance shall remain in the Confirmed
state. If Sync is greater than dot11RSNASAESync, the protocol instance shall send the parent process a Del event and transitions back to Nothing state. If Sync is not greater than dot11RSNASAESync, the protocol instance shall verify that the finite cyclic
group is the same as the previously received SAE Commit message. If the verification fails, the frame shall be silently discarded. Otherwise, the protocol instance shall increment Sync, increment Sc, and transmit its SAE Commit message and its SAE Confirm
message with the new Sc value. It then shall set the t0 (retransmission) timer.
- N
p.s. The flow of the previous text was fine and what was needed was a clarification of the phrases 'if not', 'if so' etc- which the above text does...
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Mark,
Given your hyper-sensitivity over "professional" conduct I think you should refrain from calling other
people's writing style "ambiguous rambling 'stream of consciousness'". And when you criticize other
people's writing you should at least suggest changes that are correct.
I am opposed to this CID growing, which is what you seem to be doing here. Let's address the CID
and the text it is on and not use this to rewrite a section (or other sections like 12.4.8.6.3).
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
I think some strikethroughs got lost (I have this trouble when I cut
and paste Word change-tracking).
Anyway, instead of trying to flog this dead horse, why don't we use
formatting to be clear on the sequencing? Something like this
(I've taken one possible interpretation of the current text, but
others are possible):
- Upon receipt of a Com event, the t0 (retransmission) timer shall be canceled.
- If the Status
[field? of what?] is nonzero, the frame [what frame?] shall be silently discarded, the t0 (retransmission) timer
[shall be] set, and the protocol instance shall remain in the Confirmed state.
[this should be made into an entirely active phrase "the protocol instance shall…"]
- Otherwise:
- If Sync is greater than dot11RSNASAESync, the protocol instance shall send the parent process a Del event and transitions
[no s] back to Nothing state. [and the frame shall be silently discarded?]
- Otherwise:
- If the finite cyclic group is not the same as [in] the previously received SAE Commit message, the frame shall be silently discarded.
- Otherwise, the protocol instance shall increment Sync, increment Sc, transmit its SAE Commit message and its SAE Confirm message with the new Sc value, and set the t0 (retransmission)
timer.
Note that I think the ambiguous rambling "stream of consciousness" style
is also used in other locations (e.g. 12.4.8.6.3).
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
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Thanks, Nehru. But, your suggested text seems to have gotten munged (I assume), and there are stray “Otherwise”s, or at least some problem parsing the sentences near the words “Otherwise”.
Mark
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
There is also another issue with the text, not related to the comment though. When a Com event is received, the retransmission timer is canceled. So, a fake commit message could have the effect of canceling the timer
and discarding the frame. Not sure that should be the right behavior from a security standpoint.
There is some text in the same paragraph before the text under discussion - I took another stab and simplifying and clarifying the intended semantics without reordering the phrases (and hopefully not introducing any
issues)
Upon receipt of a Com event, the t0 (retransmission) timer shall be canceled. If the Status is nonzero, the frame shall be silently discarded, the t0 (retransmission) timer set, and the
protocol instance shall remain in the Confirmed state. If Sync is greater than dot11RSNASAESync, the protocol instance shall send the parent process a Del event and transitions back to Nothing state. If Sync is not greater than dot11RSNASAESync Otherwise,
the protocol instance shall verify that the finite cyclic group is the same as the previously received SAE Commit message. If not the verification fails, the frame shall be silently discarded. If soOtherwise, the protocol instance shall increment Sync, increment
Sc, and transmit its SAE Commit message and its SAE Confirm message with the new Sc value. It then shall set the t0 (retransmission) timer.
Hi all,
For CID 116, we debated whether we could accept the comment and could not come to an agreement on a proposed resolution. (see the comment and discussed resolutions below)
I would like to initiate a discussion on the reflector to see if we can come to a resolution.
REVme SEC adhoc comments
|
2554.00
|
12.4.8.6.5
|
|
V
|
SAE: "<verify X>. If not, <do Y>. If so, <do Z>" construction can be ambiguous since it is not always clear what "if
so" is referring to (something in "verify X" vs. "do Y").
|
Replace
"If Sync is not greater than dot11RSNASAESync, the protocol instance shall verify that the finite cyclic group is the same as the previously received SAE Commit message. If not, the frame shall be silently discarded. If so, the protocol instance shall increment
Sync, increment Sc, and transmit its SAE Commit message and its SAE Confirm message with the new Sc value."
with
"If Sync is not greater than dot11RSNASAESync, the protocol instance shall verify that the finite cyclic group is the same as the previously received SAE Commit message. If not, the frame shall be silently discarded. Otherwise, the protocol instance shall increment
Sync, increment Sc, and transmit its SAE Commit message and its SAE Confirm message with the new Sc value."
|
The proposed resolution that was discussed on the call (along with an alternative that was mentioned in the chat):
Replace
"If Sync is not greater than dot11RSNASAESync, the protocol instance shall verify that the finite cyclic group is the same as the previously received SAE Commit message. If not, the frame shall be silently discarded. If so, the protocol instance shall increment
Sync, increment Sc, and transmit its SAE Commit message and its SAE Confirm message with the new Sc value."
with
"If Sync is not greater than dot11RSNASAESync, the protocol instance shall verify that the finite cyclic group is the same as in the previously received SAE Commit message. If it is not, the frame shall be silently discarded. Otherwise, the protocol instance
shall increment Sync, increment Sc, and transmit its SAE Commit message and its SAE Confirm message with the new Sc value."
Alternative:
ust a suggestion: "If Sync is not greater than dot11RSNASAESync, the protocol instance shall verify that the finite cyclic group is the same as in the previously received SAE Commit message, and if it is not, the frame shall be silently discarded. If Sync is
greater than dot11RSNASAESync, the protocol instance shall increment Sync, increment Sc, and transmit its SAE Commit message and its SAE Confirm message with the new Sc value."
|
Error! Filename not specified.
|
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
|
Error! Filename not specified.
|
|
Error! Filename not specified.
|
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
|