1 / 17

Establishing PTK liveness during re-association

Establishing PTK liveness during re-association. Nancy Cam-Winget, Cisco Systems Inc Emily H. Qi and Jesse Walker, Intel Corporation. Where we are so far…. Existing Standard & Proposals: Pre-authentication + 4-Way Handshake at Reassociation (802.11i) Pre-keying (04/476)

chester-fulton
Download Presentation

Establishing PTK liveness during re-association

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Establishing PTK liveness during re-association Nancy Cam-Winget, Cisco Systems Inc Emily H. Qi and Jesse Walker, Intel Corporation N. Cam-Winget, et al

  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 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 N. Cam-Winget, et al

  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 N. Cam-Winget, et al

  4. 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 N. Cam-Winget, et al

  5. AP Authenticator Optimized Re-Association with 4-way Client Supplicant Client determines new AP for roam, increments ANONCE Generates new PTKi, Generate 802.1X Optimized 4-way Message #2 Reassociate Request( 802.1X 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 Reassociate Response( 802.1X 4-way Message #3) Client validates Message #3 (process flows same as TGi) 802.1X 4-way Message #4 Client and AP can now protect 802.1X and 802.11 packets N. Cam-Winget, et al

  6. 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 N. Cam-Winget, et al

  7. Two new KDE’s • ANonce in Message 2 is conveyed as KDE • AP-Challenge to ensure STA liveness proof to AP N. Cam-Winget, et al

  8. 4-way Handshake Optimized Message 2 N. Cam-Winget, et al

  9. 4-way Handshake Optimized Message 3 N. Cam-Winget, et al

  10. 4-way Handshake Optimized Message 4 N. Cam-Winget, et al

  11. 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 N. Cam-Winget, et al

  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 N. Cam-Winget, et al

  13. Questions? N. Cam-Winget, et al

  14. Backup slides N. Cam-Winget, et al

  15. 802.11i 4-way Handshake Message values N. Cam-Winget, et al

  16. Optimized 802.11i 4-way Handshake Message values N. Cam-Winget, et al

  17. EAPOL Key Frame Format N. Cam-Winget, et al

More Related