doc.: IEEE /0707r0 Submission July 2003 N. Cam-Winget, et alSlide 1 Establishing PTK liveness during re-association Nancy Cam-Winget, Cisco Systems Inc Emily H. Qi and Jesse Walker, Intel Corporation

doc.: IEEE /0707r0 Submission July 2003 N. Cam-Winget, et alSlide 2 Where we are so far… Existing Standard & Proposals: –Pre-authentication + 4-Way Handshake at Reassociation (802.11i) –Pre-keying (04/476) –Tentative association (04/606) Existing Proposal Problems –Pre-authentication + 4-Way Handshake at Reassociation is not fast Otherwise r would not exist –Pre-keying and Tentative association incomplete i replay protection tied to key freshness and peer liveness So far, both have failed to explain how they will obtain these Reservation introduces a novel DoS attack against network resources Proposals must explain how to protect against these novel DoS attacks, because PAR says r can’t make security worse

doc.: IEEE /0707r0 Submission July 2003 N. Cam-Winget, et alSlide 3 4-Way Handshake Observations 4-Way Handshake overloads ANonce, SNonce to perform two functions: –They must be different on each 4-Way Handshake to provide key separation (“fresh” keys) –They must be unpredictable to prove liveness, so are specified as random Making nonces serve both functions serializes PTK derivation with 4-Way Handshake execution –Infeasible for STA to pre-compute PTK, because ANonce must be unpredictable

doc.: IEEE /0707r0 Submission July 2003 N. Cam-Winget, et alSlide 4 Proposal Pre-compute PTK on the STA prior to Re-Association Establish security associations liveness and GTK at reassociation time –Not after, as i does today –Not before, as pre-keying and tentative association propose Apply updates to the i 4-Way Handshake to allow it to meet requirements: –Eliminate 4-Way Handshake Msg 1 by making ANonce predictable for AP-to-AP transition –Embed 4-Way Handshake Msg 2 in Reassociation Request –Embed 4-Way Handshake Msg 3 in Reassociation Response –Add AP-Challenge to 4-Way Handshake Msgs 3 and 4, to prove STA liveness to AP –Don’t change the i key hierarchy

