doc.: IEEE /1426r02 Submission NameAffiliationsAddressPhone ChengYan FengZTE Corporation No.800, Middle Tianfu Avenue, Hi-tech District, Chengdu, China Dezhi ZhangZTE CorporationE3048,Bibo Rd,Pudong,shanghai, China cn Li ZhuZTE CorporationE3048,Bibo Rd,Pudong,shanghai, China Lin WangZTE CorporationEast HuaYuan Road, Haidian District, Beijing, China Fast Security Setup Nov 2011 ZTE CorporationSlide 1 Authors:

doc.: IEEE /1426r02 Submission Abstract This document proposes an approach for accelerating the security setup for FILS. Nov 2011 ZTE CorporationSlide 2

doc.: IEEE /1426r02 Submission Conformance w/ Tgai PAR & 5C Nov 2011 ZTE CorporationSlide 3 Conformance QuestionResponse Does the proposal degrade the security offered by Robust Security Network Association (RSNA) already defined in ? No Does the proposal change the MAC SAP interface?No Does the proposal require or introduce a change to the architecture?No Does the proposal introduce a change in the channel access mechanism?No Does the proposal introduce a change in the PHY?No Which of the following link set-up phases is addressed by the proposal? (1) AP Discovery (2) Network Discovery (3) Link (re-)establishment / exchange of security related messages (4) Higher layer aspects, e.g. IP address assignment 3,4

doc.: IEEE /1426r02 Submission Background 11/1160r4 has proposed that –Use of optimized full EAP in 11/1047r6 when EAP-RP context is not setup, or has expired; –Otherwise use EAP-RP based fast authentication in 11/1160r4. Our comments: –It is a good idea to combine full EAP authentication with EAP re- authentication; –It could cover both initial security setup case and re-authentication case; –It could provide fast security setup effectively. Nov 2011 ZTE CorporationSlide 4

doc.: IEEE /1426r02 Submission Our Concern: 1 EAP method authentication procedure is out of scope of IEEE In the full EAP procedure in 11/1160r4, message 3, 4, 7 and 9 are EAP method specific. Why are they introduced in IEEE ai? FILS procedure should be independent with EAP method specific procedure. Nov 2011 ZTE CorporationSlide 5

doc.: IEEE /1426r02 Submission If DHCP lasts a long time, STA doesn’t receive the Association Response message in a pre-defined time, how does STA do ？ –STA can’t know what’s the problem is. It doesn’t know if EAP authentication is successful or not, if DHCP procedure is successful or not. –STA can only have to retransmit Association Request message, also carrying EAP related message. Our Concern: 2 Nov 2011 ZTE CorporationSlide 6 DHCP procedure lasts too long!

doc.: IEEE /1426r02 Submission State Machine: Only after receiving the successful message 15 (Association Rsp) STA could transform from NO Authentication Context to FULL-EAP-Session. But actually, after step 12, authentication has finished successfully. No need to wait for step 15, especially there is something wrong with DHCP procedure and too much time is wasted. Our Concern: 2 (Cont.) Nov 2011 ZTE Corporation Slide 7 State Machine in 11/1160r4 EAP authentication shall not be performed with DHCP procedure concurrently!

doc.: IEEE /1426r02 Submission Proposal Introduction EAP-based authentication is used. The specific method should be an implementation issue and is out of ai scope. The 4-way handshake procedure is reduced to 1 round. –The key agreement procedure follows EAP authentication. EAP authentication procedure is performed separately with DHCP procedure. –After successful EAP authentication, STA can change to FULL EAP session state. No need to wait for DHCP message. Nov 2011 ZTE CorporationSlide 8

doc.: IEEE /1426r02 Submission 4-way/Group Key handshake messages reduction Nov 2011 Slide 9 STAAP EAPOL-KEY(ANonce) EAPOL-KEY(SNonce, MIC1) Generate ANonce Generate SNonce, derive PTK, EAPOL-KEY(ANonce, MIC2) derive PTK, verify MIC1 EAPOL-KEY(MIC3) verify MIC2 STAAP Auth(ANonce, GTK[KEK], MIC1) Association Req (SNonce, MIC2) Generate ANonce and GTK, Derive PTK derive PTK, verify MIC1 verify MIC2 Generate SNonce Auth(SNonce) …. ZTE EAPOL-KEY(GNonce, GTK[KEK], MIC4) Generate GTK and GNonce EAPOL-KEY(MIC5) Decrypt GTK ZTE Corporation

