Re: [STDS-802-11-TGAI] document 11-16/1100r0
I've uploaded 11-16/1100r2 after getting some last comments on clarity. I will
present r2 tomorrow (or today depending on where you are when you read this).
regards,
Dan.
On 8/22/16, 10:27 AM, "*** 802.11 TGai - Fast Initial Link Set-Up *** on behalf of Daniel Harkins" <STDS-802-11-TGAI@xxxxxxxx on behalf of dharkins@xxxxxxxxxxxxxxxxx> wrote:
> Hi Mark,
>
>On 8/22/16, 4:32 AM, "*** 802.11 TGai - Fast Initial Link Set-Up *** on behalf of Mark Rison" <STDS-802-11-TGAI@xxxxxxxx on behalf of m.rison@xxxxxxxxxxx> wrote:
>
>>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?
>
>>- 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'.
>
>>- 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.
>
>>- 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?
>
>>- 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." "peer-MAC" is "the
>peer STA's MAC address" as described above this text.
>
>>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.
>
> regards,
>
> 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
>>
>>
>>> -----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
>_______________________________________________________________________________
_______________________________________________________________________________
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
_______________________________________________________________________________