Fast Roaming Observations January 2002 Fast Roaming Observations Jesse Walker, Intel Corporation Nancy Cam-Winget, Atheros Communications Walker/Cam-Winget; Intel/Atheros

Background TGf IAPP “Fast Hand-off” to effect fast roaming January 2002 Background TGf IAPP “Fast Hand-off” to effect fast roaming TGf intended to address several important needs: Update 802 bridges after a roam Delete obsolete state off roaming STA’s old AP Move QoS data from old AP to new AP Also being (ab?) used by TGi to pass keying material from old AP to new AP on STA roam Claims: Simpler, more secure protocols are possible TGf is being needlessly complicated by considerations relevant only to TGi If it tries, TGi can find a better fast roaming solution that does not distort TGf Even if it doesn’t try, most of the work still falls to TGi, and TGi needs to undertake this work Walker/Cam-Winget; Intel/Atheros

IAPP Fast Hand-off of TGi Keys January 2002 IAPP Fast Hand-off of TGi Keys Old AP IAPP Send SecBlock IAPP Move STA IAPP Send SecBlock Ack IAPP Move Ack AS New AP Reassociate Request Query Query Response Reassociate Response Query transaction supplies IPsec security association material  only needed once if New AP caches SAs; requires AS to maintain registry of IPsec SAs SendBlock transaction copies keying material from old AP to new AP Move transaction deletes keying material off old AP Walker/Cam-Winget; Intel/Atheros

Some Problems (1) Sharing keying material among n APs January 2002 Some Problems (1) Sharing keying material among n APs increases chance of key compromise Exposure of 1 AP compromises STA on all subsequent roams All STAs that roamed through the compromised AP have to be considered compromised How does the STA and new AP establish its fresh EAPOL Key? Keys live forever Walker/Cam-Winget; Intel/Atheros

Some Problems (2) Authentication issues January 2002 Some Problems (2) Authentication issues Does client authentication really work? Does New AP have to remember every <nonce, key> pair ever seen to guarantee liveness? The answer depends critically dependent on (a) the Security Block exchange being properly protected from replay and forgery, and (b) the old AP never being compromised Who should be authenticated to whom? For protocol to be secure, each party (Old AP, new AP, STA) must be authenticated to the other two? It looks so. Walker/Cam-Winget; Intel/Atheros

January 2002 Some Problems (3) How does protocol distinguish the reassociations types: Legacy reassociation IAPP “Fast Handoff” reassociation Reassociation to the same AP Walker/Cam-Winget; Intel/Atheros

A Different Architecture (1) January 2002 A Different Architecture (1) Assume: Each AP shares a secret KAP with the AS (Needed for 802.1X support anyway) Key Hierarchy: Master Key KSTA  secure communication between AS, STA Association Key  secure EAPOL key messages Temporal Key  derive keys to secure data between AP, STA Three processing elements: STA AP (802.1X Authenticator) 802.11 Hand-off server (802.1X Authentication server) One new protocol: Key Sharing Protocol: Protocol goal: to push a fresh key out from AS to new AP and STA Walker/Cam-Winget; Intel/Atheros

A Different Architecture (2) January 2002 A Different Architecture (2) Steps on Association: Associate Run full EAP authentication (AS  STA) Derive Master Key Run key sharing protocol (AS  AP  STA) Use Master Key to distribute Association Key to STA Use AP  AS key to deliver Association Key to AP Steps on Reassociation Run key sharing protocol (AS  AP  STA) embedded in reassociation Use Master Key to distribute new Association Key to STA Use AP  AS key to deliver new Association Key to new AP Steps on Disassociation or IAPP Delete: Must carry the new Authenticator Element Old AP securely deletes Association and Temporal Keys if Authenticator Element checks STA retains only Master Key Walker/Cam-Winget; Intel/Atheros

Key Sharing Protocol STA AS AP January 2002 Key Sharing Protocol STA AP AS AP-ID, STA-ID, NonceAP EKAP(NonceAP, AP-ID, K, EKSTA(K, STA-ID)) EKSTA(K, STA-ID) K = f(K), Association Key = g(K) EK (NonceSTA) EK (NonceSTA+1) This is just the Needham-Shroeder protocol Walker/Cam-Winget; Intel/Atheros

Example Reassociation Instantiation January 2002 Example Reassociation Instantiation STA AP AS Reassociate Request (STA-ID) AP-ID, STA-ID, NonceAP EKAP(NonceAP, AP-ID, K, EKSTA(K, STA-ID)) Reassociate Response = EKSTA(K, STA-ID) EAPOL Key = EK (NonceSTA) EAPOL Key = EK (NonceSTA+1), EAssocKey(Nonce) K = f(K), AssocKey = g(K) Walker/Cam-Winget; Intel/Atheros

Comparison with IAPP “Fast Hand-off” (1) January 2002 Comparison with IAPP “Fast Hand-off” (1) Reduces # of catastrophic failure points from n to 1 STA + new AP have fresh, independent Association Key on every association v. Association Key derived from same keying material on every reassociation for IAPP Protocol is live by construction v. not evident for IAPP “Fast Hand-off” Explicit reauthentication v. don’t know if authentication works for IAPP fast hand-off Explicit key verification v. implicit key verification for IAPP Walker/Cam-Winget; Intel/Atheros

Comparison with IAPP “Fast Hand-off” (2) January 2002 Comparison with IAPP “Fast Hand-off” (2) IPsec not required v. IPsec required for IAPP Fast Hand-off New AP could forward STA’s authenticator to Old AP in an appropriate request after Key Sharing Protocol completes, causing the Old STA to delete obsolete state AS IPsec SA management suspicious If AS IPsec SA management not used, decreases number of AP keys from n(n+1)/2 to n On the other hand, if the AS supported its part of Key Sharing Protocol, this could be used between old AP and new AP to secure data exchange between them Walker/Cam-Winget; Intel/Atheros

January 2002 Summary IAPP has its proper functions, but TGi is distorting its architecture by moving keys between APs More important, using IAPP for key transfer introduces a number of security problems Simpler, more secure, more scalable architectures are feasible TGf should not compromise its architecture to accommodate TGi However, it must if TGi does not abandon this usage If it doesn’t abandon this, TGi is still responsible for Define Send Security Block and Move contents Define how it wants these contents secured Walker/Cam-Winget; Intel/Atheros

January 2002 Feedback? Walker/Cam-Winget; Intel/Atheros