doc.: IEEE /251 Submission May 2001 Bernard Aboba, MicrosoftSlide 1 Secure Roaming IEEE TgF Bernard Aboba Tim Moore Microsoft

doc.: IEEE /251 Submission May 2001 Bernard Aboba, MicrosoftSlide 2 Goals To describe security context transfer model To describe implications for TgF

doc.: IEEE /251 Submission May 2001 Bernard Aboba, MicrosoftSlide 3 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!

doc.: IEEE /251 Submission May 2001 Bernard Aboba, MicrosoftSlide 4 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

doc.: IEEE /251 Submission May 2001 Bernard Aboba, MicrosoftSlide 5 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

doc.: IEEE /251 Submission May 2001 Bernard Aboba, MicrosoftSlide 6 Proposal for Security Context Blob Element Identifier LengthInformation 2 octets OUITypeInformation 3 octets1 octet Element identifier for security TBD OUI = 0 for standardized sub-elements, otherwise vendor-specific Type = TBD for RADIUS, DIAMETER (assigned by 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) TgF Format Security Sub-element

doc.: IEEE /251 Submission May 2001 Bernard Aboba, MicrosoftSlide 7 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 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

doc.: IEEE /251 Submission May 2001 Bernard Aboba, MicrosoftSlide 8 Reassociate & Disassociate Security Currently, reassociate, disassociate messages are not secure –Enables denial of service attacks Proposal –Enable passing of information elements in TgF move-request and move-confirm messages –Add an authenticator to reassociate and disassociate messages –On reassociate: new AP validates authenticator via move-request to old AP; if invalid, old AP ignores move-request

doc.: IEEE /251 Submission May 2001 Bernard Aboba, MicrosoftSlide 9 Appendix AVPs for use in RADIUS Context Transfer Blob

doc.: IEEE /251 Submission May 2001 Bernard Aboba, MicrosoftSlide 10 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

doc.: IEEE /251 Submission May 2001 Bernard Aboba, MicrosoftSlide 11 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

doc.: IEEE /251 Submission May 2001 Bernard Aboba, MicrosoftSlide 12 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

doc.: IEEE /251 Submission May 2001 Bernard Aboba, MicrosoftSlide 13 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

doc.: IEEE /251 Submission May 2001 Bernard Aboba, MicrosoftSlide 14 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

doc.: IEEE /251 Submission May 2001 Bernard Aboba, MicrosoftSlide 15 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

doc.: IEEE /251 Submission May 2001 Bernard Aboba, MicrosoftSlide 16 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

doc.: IEEE /251 Submission May 2001 Bernard Aboba, MicrosoftSlide 17 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