November 2001

doc.: IEEE 802.11-01/TBD

Authenticated Fast Handoff

IEEE 802.11 Tgi Tim Moore Bernard Aboba Microsoft

Submission

Tim Moore, Bernard Aboba/Microsoft

November 2001

doc.: IEEE 802.11-01/TBD

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). Submission Tim Moore, Bernard Aboba/Microsoft

November 2001

doc.: IEEE 802.11-01/TBD

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
Submission Tim Moore, Bernard Aboba/Microsoft

November 2001

doc.: IEEE 802.11-01/TBD

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
Submission Tim Moore, Bernard Aboba/Microsoft

November 2001

doc.: IEEE 802.11-01/TBD

Security improvements

Submission

Tim Moore, Bernard Aboba/Microsoft

November 2001

doc.: IEEE 802.11-01/TBD

Classic 802.11 State Machine

State 1 Unauthenticated, Unassociated Class 1 Frames

Successful MAC layer Authentication State 2 Authenticated, Unassociated Successful Association or Reassociation State 3 Authenticated, and Associated
Submission

DeAuthentication Notification

Deauthentication notification

Class 1 & 2 Frames

Disassociation Notification Class 1, 2 & 3 Frames

Tim Moore, Bernard Aboba/Microsoft

November 2001

doc.: IEEE 802.11-01/TBD

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
Submission Tim Moore, Bernard Aboba/Microsoft

November 2001

doc.: IEEE 802.11-01/TBD

802.11 Classic Fast Handoff

APold STA
Associate-Request Associate-Response ACK DS Notified Disassociate Transition Period

APnew

Reassociate-Request
Reassociate-Response ACK

~ OTTSTA-AP

DS Notified

Note: Authentication not on critical path, so not included

Submission Tim Moore, Bernard Aboba/Microsoft

November 2001

doc.: IEEE 802.11-01/TBD

802.11i State Machine

Deauthentication notification
Successful MAC layer Authentication

State 1 Unauthenticated , Unassociated

Class 1 Frames + ESN Class 2 frames

ESN Association or Reassociation

ESN Disassociation Notification

DeAuthentication Notification
State 2 Authenticated, Unassociated
Class 1 & 2 Frames

State 4 ESN Associated

Class 1, 2 & 3 Frames except Authentication & Deauthentication

Successful Association or Reassociation

Disassociation Notification
State 3 Authenticated, and Associated Class 1, 2 & 3 Frames
Tim Moore, Bernard Aboba/Microsoft

Submission

November 2001

doc.: IEEE 802.11-01/TBD

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
Submission Tim Moore, Bernard Aboba/Microsoft

November 2001

doc.: IEEE 802.11-01/TBD

Questions
Should authentication occur before or after reassociation? How do we authenticate management frames?
This presentation addresses ReassociationRequest/Response, and Disassociation Notification frames Future work will address authentication of other Management Frames
Association-Request/Response, Beacon, ProbeRequest/Response, Deauthentication, ATIM

Submission

Tim Moore, Bernard Aboba/Microsoft

November 2001

doc.: IEEE 802.11-01/TBD

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 youre 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
Submission Tim Moore, Bernard Aboba/Microsoft

November 2001

doc.: IEEE 802.11-01/TBD

Proposed Approach
Authentication of Reassociate, Disassociate frames
Authenticator Information Element added to ReassociationRequest/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.

Submission

Tim Moore, Bernard Aboba/Microsoft

November 2001

doc.: IEEE 802.11-01/TBD

802.11i Fast Handoff

APold
Associate-Request
Associate-Response ACK
DS Notified

STA

APnew

802.1X/Identity Request Transition Period 802.1X/Identity Response EAP-Request EAP-Response

~ nRTTSTA-AP

n =3.5 (TLS), 2.5 (TLS continuation)

Reassociate-Request (Authenticated) Reassociate-Response (Authenticated) ACK EAP-Success
DS Notified

Disassociate (Authenticated) Transition Period

Submission

~ RTTSTA-AP

Tim Moore, Bernard Aboba/Microsoft

November 2001

doc.: IEEE 802.11-01/TBD

Authenticator Information Element

Assumes that a unicast key is available either for the current AP (Disassociation, ReassociationResponse messages), or with the previous AP (Reassociation-Request message). Authenticator = HMAC-MD5(STA MAC address | AP MAC address | Timestamp, ESSID, 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)
Submission Tim Moore, Bernard Aboba/Microsoft

November 2001

doc.: IEEE 802.11-01/TBD

Authenticator Information Element

0 1 2 3 0 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 | ESSID# | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Element ID: TBD Length: 19 = HMAC-MD5 Algorithm

1 = HMAC-MD5

ESSID#
Number of the ESSID corresponding to this authenticator (for shared use APs)

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

Submission Tim Moore, Bernard Aboba/Microsoft

November 2001

doc.: IEEE 802.11-01/TBD

Deployability improvements

Submission

Tim Moore, Bernard Aboba/Microsoft

November 2001

doc.: IEEE 802.11-01/TBD

The Registration Problem

New AP contacts the old AP via IAPP to validate the reauthenticationrequest, 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/reassociates 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

Submission

Tim Moore, Bernard Aboba/Microsoft

November 2001

doc.: IEEE 802.11-01/TBD

Alternate Solutions to the Registration Problem

1. 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) Authentication server knows where APs are, but AAA protocols werent designed to solve this problem

2. 3.

AAA protocols

Registration Service (whats 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 IP address(es) of new AP provided to STA in association-response, reassociationresponse STA provides IP address(es) of old AP to new AP in reassociation-request
Eliminates need for registration service (and resulting deployment problems)
Tim Moore, Bernard Aboba/Microsoft

4.

Include AP IP address(es) in management messages

Recommendation: Choice 4

Submission

November 2001

doc.: IEEE 802.11-01/TBD

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
Submission Tim Moore, Bernard Aboba/Microsoft

November 2001

doc.: IEEE 802.11-01/TBD

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 (its 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
Submission Tim Moore, Bernard Aboba/Microsoft

November 2001

doc.: IEEE 802.11-01/TBD

Extended Address Information Element

Added to Association-Response, ReassociationRequest 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 AssociationResponse 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.

Submission

Tim Moore, Bernard Aboba/Microsoft

November 2001

doc.: IEEE 802.11-01/TBD

Extended Address Information Element

0 1 2 3 0 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

Submission

Tim Moore, Bernard Aboba/Microsoft

November 2001

doc.: IEEE 802.11-01/TBD

New Status Codes

Status code
TBD TBD TBD

Meaning
Reassociation-Request denied due to failed authenticator Reassociation-Response denied due to failed authenticator Disassociation denied due to failed authenticator

Submission

Tim Moore, Bernard Aboba/Microsoft

November 2001

doc.: IEEE 802.11-01/TBD

Motion
To amend the TGi draft to include text detailing usage of the Extended Address and Authenticator Information Elements.

Submission

Tim Moore, Bernard Aboba/Microsoft

November 2001

doc.: IEEE 802.11-01/TBD

Feedback?

Submission

Tim Moore, Bernard Aboba/Microsoft