doc.: IEEE /0707r0 Submission July 2003 N. Cam-Winget, et alSlide 5 Optimized Re-Association with 4-way Supplicant Client Authenticator AP Reassociate Request( 802.1X 4-way Message #2) Reassociate Response( 802.1X 4-way Message #3) Client determines new AP for roam, increments ANONCE Generates new PTK i, Generate 802.1X Optimized 4-way Message #2 AP validates ANONCE Generates new PTK validate 802.1X 4-way Message #2 Generate 802.1X Optimized 4-way Message #3 Client and AP can now protect 802.1X and packets 802.1X 4-way Message #4 Client validates Message #3 (process flows same as TGi)

doc.: IEEE /0707r0 Submission July 2003 N. Cam-Winget, et alSlide 6 Optimized 4-way Handshake Use of 4-way Handshake as on associations defined in i: –SNonce and ANonce remain unpredictable and random On Roam use Optimized 4-way Handshake: –ANonce becomes an incrementing counter in reassociations, used as replay protector against rekeys triggered either by IV exhaustion or roams –4-way Message #1 is not used in the optimized 4-way handshake –Reassociation Request includes optimized Message # 2 –Message #2 conveys ANonce and PMKID STA used to generate the PTK –AP validates ANonce from STA to ensure it is not a replay –Reassociation Response includes optimized Message # 3 –Optimized Message #4 flows as defined in i –Uses PMK cacheing and established PMKID to kickstart optimized 4-way handshake ANonce is bound to STA, BSSID and PMKID Proposal enables i 4-way and Optimized 4-way handshakes to co-exist

doc.: IEEE /0707r0 Submission July 2003 N. Cam-Winget, et alSlide 7 Two new KDE’s ANonce in Message 2 is conveyed as KDE AP-Challenge to ensure STA liveness proof to AP

doc.: IEEE /0707r0 Submission July 2003 N. Cam-Winget, et alSlide 8 4-way Handshake Optimized Message 2 Key Descriptor Type (1 octet) Key Information (2 octets)Key Length (2 octets) Key Replay Counter (8 octets) SNonce (32 octets) Key MIC (16 octets) Key Data Length (2 octets)RSN IE, PMKID, ANonce

doc.: IEEE /0707r0 Submission July 2003 N. Cam-Winget, et alSlide 9 4-way Handshake Optimized Message 3 Key Descriptor Type (1 octet) Key Information (2 octets)Key Length (2 octets) Key Replay Counter (8 octets) ANonce (32 octets) Key MIC (16 octets) Key Data Length (2 octets)RSN IE, GTK, AP-Challenge

doc.: IEEE /0707r0 Submission July 2003 N. Cam-Winget, et alSlide 10 4-way Handshake Optimized Message 4 Key Descriptor Type (1 octet) Key Information (2 octets)Key Length (2 octets) Key Replay Counter (8 octets) Key MIC (16 octets) Key Data Length (2 octets)AP-Challenge

doc.: IEEE /0707r0 Submission July 2003 N. Cam-Winget, et alSlide 11 Inserting 802.1X in X EAPOL Key Frame (Message 2 and 3) are embedded into Reassociation Request and Response in new IE Element IDLengthData TBD802.1X packet length 802.1X EAPOL Key frame

doc.: IEEE /0707r0 Submission July 2003 N. Cam-Winget, et alSlide 12 Optimizations enable Reuse of TGi Compression of exchanges reduce latencies Enables the STA to precompute PTK prior to association (to minimize time spent during association) Enables the STA to plumb PTK prior to reassociation….fixes race conditions in 4-way handshake

doc.: IEEE /0707r0 Submission July 2003 N. Cam-Winget, et alSlide 13 Questions?

doc.: IEEE /0707r0 Submission July 2003 N. Cam-Winget, et alSlide 14 Backup slides

doc.: IEEE /0707r0 Submission July 2003 N. Cam-Winget, et alSlide 15 EAPOL Message FieldMessage 1Message 2Message 3Message 4 Key InformationVersionV1 or v2 Key Type1111 Install0010 Key ACK1010 Key MIC0111 Secure0011 Error0000 Request0000 ENC Key Data 0010 Key LengthCipher spec0 0 Key Replay Counternnn+1 Key NonceANonceSNonceANonce0 Key IV000 if v2 Random v1 0 Key RSC00GTK’s PN0 Key MIC0MIC 0 Key Data Length22Len-2Len-30 Key DataPMKIDRSNIE STA RSNIE AP, GTK i 4-way Handshake Message values

doc.: IEEE /0707r0 Submission July 2003 N. Cam-Winget, et alSlide 16 EAPOL Message FieldMessage 1Message 2Message 3Message 4 Key Information VersionNot Used on Reassociation V1 or v2 Key Type111 Install110 Key ACK010 Key MIC111 Secure011 Error000 Request000 ENC Key Data010 Key Length0Cipher spec0 Key Replay Counternn+1 Key NonceSNonceANonce0 Key IV00 if v2 Random v1 0 Key RSC0GTK’s PN0 Key MICMIC 0 Key Data Length62RSNIE AP + GTK len0 Key DataRSNIE STA, PMKID, ANonce RSNIE AP, GTK, AP-Challenge Optimized i 4-way Handshake Message values

doc.: IEEE /0707r0 Submission July 2003 N. Cam-Winget, et alSlide 17 EAPOL Key Frame Format Key Descriptor Type (1 octet) Key Information (2 octets)Key Length (2 octets) Key Replay Counter (8 octets) Key Nonce (32 octets) Key IV (16 octets) Key RSC (8 octets) Reserved (8 octets) Key MIC (16 octets) Key Data Length (2 octets)Key Data (n octets)