Authenticated Fast Handoff

1
Authenticated Fast Handoff

• IEEE 802.11 Tgi
• Tim Moore
• Bernard Aboba
• Microsoft

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

3
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

4
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

5
Security improvements
6
Classic 802.11 State Machine
State 1Unauthenticated, Unassociated
Class 1 Frames
DeAuthentication Notification
Successful MAC layer Authentication
State 2Authenticated, Unassociated
Class 1 2 Frames
Deauthentication notification
Successful Association or Reassociation
Disassociation Notification
State 3Authenticated, and Associated
Class 1, 2 3 Frames
7
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-Reques
  t/Response, Disassociation notification are
  unauthenticated
• Enables an attacker to forge these and other
  management frames, take over sessions

8
802.11 Classic Fast Handoff
STA
APold
APnew
Associate-Request
Associate-Response
ACK
DS Notified
Reassociate-Request
Reassociate-Response
Disassociate
ACK
Transition Period OTTSTA-AP
DS Notified
Note Authentication not on critical path, so not
included
9
802.11i State Machine
Class 1 Frames ESN Class 2 frames
State 1Unauthenticated, Unassociated
ESN Association or Reassociation
Deauthentication notification
ESN Disassociation Notification
Successful MAC layer Authentication
State 4ESN Associated
DeAuthentication Notification
State 2Authenticated, Unassociated
Class 1 2 Frames
Class 1, 2 3 Frames except Authentication
Deauthentication
Successful Association or Reassociation
Disassociation Notification
State 3Authenticated, and Associated
Class 1, 2 3 Frames
10
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

11
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

12
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/Res
  ponse, 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

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

14
802.11i Fast Handoff
STA
APold
APnew
Associate-Request
Associate-Response
ACK
DS Notified
802.1X/Identity Request
Transition Period nRTTSTA-AP
802.1X/Identity Response
n 3.5 (TLS), 2.5 (TLS continuation)
EAP-Request
EAP-Response
Reassociate-Request (Authenticated)
Reassociate-Response (Authenticated)
Disassociate (Authenticated)
ACK
EAP-Success
Transition Period RTTSTA-AP
DS Notified
15
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, 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)

16
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 Algorithm1, 128-bit HMAC-MD5(STA MAC address
  AP MAC address Timestamp, key)
• Authentication key session key used to
  authenticate the EAPOL-Key message

17
Deployability improvements
18
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

19
Alternate Solutions to the Registration Problem

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

20
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

21
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

22
Extended Address Information Element

• Added to Association-Response, Reassociation-Reque
  st 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.

23
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 Type1, 32-bit IPv4 address
• For Type2, 128-bit IPv6 address

24
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

25
Motion

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

26
Feedback?