doc.: IEEE /008r0 Submission January 2003 N. Cam-Winget, D. Smith, K. AmannSlide 1 Proposed new AKM for Fast Roaming Nancy Cam-Winget, Cisco Systems Inc Doug Smith, Cisco Systems Inc Keith Amann, Spectralink

doc.: IEEE /008r0 Submission January 2003 N. Cam-Winget, D. Smith, K. AmannSlide 2 Fast Roam Goals TGi has provided sound framework and protocols to secure 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

doc.: IEEE /008r0 Submission January 2003 N. Cam-Winget, D. Smith, K. AmannSlide 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.

doc.: IEEE /008r0 Submission January 2003 N. Cam-Winget, D. Smith, K. AmannSlide 4 Handoff Process Delays STA APs … Probe Requests Probe Response Pre-authentication Exchange Re-association Exchange4-way & 2-way handshakes Other APs IAPP Discovery Reauthentication New AP

doc.: IEEE /008r0 Submission January 2003 N. Cam-Winget, D. Smith, K. AmannSlide 5 The Handoff Procedure : two phases 1.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 2.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

doc.: IEEE /008r0 Submission January 2003 N. Cam-Winget, D. Smith, K. AmannSlide 6 Average Roam latencies in current systems PhaseAverage measured latencies Discovery66ms – 440ms Reauthentication (Open Auth, no WEP) 12ms – 40ms

doc.: IEEE /008r0 Submission January 2003 N. Cam-Winget, D. Smith, K. AmannSlide 7 Cryptographic computations for RSN 4-way and 2-way exchanges NodeMessageNonce GenHmac-SHA1 1 ops Hmac-md5 2 ops STA ← AP4-way: 1 st msg1-- STA → AP4-way: 2 nd msg132 STA ← AP4-way: 3 rd msg-32 STA → AP4-way: 4 th msg--(2 4 ) STA ← AP2-way: 1 st msg(1 3 )(3 3 )2 STA → AP2-way: 2 nd msg--2 Total6 msgs268 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

doc.: IEEE /008r0 Submission January 2003 N. Cam-Winget, D. Smith, K. AmannSlide 8 RSN Relative Costs Initial AssocReassociation Crypto operations 2 Nonce Gen + 6 HMAC-SHA1 + 8 HMAC-MD5 2 Nonce Gen + 6 HMAC-SHA1 + 8 HMAC-MD5 Packet count(4+ EAP + 6) ** packets(4 + 6) ** packets ** Open Auth + (Re)Assoc = 4 pkts

doc.: IEEE /008r0 Submission January 2003 N. Cam-Winget, D. Smith, K. AmannSlide 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….

doc.: IEEE /008r0 Submission January 2003 N. Cam-Winget, D. Smith, K. AmannSlide 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

doc.: IEEE /008r0 Submission January 2003 N. Cam-Winget, D. Smith, K. AmannSlide 11 Ideally, compress roaming to: Supplicant Client Authenticator AP Reassociate Request: negotiate CKM, authenticate rekey Reassociate Response: validate rekey, random challenge, deliver group key Client and AP can now protect 802.1X and packets Reassociate Confirm: random challenge response, MIC

doc.: IEEE /008r0 Submission January 2003 N. Cam-Winget, D. Smith, K. AmannSlide 12 Handoff Procedure using a Roam Server Roam Server 1st APNew AP Establish Security Block Send Security Block 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

doc.: IEEE /008r0 Submission January 2003 N. Cam-Winget, D. Smith, K. AmannSlide 13 Roam Server is Central Key Manager (CKM) Central Key Management (CKM) Protocol: Uses PMK from successful EAP Authentication to derive 1.rekey request key (RRK) – used to authenticate rekey element in reassociation request 2.Rekey base key (RBK) – used to mutually derive pairwise transient keys (PTK) to protect 802.1X and 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 to APs

doc.: IEEE /008r0 Submission January 2003 N. Cam-Winget, D. Smith, K. AmannSlide 14 New Key Hierarchy PMK implicitly derived as a result of a successful EAP authentication RRK 128 bits RBK 256 bits Generate RRK and BRK: PRF-384(PMK, “Fast-Roam Generate Base Key”, MAC APi | MAC STA | Nonce STA | Nonce RS ) 802.1X Encrypt Key (16bytes) 802.1X MIC Key (16 bytes) Encrypt Key (16 bytes) MIC Keys (TKIP only) Tx Key Rx Key 8 bytes 8 bytes PTK RSC = PRF-XXX(RBK, RSC|BSSID)

