1 / 21

Secure Roaming

Secure Roaming. Greg Chesson, Atheros Nancy Cam Winget, Atheros Jesse Walker, Intel Doug Whiting, HiFN. Outline. Motivation and Objectives Definitions Association/Authentication Secure Roaming Framework Details. Motivations. 802.11 architecture requires two key handoff procedures:

stacie
Download Presentation

Secure 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. Secure Roaming Greg Chesson, Atheros Nancy Cam Winget, Atheros Jesse Walker, Intel Doug Whiting, HiFN Greg Chesson,Atheros, et al.

  2. Outline • Motivation and Objectives • Definitions • Association/Authentication • Secure Roaming Framework • Details Greg Chesson,Atheros, et al.

  3. Motivations • 802.11 architecture requires two key handoff procedures: • Initial contact - 802.1X AS to AP/STA • Roaming: from 802.1X AS or old AP or STA to new AP • Claims • Different methods for each case introduces too much complexity to get right • To be secure, key exchange between STA and AP must be tied to the back-end key handoff protocol Greg Chesson,Atheros, et al.

  4. Objectives for Secure Roaming • Utilize the same key-passing procedure both for initial contact and for roaming • Utilize proven authentication procedures • Station-initiated key exchanges • Eliminate AP-AP transactions (!) • Except when AP is also an AS Greg Chesson,Atheros, et al.

  5. Definitions • Associate: STA/AP handshake whereby station connects to the Distribution Service (DS) at the AP. Implies nothing about security. A station shall associate with only one AP at a time to ensure DS correctness. • Security Context:synchronized state between a pair of endpoints consisting of identical key material and algorithms and agreement on their usage. • Authentication: process whereby an initial security context is created between an AP and STA. • 2-party authenticated key exchange: key exchange with key verification between A and B, involving messages only between A and B. • 3-party authenticated key exchange: key exchange between A and B relying on a trusted 3rd party authentication server (AS), with key verification between A and B. Greg Chesson,Atheros, et al.

  6. Definitions • Roam: a station moves its DS association from one AP to another. • Secure Roam: a station moves its DS association from one AP/context to another AP/context. Greg Chesson,Atheros, et al.

  7. Association/Authentication Independence • Station associates without a security context • Legacy 802.11-1999 definition • RSN Security context possible without association • Unexploited property of RSN 1X proposals • STA does not know address of AS • AP forwards 1X messages to AS on behalf of STA • STA does not need DS for RSN-authentication Observation: multiple security contexts may exist between one station and several APs. Greg Chesson,Atheros, et al.

  8. Secure Roaming Framework • Security context is independent of association. • Station maintains multiple independent security contexts at its discretion; e.g. “pre-authentication”. • Each context is a “secure stovepipe” - created by RSN authentication between STA and each AP/AS without message exchanges or key exchange between APs. • A station shall perform standard 802.11 association after RSN authentication. Greg Chesson,Atheros, et al.

  9. Framework Auth Server Roam Manager AS MSKa APa MSKb RM APb Table: STA MAC MSKa 0 MSKb 0 MSKc 1 MSKc STA APc MSKa MSKb MSKc Active association Greg Chesson,Atheros, et al.

  10. Details • AP retains MSK context per STA • Context may be associated or not • AP forwards association state changes to RM • (side effect of keying protocol) • AS/RM maintains table of stations, keys, associations • AS/RM may provide context removal policy • (new AP/AS message exchange) Greg Chesson,Atheros, et al.

  11. Properties • No dependence on an IAPP for security • Each STA/AP/AS is a “secure stovepipe” • One key-passing protocol used in all cases • Propose Otway-Rees (see next slides) • Pre-authentication now feasible at each STA • Roam via association/disassociation/reassoc. • Appeal to IAPP for DS management only Greg Chesson,Atheros, et al.

  12. Step 1: Encapsulate EAPOL in 802.11 Authentication • Message 1 is null • Message 2 can include any EAPOL message but EAP-Success • Message 3 includes EAP-Success • Need new service interface to allow 802.1X to send these? Greg Chesson,Atheros, et al.

  13. Step 2 – Designing the Stovepipe: Supplicant-Initiated Key Handoff • Use Otway-Rees protocol as the model • Otway-Rees defines a mechanism for distributing keys from a KDC to a server and client that fits our application: • Client contacts Server • Server contacts KDC • KDC responds to Server • Server responds to Client Greg Chesson,Atheros, et al.

  14. KDC Server Client Cid, Sid, Xid, RC, EKC(RC, Cid, Sid, Xid) Cid, Sid, Xid, EKC(RC, Cid, Sid, Xid), EKS(RS, Cid, Sid, Xid) EKS(RS, K), EKC(RC, K) EK(CA) EK(RC, CA), EKS(RC, K) Otway-Rees Greg Chesson,Atheros, et al.

  15. Otway-Rees Adaptation • To use this model: • Let • The Supplicant (STA) play the role of the client • The Authenticator (new AP) play the role of the server • The AS plays the role of the KDC • Let the MSK play the role of the session key K • Separate MIC from encryption • Minimize amount of encrypted data Greg Chesson,Atheros, et al.

  16. AS Supplicant (STA) Aid, Sid, Xid, RS, NS, MICKS(RS , Xid, Aid, Sid) Aid, Sid, Xid, RS , MICKS(RS , Xid, Aid, Sid), RA, MICKA(RS , Xid, Aid, Sid) EKE(MSK), MICKA(RA, EKE(MSK)), EKD(MSK), MICKS(RS, EKD(MSK)) EKD(MSK), MICKS(RS, EKD(MSK)), NA, CA, MICK(Aid, Sid , RS, CA) MICK(Sid, CA) Supplicant-Initiated Key Passing Authenticator (New AP) K= f(MSK, NS, NA), TSK = g(MSK, NS, NA) K= f(MSK, NS, NA), TSK = g(MSK, NS, NA) Greg Chesson,Atheros, et al.

  17. Step 3: Expand 8021.X to do Key Passing Right • First use 802.1X authentication • EAP-Success message triggers key passing • Neither Station nor AP 802.1X authorization state machines transition to “Authenticated” yet • Alter Success message to include MIC based to signal use of key passing protocol • Station transitions to “Authenticated” after sending message 5 of key passing protocol • AP transitions to “Authenticated” after receiving message 5 of key passing protocol Greg Chesson,Atheros, et al.

  18. Step 4: Initial Contact v. Reassociation • On initial contact: • First AS and Station first mutually authenticate • Then AS and Station agree on authentication key KS, key encryption key KD • Finally use KS and KD to run key passing protocol • AS and Station cache KS and KD for later use • On reassociation: • Only run the key passing protocol using cached keys KS and KD Greg Chesson,Atheros, et al.

  19. Step 5: Integrate into TGi • Remove ASE from (Re)association frames • Reinstate 802.11 Authentication frames • Declare 802.1X is always used with RSN • Declare independence of authentication and association Greg Chesson,Atheros, et al.

  20. To Do • Liaison with 802.1aa, IETF to define EAP encapsulation of key passing protocol • Liaison with RADIUS server vendors to have key passing protocol implemented Greg Chesson,Atheros, et al.

  21. Feedback? Greg Chesson,Atheros, et al.

More Related