Re: [STDS-802-11-TGAI] document 11-13/0469r0
Hi Lei,
On 5/7/13 11:36 PM, "Lei Wang" <leiw@xxxxxxxxxxxxxx> wrote:
>Hi, Dan,
>
>Thanks for your quick response. Please see my follow-up response below.
>
>BR,
>
>Lei
>
>-----Original Message-----
>From: *** 802.11 TGai - Fast Initial Link Set-Up ***
>[mailto:STDS-802-11-TGAI@xxxxxxxx] On Behalf Of Dan Harkins
>Sent: Tuesday, May 07, 2013 10:40 AM
>To: STDS-802-11-TGAI@xxxxxxxxxxxxxxxxx
>Subject: Re: [STDS-802-11-TGAI] document 11-13/0469r0
>
> Hi Lei,
>
>On 5/7/13 9:47 AM, "Lei Wang" <leiw@xxxxxxxxxxxxxx> wrote:
>
>>Hi, Dan,
>>
>>Thanks for reviewing the contribution 13/0469
>>
>>Please see my responses below inline.
>>
>>BR,
>>
>>Lei
>>
>>-----Original Message-----
>>From: *** 802.11 TGai - Fast Initial Link Set-Up ***
>>[mailto:STDS-802-11-TGAI@xxxxxxxx] On Behalf Of Dan Harkins
>>Sent: Monday, May 06, 2013 6:08 PM
>>To: STDS-802-11-TGAI@xxxxxxxxxxxxxxxxx
>>Subject: [STDS-802-11-TGAI] document 11-13/0469r0
>>
>> Hi Lei,
>>
>> I just read your document 11-13/0469r0 on the FILS Wrapped Data
>>element. I
>>think there is a misunderstanding about how these "variable" length
>>fields are
>>parsed.
>>
>> The element field is marked as "variable" and does, indeed, end up in
>>the
>>middle of some other fields in a frame. But contrary to your assertion,
>>this is
>>not a problem because the length of the field is inferred by a
>>fixed-length
>>field that precedes the element, namely the finite cyclic group. So what
>>happens is the finite cyclic group is parsed (it is 2 octets in length)
>>and the
>>encoded group is looked up. Each group will have elements in it that are
>>a fixed length. If the AP doesn't understand the encoded group then it
>>won't know how big the element field should be but if it doesn't
>>understand the encoded group then it will fail processing of the frame
>>anyway (and reply with a status code of 77 per 11.11.2.2.2). So even
>>though
>>the element field is "variable", it is quite easy to parse. I know, I
>>wrote code
>>that does it!
>><LW> I see your point, and agree. Basically, for each value of Finite
>>Cyclic Group field, there is a corresponding ³Element² field with a
>>deterministic size. Since different values of Finite Cyclic Group
>> field may have different sizes of ³Element² field, the ³Element² field
>>in Authentication frames is a variable-size field in general. Well, I
>>have couple of follow-up questions below:
>>a)
>>On page 435, in 802.11-2012 spec, Table 8-29, SAE with transaction
>>sequence no. equals to 1, if Status is zero, there are two variable-size
>>fields, Scalar and Element. Your above explanation tells
>> how the ³Element² field is decoded. Does the same explanation work for
>>decoding the Scalar field too?
>
> Yes, the scalar is the size of the order of the group.
>
>>b)
>>Also, on page 435, in 802.11-2012 spec, Table 8-29, SAE with transaction
>>sequence no. equals to 2, the Confirm field is a variable-size field,
>>following the same thinking, is its size implied by
>> the 2-byte Send-Confirm field?
>
> No, that's determined by the size of digest created by H() which you
>know because you negotiated it.
><LW> negotiated it? When / how? Not clear to me, by reading Subsection
>11.3.7.5 in 802.11-2012. Again, could you please point out the relevant
>text? Thanks.
11.3.7.5 tells you what goes into the Confirm field and it tells you
what section describes the process of obtaining that thing that goes
in the Confirm field. And if you look there you'll see I misspoke. It's
not function H(). It's CN(). And if you look at what CN() is in 11.3.2
you'll also find text that says how it is instantiated and that it is
the AKM that governs the particular instantiation.
>
>>c)
>>Although your above explanation is clear to me, I could not find similar
>>text/info by just reading the 802.11-2012 spec, including sections
>>8.3.3.11 and 11.3.4. can you please point out the relevant
>> text? Thanks.
>
> You're just looking at fields that are variable and raising issues. If
>you look
>into what is contained in the field and how the field is created you will
>not
>have these issues.
><LW> I did look at the descriptions given in Subsection 11.3.4, in
>addition to frame format in 8.3.3.11, still not clear to me. Again, your
>explanation is clear, but could not
> found similar text in the current spec. Probably the current spec text
>looks very clear to the original contributors and to those people who
>were actively involved in the relevant text development discussions.
You act as if you're the first person to read 11.3 other than "those
people
who were actively involved in the relevant text development discussions."
You're not.
11.3.4 describes the groups and what an element in the group is.
11.3.7.2.4
describes how you encode an element in a group. For instance, the 2nd
paragraph
in that section says how long an FFC element is-- "To convert this element
into
an octet string, it shall be treated directly as an integer and converted
into
an octet string whose length is the smallest integer m such that 2^8m > p,
where
p is the prime number specified by the domain parameters." And we know
what the
domain parameters are since they are uniquely identified by the finite
cyclic
group (which is a fixed length field). So we have all the info we need to
determine how big an element is.
11.3.7.5, which you have previously indicated you are familiar with,
says,
"the output of the random function shall be treated as an integer and
converted
into an octet string of length m, where m is the block size of the random
function...." And we know what the block size of the random function is
because
we know how we instantiated it (again, see 11.3.2).
>
>>
>> Similarly, the length of the FILS Wrapped Data field can be determined
>>without resorting to turning it into an Information Element (and adding
>>2 more octets). That is because the field is, itself, an EAP packet that
>>has
>>a parseable format. When an Authentication frame used for FILS
>>
>>Authentication with a TTP has a transaction sequence number of 1, the
>>entirety of the FILS Wrapped Data field is a EAP-Initiate/Re-auth packet
>>whose format can be found in RFC 6696, in section 5.3.2, Figure 9. There
>>is
>>no need to worry about a STA not knowing the format of such a packet
>>because if it didn't then it wouldn't know how to do FILS Authentication
>>with a TTP and if it didn't know how to do that then it wouldn't be
>>receiving
>>such a frame in the first place.
>><LW> I see your point, but for this one, I don¹t agree based on the
>>current 11ai draft spec, for the reasons/questions below:
>>a)
>>The FILS Wrapped Data field is not always included in Authentication
>>frames with Authentication Algorithm equals ³FILS², as it is not needed
>>for FILS Authentication without TTP.
>
> Yes, if you look in table 8-29 you will see that this is only present
>when
>a TTP is used. And that's why I said "when an Authentication frame used
>for
>FILS Authentication with a TTP...." So what's your point?
><LW> Ok, the point is that, if it is not always included, then it should
>be encoded as Information Element, not an Information Field, as any
>non-mandatory info items in a MAC
> management should be self-identifiable.
That is a non sequitur.
>
>>b)
>>There are two places in 11ai/D0.5, line 27 page 82 and line 42 page 82,
>>talking about copying/extracting ³EAP-Initiate/Re-auth packet² into/from
>>Wrapped Data field. It means EAP packet can be a
>> Wrapped Data, but it does not mean FILS Wrapped Data, itself, is an EAP
>>packet. If the TGai group agrees FILS Wrapped Data is EAP packet, then at
>>minimum, it should be clearly specified, i.e., FILS Wrapped Data field is
>>EAP packet as in RFC 6696. Well, during
>> the previous 11ai discussions, my understanding is that the higher layer
>>protocol can also be encoded as ³Wrapped Data², am I right?
>
> 8.4.1.53, which describes the field in question, says "The FILS wrapped
>data
>field is used for the STA and AP to communicate data used by the FILS
>authentication
>algorithm." And, as we have just established above, it is only used in
>FILS authentication
>when there is a TTP. The text in 11.11.2.2.1 describes FILS Authentication
>with a TTP and
>how to populate this field. So I think the use of this field is already
>pretty tightly
>constrained.
><LW> ok, your above answer basically tells me that this FILS Wrapped Data
>won’t be extended to carry HLD (Higher Layer Data) as part of still
>on-going effort of TGai group to
> complete the higher layer protocol data piggyback scheme. Ok with me, no
>objection.
I never mentioned extending anything. I merely said what is currently in
the text and how it is consistent.
>
>>c)
>>If the FILS Wrapped Data is EAP packet, then why do we just call it EAP
>>Packet field?
>
> I don't think the name is the issue here.
><LW> cannot agree here. Wrapped Data indicates the MAC management frame
>processing module passes it to other layer/module without a need to
>interpreter/decode its contents; while
> EAP-Packet field or any other meaningful name can be used to indicate
>the MAC frame management frame processing module decodes it as EAP-packet.
OK fine, you don't agree. I'm still going to recommend that your comment
be rejected.
Dan.
>
> Dan.
>
>>
>> For these reasons, I am going to recommend that your comment
>>(as described in 11-13/0469r0) be rejected. I also advise you against
>>commenting on the TGmc draft (which you suggested in your submission).
>>
>> 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
_______________________________________________________________________________