SlideServe
Télécharger Obtenir Pro
Menu
Accueil Pro
Préférences
ApparenceLight Aide et commentaires
© SlideServe · v2026

Establishing PTK liveness during re-association

chester-fulton avatar
chester-fulton
17 diapositives · 267 Views · Nov 20, 2014

This article reviews existing protocols and proposes improvements to enhance liveness verification in PTK during re-association in wireless networks, addressing security vulnerabilities and proposing optimized 4-way handshake processes.

#establishing ptk liveness during re-association #establishing ptk liveness during re-association ppt #powerpoint #presentation
Establishing PTK liveness during re-association - slide 1
01 / 17Establishing PTK liveness during re-association
1 / 17

Télécharger la présentation

Establishing PTK liveness during re-association
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation

  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