Tap transition acceleration protocol
1 / 33

TAP (Transition Acceleration Protocol) - PowerPoint PPT Presentation

  • Uploaded on

TAP (Transition Acceleration Protocol). Dorothy Stanley, Agere Pat Calhoun, Bob O’Hara, Airespace Patrick Mourot, Alcatel Kevin Hayes, Matt Smith, Atheros Theodore Karoubalis, Ioanna Samprakou, Atmel Henry Ptasinski, Broadcom Paul Funk, Funk Software Jon Edney, InTalk2K

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' TAP (Transition Acceleration Protocol)' - glenys

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Tap transition acceleration protocol

TAP(Transition Acceleration Protocol)

Dorothy Stanley, Agere

Pat Calhoun, Bob O’Hara, Airespace

Patrick Mourot, Alcatel

Kevin Hayes, Matt Smith, Atheros

Theodore Karoubalis, Ioanna Samprakou, Atmel

Henry Ptasinski, Broadcom

Paul Funk, Funk Software

Jon Edney, InTalk2K

Joe Kubler, Intermec

James Chen, Peter Loc, Marvell

Stefano Faccin, Nokia

Darwin Engwer, Haixiang He, Nortel Networks

Keith Amann, Chris Durand, Spectralink

Contact e-mail: [email protected]

Calhoun et al.

Introducing tap
Introducing TAP

  • TAP Goals

    • Speed the transition between APs.

    • Minimize packet loss during transitions.

    • Provide for continuity of resources across transitions.

    • Support all AP architectures.

    • Do all this in a scalable and secure manner.

  • Status since the last meeting

    • An improved form of the message flow has been incorporated

    • Resource pre-allocation has been fleshed out.

    • Document is fairly complete.

Calhoun et al.

What is being optimized
What is being optimized?


Old AP

New AP


Channel switch

Pre-Key Phase

Channel switch


Channel switch

Association Phase

Time from last data packet on old AP

to first data packet on new AP


Follows 802.11r scope/definition of transition time

Calhoun et al.

What is being introduced
What is being introduced?

  • Two-tier PMK distribution hierarchy

    • Eliminates need for full authentication at each AP.

    • “Key Circles” and optional “Extended Key Circles” provide high degree of scalability.

    • All known AP architectures are supported.

  • Pre-keying

    • PTK is negotiated in MAC Authentication frames prior to association, rather than in 4-way handshake.

    • Station can perform pre-keying with new AP off channel, while still retaining data connectivity with current AP.

  • Resource pre-allocation

    • Network resources are allocated prior to association.

    • Pre-allocation is simultaneous with pre-keying.

Calhoun et al.

Two tier pmk distribution hierarchy
Two-Tier PMK Distribution Hierarchy

  • Key Circle (KC) – a group of one or more APs sharing a common PMK store (e.g. a common RADIUS client).

    • May be a switch/concentrator serving multiple APs.

    • May be a single AP.

    • May be a group of APs with one “master” AP.

  • Extended Key Circle (EKC) – a group of KCs capable of sharing PMK information.

Calhoun et al.

Key circle identification
Key Circle Identification

  • Each KCID must be globally unique (within KCID namespace)

    • Starts with vendor OUI

    • Remaining vendor defined binary string

    • Could be MAC address

EKCID (variable)

  • Each EKCID must be globally unique (within EKCID namespace)

    • Starts with vendor OUI

    • Remaining vendor defined binary string

    • Could be MAC address

Calhoun et al.

Pmk key hierarchy
PMK Key Hierarchy

  • Two new levels of key hierarchy between PMK and PTK:

    • PMK is acquired via 802.1X or is Pre-Shared Key, as usual.

    • D-PMK (Derived PMK) is derived from PMK.

      • D-PMK may be transmitted by “original” KC to “foreign” KC when station roams between KCs in common EKC.

    • DA-PMK (Derived AP PMK) is derived from D-PMK.

      • DA-PMK may be transmitted by KC to AP when station roams between APs in single KC.

    • PTK is derived from DA-PMK.

  • Cryptographic Separation

    • D-PMK and DA-PMK are always unique to target KC or AP.

    • Station computes D-PMK and DA-PMK using KCID or BSSID.

Calhoun et al.

New key hierarchy
New Key Hierarchy

Calhoun et al.

Key hierarchy details
Key Hierarchy Details


D-PMK = PRF-256(PMK, "D-PMK", SPA || KCID)



*SPA = STA MAC Address

