1 / 29

Secure Roaming

Secure Roaming. IEEE 802.11 Tgi Bernard Aboba Tim Moore Microsoft. Goals. To describe typical roaming scenarios To describe requirements for a roaming solution To evaluate proposed solutions To recommend what 802.11 Tgi should do to support roaming. Roaming Scenarios. Enterprise

enye
Télécharger la présentation

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 IEEE 802.11 Tgi Bernard Aboba Tim Moore Microsoft Bernard Aboba, Microsoft

  2. Goals • To describe typical roaming scenarios • To describe requirements for a roaming solution • To evaluate proposed solutions • To recommend what 802.11 Tgi should do to support roaming Bernard Aboba, Microsoft

  3. Roaming Scenarios • Enterprise • 802.11 wireless access within a corporate campus • VLANs may be implemented • Authentication may involve passwords, smartcards, token cards, OTP, etc. • User authenticates to an authentication server on the same campus • “Hot Spot” • 802.11 wireless access in airports, hotels, cafes • Authentication is typically password-based • Account at wireless ISP • Wholesale wireless access to corporations may eventually become popular • VLANs typically not implemented • User authenticates to the home authentication server, which may be far away Bernard Aboba, Microsoft

  4. Roaming Requirements • Enterprise • User is identified by user-name (NAI), not IP or MAC address • Security is not compromised • Roaming needs to be available for all potential 802.1X authentication methods • Desirable for user to be able to keep the same IP address when roaming, if possible • MUST be able to roam without reauthentication if desired • MUST be able to roam without dropping traffic in case of reauthentication • “Hot Spot” • User is identified by user-name (NAI), not IP or MAC address • Security is not compromised • Roaming should be fast • Going back to the home authentication server may cause substantial delays (~ seconds) Bernard Aboba, Microsoft

  5. Potential Roaming Solutions • Kerberos-based roaming • Extended ticket solution • Context transfer Bernard Aboba, Microsoft

  6. Kerberos-Based Roaming • User initially authenticates to the AP, receives TGT, ticket to the AP • On roaming within the same domain, client submits AP ticket, authenticator in AP-REP • Pros • Can supply new AP with 802.11 encryption key • No modifications to EAP or 802.1X required • Cons • Requires Access Points to share a Kerberos Key • Not general across all 802.1X authentication methods • Does not provide new AP with authorizations (VLANID) unless a new Kerberos Authorization field is defined • Trip back to the home server typically required for authorizations • Verdict • Does not meet requirements for hot spot or enterprise scenarios Bernard Aboba, Microsoft

  7. Extended Ticket Solution • User initially authenticates using any 802.1X authentication method • Within EAP-Success, a ticket to the AP is returned • Pros • General across all 802.1X authentication methods • Could provide AP with authorizations • No trip back to home server required • Cons • Requires update to RFC 2284 to enable EAP Success to carry ticket • Requires changes to 802.1X to enable passthrough of extended EAP-Success packet • Verdict • Meets requirements, but may take significant time to implement Bernard Aboba, Microsoft

  8. Context Transfer • User initially authenticates using any 802.1X authentication method • When user moves to a new AP, the old AP transfers the session context to the new AP • Context includes VLANID, session key, etc. • Pros • General across all 802.1X authentication methods • Can provide AP with authorizations • No trip back to home server required • No modifications to EAP or 802.1X required • Cons • Requires APs to support context transfer protocol • Assumes that new AP would receive the same authorizations as the old AP from the authentication server • May not be true if new AP from different vendor or within a different administrative domain • Competing context transfer protocols (IEEE 802.1 TgF vs. SEAMOBY) • Verdict • Meets requirements, can be delivered sooner than other methods Bernard Aboba, Microsoft

  9. Recommendation • Context-transfer solution appears superior in terms of delivery timeframe, conformance to requirements • Kerberos does not meet enterprise or “hot spot” roaming requirements without modification • IEEE 802.11 Tgi should work with 802.11 TgF in order to ensure compatibility between security and context transfer solutions Bernard Aboba, Microsoft

  10. 802.11 TgF • Inter-Access Point Protocol for use with IEEE 802.11 access points • Protocol features • Support for determining access point IP addresses based on MAC address (registration service) • IAPP-INITIATE.request, IAPP-INITIATE.confirm, IAPP-TERMINATE.request, IAPP-TERMINATE.confirm • Support for notifying distribution system of new associations • IAPP-ADD.request, IAPP-ADD.confirm, IAPP-ADD.indication • Support for moving context after reassociate request • IAPP-MOVE.request, IAPP-MOVE.confirm, IAPP-MOVE.indication, IAPP-MOVE.response • Support for obtaining configuration information • IAPP-Config-READ.request, IAPP-Config-READ.confirm • Context blob definition • Context blobs defined as AVPs: 16-bit type, 16-bit length • Context blob values not defined in 802.11 TgF: left to other task groups Bernard Aboba, Microsoft

  11. A Model for Security Context Transfer • Model for security context establishment • AP receives result (Accept/Reject) + authorizations from backend authentication server, implements the requested service • AP issues accounting records identified by Session-Id and Multi-Session-Id • Requirements for security context transfer • To achieve the same result as if the new AP authenticated to backend authentication server • Assumptions • Backend authentication server would send same Result + authorizations to new AP as it would to old AP • If so, sending result + authorizations from old AP to new AP satisfies the requirement • When the assumptions are invalidated • When the backend authentication server does conditional evaluation based on: • Nas-IP-Address, Nas-Port-Type, NAS-Identifier, Vendor-Id, User-Name • Result is typically sending of vendor, link type or domain-specific attributes • When Access Points differ substantially in their supported services • Can’t transfer context of a service that the new AP doesn’t support! Bernard Aboba, Microsoft

  12. Defining Security Context • Context is the definition of the service to be provided to the user • How do we define services today? • IETF standards: RADIUS, COPS, LDAP • Standards in development: DIAMETER • Model for security context transfer • Transport Accept message from old AP to new AP • No need to transfer Reject message – just say No! • New AP processes context transfer as though it were receiving a message from the backend authentication server • Multiple definitions of security context can be supported – one for each backend authentication protocol Bernard Aboba, Microsoft

  13. Implications of Context Transfer Model • Context blob types • Security context blob sub-types needed for each supported backend authentication protocol • Security • Context blobs can contain security information (keys) • Need to either encrypt individual sub-elements or the entire context transfer message • RADIUS guidelines: AVPs are encrypted with the RADIUS shared secret, OR if no shared secret and if IPSEC ESP w/non-null transfer is used then null shared secret assumed • Mandatory vs. non-mandatory security context blobs • Multiple security context blobs can be included in a context transfer • If a context blob type (protocol) isn’t supported by the new AP, it is ignored • Context transfer can (partially) succeed if only one blob is supported and accepted by new AP • Blobs that are understood but cannot be accepted may need to be acquired from a backend server • Mandatory vs. non-mandatory elements and sub-elements • If a context blob type is supported, but describes an unavailable service, context transfer fails • Assumptions underlying context transfer invalidated • Result: new AP authenticates to backend auth server Bernard Aboba, Microsoft

  14. Element Identifier Length Information Proposal for Security Context Blob 2 octets 2 octets • Element identifier for security TBD • OUI = 0 for standardized sub-elements, otherwise vendor-specific • Type = TBD for RADIUS, DIAMETER (assigned by 802.11 Tgi) • Elements, Types that are not understood may be ignored • If a Type is supported, must understand mandatory AVPs within it • Information field encodes RADIUS/DIAMETER AVPs (including vendor-specific) • Can encode AVPs in one or both protocols if necessary (can have more than one security element) 802.11 TgF Format Security Sub-element OUI Type Information 3 octets 1 octet Bernard Aboba, Microsoft

  15. Contents of RADIUS Sub-element • RADIUS usage in IEEE 802.1X • Appendix of IEEE 802.1X standard includes (non-normative) guidelines for RADIUS usage • Defines which RADIUS AVPs make sense for use with IEEE 802.1X • RADIUS context • No need to transfer entire message, just AVPs • Message type assumed to be Accept • Relevant AVPs are those allowable with 802.1X, included in Access-Accept + two accounting AVPs: Acct-Authentic & Acct-Multi-SessionId • Issues • Are Message-Authenticator, EAP-Message attributes transferred? • AP will send Success regardless of what is in EAP-Message • IEEE 802.11 TgF already supports integrity protection • However, including all attributes may make processing simpler • How are encrypted attributes transferred? • 802.1X encrypted attributes: WEP Keys, Tunnel-Password (layer 3 only) • Process them as if they came from backend authentication server • RADIUS: encrypt with shared secret OR if IPSEC ESP available, use a null shared secret Bernard Aboba, Microsoft

  16. Context Transfer & IEEE 802.1X State Machine • Goal • User context can move to new AP without reauthentication, if desired • May wish to enable delayed reauthentication on roam • Process • Client reassociates to new AP • New AP validates reassociate, attempts context transfer from old AP • Context transfer succeeds: AP sends EAP-Success to client • Context transfer fails: re-associate treated as an associate • Requirements • Successful reassociate has same result as if new AP authenticated successfully to backend authentication server • Unsuccessful reassociate has same result as an associate • Authentication for reassociate, disassociate, beacon messages • Issues • No 802.1X event or state corresponding to successful re-associate! Bernard Aboba, Microsoft

  17. Reassociate, Disassociate & Beacon Security • Currently, reassociate, disassociate messages are not secure • Enables denial of service attacks • Proposal • Enable passing of information elements in 802.11 TgF move-request and move-confirm messages • Add an authenticator to reassociate and disassociate messages • Replay counter, HMAC-SHA1 (replay counter || SourceMAC || destMAC || transmit key) • On disassociate: ignore if HMAC is not valid • On reassociate: validate hash via move-request to old AP; if invalid, old AP ignores move-request • Beacon security • Currently, beacon messages are not authenticated • Enables station to roam to an incorrect AP • Proposal: validate beacon before reassociating • Replay Counter, HMAC-SHA1 (replay counter || sourceMAC || multicast key) • Any station can forge this, but better than nothing Bernard Aboba, Microsoft

  18. Backend Authentication State Machine (Figure 8-12) • Goal • Successful re-associate has same result as if new AP authenticated to backend authentication server • Successful reassociate equivalent to: • Setting aSuccess=TRUE; aWhile=serverTimeout; reqCount=0; currentId=0; rxResp=aFail=FALSE; authTimeout=FALSE; aReq=FALSE • Transition to SUCCESS state • Causes canned Success message to be sent • Unsuccessful reassociate equivalent to associate: • Set authAbort=TRUE • Transition to INITIALIZE state • Authentication starts again Bernard Aboba, Microsoft

  19. Authenticator PAE State Machine (Figure 8-8) • Goal • Successful re-associate has same result as if new AP authenticated to backend authentication server • Unsuccessful reassociate equivalent to: • Set portEnabled=TRUE; currentId=1; portMode=Auto; portStatus=Unauthorized; eapLogff=FALSE; reAuthCount=0; • Transition to CONNECTING state • Successful reassociate with no-reauth == TRUE equivalent to: • Set portMode=Auto; eapLogoff=FALSE; reAuthCount=1; currentId=1; portStatus=Unauthorized; eapStart=FALSE; reAuthenticate=FALSE; authSuccess=TRUE; authFail=FALSE; authTimeout=FALSE; portEnabled=TRUE; • Transition to AUTHENTICATED • Successful reassociate with no-reauth == FALSE equivalent to: • Set portMode=Auto; currentId = 2; eapLogoff=FALSE; reAuthCount=0; portStatus=Authorized; portEnabled=TRUE; reAuthenticate=TRUE; • Transition to CONNECTING Bernard Aboba, Microsoft

  20. Supplicant PAE State Machine (Figure 8-14) • Goal • Successful reassociate has same result as if supplicant successfully authenticated to authenticator • Sequence of events for successful reassociate • Supplicant in AUTHENTICATED state • Reassociate request sent by Supplicant • Success sent by Authenticator • Supplicant remains in AUTHENTICATED state • Sequence of events for unsuccessful reassociate • Supplicant in AUTHENTICATED state • Reassociate request sent by Supplicant • EAP-Request/Identity sent by Authenticator • On EAP-Request/Identity, supplicant transitions to ACQUIRED state Bernard Aboba, Microsoft

  21. AppendixAVPs for use inRADIUS Context Transfer Blob Bernard Aboba, Microsoft

  22. Attribute Table 802.1X Context # Attribute X X 1 User-Name 2 User-Password 3 CHAP-Password X 4 NAS-IP-Address X 5 NAS-Port X X 6 Service-Type 7 Framed-Protocol 8 Framed-IP-Address 9 Framed-IP-Netmask L3 X 10 Framed-Routing 802.1X Context # Attribute Key === 802.1X = Allowed for use with IEEE 802.1X Context = Transferred between access points during roaming if available L3 = implemented only on switches/access points with Layer 3 capabilities Bernard Aboba, Microsoft

  23. Attribute Table (cont’d) 802.1X Context # Attribute X X 11 Filter-Id X X 12 Framed-MTU 13 Framed-Compression 14 Login-IP-Host 15 Login-Service 16 Login-TCP-Port X X 18 Reply-Message 19 Callback-Number 20 Callback-Id 802.1X Context # Attribute Key === 802.1X = Allowed for use with IEEE 802.1X Context = Transferred between access points during roaming if available L3 = implemented only on switches/access points with Layer 3 capabilities Bernard Aboba, Microsoft

  24. Attribute Table (cont’d) 802.1X Context # Attribute L3 X 22 Framed-Route L3 X 23 Framed-IPX-Network X X 24 State X X 25 Class X X 26 Vendor-Specific X X 27 Session-Timeout X X 28 Idle-Timeout X X 29 Termination-Action X 30 Called-Station-Id X 31 Calling-Station-Id X 32 NAS-Identifier 802.1X Context # Attribute Key === 802.1X = Allowed for use with IEEE 802.1X Context = Transferred between access points during roaming if available L3 = implemented only on switches/access points with Layer 3 capabilities Bernard Aboba, Microsoft

  25. Attribute Table (cont’d) 802.1X Context # Attribute X 33 Proxy-State 34 Login-LAT-Service 35 Login-LAT-Node 36 Login-LAT-Group L3 X 37 Framed-AppleTalk-Link L3 X 38 Framed-AppleTalk-Network L3 X 39 Framed-AppleTalk-Zone X 40 Acct-Status-Type X 41 Acct-Delay-Time X 42 Acct-Input-Octets X 43 Acct-Output-Octets 802.1X Context # Attribute Key === 802.1X = Allowed for use with IEEE 802.1X Context = Transferred between access points during roaming if available L3 = implemented only on switches/access points with Layer 3 capabilities Bernard Aboba, Microsoft

  26. Attribute Table 802.1X Context # Attribute X 44 Acct-Session-Id X X 45 Acct-Authentic X 46 Acct-Session-Time X 47 Acct-Input-Packets X 48 Acct-Output-Packets X 49 Acct-Terminate-Cause X X 50 Acct-Multi-Session-Id 51 Acct-Link-Count X 52 Acct-Input-Gigawords X 53 Acct-Output-Gigawords X 55 Event-Timestamp 802.1X Context # Attribute Key === 802.1X = Allowed for use with IEEE 802.1X Context = Transferred between access points during roaming if available L3 = implemented only on switches/access points with Layer 3 capabilities Bernard Aboba, Microsoft

  27. Attribute Table 802.1X Context # Attribute 60 CHAP-Challenge X X 61 NAS-Port-Type 62 Port-Limit 63 Login-LAT-Port X X 64 Tunnel-Type X X 65 Tunnel-Medium-Type L3 X 66 Tunnel-Client-Endpoint L3 X 67 Tunnel-Server-Endpoint L3 X 68 Acct-Tunnel-Connection L3 X 69 Tunnel-Password 70 ARAP-Password 71 ARAP-Features 802.1X Context # Attribute Key === 802.1X = Allowed for use with IEEE 802.1X Context = Transferred between access points during roaming if available L3 = implemented only on switches/access points with Layer 3 capabilities Bernard Aboba, Microsoft

  28. Attribute Table 802.1X Context # Attribute 72 ARAP-Zone-Access 73 ARAP-Security 74 ARAP-Security-Data 75 Password-Retry 76 Prompt X 77 Connect-Info X 78 Configuration-Token X 79 EAP-Message X 80 Message-Authenticator X X 81 Tunnel-Private-Group-ID L3 X 82 Tunnel-Assignment-ID X X 83 Tunnel-Preference 802.1X Context # Attribute Key === 802.1X = Allowed for use with IEEE 802.1X Context = Transferred between access points during roaming if available L3 = implemented only on switches/access points with Layer 3 capabilities Bernard Aboba, Microsoft

  29. Attribute Table 802.1X Context # Attribute 84 ARAP-Challenge-Response X 85 Acct-Interim-Interval X 86 Acct-Tunnel-Packets-Lost X 87 NAS-Port-Id 88 Framed-Pool L3 X 90 Tunnel-Client-Auth-ID L3 X 91 Tunnel-Server-Auth-ID X TBD NAS-IPv6-Address TBD Framed-Interface-Id L3 X TBD Framed-IPv6-Prefix TBD Login-IPv6-Host L3 X TBD Framed-IPv6-Route 802.1X Context # Attribute Key === 802.1X = Allowed for use with IEEE 802.1X Context = Transferred between access points during roaming if available L3 = implemented only on switches/access points with Layer 3 capabilities Bernard Aboba, Microsoft

More Related