Re: [STDS-802-11-TGAI] [Feedback due Fri March 29th, 12pm EDT] Call for offline comments on 802.11ai documents re representation of "Higher-Layer Objects" and "Large Objects", and processing during FILS authentication scheme
- To: STDS-802-11-TGAI@xxxxxxxxxxxxxxxxx
- Subject: Re: [STDS-802-11-TGAI] [Feedback due Fri March 29th, 12pm EDT] Call for offline comments on 802.11ai documents re representation of "Higher-Layer Objects" and "Large Objects", and processing during FILS authentication scheme
- From: Dan Harkins <dharkins@xxxxxxxxxxxxxxxxx>
- Date: Tue, 26 Mar 2013 00:53:55 +0000
Hi Rene,
On 3/25/13 5:55 AM, "Rene Struik" <rstruik.ext@xxxxxxxxx> wrote:
>[This reiterates my earlier request for comments, made during the Thu
>pm2 session of TGai last wee in Orlando]
>
>Dear colleagues:
>
>Hereby, I would like to request constructive feedback on the mechanisms
>presented in document 13/201r5 and those specified in 13/311r0.
I think the ideas presented in 11-13/0201r5 go well beyond the problem.
There is no real need to have a kind of ultimate flexibility to do
"aggressive schemes", or to split plaintext into pieces, or to reorder
IEs. I don't think the "additional problem statement" is anything the
group has agreed is a problem that we need to solve.
Most interfaces to cipher modes provide for input of a key, plaintext,
and a length of the plaintext (plus other stuff like an IV/counter and
AAD as the mode allows), they output cipher text. To allow for the scheme
you are proposing, one would require a gather/scatter interface to a
cipher mode or something analagous to that used by hash functions--
where there's a hashupdate() call that is made over and over for each
chunk of data to be hashed, and a hashfinal() when there is no more.
This is an unnecessary complexity.
Sections 8.4.1a.2.1/2 from 11-13/0311r0 are ambiguous and confusing,
in my opinion. I do not believe this scheme is implementable. There is
no reason to have an "encryption indicator". The key agreement schemes
already indicate what data is encrypted and what is not.
All we need to do is break up data that is too big to fit in an IE
(i.e. it's length is > 255 octets) into a sequence of IEs that can be
put into a really big 802.11 frame that will be fragmented by the MAC,
much in the same way that giant EAP packets get broken up into RADIUS
attributes that are all < 255 octets.
I don't understand why 11-13/0311r0 strikes out the entirety of the
key agreement schemes we have already voted into our draft (pages 10
to 32).
>Please provide your comments to me personally offline by Good Friday
>(i.e., Friday March 29, 2013), noon EDT.
>
>I will summarize comments and make these available to the group. I will
>also use these comments to guide updates of the documents referred to
>above.
I think it would be better if people provided comments to the list
instead of sending them to you offline and having you summarize them
for us. The WG can handle an open discussion of this problem.
regards,
Dan.
>Hiroshi/Marc:
>I would tentatively like to revisit this topic during the conf call on
>Tue April 16, 2013, 9am EDT.
>
>Note:
>In case you wish to share information (e.g., specifics on the
>I/O-interface of CCM processing on your favorite 802.11 platform), you
>can do so. I will treat this as offline communication not to be shared
>with the group in an identifiable manner.
>
>Best regards, Rene
>
>--
>email: rstruik.ext@xxxxxxxxx | Skype: rstruik
>cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>
>__________________________________________________________________________
>_____
>
>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
_______________________________________________________________________________