1 / 29

Proposed new AKM for Fast Roaming

Proposed new AKM for Fast Roaming. Nancy Cam-Winget, Cisco Systems Inc Doug Smith, Cisco Systems Inc Keith Amann, Spectralink. Fast Roam Goals. TGi has provided sound framework and protocols to secure 802.11 link communications Next step is to evaluate Fast Roaming

brian-brennan
Download Presentation

Proposed new AKM for Fast Roaming

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. Proposed new AKM for Fast Roaming Nancy Cam-Winget, Cisco Systems Inc Doug Smith, Cisco Systems Inc Keith Amann, Spectralink N. Cam-Winget, D. Smith, K. Amann

  2. Fast Roam Goals • TGi has provided sound framework and protocols to secure 802.11 link communications • Next step is to evaluate Fast Roaming • Voice advocates no more than 50ms handoff latency • Are security considerations for voice the same as data? • Submission focuses on fast roaming for voice • Only reassociation exchange is applied N. Cam-Winget, D. Smith, K. Amann

  3. Handoff Times for Voice • Doc 02/758 states: • ITU guidance on TOTAL hand-off latency is that it should be less than 50 ms. Cellular networks try to keep it less than 35 ms. N. Cam-Winget, D. Smith, K. Amann

  4. Probe Requests … Probe Response Pre-authentication Exchange Re-association Exchange 4-way & 2-way handshakes Handoff Process Delays STA APs Discovery Other APs New AP IAPP Reauthentication N. Cam-Winget, D. Smith, K. Amann

  5. The Handoff Procedure : two phases • Discovery (active or passive scanning) • Determination to find new AP due to signal strength loss (or inability to communicate) with current AP • Probe delays incurred when client searches for new AP • Reauthentication • Station reauthenticates and reassociates to new AP • Reauthentication and reassociation delays • Implications: • Discovery phase – out of TGi’s scope • Reauthentication phase must be efficient to support wireless voice N. Cam-Winget, D. Smith, K. Amann

  6. Average Roam latencies in current 802.11 systems N. Cam-Winget, D. Smith, K. Amann

  7. Cryptographic computations for RSN 4-way and 2-way exchanges 1 Hmac-SHA1 used as PRF to compute WRAP or CCMP keys 2 Hmac-MD5 requires 2 MD5 operations 3 Only computed when GTK is refreshed 4 MIC check doesn’t affect data flow N. Cam-Winget, D. Smith, K. Amann

  8. RSN Relative Costs **802.11 Open Auth + (Re)Assoc = 4 pkts N. Cam-Winget, D. Smith, K. Amann

  9. Potential delays • Computational delay • Each authentication packet • Each packet requiring generation of PRF • Media access delay : due to packets sent by other NICs between the authentication packets Example: 1500 octet packet arrives while AP is processing an association response: • AP at 11Mbps ≈ 1.1ms delay between each packet • AP at 6Mbps ≈ 2ms delay between each packet • AP at 2Mbps ≈ 6ms delay between each packet For 10 message exchange, media access delay alone is 10-60ms! The heavier the traffic, the higher the delay…. N. Cam-Winget, D. Smith, K. Amann

  10. Fast Roam for voice implies: • Pre-authentication is required • Re-association 4-way handshake is too expensive • Additional 2-way handshake for GTK delivery does not help. GOAL: • Hand-off times MUST be efficient to support synchronous connections, e.g. VoIP N. Cam-Winget, D. Smith, K. Amann

  11. AP Authenticator Ideally, compress roaming to: Client Supplicant Reassociate Request: negotiate CKM, authenticate rekey Reassociate Response: validate rekey, random challenge, deliver group key Reassociate Confirm: random challenge response, MIC Client and AP can now protect 802.1X and 802.11 packets N. Cam-Winget, D. Smith, K. Amann

  12. Handoff Procedure using a Roam Server Roam Server Send Security Block Establish Security Block 1st AP New AP Re-association • Assumptions: • Roam Server can be adapted to document 02/758 • Roam Server is trusted, can be the Authentication Server • AP is trusted and has trust relationship with Roam Server N. Cam-Winget, D. Smith, K. Amann

  13. Roam Server is Central Key Manager (CKM) Central Key Management (CKM) Protocol: • Uses PMK from successful EAP Authentication to derive • rekey request key (RRK) – used to authenticate rekey element in reassociation request • Rekey base key (RBK) – used to mutually derive pairwise transient keys (PTK) to protect 802.1X and 802.11 packets. • RRK and RBK derived on association • RRK serves as authorization key • RBK serves as Base Key used to derive PTKs • Roam Server may only distribute PTKs or with proactive key distribution can forward <RRK,RBK> to APs N. Cam-Winget, D. Smith, K. Amann

  14. PMK implicitly derived as a result of a successful EAP authentication Generate RRK and BRK: PRF-384(PMK, “Fast-Roam Generate Base Key”, MACAPi | MACSTA | NonceSTA | NonceRS) RBK 256 bits RRK 128 bits PTKRSC = PRF-XXX(RBK, RSC|BSSID) 802.1X Encrypt Key (16bytes) 802.11 Encrypt Key (16 bytes) MIC Keys (TKIP only) Tx Key Rx Key 8 bytes 8 bytes 802.1X MIC Key (16 bytes) New Key Hierarchy N. Cam-Winget, D. Smith, K. Amann

  15. New Key Hierarchy facilitates reassoc • RRK used to authenticate new Reassociation Request element MIC = HMAC-MD5(RRK, MACSTA | BSSID | RSNESTA | RSC ) N. Cam-Winget, D. Smith, K. Amann

  16. Reassociation Response includes GTK MICRRK = HMAC-MD5(RRK, RSC | MACSTA) PTKRSC = <KCK, KEK, TK> = PRF-XXX(RBKBSSID, RSC | BSSID ) MICPTK = HMAC-MD5(TKRSC, RSNEAP | RSC | KeyIDunicast | KeyIDmulticast | Multicast Key length | E(PTKRSC, GTK) ) N. Cam-Winget, D. Smith, K. Amann

  17. Re-association Confirm • New 3rd message should be management : • 3rd message includes random challenge response • 3rd message confirms liveness of PTK • 3rd message defeats MIM attack N. Cam-Winget, D. Smith, K. Amann

  18. Same Assoc and 802.1X Auth as default RSN Open Authentication Request Open Authentication Response Association Req + RSN IE (802.1X, CKM)** Association Response (success) EAP type specific mutual authentication Derive Pairwise Master Key (PMK) Derive Pairwise Master Key (PMK) RADIUS ACCEPT (with PMK) 802.1X/EAP-SUCCESS **New AKM → Central Key Management (CKM) is negotiated N. Cam-Winget, D. Smith, K. Amann

  19. Initial 4-way handshake with Roam Server STA RS AP PMK PMK Derive SNonce Derive ANonce EAPoL-Key(Unicast, ANonce) Derive RRK, RBK, PTK1 EAPoL-Key(Unicast, SNonce, MIC, RSNESTA) Derive RRK, RBK, PTK1 EAPoL-Key(Install PTK1, Unicast, MIC, RSNEAP) EAPoL-Key(Unicast, MIC) Deliver PTK1 Install Keys Install Keys Group key handshake used for PTK liveness confirm N. Cam-Winget, D. Smith, K. Amann

  20. AP Authenticator Ideally, compress roaming to: Client Supplicant Client determines new AP for roam, increments RSC Generates new PTKi, requests CKM Generate CKM rekey authentication element Reassociate Request: negotiate CKM, authenticate rekey AP validates CKM rekey authentication element Generates new PTKi, finalizes Client switch to AP Generate CKM rekey response authentication element Deliver group keys to Client Reassociate Response: validate rekey, random challenge, deliver group key Reassociate Confirm: random challenge response, MIC Client and AP can now protect 802.1X and 802.11 packets N. Cam-Winget, D. Smith, K. Amann

  21. Using Roam Server STA RS AP Reassoc Req: negotiate CKM, authenticate rekey AP requests for STA’s RBK (For proactive key distribution, no request is needed) Deliver STA’s RBK Reassoc Resp: validate rekey, random challenge, deliver group key Reassoc Confirm: random challenge response N. Cam-Winget, D. Smith, K. Amann

  22. Reassociation triggers rekey with new AP • Rekey obviates need to reauthenticate with AS • Rekey obviates need for client to pre-authenticate • Rekey is embedded in reassociate exchange to reduce number of packet exchanges • Reassociation messages include new authenticated element to validate rekey request N. Cam-Winget, D. Smith, K. Amann

  23. Cryptographic computations for CKM Reassociation 1 Hmac-SHA1 used as PRF to compute CCMP keys 2 Hmac-MD5 requires 2 MD5 operations 3 Only computed when GTK is refreshed 4 Can be precomputed before reassociation commit N. Cam-Winget, D. Smith, K. Amann

  24. Relative Costs **Presumes Pre-authentication N. Cam-Winget, D. Smith, K. Amann

  25. Proposal optimizes Fast roaming by • Reduction in packet exchanges • Reduction in cryptographic computations • No propagation of MK or PMK is required • Roam Server can be adapted to use proactive key distribution and forward <RRK,RBK,RSC> in context N. Cam-Winget, D. Smith, K. Amann

  26. TGi must address Fast Roaming • Roaming must be seamless for all clients • Must account for small clients (e.g. wireless phones) N. Cam-Winget, D. Smith, K. Amann

  27. Feedback? N. Cam-Winget, D. Smith, K. Amann

  28. Roam Server generates AP specific <RRK, RBK> Roam Server <RRKAP1, RBKAP1> <RRKAP1, RBKAP1> 1st AP New AP Re-association <RRKAP1, RBKAP1> = PRF-384(PMK, “Fast-Roam Generate Base Key”, MACAP1 | MACSTA | NonceSTA | NonceRS) N. Cam-Winget, D. Smith, K. Amann

  29. Initial 4-way handshake in distributed model…. PMK PMK Derive SNonce Derive ANonce EAPoL-Key( Unicast, ANonce) Derive RRK, RBK, PTK1 EAPoL-Key(Unicast, SNonce, MIC, RSNESTA) Derive RRK, RBK, PTK1 EAPoL-Key( Install PTK1, Unicast, MIC, RSNEAP) EAPoL-Key(Unicast, MIC) Install Keys Install Keys N. Cam-Winget, D. Smith, K. Amann

More Related