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

Re: [STDS-802-11-TGAI] comments/questions on your joined contribution 12/1045r6



Thanks Lei for your comments. Please see my comments below:

 

From: Lei Wang [mailto:leiw@xxxxxxxxxxxxxx]
Sent: Monday, November 12, 2012 9:18 PM
To: Dan Harkins; Cherian, George; Malinen, Jouni; 'Rene Struik'
Cc: 'Gabor.Bajko@xxxxxxxxx B'; 'mano'; 'Marc Emmelmann'; STDS-802-11-TGAI@xxxxxxxxxxxxxxxxx
Subject: comments/questions on your joined contribution 12/1045r6

 

Hi, Dan, George, Jouni, and Rene,

 

I’ve reviewed your joined contribution 12/1045r6 and have some questions/comments. Was hoping we will have time to discuss them during the FtF meeting here in San Antonio. Well, based on this afternoon’s meeting planning discussion, I am not so sure about the time allowed for discussions on detailed comments/questions here. So, I am sending you the email with my questions/comments below:

1.       The reference to EAP-RP in 12/1045r6 is RFC 6696, which is different from the references given in TGai SFD, 12/0151r13, where the references are RFC 5295/5296. Then, my questions are: what’re the major differences, particularly, in implementation complexities?

[George] RFC 6696 is the updated IETF RFC for 5296. Changes with respect to 5296 is captured in the section 1.1 of RFC 6696, “Changes from RFC 5296”

2.       The term “FILS Authentication” is used in 12/1045r6, but the current text covers the Re-Authentication portion in FILS. Then my concern is about the cases where there is no prior-authentication, i.e., FILS with initial authentication. Should FILS authentication also include “fast” initial authentication too?

[George] Here is the clarification we added in Section 4.5.4.2 based on your comment from last meeting: “When a trusted third party is used for FILS authentication  A STA that discovers a FILS-capable AP that claims a trusted relationship with a mutually-trusted third party it may begin the FILS Authentication protocol to the AP and perform mutual authentication using the trusted third party only if the STA and trusted third party already share a valid rRK, as defined in [IETF RFC 6696] (see section 11.9a.2.1); otherwise the STA may perform full EAP authentication via IEEE 802.1X authentication”

So, couple of points to note: (1) On terminology, we use “Full EAP authentication” & “FILS authentication”. (2) We expect that the rRK life time can be long enough so that the full-EAP authentication is performed very infrequently. However, we are open for other contributions that could improve the full EAP authentication.

3.       In 12/1045r6, page 4, Figure <ANA-0>—FILS Authentication, what’s the relationship between this procedure and 802.1x procedure (if assuming both carry EAP messages)? Co-exist? Replacement?

[George] FILS authentication cuts down the number of messages used in 802.1x - so clearly from messaging stand point they are different. However, the FILS authentication messages follows 802.1x architecture. It is also RSNA compliant.

 

4.       On page 18 in 12/1045r6, the new text about key confirmation, “Key confirmation is part of the FILS authentication exchange and no further handshakes are needed to satisfy key management requirements in an ESS.”  Does this mean the FILS authentication does  not use the 4-way handshake?

[George] No. We believe the 4-way handshake can be simplified in order to accelerate the messaging without compromising on security.

 

Hope to hear back from you soon. Thanks.

 

BR,

 

Lei

_______________________________________________________________________________

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-FIA 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 _______________________________________________________________________________