doc.: IEEE /1426r00 Submission NameAffiliationsAddressPhone ChengYan FengZTE Corporation No.800, Middle Tianfu Avenue, Hi- tech District, Chengdu, P.R.China, m.cn Dezhi ZhangZTE CorporationE3048,Bibo Rd,Pudong,shanghai,c hina cn Fast Security Setup Date: Nov 2011 ZTE CorporationSlide 1 Authors:

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

doc.: IEEE /1426r00 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 /1426r00 Submission Background Some contributions (e.g. 11/1047r3 and 11/1160r2) have proposed to use current 11ai messages carrying upper layer messages: –Carry out EAP, IP assignment, 4-way handshake concurrently –Pre-assigned IP address and network configuration information are sent to STA before AS authenticates STA –4-Way handshake is concurrently carried out with EAP procedure in Authentication frames Nov 2011 ZTE CorporationSlide 4

doc.: IEEE /1426r00 Submission Problems may be introduced Security level may be lowered because of no independent 4-way handshake, as –EAP Authentication is used to authenticate each other –4-way handshake is used to verify the keys individually generated by AP and STA It’s not easy to standardize the procedure for concurrent 4-way handshake with EAP authentication, as –Authentication procedure is dependent on specific EAP method, which is out of scope of work. It’s not secure that available IP address and network configuration information are sent to an un-authenticated STA. Nov 2011 ZTE CorporationSlide 5

doc.: IEEE /1426r00 Submission DHCP Security Considerations RFC 2131 ： DHCP is built directly on UDP and IP which are as yet inherently insecure. Unauthorized DHCP servers may be easily set up. Such servers can then send false and potentially disruptive information to clients such as incorrect or duplicate IP addresses, incorrect routing information (including spoof routers, etc.), incorrect domain nameserver addresses (such as spoof nameservers), and so on. Clearly, once this seed information is in place, an attacker can further compromise affected systems. Malicious DHCP clients could masquerade as legitimate clients and retrieve information intended for those legitimate clients. Where dynamic allocation of resources is used, a malicious client could claim all resources for itself, thereby denying resources to legitimate clients. Nov 2011 ZTE CorporationSlide 6

doc.: IEEE /1426r00 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. A part of IP address assignment procedure and EAP procedure are carried out concurrently –The offered IP address and network configuration parameters are sent to STA ciphered after STA has been authenticated by AS Nov 2011 ZTE CorporationSlide 7

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

doc.: IEEE /1426r00 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: STA verifies MIC2 and send MIC3 to AP in order to trigger group key handshake; 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 9

doc.: IEEE /1426r00 Submission Solution Overview Nov 2011 ZTE CorporationSlide 10

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

doc.: IEEE /1426r00 Submission Conclusions EAP-based authentication is unchanged and the specific EAP method is out of scope as has defined. DHCP procedure(or other IP address allocation mechanism) is performed with EAP and key agreement procedure. –The offered IP address and network configuration parameters are sent to STA ciphered after STA has been authenticated by AS. 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 12

doc.: IEEE /1426r00 Submission Thanks! Nov 2011 Slide 13ZTE Corporation