Secure Roaming IEEE 802.11 Tgi Bernard Aboba Tim Moore Microsoft doc.: IEEE 802.11-01/252 May 2001 May 2001 Secure Roaming IEEE 802.11 Tgi Bernard Aboba Tim Moore Microsoft Bernard Aboba, Microsoft Bernard Aboba, Microsoft

Goals To describe typical roaming scenarios May 2001 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

Roaming Scenarios Enterprise “Hot Spot” May 2001 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

Roaming Requirements Enterprise “Hot Spot” May 2001 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” Roaming should be fast Going back to the home authentication server may cause substantial delays (~ seconds) Bernard Aboba, Microsoft

Potential Roaming Solutions May 2001 Potential Roaming Solutions Kerberos-based roaming Extended ticket solution Context transfer Bernard Aboba, Microsoft

Kerberos-Based Roaming May 2001 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

Extended Ticket Solution May 2001 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

May 2001 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

May 2001 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

May 2001 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

A Model for Security Context Transfer May 2001 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

Defining Security Context May 2001 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

Implications of Context Transfer Model May 2001 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

Proposal for Security Context Blob May 2001 Proposal for Security Context Blob 2 octets 2 octets Element Identifier Length Information 802.11 TgF Format Security Sub-element OUI Type Information 3 octets 1 octet 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) Bernard Aboba, Microsoft

Contents of RADIUS Sub-element May 2001 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

Context Transfer & IEEE 802.1X State Machine May 2001 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

Reassociate, Disassociate & Beacon Security May 2001 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

Backend Authentication State Machine (Figure 8-12) May 2001 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

Authenticator PAE State Machine (Figure 8-8) May 2001 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

Supplicant PAE State Machine (Figure 8-14) May 2001 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 EAP-Request/Identity sent by Authenticator On EAP-Request/Identity, supplicant transitions to ACQUIRED state Bernard Aboba, Microsoft

Appendix AVPs for use in RADIUS Context Transfer Blob May 2001 Appendix AVPs for use in RADIUS Context Transfer Blob Bernard Aboba, Microsoft

Attribute Table May 2001 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

Attribute Table (cont’d) May 2001 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 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

Attribute Table (cont’d) May 2001 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 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

Attribute Table (cont’d) May 2001 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 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

Attribute Table May 2001 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 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

Attribute Table May 2001 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 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

Attribute Table May 2001 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 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

Attribute Table May 2001 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 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