doc.: IEEE /1426r02 Submission Original 4-way handshake: –1 st message: AP sends ANonce to STA; –2 nd message: STA generates SNonce, derives PTK, and sends SNonce and MIC1 to AP; –3 rd message: AP derives PTK, verifies MIC1 and sends MIC2 to STA; –4 th message: It serves no cryptographic purpose. It serves as an acknowledgment to Message 3. Group Key handshake: 2 messages are used to transfer GTK Proposed key agreement procedure: –ANonce is transferred to AP in advance: the 1 st message could be removed; –Only 2 messages are used to verify keys; –Group key handshake could be carried out in key agreement procedure concurrently: the 4 th message could be avoided. 4-way/Group Key handshake messages reduction Nov 2011 ZTE CorporationSlide 10

doc.: IEEE /1426r02 Submission Proposed Fast Security Setup Procedure Nov 2011 ZTE CorporationSlide 11

doc.: IEEE /1426r02 Submission State transition diagram Jan 2012 ZTE CorporationSlide 12 State 3 is skipped!. When STA receives Authentication message, STA can enter State 2 (Authenticated and unassociated).

doc.: IEEE /1426r02 Submission Conclusions EAP-based authentication is unchanged and the specific EAP method is out of scope as has defined. DHCP procedure is independent of EAP authentication. –After successful EAP authentication, STA can change to FULL EAP session state. No need to wait for DHCP message. Key agreement procedure is independent of EAP authentication. –Key verification is performed after a successful EAP authentication. The 4-way handshake procedure is reduced to 1 round. Group key handshake is performed with key verification concurrently. Nov 2011 ZTE CorporationSlide 13

doc.: IEEE /1426r02 Submission Nov 2011 ZTE CorporationSlide 14 Response to Questions

doc.: IEEE /1426r02 Submission Message 1 could be Authentication message. It could be triggered by receiving Beacon or Probe Response. Question 1: How to trigger Message 1? Nov 2011 ZTE CorporationSlide 15

doc.: IEEE /1426r02 Submission In the current RSNA, ANONCE and SNONCE is sent to STA without encryption protection. There is no risk. So there is no requirement for nonce encryption. Either current RSNA or 1426, one of the two nonces has no integrity protection. If anyone of the two nonces is tampered, the keys generated by AP and STA respectively would be different, so the key verification would be failed. Even if SNONCE is sent to AP before authentication, it is used only after the successful authentication. Question 2: SNONCE is sent to AP before EAP authentication. Is there any security problem? Nov 2011 ZTE CorporationSlide 16

doc.: IEEE /1426r02 Submission Question 3: Key verification is reduced from 2 rounds to 1 round, and is triggered by AP. Is there any security problem, e.g., MITM attack ？ Nov 2011 ZTE CorporationSlide 17 StepsCurrent MessageNew MessageProcedure upon receiving the message Step-1AP sends ANonce to STA in EAPOL-Key message STA sends SNonce to AP in the Association Request. [Current] STA calculates PTK using ANonce & SNonce [New] AP calculates PTK using ANonce & SNonce Step-2STA sends SNonce to AP in EAPOL-Key message (protected using MIC1) AP sends ANonce to STA in Auth as an IE of the 1 st key agreement message (protected using MIC1) [Current] AP calculates PTK using ANonce & SNonce [New] STA calculates PTK using ANonce & SNonce; STA installs the key Step-3AP verifies MIC1 and sends Key-Install information and MIC2 to STA in EAPOL-Key message (protected using MIC2) STA verifies MIC1 and sends Association Req as an IE of the 2 nd key agreement message (protected using MIC2), AP verifies MIC2 [Current procedure]: STA installs the key. Also, STA sends EAPOL-Key message to AP confirming temporal key is installed [New procedure] AP installs the key. Step-4STA verifies MIC2 and sends confirmation of key- install from STA to AP in EAPOL-Key (protected using MIC3) Not sent (serves no cryptographic purpose) [Current procedure] AP installs the keys

doc.: IEEE /1426r02 Submission If there is a MITM attack, the key agreement message 1 and message 2 can not be successfully verified. As the PTK includes the IEEE 802 MAC addresses of both STA and AP, MAC address tampering would result in key asynchronization between STA and AP, thus MIC verification would fail. Question 3: Key verification is reduced from 2 rounds to 1 round, and is triggered by AP. Is there any security problem, e.g., MITM attack ？ (Cont.) Nov 2011 ZTE CorporationSlide 18

doc.: IEEE /1426r02 Submission Question 4: How to allocate an IPv6 address? Nov 2011 ZTE CorporationSlide 19

doc.: IEEE /1426r02 Submission Question 4: How to allocate an IPv6 address? (Cont.) Nov 2011 ZTE CorporationSlide 20

doc.: IEEE /1426r02 Submission Thanks! Nov 2011 Slide 21ZTE Corporation