-----Original Message-----
Sent: 2 January 2015 18:42
Subject: Re: 11-14/1621r1 and 11-14/1622r0
Hi Mark,
>Thank you for these resolutions, Dan. I have the following comments on
>the spreadsheet:
>
>CID
>Page
>Line
>Clause
>Comment
>Proposed Change
>Resolution
>mgr Comments
>6026
>111.00
>9
>11.11.1
>shared key authentication can also be used with a cached PMK
>state that the rRK is necessary only when not doing PMK caching
>revised: stated that what is shared is either an rRK from ERP or a PMK
>from a previous FILS authenciated connection.
>Why does the PMK have to be from a FILS-authenticated connection? Why
>won't any old authenticated connection do?
This is a responsive resolution.
>6034
>116.00
>28
>11.11.2.2.2
>the procedure described in 11.11.2.2.2 reads as a long
>stream-of-consciousness and is hard to follow
>rewrite the requriements so the steps are not so confusing
>revised: enumerated process to make it easier to follow.
>Enumerations introduced are a good start, but more could be done,
>specifically to address the "shall then"s
While it is hard to dispute that "more could be done", this is
a responsive resolution.
>6668
>117.00
>39
>11.11.2.3.2
>Having || on the left of an equation is a bit weird and might lead to
>confusion
>Define an intermediate value PTK and then use L(); see 1931.62 and
>1939.23 of mc/D3.0 for inspiration
>reject: this is not confusing as illustrated by the fact that the
>proposed change would restate the procedure identically, but differently.
>Obviously the commenter understands it.
>The commenter does *not* understand the equation at the cited location to
>the extent of being sure what is intended, so as the commenter suggested,
>it is confusing, and should be
> addressed as suggested by the commenter
As was noted, the commenter proposed an identical procedure. To be
able to see a procedure and define a different procedure that produces
identical results is to illustrate understanding of the procedure.
>6071
>117.00
>62
>11.11.2.3.1
>IKM is not defined
>Define IKM
>revised: key derivation has been rewritten into 2, one for shared key and
>one for public key.
>Rewriting has reintroduced the "[|| ss]" which caused issues last time
>round
The issues the last round concerned multiple optional components
that the commenter at that time found confusing. Since there is only
1 optional component now those issues have not been reintroduced.
>6075
>118.00
>39
>11.11.2.3.1
>PKT derivation is wrong (i.e., Snonce is missing; PMK should be the first
>argument; and context change)
>Suggested change:
>KCK || KEK || TK = KDF-X(PMK, "PTK Derivation", SPA ||AA ||
>Snonce||Anonce)
>accept
>This will conflict with the resolution for CID 6803
No it won't because I have resolved the two CIDs in the right
order. If 11-14/1622 is adopted the editor can just fold the changes
from that submission into the draft and there is no conflict.
>6801
>118.00
>39
>11.11.2.3.2
>"SPA ||AA || ANonce" -- no SNonce?
>Add "|| SNonce" before "|| ANonce" and add a space before "AA"
>revised: SNonce was added after ANonce.
>Why after? This seems inconsistent with nearby orderings
Yes, good point. I will update the two documents to move SNonce
before ANonce.
>6683
>123.00
>27
>11.11.2.5
>"Each successive invocation of the encryption operation of GCM shall
>increment the AEAD counter by one (1). Processing of a received EAPOL-Key
>frame shall include verification that
> the received frame contains a counter that is strictly greater than the
>counter in the last received EAPOL-key frame, and shall update its copy
>of the peer's AEAD counter in its PTKSA to the value of the AEAD counter
>in the received, and verified, frame."
> -- this seems to be fragments of behaviour (e.g. missing is
>specification of what happens in the failure cases). It also seems to be
>potentially dangerous (you invoke encryption for some unexpected reason,
>and BAM! your AEAD counter gets incremented)
>Move this stuff to more appropriate subclauses (maybe 11.11.2.4)
>reject: this stuff is a component of the cipher mode and, as such, the
>section dealing with the specifics of the cipher mode is already the most
>appropriate subclause.
>I don't understand how the proposed resolution addresses the comment.
>Where is the specfication of what happens in failure cases, for example?
It is not apparent how one could "invoke encryption for some
unexpected reason" so I'm not seeing this fear of failure.
The proposed resolution is "Move this stuff to more appropriate
subclauses" which, as the resolution notes is not right because
the behavior is part of the mode and not of the procedure that
use an AEAD mode.
>6297
>If FILS is about initial link setup, then why does there need to be any
>discussion of SA caching?
>Delete all material related to xxKSA caching
>reject: the TG voted in this text and disagree about its importance.
>This is not a responsive resolution. A resolution needs to be provided
>which addresses the specific question in the comment. If, as the
>proposed resolution suggests, there was a
> vote about this, then presumably there was prior discussion addressing
>the question, which the resolution needs to reference (specifically
>enough so that it can be found). See section 2.9.3 of 11/1625 for
>further information
It should be self-evident that there was a vote because PMKSA Caching
is part of the draft. It didn't just appear out of thin air. I'm not
going to spend my time doing what you can do yourself (go through old
minutes to find the vote).
Furthermore, the vote on LB204 passed so I do not think it is right,
at this point in the process, to remove features that have been approved
by the WG. Changing the way a feature is handled-- s/GCM/SIV/ for
instance--
is acceptable but wholesale removal of approved features is not.
>
>I also have a number of comments on the Word document, which I attach.
>Some are just editorial, but some are technical.
Disagree; they are all editorial (and include unhelpful editorial
comments).
Dan.
>
>Regards,
>
>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
>
>From: *** 802.11 TGai - Fast Initial Link Set-Up ***
>On Behalf Of Dan Harkins
>Sent: 29 December 2014 22:33
>Subject: [STDS-802-11-TGAI] 11-14/1621r1 and 11-14/1622r0
>
>
>
>
>
> Hello,
>
>
>
> I've uploaded 2 documents to mentor that address comments from section
>11
>
>that are assigned to me. 11-14/1621r1 is a spreadsheet with proposed
>resolutions
>
>to the comments (some are accept, some are reject, and some are revised);
>and,
>
>11-14/1622r0 is a submission proposing text changes to our draft for the
>CIDs in
>
>11-14/1621r1 that are either accept or revised.
>
>
>
> Please take a look, especially if you have and outstanding section 11
>comment.
>
>I'd like to get this on the agenda for Atlanta so comments in the next
>couple of
>
>weeks will help ensure acceptable resolution to these CIDs.
>
>
>
> best regards, and Happy New Year to everyone!
>
>
>
> Dan.
>
>
>
>__________________________________________________________________________
>_____
>
>IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your
>request to this CLOSED reflector. We use this valuable tool to
>communicate on the issues at hand.
>
>SELF SERVICE OPTION: Point your Browser to -
>amend your subscription on the form provided. If you require removal from
>the reflector press the LEAVE button.
>
>Further information can be found at:
>__________________________________________________________________________
>_____