Fast Roaming Observations

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

2. 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

3. STA IAPP Move IAPP Send SecBlock IAPP Send SecBlock Ack IAPP Move Ack Reassociate Request Query New AP Query Response Reassociate Response IAPP Fast Hand-off of TGi Keys Old AP AS • 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

4. 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

5. 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

6. 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

7. A Different Architecture (1) • Assume: Each AP shares a secret KAP with the AS (Needed for 802.1X support anyway) • Key Hierarchy: • Master KeyKSTA 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

8. 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

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

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

11. 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

12. 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

13. 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

14. Feedback? Walker/Cam-Winget; Intel/Atheros