Re: [STDS-802-11-TGAI] 11-14/1621r1 and 11-14/1622r0
Hello Dan,
> >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.
I didn't say it wasn't. The question is whether it's a good/correct
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.
I didn't say it wasn't. See comments in Word doc for specific suggestions
on how to make it better.
> >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.
I don't understand.
> >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.
No opening square bracket immediately followed by an operator appears
in Clause 11 in the baseline (I haven't checked other clauses in detail,
but a quick skim didn't identify any instances).
I think it is clearer to spell out the intent, as in 14/0692r2.
> >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.
Unless you're going to craft a special motion, the resolutions will
be adopted as in the spreadsheet, which merely says "accept" for
the resolution. There is no such thing as ordering of the resolutions
in this case.
Anyway, I'm fine in principle, since this kind of thing is for the
editor(s) to watch out for. I just wanted to make sure it wasn't
missed.
> >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.
E.g. someone forges a frame which causes you to invoke AEAD processing?
But anyway, that was not my question. My question was what happens
in failure cases. The quoted text says "Processing [...] shall
include verification", so what happens if the verification comes up
with a nyet?
> 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.
I seem to recall that Rene had volunteered to deal with the AEAD-related
comments, so perhaps he could take this on.
> >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).
You seem to be suggesting that the vote to put D3.0 to letter ballot
means the question is already answered. This makes no sense. If this
were the case, then there would be no need for any comment resolution,
as all comments could be rejected with "the TG voted in the D1.0 text"!
> 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 am not aware of any 802.11 rule that features in a draft that passed
letter ballot cannot be removed in a subsequent letter ballot, if found
to be broken/unworkable/outside the scope of the PAR/whatever.
I suggest you (or someone else), give a responsive resolution, i.e.
explain why SA caching is relevant to initial link setup.
> >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).
I see "I shall try to be more gracious" was not one of your new year's
resolutions!
[In any case, mgr2, mgr29, mgr30 and mgr33 are definitely not editorial,
and mgr4, mgr5 and mgr21 are arguably technical too.]
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
> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@xxxxxxxxxxxxxxxxx]
> Sent: 2 January 2015 18:42
> To: Mark Rison; 'STDS-802-11-TGAI@xxxxxxxxxxxxxxxxx'
> Subject: Re: 11-14/1621r1 and 11-14/1622r0
>
>
> Hi Mark,
>
> On 1/2/15 7:55 AM, "Mark Rison" <m.rison@xxxxxxxxxxx> wrote:
>
>
> >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
> >ROYAUME UNI WWW: http://www.samsung.com/uk
> >
> >From: *** 802.11 TGai - Fast Initial Link Set-Up ***
> >[mailto:STDS-802-11-TGAI@xxxxxxxx]
> >On Behalf Of Dan Harkins
> >Sent: 29 December 2014 22:33
> >To: STDS-802-11-TGAI@xxxxxxxxxxxxxxxxx
> >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 -
> >http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAI
> ><http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAI> and then
> >amend your subscription on the form provided. If you require removal from
> >the reflector press the LEAVE button.
> >
> >Further information can be found at:
> >http://www.ieee802.org/11/Email_Subscribe.html
> ><http://www.ieee802.org/11/Email_Subscribe.html>
> >__________________________________________________________________________
> >_____
_______________________________________________________________________________
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 - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAI and
then amend your subscription on the form provided. If you require removal from the reflector
press the LEAVE button.
Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html
_______________________________________________________________________________