doc.: IEEE /008r0 Submission January 2003 N. Cam-Winget, D. Smith, K. AmannSlide 15 New Key Hierarchy facilitates reassoc RRK used to authenticate new Reassociation Request element Element ID LengthRekey Sequence Counter MIC 1octet 4octets8octets MIC = HMAC-MD5(RRK, MAC STA | BSSID | RSNE STA | RSC )

doc.: IEEE /008r0 Submission January 2003 N. Cam-Winget, D. Smith, K. AmannSlide 16 Reassociation Response includes GTK MIC RRK = HMAC-MD5(RRK, RSC | MAC STA ) PTK RSC = = PRF-XXX(RBK BSSID, RSC | BSSID ) MIC PTK = HMAC-MD5(TK RSC, RSNE AP | RSC | KeyID unicast | KeyID multicast | Multicast Key length | E(PTK RSC, GTK) ) Elem IDLenRSCRandom Challenge KeyID unicast KeyID multi- cast Multi- cast key length MIC RRK MIC PTK E(GTK) 1octet 4octets16 octects1octet 2octets8 octets N octets

doc.: IEEE /008r0 Submission January 2003 N. Cam-Winget, D. Smith, K. AmannSlide 17 Re-association Confirm New 3 rd message should be management : –3 rd message includes random challenge response –3 rd message confirms liveness of PTK –3 rd message defeats MIM attack

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

doc.: IEEE /008r0 Submission January 2003 N. Cam-Winget, D. Smith, K. AmannSlide 19 Initial 4-way handshake with Roam Server EAPoL-Key(Unicast, ANonce) PMK Derive ANonce Derive SNonce EAPoL-Key(Unicast, SNonce, MIC, RSNE STA ) EAPoL-Key(Install PTK 1, Unicast, MIC, RSNE AP ) Derive RRK, RBK, PTK 1 EAPoL-Key(Unicast, MIC) Install Keys Deliver PTK 1 RS AP STA Group key handshake used for PTK liveness confirm

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

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

doc.: IEEE /008r0 Submission January 2003 N. Cam-Winget, D. Smith, K. AmannSlide 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

doc.: IEEE /008r0 Submission January 2003 N. Cam-Winget, D. Smith, K. AmannSlide 23 Cryptographic computations for CKM Reassociation NodeMessageNonce GenHmac-Sha1 1 ops Hmac-md5 2 ops STA → APReassoc Request-(3 4 )1 AP → RSPTK request--3 RS → APPTK response-(3 4 )3 STA ← APReassoc Response(1) STA → APReassoc Confirm--2 Total3 air pkts + 2 DS pkts 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

doc.: IEEE /008r0 Submission January 2003 N. Cam-Winget, D. Smith, K. AmannSlide 24 Relative Costs RSNCKM Crypto Ops for Assoc 2 Nonce Gen + 6 HMAC-SHA1 + 8 HMAC-MD5 2 Nonce Gen + 12 HMAC-SHA1 + 8 HMAC-MD5 Crypto Ops for Reassociation 2 Nonce Gen + 6 HMAC-SHA1 + 8 HMAC-MD5 1 Nonce Gen + 0 HMAC-SHA HMAC-MD5 Assoc pkts(4 + EAP + 6) pkts Reassoc pkts(4 + 6) ** pkts3 pkts over air + 2pkts on DS ** Presumes Pre-authentication

doc.: IEEE /008r0 Submission January 2003 N. Cam-Winget, D. Smith, K. AmannSlide 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 in context

doc.: IEEE /008r0 Submission January 2003 N. Cam-Winget, D. Smith, K. AmannSlide 26 TGi must address Fast Roaming Roaming must be seamless for all clients Must account for small clients (e.g. wireless phones)

doc.: IEEE /008r0 Submission January 2003 N. Cam-Winget, D. Smith, K. AmannSlide 27 Feedback?

doc.: IEEE /008r0 Submission January 2003 N. Cam-Winget, D. Smith, K. AmannSlide 28 Roam Server generates AP specific Roam Server 1st APNew AP Re-association = PRF-384(PMK, “Fast-Roam Generate Base Key”, MAC AP1 | MAC STA | Nonce STA | Nonce RS )

doc.: IEEE /008r0 Submission January 2003 N. Cam-Winget, D. Smith, K. AmannSlide 29 Initial 4-way handshake in distributed model…. EAPoL-Key( Unicast, ANonce) PMK Derive ANonceDerive SNonce EAPoL-Key(Unicast, SNonce, MIC, RSNE STA ) EAPoL-Key( Install PTK 1, Unicast, MIC, RSNE AP ) Derive RRK, RBK, PTK 1 EAPoL-Key(Unicast, MIC) Install Keys