Nov 2011 doc IEEE 802 11 111426 r

Nov 2011 doc. : IEEE 802. 11 -11/1426 r 02 Fast Security Setup Authors: Name Cheng. Yan Feng Affiliations ZTE Corporation Dezhi Zhang ZTE Corporation Li Zhu ZTE Corporation Lin Wang ZTE Corporation Submission Address No. 800, Middle Tianfu Avenue, Hi-tech District, Chengdu, China E 3048, Bibo Rd, Pudong, shanghai, China East Hua. Yuan Road, Haidian District, Beijing, China Slide 1 Phone email +86 -28 85342869 feng. chengyan@zte. com. cn +8613816335629 zhang. dezhi 2@zte. com. cn +86 -2168896274 zhu. li 8@zte. com. cn +86 -1082963667 wang. lin 45@zte. com. cn ZTE Corporation

Nov 2011 doc. : IEEE 802. 11 -11/1426 r 02 Abstract This document proposes an approach for accelerating the security setup for FILS. Submission Slide 2 ZTE Corporation

Nov 2011 doc. : IEEE 802. 11 -11/1426 r 02 Conformance w/ Tgai PAR & 5 C Conformance Question Response Does the proposal degrade the security offered by Robust Security Network Association (RSNA) already defined in 802. 11? No Does the proposal change the MAC SAP interface? No Does the proposal require or introduce a change to the 802. 1 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 Submission Slide 3 ZTE Corporation

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

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

Nov 2011 doc. : IEEE 802. 11 -11/1426 r 02 Our Concern: 2 • If DHCP lasts a long time, STA doesn’t receive the Association Response message in a pre-defined time, how does STA do？ DHCP procedure lasts too long! Submission Slide 6 – 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. ZTE Corporation

Nov 2011 doc. : IEEE 802. 11 -11/1426 r 02 Our Concern: 2 (Cont. ) • 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. State Machine in 11/1160 r 4 Submission Slide 7 EAP authentication shall not be performed with DHCP procedure concurrently! ZTE Corporation

Nov 2011 doc. : IEEE 802. 11 -11/1426 r 02 Proposal Introduction • EAP-based authentication is used. The specific method should be an implementation issue and is out of 802. 11 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. Submission Slide 8 ZTE Corporation

Nov 2011 doc. : IEEE 802. 11 -11/1426 r 02 4 -way/Group Key handshake messages reduction AP STA Generate ANonce AP EAPOL-KEY(ANonce) Generate SNonce, derive PTK, Auth(SNonce) …. EAPOL-KEY(SNonce, MIC 1) derive PTK, verify MIC 1 EAPOL-KEY(ANonce, MIC 2) Generate ANonce and GTK, Derive PTK Auth(ANonce, GTK[KEK], MIC 1) verify MIC 2 derive PTK, verify MIC 1 EAPOL-KEY(MIC 3) Generate GTK and GNonce Association Req (SNonce, MIC 2) EAPOL-KEY(GNonce, GTK[KEK], MIC 4) verify MIC 2 Decrypt GTK EAPOL-KEY(MIC 5) Submission Slide 9 ZTE Corporation

Nov 2011 doc. : IEEE 802. 11 -11/1426 r 02 4 -way/Group Key handshake messages reduction • Original 4 -way handshake: – 1 st message: AP sends ANonce to STA; – 2 nd message: STA generates SNonce, derives PTK, and sends SNonce and MIC 1 to AP; – 3 rd message: AP derives PTK, verifies MIC 1 and sends MIC 2 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. Submission Slide 10 ZTE Corporation

Nov 2011 doc. : IEEE 802. 11 -11/1426 r 02 Proposed Fast Security Setup Procedure Submission Slide 11 ZTE Corporation

Jan 2012 doc. : IEEE 802. 11 -11/1426 r 02 State transition diagram When STA receives Authentication message, STA can enter State 2 (Authenticated and unassociated). State 3 is skipped!. Submission Slide 12 ZTE Corporation

Nov 2011 doc. : IEEE 802. 11 -11/1426 r 02 Conclusions • EAP-based authentication is unchanged and the specific EAP method is out of scope as 802. 11 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. Submission Slide 13 ZTE Corporation

Nov 2011 doc. : IEEE 802. 11 -11/1426 r 02 Response to Questions Submission Slide 14 ZTE Corporation

Nov 2011 doc. : IEEE 802. 11 -11/1426 r 02 Question 1: How to trigger Message 1? • Message 1 could be Authentication message. • It could be triggered by receiving Beacon or Probe Response. Submission Slide 15 ZTE Corporation

Nov 2011 doc. : IEEE 802. 11 -11/1426 r 02 Question 2: SNONCE is sent to AP before EAP authentication. Is there any security problem? • • • In the current 802. 11 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. Submission Slide 16 ZTE Corporation

Nov 2011 doc. : IEEE 802. 11 -11/1426 r 02 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？ Steps Current Message New Message Procedure upon receiving the message Step-1 AP 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-2 STA sends SNonce to AP in EAPOL-Key message (protected using MIC 1) AP sends ANonce to STA in Auth as an IE of the 1 st key agreement message (protected using MIC 1) [Current] AP calculates PTK using ANonce & SNonce [New] STA calculates PTK using ANonce & SNonce; STA installs the key Step-3 AP verifies MIC 1 and sends Key-Install information and MIC 2 to STA in EAPOL-Key message (protected using MIC 2) STA verifies MIC 1 and sends Association Req as an IE of the 2 nd key agreement message (protected using MIC 2), AP verifies MIC 2 [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-4 STA verifies MIC 2 and sends confirmation of keyinstall from STA to AP in EAPOL-Key (protected using MIC 3) Not sent (serves no cryptographic purpose) [Current procedure] AP installs the keys Submission Slide 17 ZTE Corporation

Nov 2011 doc. : IEEE 802. 11 -11/1426 r 02 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. ) • • 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. Submission Slide 18 ZTE Corporation

Nov 2011 doc. : IEEE 802. 11 -11/1426 r 02 Question 4: How to allocate an IPv 6 address? Submission Slide 19 ZTE Corporation

Nov 2011 doc. : IEEE 802. 11 -11/1426 r 02 Question 4: How to allocate an IPv 6 address? (Cont. ) Submission Slide 20 ZTE Corporation

Nov 2011 doc. : IEEE 802. 11 -11/1426 r 02 Thanks! Submission Slide 21 ZTE Corporation