Re: [STDS-802-11-TGAI] document 11-16/1100r0
Hello Dan,
> >I've had a quick look at the proposed changes. My comments on
> >the technical changes are:
> >
> >- No justification is given for the technical changes, apart from
> >"in order to deal with related key attacks". It would be desirable
> >to explain in more detail how these attacks work and how the proposed
> >changes deal with them
>
> I will discuss this on the call. Is that OK?
Personally, I think that for the benefit of people who can't attend,
and also for the record (especially for something involving security,
whose assumptions and derivations need to be scrutinised carefully),
there should be some detail in the document.
> >- In 12.7.12.4.2, the change to step 4 ("C" -> "C'") means that
> >C (used in step 7) is no longer defined. What is C?
> C is described above this text on lines 1-5 of page 144 in D9.0. It is
> the
> encrypted public key of the device running the protocol. Step 4 was
> wrong
> because you don't decrypt your own key to obtain the peer's unencrypted
> key you decrypt the peer's encrypted key, C'.
I see. Hm, then I find it a bit confusing. We have:
"[an] encrypted public key, C" (144.1-5/D9.0)
"[The] encrypted public key, C’" (16/1100r0, 12.7.12.4.2)
I think that to disambiguate these two "encrypted public key"s, they
need to have qualifiers like "the STA's" and "peer's" respectively.
> >- In 12.7.12.4.2, the change in the x assignment in step 7 means
> >that Hash() is now a two-argument function, which doesn't prima
> >facie make sense (a hash takes one string and generates another).
> >Where is Hash() defined?
> Ahh, good eye. The comma should be a bar indicating concatenation.
> The hash algorithm to use is explained in 12.7.12.2.
OK.
> >- Similarly, in 12.7.12.4.2, where is "KDF-i" defined? In the
> >baseline we are careful to always say "KDF-Hash-Length, where
> >KDF-Hash-Length is the key derivation function defined in
> 12.7.1.7.2 (Key derivation function (KDF)) using the hash
> algorithm identified by the AKM suite selector (see Table 9-133
> (AKM suite selectors)" or similar
> Since PKEX does not use an AKM there is no AKM suite selector. In
> 12.7.12.2
> it mentions that the KDF and it's the one from 12.7.1.7.2. You're right
> that
> this is different. I will update the submission to indicate that it's
> KDF-Hash-Length
> and explain that the hash is as indicated in 12.7.12.2 and the length is
> the length
> of the digest produced by the hash function (which is stated above the
> use of KDF
> but that is, as you note, different than the way the KDF is referred to
> in the base
> standard). How does that sound?
Sounds OK, I think.
> >- Similarly, in 12.7.12.4.2, where are "STA-nonce" and "peer-nonce"
> >defined? And "peer-MAC" (also the one in 12.7.12.4.2 of D9.0)
> I will refer to these "the nonce produced by the STA and the nonce
> produced
> by the peer, respectively, as part of the PKEX exchange."
The important thing is to try to be consistent with other
similar references. Grepping for -nonce and ANonce/SNonce I find:
where SNonce is the STA nonce and ANonce is the AP nonce.
where SNonce is the STA’s nonce and ANonce is the AP’s nonce.
where SNonce is the STA's nonce, ANonce is the AP’s nonce.
[concatenation with] the STA’s nonce SNonce, the AP’s nonce ANonce,
where ANonce is the AP’s nonce and SNonce is the STA’s nonce.
[concatenation with] — the AP’s nonce ANonce, — the STA’s nonce SNonce,
Hm, actually I can't find any instances of "-nonce" except in 11ai.
It might be worth using terminology that matches the baseline more
closely. Maybe PNonce and INonce (not sure about the latter)?
> "peer-MAC" is
> "the peer STA's MAC address" as described above this text.
OK, but nowhere does it actually say that. It needs to do so.
Cf. 12.7.12.4.1, which says "STA-MAC is the MAC address of the STA
generating Q".
> >Looking at the editorial changes to the subclause references:
> >
> >- The reference to "11.3.4.1 (General)" in D9.0 12.11.2.3.2 looks
> >stale to me too (i.e. needs to be made into a 12.4.4.1 reference,
> >I think)
> >
> >- The reference to "11.6.12 (Authenticated Public Key Exchange)"
> >in 9.4.2.119 in D9.0 ditto should be 12.7.12. Note that the
> >parenthesis should be part of the cross-reference, so it disappears
> >in the final publication
> >
> >- Ditto "11.6.1 (Key hierarchy)" in D9.0 11.47.4,
> >"11.6.1.3 (Pairwise key hierarchy)" in D9.0 12.6.1.1.2 (twice)
> >
> >- Ditto "11.6.1.2 (PRF)" in D9.0 12.7.1.7.2
> >
> >- Ditto "11.3.7.2.4 (Ele-ment to octet string conversion)"
> >in D9.0 12.7.12.4.2
> >
> >- Given all this, I think the editor should go through D9.0 and
> >re-check whether there is anything else from the baseline that
> >has been missed (a good start would be subclause and other
> >references that are not hyperlinks)
>
> This submission is focused on 12.7.12 (PKEX) and I will fix the
> references
> in that section with this submission. I will leave the others to the
> chairs and
> the editors for their proper resolution.
I don't mind who does it, but it we fix some references we should fix
them all.
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
> >> -----Original Message-----
> >> From: *** 802.11 TGai - Fast Initial Link Set-Up *** [mailto:STDS-
> 802-
> >> 11-TGAI@xxxxxxxx] On Behalf Of Marc Emmelmann
> >> Sent: 18 August 2016 09:21
> >> To: STDS-802-11-TGAI@xxxxxxxxxxxxxxxxx
> >> Subject: Re: [STDS-802-11-TGAI] document 11-16/1100r0
> >>
> >> Dan,
> >>
> >> we'll put this as an discussion item on the agenda for the upcoming
> >> telco next week.
> >>
> >> Ping: As the Vice-Editor, would you please be so kind to review the
> >> contribution to check if it contains any text from the baseline
> >> that has to be updated against REVmc ?
> >>
> >> Please sync with Dan and with Lee to assure that the submission can
> be
> >> immediately rolled in our draft in case
> >> it is approved.
> >>
> >> I would also encourage all TGai members to review the submission and
> >> provide feedback before the weekend. If we agree that the
> >> "potential securiy issue" has to be addressed and the submission is
> >> rolled in, we have to assure that
> >> it is "perfect", i.e., does not contain any errors / issues at all,
> as
> >> the upcoming D10.0 is the last draft that may contain any changes.
> >>
> >> Best,
> >>
> >> Marc
> >>
> >> On 16 Aug 2016, at 22:23, Daniel Harkins <dharkins@xxxxxxxxxxxxxxxxx>
> >> wrote:
> >>
> >> >
> >> > Hello,
> >> >
> >> > I've just been alerted to a small problem with PKEX. The issue is
> a
> >> "related key attack".
> >> > It's kind of esoteric but the fix is easy and I'd like to fix it
> now
> >> before 11ai is published.
> >> > Also, the references in the whole PKEX section were wrong (old
> section
> >> 11 references
> >> > that needed to be changed to section 12) so I took care of those
> too.
> >> >
> >> > I'd like some time to present this. I'm sorry it's so late but
> >> better now than even later.
> >> >
> >> > regards,
> >> >
> >> > 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 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__________________________
> >> _____________________________________________________
> >>
> >>
> ________________________________________________________________________
> >> _______
> >>
> >> 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
> >>
> ________________________________________________________________________
> >> _______
> >
> >_______________________________________________________________________
> ________
> >
> >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
> >_______________________________________________________________________
> ________
_______________________________________________________________________________
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
_______________________________________________________________________________