1. TAP (Transition Acceleration Protocol)
January 2005
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
Calhoun et al.

2. Introducing TAP TAP Goals Status since the last meeting
January 2005
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.

3. What is being optimized?
January 2005
What is being optimized?
Old AP
Station
New AP
Data
Channel switch
Pre-Key Phase
Channel switch
Data
Channel switch
Association Phase
Time from last data packet on old AP
to first data packet on new AP
Data
Follows r scope/definition of transition time
Calhoun et al.

4. What is being introduced?
January 2005
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.

5. Two-Tier PMK Distribution Hierarchy
January 2005
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.

6. Key Circle Identification
January 2005
Key Circle Identification
KCID (variable)
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.

7. PMK Key Hierarchy Two new levels of key hierarchy between PMK and PTK:
January 2005
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.

8. January 2005
New Key Hierarchy
Calhoun et al.

9. DA-PMK = PRF-256(D-PMK, "DA-PMK", SPA || BSSID)
January 2005
Key Hierarchy Details
PMK
D-PMK = PRF-256(PMK, "D-PMK", SPA || KCID)
DA-PMK = PRF-256(D-PMK, "DA-PMK", SPA || BSSID)
PTK
*SPA = STA MAC Address
KCID = Key Circle Identifier
Calhoun et al.

10. Distribution of Derived PMKs
January 2005
Distribution of Derived PMKs
Calhoun et al.

11. January 2005
Case 1: Standalone APs
Calhoun et al.

12. Case 2: Concentrator with Authenticator APs
January 2005
Case 2: Concentrator with Authenticator APs
Authentication Server
Authenticator
Supplicant
Calhoun et al.

13. Case 3: Concentrator with Radios
January 2005
Case 3: Concentrator with Radios
Authentication Server
Authenticator
Supplicant
Calhoun et al.

14. January 2005
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.

15. TAP PMKSA PMK PMK Type (PMK, D-PMK, DA-PMK) Original KCID
January 2005
TAP PMKSA
PMK
PMK Type (PMK, D-PMK, DA-PMK)
Original KCID
BSSID (If DA-PMK)
STA MAC Address
Expiration Time
AAA Authorization Parameters
Resource Context
Concurrent Resource Counter
Calhoun et al.

16. Pre-Keying Overview Station initiates pre-keying when:
January 2005
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.

17. Pre-Key Sequence Overview
January 2005
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.

18. Pre-Key Message Features
January 2005
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.

19. Pre-key Sequence – 2 Round Trips
January 2005
Pre-key Sequence – 2 Round Trips
Calhoun et al.

20. Pre-key Sequence – 3 Round Trips
January 2005
Pre-key Sequence – 3 Round Trips
Calhoun et al.

21. PIQ/PIS (authentication frames)
January 2005
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.

22. PEQ/PES (authentication frames)
January 2005
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
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.

23. PCQ/PCS (association frames)
January 2005
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)
Connection is now open.
Since keys were plumbed prior to association, no packet loss will occur due to race conditions
Calhoun et al.

24. TAP Signaling 0 - 4 5 6 7 8 Version Pre-Key Pre-Authentication EKC RIC
January 2005
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 i 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 i 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.
0 - 4 5 6 7 8
Version
Pre-Key
Pre-Authentication
EKC
RIC
TAP Advertisement
Calhoun et al.

25. Resource pre-allocation
January 2005
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.

26. Options for pre-allocation
January 2005
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.

27. Optional Validation New AP may check with old AP:
January 2005
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.

28. Resource Request Messages
January 2005
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.

29. January 2005
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.

30. RIC – Simple but flexible
January 2005
RIC – Simple but flexible
Single TSPEC
Root
Leaf (TSPEC)
Multiple unordered resource requests
Root
Leaf 1 (req)
Leaf 2 (req)
Leaf 3 (req)
Grouped resource requests
Root
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.

31. Resource Information Container IE
January 2005
Resource Information Container IE
Root
Group
Leaf …
Leaf
Group
Leaf
Leaf
EID
Length
RNode Type | Mandatory | Current / Defer | Reserved
Type / IndexL
IndexH
Payload
Calhoun et al.

32. RIC Node control bits Avoiding resource starvation
January 2005
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.

33. TAP Benefits Questions? Scalable architecture
January 2005
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.
Questions?
Calhoun et al.