Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGAI] Contribution uploaded & MDR open issues (and AEAD/GCM clarifications)



> On 12 May 2015, at 2:14 pm, Daniel Harkins <dharkins@xxxxxxxxxxxxxxxxx> wrote:
> 
>   It appears that the modifications to 11.11.2.4.3 are for a different version of the draft.
> Version 4.3 does not contain the paragraph that is being modified; it has something very
> similar but it's not the same.

Correct. This is based on the latest work version I received from the editor.

> Also, why set both AEAD counters to zero when the PTKSA is
> created and then construct the nonce in the way specified in 11.11.2.6? Why not just set
> the AEAD counters to be all zeros on one side and 0x01 || rest zeros on the other (or better
> 0x80 || rest zeros) at PTKSA creation time and then just increment when used? 

Using a simpler definition for the AEAD counter seemed to make the complete description simpler. And yes, that would be 0x80 || zeros in this case with 802.1X conventions. My reasons for this approach was to keep the nonce uniqueness requirement as part of the GCM-specific language and leave the AEAD counter more generic. There was need to add a more explicit description of the exact GCM nonce construction (mainly, byte order), so handling the sender role was an easy addition to do.

>   Also I have a slight preference to making the encrypted data in the (Re)Association
> frames to be the tag concatenated with cipher text instead of the cipher text
> concatenated with the tag. The reason is:
> 
>    t = p
>    c = p + taglen
> 
> seems better to me than:
> 
>   c = p
>   t = p + len(p) - taglen
> 
> but that's not a hill I'm willing to die on so if the author likes it better C || T then I
> won't complain. 

I have no strong (if any) preference on this. All I needed to make sure is that the location of the tag is specified. In case of GCMP (the only existing use of GCM in the base standard), the tag happens to be immediately after the ciphertext which is the model I used here. In practice, I don't see much of a difference in implementation complexity regardless of which sequence is used here.

- Jouni

_______________________________________________________________________________

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
_______________________________________________________________________________