Doc.: IEEE 802.11-01/553r0 Submission September 2001 Tim Moore, Bernard Aboba/Microsoft...
-
Upload
leslie-rogers -
Category
Documents
-
view
214 -
download
0
Transcript of Doc.: IEEE 802.11-01/553r0 Submission September 2001 Tim Moore, Bernard Aboba/Microsoft...
September 2001
Tim Moore, Bernard Aboba/Microsoft
doc.: IEEE 802.11-01/553r0
Submission
Authenticated Fast Handoff
IEEE 802.11 TgiTim Moore
Bernard AbobaMicrosoft
September 2001
Tim Moore, Bernard Aboba/Microsoft
doc.: IEEE 802.11-01/553r0
Submission
Why Do We Care About Fast Handoff?• 802.11 is becoming popular on small devices
– PDAs, phones, not just laptops• Multimedia applications sensitive to connectivity loss
– Audio, Video• TCP sensitive to multiple losses
– Loss of an entire window will cause connection to go into slow-start• 802.11-1997 fast handoff is fast, simple and insecure
– Authentication occurs prior to reassociation so pre-authentication is possible– Management frames are not authenticated, no cryptographic operations in critical path– If all APs use the same WEP key, no inter-AP communication is required
• 802.1X support complicates 802.11 fast handoff– STAs have dynamic per-session keys– With 802.1X, authentication occurs after reassociation, not before
• If re-authentication is required, STAs need to complete authentication conversation before recovering connectivity
– Authentication and key management methods requiring public key operations (e.g. EAP-TLS) can take several seconds to complete
– TLS continuation can decrease round-trips (from 3.5 to 2.5) • Disconnection time is still significant, particularly if backend authentication server is far away (e.g. “hotspot”
scenarios).
September 2001
Tim Moore, Bernard Aboba/Microsoft
doc.: IEEE 802.11-01/553r0
Submission
Fast Handoff 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
September 2001
Tim Moore, Bernard Aboba/Microsoft
doc.: IEEE 802.11-01/553r0
Submission
Goals for Authenticated Fast Handoff• Fast
– Transfer times on order of 20 ms or less, not seconds– No need to reauthenticate after each reassociation– Support for complete context transfer (including VLANID) for
seamless user experience• Secure
– Support for per-session keys, dynamic key generation– Works with all EAP authentication methods– Secure reassociation requests and responses, as well as
disassociation notifications– Protection against spoofing, denial of service, hijacking
• Deployable– Enable deployment of inter-access point protocol (IAPP) without a
registration service
September 2001
Tim Moore, Bernard Aboba/Microsoft
doc.: IEEE 802.11-01/553r0
Submission
Security improvements
September 2001
Tim Moore, Bernard Aboba/Microsoft
doc.: IEEE 802.11-01/553r0
Submission
State 1Unauthenticated,
Unassociated
State 2Authenticated, Unassociated
State 3Authenticated, and Associated
Successful MAC layer Authentication
Successful Association or Reassociation
Disassociation Notification
DeAuthentication Notification
Deauthentication notification
Class 1 Frames
Class 1 & 2 Frames
Class 1, 2 & 3 Frames
Classic 802.11 State Machine
September 2001
Tim Moore, Bernard Aboba/Microsoft
doc.: IEEE 802.11-01/553r0
Submission
802.11 “Classic”: Implications for Fast Handoff• Classic 802.11 authentication occurs before reassociation
– Enables a STA to pre-authenticate with the new AP prior to reassociation• Inter-Access Point communication typically not necessary
– If all APs use the same key, new AP can validate the STA authentication without contacting the old AP.
• Ability for STAs to quickly reassociate between access points– STA sends Disassociate to old AP after it receives Reassociation-Response from new
AP– New AP install STA state in DS after receiving an ACK of the Reassociation-
Response from STA– No cryptographic operations in the critical path
• Management frames are not authenticated– Association-Request/Response, Reassociation-Request/Response, Disassociation
notification are unauthenticated– Enables an attacker to forge these and other management frames, take over sessions
September 2001
Tim Moore, Bernard Aboba/Microsoft
doc.: IEEE 802.11-01/553r0
Submission
802.11 “Classic” Fast Handoff
STAAPold APnew
Associate-Request
Associate-Response
ACK
DSNotified
Reassociate-Request
Reassociate-Response
ACK
DSNotified
Disassociate
Note: Authentication not on critical path, so not included
Transition Period ~ STA-AP
September 2001
Tim Moore, Bernard Aboba/Microsoft
doc.: IEEE 802.11-01/553r0
Submission
State 1Unauthenticated, Unassociated
State 2Authenticated, Unassociated
State 3Authenticated, and Associated
Successful MAC layer Authentication
Successful Association or Reassociation
Disassociation Notification
DeAuthentication Notification
Deauthentication notification
Class 1 Frames + ESN Class 2 frames
Class 1 & 2 Frames
Class 1, 2 & 3 Frames
802.11i State Machine
State 4ESN Associated
ESN Association or Reassociation
ESN Disassociation
Notification
Class 1, 2 & 3 Frames except Authentication & Deauthentication
September 2001
Tim Moore, Bernard Aboba/Microsoft
doc.: IEEE 802.11-01/553r0
Submission
802.11i: Implications for Fast Handoff• With 802.1X, upper layer authentication occurs after ESN association/reassociation
– 802.1X state machine is driven by association/reassociation events– AP can only be associated with a single STA; since 802.1X authentication occurs after
reassociation, an ESN STA can only authenticate to a single ESN AP• Full reauthentication to each AP a significant cost
– 802.1X authentication may involve multiple round-trips, public key operations– Environments with many mobile stations can heavily load the backend authentication
server– Desirable to avoid a full reauthentication at every AP
• Need to lock all doors left open by classic 802.11– 802.11i adds dynamic keying (802.1X), credible ciphersuite (AES), but…– Need to address other 802.11 security holes such as unauthenticated management frames
• Cryptographic operations now in the critical path for Fast Handoff– ESN reassociated STA cannot access the controlled port of the ESN AP until upper layer
authentication completes– Authentication of Reassociation-Request/Response, Disassociation required to prevent
hijacking
September 2001
Tim Moore, Bernard Aboba/Microsoft
doc.: IEEE 802.11-01/553r0
Submission
Questions
• Should authentication occur before or after reassociation?
• How do we authenticate management frames?– This presentation addresses
Reassociation-Request/Response, and Disassociation Notification frames
– Future work will address authentication of other Management Frames• Association-Request/Response, Beacon,
Probe-Request/Response, Deauthentication, ATIM
September 2001
Tim Moore, Bernard Aboba/Microsoft
doc.: IEEE 802.11-01/553r0
Submission
Alternatives• Authentication before reassociation
– Pros• Enables pre-authentication• Authentication no longer in the critical path for reassociation
– Cons• If you authenticate management frames, cryptographic operations remain in the
critical path (since you need to authenticate the Reassociation Request/Response)
• If you’re already authenticating reassociation request/response, why do more than “canned” authentication in addition?
• Reassociation before Authentication– Pros
• Simplicity: authenticate Reassociation-Request/Response, Disassociation, AP issues “canned success” in upper layer authentication if authentication is successful at MAC layer
• Minimizes cryptographic operations in the critical path for reassociation– Cons
• No pre-authentication
September 2001
Tim Moore, Bernard Aboba/Microsoft
doc.: IEEE 802.11-01/553r0
Submission
Proposed Approach• Authentication of Reassociate, Disassociate frames
– Authenticator Information Element added to Reassociation-Request/Response, Disassociation notification frames
– Authenticator Information Element enables STA and new AP to provide possession of the unicast authentication session key negotiated with the old access point.
• Support within the Inter-Access Point Protocol (IAPP)– New AP passes the Authenticator IE to the with old AP in the Inter-Access Point
Protocol (IAPP) Move-Request– Old AP validates the Authenticator– If successfully validated, old AP sends IAPP Move-Response to new AP– Otherwise, old AP silently discards IAPP Move-Request
• New AP will not send Reassociation-Response• STA Reassociation-Request will time out• STA, AP will re-authenticate• Appropriate 802.11f MIB variable is incremented
– 802.1X “canned success” sent from AP to STA if Authenticator IE included within the Reassociation-Request is valid.
September 2001
Tim Moore, Bernard Aboba/Microsoft
doc.: IEEE 802.11-01/553r0
Submission
802.11i Fast Handoff
STAAPold APnew
Associate-Request
Associate-Response
ACKDSNotified
Reassociate-Request (Authenticated)
Reassociate-Response (Authenticated)
ACK
DSNotified
Disassociate (Authenticated)
Transition Period ~ RTTSTA-AP
802.1X/Identity Request
EAP-Success
802.1X/Identity Response
EAP-RequestEAP-Response
Transition Period ~ nRTTSTA-AP
n =3.5 (TLS), 2.5 (TLS continuation)
September 2001
Tim Moore, Bernard Aboba/Microsoft
doc.: IEEE 802.11-01/553r0
Submission
Authenticator Information Element• Assumes that a unicast key is available either for
the current AP (Disassociation, Reassociation-Response messages), or with the previous AP (Reassociation-Request message).
• Authenticator = HMAC-MD5(STA MAC address | AP MAC address | Timestamp, key)– Timestamp = 8 octet timestamp (see Section 7.3.1.10) to
prevent replay
– The authentication session key derived from the negotiated master key is used (same key as is used to authenticate the EAPOL-Key message)
September 2001
Tim Moore, Bernard Aboba/Microsoft
doc.: IEEE 802.11-01/553r0
Submission
Authenticator Information Element0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Element ID | Length | Algorithm |Authenticator...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Authenticator+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
• Element ID: TBD• Length: 19 = HMAC-MD5• Algorithm
– 1 = HMAC-MD5• Authenticator
– For Algorithm=1, 128-bit HMAC-MD5(STA MAC address | AP MAC address | Timestamp, key)
– Authentication key = session key used to authenticate the EAPOL-Key message
September 2001
Tim Moore, Bernard Aboba/Microsoft
doc.: IEEE 802.11-01/553r0
Submission
Deployability improvements
September 2001
Tim Moore, Bernard Aboba/Microsoft
doc.: IEEE 802.11-01/553r0
Submission
The Registration Problem• New AP contacts the old AP via IAPP to validate the reauthentication-
request, transfer context• IAPP runs over IP
– Implication: New AP needs the IP address of the old AP in order to communicate with it
• 802.11 enables the STA to obtain the MAC address of the old & new APs– Client obtains the MAC address of the old AP when it associates/re-
associates with it– Client provides the new AP with the MAC address of the old AP in the
re-association request• But how does the new AP locate the old AP IP address?
– New AP knows the MAC address of the old AP, not its IP address– Need a way to map the MAC address to an IP address
September 2001
Tim Moore, Bernard Aboba/Microsoft
doc.: IEEE 802.11-01/553r0
Submission
Alternate Solutions to the Registration Problem1. Inverse ARP (RFC 2390)
– Assumes APs are all on the same subnet, so not a general solution– Note: Having APs on different subnets does not imply change of subnet for the client
(possible for the AP to support dynamic VLANs)2. AAA protocols
• Authentication server knows where APs are, but…• AAA protocols weren’t designed to solve this problem
3. Registration Service (what’s in 802.11 TgF Draft 2)• Problems:– Enterprise customers do not wish to deploy yet another service– Selecting an AP to run the service requires an election protocol– Registration service designs discussed so far (SLPv2, DNS) have serious flaws
4. Include AP IP address(es) in management messages – IP address(es) of new AP provided to STA in association-response, reassociation-
response– STA provides IP address(es) of old AP to new AP in reassociation-request
• Recommendation: Choice 4– Eliminates need for registration service (and resulting deployment problems)
September 2001
Tim Moore, Bernard Aboba/Microsoft
doc.: IEEE 802.11-01/553r0
Submission
Issues with use of SLPv2 for Registration Service
• SLPv2 designed for use in service discovery, not resolving MAC addresses to IP addresses
– Use of SLPv2 as a routable version of InverseARP is inefficient
• SLPv2 requires multicast routing to all access points; not widely deployed
• SLPv2 limited to use within a single administrative domain – prevents context transfer between domains
– Inter-domain context transfer should not be prohibited in situations where the trust issues can be worked out
• For scalability, SLPv2 requires deployment of Directory Agents (DAs)
• SLPv2 security is inflexible– Requires certificate infrastructure– Supports only DSA signatures (RSA much more widely used)– No known implementations
September 2001
Tim Moore, Bernard Aboba/Microsoft
doc.: IEEE 802.11-01/553r0
Submission
Issues with use of DNS for Registration Service• DNS not designed as a mechanism for translating MAC
addresses to IP Addresses• Would require addition of a MAC address record to DNS
– DNSEXT WG unlikely to agree to this (it’s a bad idea!)– DHCPID RR based on a hash of the MAC address– DHCPID RR not to be used for alternative purposes
• Would require APs, DNS servers to support new DNS record types as well as DNS dynamic update
• DNS dynamic update not yet widely deployed• Secure dynamic update implementations not yet
interoperable– Use by APs would require trust between APs and DNS Server
September 2001
Tim Moore, Bernard Aboba/Microsoft
doc.: IEEE 802.11-01/553r0
Submission
Extended Address Information Element• Added to Association-Response, Reassociation-
Request and Reassociation-Response messages• Multiple Extended Address Information Elements can
be included if the AP has multiple addresses (IPv4, IPv6, etc.)
• New AP provides address(es) to STA in Association-Response and Reassociation-Response messages
• STA provides new AP with address(es) of old AP in the Reassociation-Request message
• AP uses the address(es) to determine the destination for the Move-Request message sent to the old AP.
September 2001
Tim Moore, Bernard Aboba/Microsoft
doc.: IEEE 802.11-01/553r0
Submission
Extended Address Information Element0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Element ID | Length | Type | Address....+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Address...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
• Element ID: TBD• Length: 7 = IPv4, 19 = IPv6• Type: from “Address Family Numbers” in RFC 1700
– 1 = IPv4– 2 = IPv6
• Address– For Type=1, 32-bit IPv4 address– For Type=2, 128-bit IPv6 address
September 2001
Tim Moore, Bernard Aboba/Microsoft
doc.: IEEE 802.11-01/553r0
Submission
New Status Codes
Status code Meaning
TBD Reassociation-Request denied due to failed
authenticator
TBD Reassociation-Response denied
due to failed authenticator
TBD Disassociation denied due to
failed authenticator
September 2001
Tim Moore, Bernard Aboba/Microsoft
doc.: IEEE 802.11-01/553r0
Submission
Motion
• To amend the TGi draft to include text detailing usage of the Extended Address and Authenticator Information Elements.
September 2001
Tim Moore, Bernard Aboba/Microsoft
doc.: IEEE 802.11-01/553r0
Submission
Feedback?