KCID = Key Circle Identifier

Calhoun et al.

Case 1 standalone aps
Case 1: Standalone APs

Calhoun et al.

Case 2 concentrator with authenticator aps
Case 2: Concentrator with Authenticator APs

Authentication Server



Calhoun et al.

Case 3 concentrator with radios
Case 3: Concentrator with Radios

Authentication Server



Calhoun et al.

First association
First Association

  • Station notes TAP advertisement, KCID and EKCID in AP’s beacon/probe response.

  • If no PMKSA exists for KCID or EKCID:

    • Station associates normally, adding its own TAP advertisement to association request.

    • During 4-way handshake:

      • AP confirms TAP association.

      • AP sends lifetime of PMK to station.

    • Station creates new TAP PMKSA, including:

      • Lifetime, to determine how long the new PMK can be used.

      • KCID, to determine with whom the new PMK can be used.

Calhoun et al.

Tap pmksa

Calhoun et al.

Pre keying overview
Pre-Keying Overview

  • Station initiates pre-keying when:

    • PMKSA exists with the AP’s KC, or

    • PMKSA exists with the EKC of which the AP’s KC is a member.

  • The PTK is established prior to association, in AUTH frames.

    • Keys are plumbed prior to association, avoiding race conditions

  • Message Flow

    • Pre-keying is driven by station.

    • If AP cannot respond immediately, it asks station to reissue request after time interval.

    • Station may return to original channel between pre-key exchanges to avoid packet loss.

  • Cryptographic properties

    • Association is cryptographically bound to AUTH frames by PTK.

    • All messages are bound by common nonces, for some DoS protection.

    • AP sets time limit on completion of association.

    • Similar to 4-way handshake, except driven by station.

Calhoun et al.

Pre key sequence overview
Pre-Key Sequence Overview

  • Pre-Key Message Types

    • Pre-Key Initiation Request/Response (PIQ/PIS)

    • Pre-Key Establishment Request/Response (PEQ/PES)

      • Only required if PIS returned “Not Ready”

    • Pre-Key Confirmation Request/Response (PCQ/PCS)

  • PIQ/PIS and PEQ/PES messages are sent in authentication frames

  • PCQ/PCS are sent in association frames

Calhoun et al.

Pre key message features
Pre-Key Message Features

  • Cryptographic features

    • STA always includes SNonce in its requests

    • AP always includes ANonce in its response

    • Replay counter counters replays

    • All exchanged information is confirmed by MIC

  • Timing

    • STA initiates each request/response exchange

    • AP indicates its own timing parameters in response:

      • Minimum time before STA should issue next request

      • Maximum time allowed for association to complete (or AP may abandon state)

    • STA may use interval between exchanges to return to old AP for service

  • Status code in response may indicate “Not Ready”, allowing STA to retry if AP needs more time to satisfy request

  • Resource negotiation occurs within pre-key exchange

Calhoun et al.

Piq pis authentication frames
PIQ/PIS (authentication frames)

  • STA sends PIQ, which includes:

    • PMKID

    • TAP Capabilities, KCID and RSN IEs

    • Resource request

  • AP replies with PIS

    • If AP has PMK and can immediately allocate resources, it computes PTK and returns Status = “Success”; PIS includes:

      • Resource reply

      • PIQ-MIC (to confirm PIQ was not tampered with)

      • MIC

    • Otherwise, PIS returns Status = “Not Ready”, with no MIC

      • STA must issue PEQ prior to (re)association

  • Upon receipt of PIS, STA:

    • May return to old AP for service

    • Computes PTK prior to issuing next request

Calhoun et al.

Peq pes authentication frames
PEQ/PES (authentication frames)

  • This exchange only occurs if AP returned “Not Ready” in PIS

  • STA sends PEQ, which includes:

    • PMKID

    • TAP Capabilities, KCID and RSN IEs

    • Resource request

    • MIC

  • AP replies with PES

    • If AP now has PMK and has allocated resources, it computes PTK and returns Status = “Success”; PES includes:

      • Resource reply

      • MIC

    • Otherwise, AP returns Status = “Not Ready”, with no MIC

      • STA must reissue PEQ again later

  • Upon receipt of PES, STA may return to old AP for service

Calhoun et al.

Pcq pcs association frames
PCQ/PCS (association frames)

  • Both STA and AP plumb keys prior to association

  • STA sends PCQ, which includes:

    • MIC

  • AP replies with PCS, which includes:

    • Resource reply (if not sent previously)

    • MIC

  • Connection is now open.

    • Since keys were plumbed prior to association, no packet loss will occur due to race conditions

