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

DeAuthentication
Notification

Successful MAC
layer Authentication
State 2
Authenticated,
Unassociated

Deauthentication
notification
Successful
Association or
Reassociation

Class 1 & 2
Frames

Disassociation
Notification
State 3
Authenticated,
and Associated

Submission

Class 1
Frames

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

APnew

Associate-Request
Associate-Response
ACK
DS
Notified

Reassociate-Request
Disassociate

Reassociate-Response
ACK

Transition Period

~ STA-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

State 1
Unauthenticated
, Unassociated

Deauthentication
notification
Successful MAC
layer Authentication

DeAuthentication
Notification

State 4
ESN Associated

Class 1 & 2
Frames

Class 1, 2 & 3
Frames except
Authentication &
Deauthentication

Disassociation
Notification
State 3
Authenticated,
and Associated

Submission

ESN Association or
Reassociation

ESN
Disassociation
Notification

State 2
Authenticated,
Unassociated

Successful
Association or
Reassociation

Class 1 Frames + ESN

Class 2 frames

Class 1, 2 & 3
Frames
Tim Moore, Bernard Aboba/Microsoft

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 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.

Submission

Tim Moore, Bernard Aboba/Microsoft

November 2001

doc.: IEEE 802.11-01/TBD

802.11i Fast Handoff

APold

STA

APnew

Associate-Request
Associate-Response
DS
Notified

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

EAP-Request

Disassociate (Authenticated)
Transition Period
Submission

~ RTTSTA-AP

~ nRTTSTA-AP

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

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

DS
Notified

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

1.

Alternate Solutions to the Registration

Problem
Inverse ARP (RFC 2390)

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

Include AP IP address(es) in management messages

Authentication server knows where APs are, but

AAA protocols werent designed to solve this problem

Registration Service (whats in 802.11 TgF Draft 2)

4.

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)

AAA protocols

3.

doc.: IEEE 802.11-01/TBD

IP address(es) of new AP provided to STA in association-response, reassociation-respons

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)

Submission

Tim Moore, Bernard Aboba/Microsoft

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

Meaning

TBD

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

TBD
TBD

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