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.
>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.
>
> 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?
>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.
>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.
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
_______________________________________________________________________________