Calhoun et al.

Tap signaling
TAP Signaling

  • AP advertises TAP support in beacon/probe response

  • Station requests TAP features in initial association request

  • Lack of advertisement or version support defaults to existing 802.11i behavior

  • Feature bits:

    • Pre-key indicates TAP pre-key support

    • Pre-authentication indicates AP’s support of pre-authentication, when TAP PMKSA not available (overrides 802.11i pre-authentication bit)

    • EKC indicates AP is a member of an Extended Key Circle

    • RIC (Resource Information Container) indicates AP’s ability to pre-allocate resources.

TAP Advertisement

Calhoun et al.

Resource pre allocation
Resource pre-allocation

  • TAP has an integrated method to allow stations to request resource allocation prior to a transition (e.g. TSPECs)

  • The approach is highly flexible allowing different policies to be implemented according to concerns about resource management

Calhoun et al.

Options for pre allocation
Options for pre-allocation

1. No pre-allocation - mechanism is optional

2. AP allocates resources immediately based on unauthenticated request

3. AP requires authenticated request before allocation

4. Station gives AP option to defer allocation to association time to minimize resource starvation.

Calhoun et al.

Optional validation
Optional Validation

  • New AP may check with old AP:

    • Whether the station already has these resources allocated at the old AP (i.e. it is a transfer or resources)

    • How many pre-allocations the station has already requested (old AP acts as arbiter based on notifications from potential new APs)

Calhoun et al.

Resource request messages
Resource Request Messages

  • Requests and responses are embedded in pre-key messages using a Resource Information Container (RIC)

  • RIC Design goals:

    • Flexible for use with range of resources

    • Ability to define groups of resources

    • Allow STA to indicate which groups are “must have”

    • Provide referral to current AP for state confirmation

    • Allow resources to be referenced by index after initial request

Calhoun et al.

Details of ric nodes
Details of RIC nodes

RIC is formed as a sequence of IEs of identical format:

  • Root node (one only):

    • Indicates number of nodes

    • Contains reference information for old AP

  • Group Node

    • Indicates high and low index numbers for a group of leaf nodes

  • Leaf Node

    • Contains one resource description (e.g. TSPEC)

All nodes contain control bits: Mandatory, Current/Defer

Calhoun et al.

Ric simple but flexible
RIC – Simple but flexible

Single TSPEC


Leaf (TSPEC)

Multiple unordered resource requests


Leaf 1 (req)

Leaf 2 (req)

Leaf 3 (req)

Grouped resource requests


Group 1-3

Leaf 1

Leaf 2

Leaf 3

Leaf 4

e.g. Resources in leaf 1,2 & 3 must be allocated together

Calhoun et al.

Resource information container ie
Resource Information Container IE








Calhoun et al.

Ric node control bits
RIC Node control bits

  • Mandatory: If set all resources in the group must be allocated or request is rejected

    • Avoids wasted time by AP if first resources unavailable

  • Defer: In root node, indicates that AP may defer allocation of resources till association (may save a round trip).

  • Current: STA claims to have the resource allocated with the current AP (prior to transition.) New AP may elect to verify.

  • Avoiding resource starvation

    • New AP can require that only “current” resources are pre-reserved

    • Old AP / KC can count number of pre-allocation currently in use by STA and new AP can check. New AP policy may limit concurrent pre-allocations

Calhoun et al.

Tap benefits
TAP Benefits

  • Scalable architecture

    • Two-tier hierarchy assures wide coverage

    • All AP architectures are supported

  • Accelerated Transition

    • Eliminates 802.1X and 4-way handshake on (re)association

    • PTK is established prior to (re)association

    • Keys for data connection are ready to use immediately upon (re)association

    • QoS resources are established prior to (re)association

    • Minimizes packet loss

  • Station-friendly architecture

    • STA drives pre-key process at its own pace

    • Pre-key process minimizes off-channel time

    • Crypto computations are performed between pre-key messages, while servicing data connection

    • Low powered devices are not disadvantaged

    • STA can accurately predict if pre-keying will succeed, based on communicated PMKSA lifetime

  • Secure architecture

    • Cryptographic separation of derived PMKs (no PMK sharing between APs)

    • Association messages are MIC’d

    • Nonces ensure key liveness

    • Provides general framework for authenticated mgmt frames.


Calhoun et al.