Post on 14-Dec-2015
July 2003
N. Cam-Winget, et alSlide 1
doc.: IEEE 802.11-04/0707r0
Submission
Establishing PTK liveness during re-association
Nancy Cam-Winget, Cisco Systems Inc
Emily H. Qi and Jesse Walker, Intel Corporation
July 2003
N. Cam-Winget, et alSlide 2
doc.: IEEE 802.11-04/0707r0
Submission
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 802.11r would not exist– Pre-keying and Tentative association incomplete
• 802.11i 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 802.11r can’t make security worse
July 2003
N. Cam-Winget, et alSlide 3
doc.: IEEE 802.11-04/0707r0
Submission
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
July 2003
N. Cam-Winget, et alSlide 4
doc.: IEEE 802.11-04/0707r0
Submission
Proposal
• Pre-compute PTK on the STA prior to Re-Association• Establish security associations liveness and GTK at reassociation time
– Not after, as 802.11i does today– Not before, as pre-keying and tentative association propose
• Apply updates to the 802.11i 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 802.11i key hierarchy
July 2003
N. Cam-Winget, et alSlide 5
doc.: IEEE 802.11-04/0707r0
Submission
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 ANONCEGenerates new PTKi, Generate 802.1X Optimized 4-way Message #2
AP validates ANONCEGenerates new PTK validate 802.1X 4-way Message #2Generate 802.1X Optimized 4-way Message #3
Client and AP can now protect 802.1X and 802.11 packets
802.1X 4-way Message #4
Client validates Message #3 (process flows same as TGi)
July 2003
N. Cam-Winget, et alSlide 6
doc.: IEEE 802.11-04/0707r0
Submission
Optimized 4-way Handshake
• Use of 4-way Handshake as on associations defined in 802.11i:– 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 802.11i– Uses PMK cacheing and established PMKID to kickstart optimized 4-way
handshake
• ANonce is bound to STA, BSSID and PMKID• Proposal enables 802.11i 4-way and Optimized 4-way handshakes to co-exist
July 2003
N. Cam-Winget, et alSlide 7
doc.: IEEE 802.11-04/0707r0
Submission
Two new KDE’s
• ANonce in Message 2 is conveyed as KDE• AP-Challenge to ensure STA liveness proof to AP
July 2003
N. Cam-Winget, et alSlide 8
doc.: IEEE 802.11-04/0707r0
Submission
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
July 2003
N. Cam-Winget, et alSlide 9
doc.: IEEE 802.11-04/0707r0
Submission
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
July 2003
N. Cam-Winget, et alSlide 10
doc.: IEEE 802.11-04/0707r0
Submission
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
July 2003
N. Cam-Winget, et alSlide 11
doc.: IEEE 802.11-04/0707r0
Submission
Inserting 802.1X in 802.11
• 802.1X EAPOL Key Frame (Message 2 and 3) are embedded into Reassociation Request and Response in new IE
Element ID Length Data
TBD 802.1X packet length
802.1X EAPOL Key frame
July 2003
N. Cam-Winget, et alSlide 12
doc.: IEEE 802.11-04/0707r0
Submission
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
July 2003
N. Cam-Winget, et alSlide 13
doc.: IEEE 802.11-04/0707r0
Submission
Questions?
July 2003
N. Cam-Winget, et alSlide 14
doc.: IEEE 802.11-04/0707r0
Submission
Backup slides
July 2003
N. Cam-Winget, et alSlide 15
doc.: IEEE 802.11-04/0707r0
Submission
EAPOL Message Field Message 1 Message 2 Message 3 Message 4
Key Information Version V1 or v2 V1 or v2 V1 or v2 V1 or v2
Key Type 1 1 1 1
Install 0 0 1 0
Key ACK 1 0 1 0
Key MIC 0 1 1 1
Secure 0 0 1 1
Error 0 0 0 0
Request 0 0 0 0
ENC Key Data
0 0 1 0
Key Length Cipher spec 0 Cipher spec 0
Key Replay Counter n n n+1 n+1
Key Nonce ANonce SNonce ANonce 0
Key IV 0 0 0 if v2
Random v1
0
Key RSC 0 0 GTK’s PN 0
Key MIC 0 MIC MIC 0
Key Data Length 22 Len-2 Len-3 0
Key Data PMKID RSNIESTA RSNIEAP, GTK 0
802.11i 4-way Handshake Message values
July 2003
N. Cam-Winget, et alSlide 16
doc.: IEEE 802.11-04/0707r0
Submission
EAPOL Message Field Message 1 Message 2 Message 3 Message 4
Key Information
Version Not Used on Reassociation
V1 or v2 V1 or v2 V1 or v2
Key Type 1 1 1
Install 1 1 0
Key ACK 0 1 0
Key MIC 1 1 1
Secure 0 1 1
Error 0 0 0
Request 0 0 0
ENC Key Data 0 1 0
Key Length 0 Cipher spec 0
Key Replay Counter n n+1 n+1
Key Nonce SNonce ANonce 0
Key IV 0 0 if v2
Random v1
0
Key RSC 0 GTK’s PN 0
Key MIC MIC MIC 0
Key Data Length 62 RSNIEAP+ GTK len 0
Key Data RSNIESTA, PMKID, ANonce
RSNIEAP, GTK,
AP-Challenge
AP-Challenge
Optimized 802.11i 4-way Handshake Message values
July 2003
N. Cam-Winget, et alSlide 17
doc.: IEEE 802.11-04/0707r0
Submission
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)