1. TAP (Transition Acceleration Protocol)
October 2004
TAP (Transition Acceleration Protocol)
Dorothy Stanley, Agere
Pat Calhoun, Bob O’Hara, Airespace Inc.
Kevin Hayes, Matt Smith, Atheros
Henry Ptasinski, Broadcom
Paul Funk, Funk Software
Jon Edney, InTalk2K
Stefano Faccin, Nokia
Haixiang He, Nortel Networks
Keith Amann, Spectralink
Contact
Calhoun et al.

2. Introducing TAP TAP Goals TAP Status Speed the transition between APs.
October 2004
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.
TAP Status
A number of companies are participating in the design.
A variety of architectures and applications are represented.
The TAP working document is already quite extensive.
Work is continuing apace to complete it for submission.
Calhoun et al.

3. What is being optimized?
October 2004
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?
October 2004
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 Auth. Frames prior to association, rather than in 4-way handshake.
Station can pre-key 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
October 2004
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.
May be a collection of switch/concentrators.
May be a collection of APs.
May be a collection of AP groups, each with its own “master” AP.
Calhoun et al.

6. Key Circle Identification
October 2004
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:
October 2004
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. October 2004
New Key Hierarchy
Calhoun et al.

9. DA-PMK = PRF-256(D-PMK, "DA-PMK", SPA || BSSID)
October 2004
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
October 2004
Distribution of Derived PMKs
Calhoun et al.

11. October 2004
Case 1: Standalone APs
Calhoun et al.

12. Case 2: Concentrator with Authenticator APs
October 2004
Case 2: Concentrator with Authenticator APs
Calhoun et al.

13. Case 3: Concentrator with Radios
October 2004
Case 3: Concentrator with Radios
Calhoun et al.

14. October 2004
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
October 2004
TAP PMKSA
PMK
PMK Type - PMK, D-PMK, DA-PMK
Original KCID
BSSID (If DA-PMK)
STA MAC Address
Expiration Time
Resource Context
Concurrent Resource Counter
Calhoun et al.

16. Pre-Keying Overview Station initiates pre-keying when:
October 2004
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.
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. TAP Exchange (Request)
October 2004
TAP Exchange (Request)
Request Phase
Sent in AUTH messages
STA sends SNonce in Pre-Key Initiation Request (PIQ)
Includes list of required (or desired) resources
AP can optionally send Pre-Key Initiation Response (PIS) with “Not Ready”
Min ms before STA should retry
Max ms before association must occur (clear state)
Otherwise, AP sends PIS ANonce
STA may optionally return to old AP for service
Both AP and STA must pre-compute PTK
Calhoun et al.

18. Pre-Key Exchange (Request)
October 2004
Pre-Key Exchange (Request)
Client
Authenticator AP
Supplicant
STA derives DA-PMK
STA forms resource list (RIC)
AUTH( PIQ( KCID, PMKID, SNonce ), RIC ))
AP fails to find STA state
AUTH( Error=Not Ready, ComeBackTime, maxTime )
AP identifies resources
Checks with original AP
Enables the AP to inform STA to come back later while it
fetches state information from old AP
Calhoun et al.

19. Pre-Key Exchange (Reissued Request)
October 2004
Pre-Key Exchange (Reissued Request)
Client
Authenticator AP
Supplicant
STA derives DA-PMK
STA forms resource list (RIC)
AUTH( PIQ( KCID, PMKID, SNonce, Replay Counter ), RIC)
AP Validates PMKID
Ensures resources are available
AUTH( PIS( ANonce, Replay Counter, Auth TAP IE, Auth RSN IE , maxTime ))
Computes PTK based on DA-PMK
Calhoun et al.

20. TAP Exchange (Confirm)
October 2004
TAP Exchange (Confirm)
Confirm Phase
Sent in AUTH messages
STA issues Pre-Key Establishment Request (PEQ)
Includes TAP and RSN IEs
Includes SNonce
Includes list of required (or desired) resources
Authenticates request via WMIC IE
AP Replies with Pre-Key Establishment Response (PES)
Ensures resources are available and tentatively allocates them
Calhoun et al.

21. Pre-Key Exchange (Confirm)
October 2004
Pre-Key Exchange (Confirm)
Client
Authenticator AP
Supplicant
STA optionally moves to old AP for service
STA computes PTK
AUTH( PEQ( SNonce, Replay Counter, Supp TAP IE, Supp RSN IE ), RIC, WMIC )
AP allocates resources tentatively
AUTH( PES( ANonce, Replay Counter, maxTime ), WMIC )
Calhoun et al.

22. TAP Exchange (Commit) Commit Phase Sent in (re)association messages
October 2004
TAP Exchange (Commit)
Commit Phase
Sent in (re)association messages
STA issues Pre-Key Confirmation Request (PCQ)
Includes SNonce, which AP validates
Binds the association to the pre-key transactions
Includes TAP and RSN IEs
Includes list of required (or desired) resources
Includes MIC, which AP validates
AP Replies with Pre-Key Confirmation Response (PCS)
Commits resources
Includes ANonce, which STA validates
Includes current GTK encrypted using AES-KeyWrap
Includes MIC, which station validates
Calhoun et al.

23. Association (Commit) STA optionally moves to old AP for service
October 2004
Association (Commit)
Client
Authenticator AP
Supplicant
STA optionally moves to old AP for service
STA Indicates commitment to AP (decision to roam)
(re)association-request( PCQ( SNonce, Replay Counter ), RIC, WMIC )
AP Commits Resources
AP Encrypts Group Key
(re)association-response( PCS( ANonce, Replay Counter, AES-KeyWrap( GTK )), RIC, WMIC )
Calhoun et al.

24. TAP Signaling 0 - 4 5 6 7 Version Pre-Key Pre-Authentication RIC
October 2004
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)
RIC (Resource Information Container) indicates AP’s ability to pre-allocate resources.
0 - 4 5 6 7
Version
Pre-Key
Pre-Authentication
RIC
TAP Advertisement
Calhoun et al.

25. Alternate Pre-Key Mechanism
October 2004
Alternate Pre-Key Mechanism
A variation of the pre-key mechanism described above is being evaluated.
Saves a pre-key round trip when the AP already has a cached PMKSA.
Has additional cryptographic hygiene:
If a KC or AP reboots or flushes its PMKSA cache, it may need to re-fetch a D-PMK or DA-PMK.
A newly fetched D-PMK or DA-PMK will never be the same as previously fetched one, even for the same original PMKSA.
Calhoun et al.

26. Alternate PMK Derivations
October 2004
Alternate PMK Derivations
When a derived PMK is distributed, the sender incorporates a fresh nonce into the derivation:
D-Nonce is added to D-PMK derivation
D-PMK = PRF-256(PMK, "D-PMK", D-Nonce || SPA || KCID)
DA-Nonce is added to DA-PMK derivation
DA-PMK = PRF-256(D-PMK, "DA-PMK", DA-Nonce || SPA || BSSID)
D-Nonce and DA-Nonce are transmitted with D-PMK and DA-PMK, respectively.
D-Nonce and DA-Nonce are communicated to the station in 4-way handshake and pre-key.
Calhoun et al.

27. Alternate Pre-key Message Flow
October 2004
Alternate Pre-key Message Flow
Calhoun et al.

28. October 2004
Structure of the RIC
Resource Information Container (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. RIC – Simple but flexible
October 2004
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.

30. Resource Information Container IE
October 2004
Resource Information Container IE
Root
Group
Leaf …
Leaf
Group
Leaf
Leaf
EID
Length
RNode Type Mandatory Current Rsv
Type
Index
Payload
Calhoun et al.

31. October 2004
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, More, Current
Calhoun et al.

32. October 2004
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
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. Pre-Key Initiation Request (PIQ)
October 2004
Pre-Key Initiation Request (PIQ)
Selector (4 octet)
Payload Length (2 octets)
Unencrypted IE Offset (2 octets)
Encrypted IE Offset (2 octets)
Status Code (2 octets)
Key Length (2 octets)
Supplicant Replay Code (8 octets)
SNonce (32 octets)
Reserved (16 octets)
Reissue Min Interval (2 octets)
Association Max Interval (2 octets)
Unencrypted IEs (variable)
PMKID, KCID, RIC
Encrypted IE (variable)
NULL
Calhoun et al.

34. Pre-Key Initiation Response (PIS)
October 2004
Pre-Key Initiation Response (PIS)
Selector (4 octet)
Payload Length (2 octets)
Unencrypted IE Offset (2 octets)
Encrypted IE Offset (2 octets)
Status Code (2 octets)
Key Length (2 octets)
Supplicant Replay Code (8 octets)
ANonce (32 octets)
Reserved (16 octets)
Reissue Min Interval (2 octets)
Association Max Interval (2 octets)
Unencrypted IEs (variable)
TAP Advertisement, RSN, RIC
Encrypted IE (variable)
NULL
Calhoun et al.

35. Pre-Key Establishment Request (PEQ)
October 2004
Pre-Key Establishment Request (PEQ)
Selector (4 octet)
Payload Length (2 octets)
Unencrypted IE Offset (2 octets)
Encrypted IE Offset (2 octets)
Status Code (2 octets)
Key Length (2 octets)
Supplicant Replay Code (8 octets)
SNonce (32 octets)
Reserved (16 octets)
Reissue Min Interval (2 octets)
Association Max Interval (2 octets)
Unencrypted IEs (variable)
TAP Advertisement, RSN
Encrypted IE (variable)
NULL
Calhoun et al.

36. Pre-Key Establishment Response (PES)
October 2004
Pre-Key Establishment Response (PES)
Selector (4 octet)
Payload Length (2 octets)
Unencrypted IE Offset (2 octets)
Encrypted IE Offset (2 octets)
Status Code (2 octets)
Key Length (2 octets)
Supplicant Replay Code (8 octets)
ANonce (32 octets)
Reserved (16 octets)
Reissue Min Interval (2 octets)
Association Max Interval (2 octets)
Unencrypted IEs (variable)
RIC
Encrypted IE (variable)
NULL
Calhoun et al.

37. Pre-Key Confirmation Request (PCQ)
October 2004
Pre-Key Confirmation Request (PCQ)
Selector (4 octet)
Payload Length (2 octets)
Unencrypted IE Offset (2 octets)
Encrypted IE Offset (2 octets)
Supplicant Replay Code (8 octets)
SNonce (32 octets)
Reserved (16 octets)
Unencrypted IEs (variable)
NULL
Encrypted IE (variable)
Calhoun et al.

38. Pre-Key Confirmation Response (PCS)
October 2004
Pre-Key Confirmation Response (PCS)
Selector (4 octet)
Payload Length (2 octets)
Unencrypted IE Offset (2 octets)
Encrypted IE Offset (2 octets)
Supplicant Replay Code (8 octets)
Key RSC (8 octets)
Remaining Lifetime (4 octets)
ANonce (32 octets)
Reserved (16 octets)
Reissue Min Interval (2 octets)
Association Max Interval (2 octets)
Unencrypted IEs (variable)
KCID
Encrypted IE (variable)
GTK
Calhoun et al.

39. TAP MIC (PEQ, PES, PCQ,PCS)
October 2004
TAP MIC (PEQ, PES, PCQ,PCS)
MIC (16 Octets)
Calhoun et al.

40. Open Questions Should the “alternate” pre-key protocol be used?
October 2004
Open Questions
Should the “alternate” pre-key protocol be used?
Should a KC be allowed to be a member of multiple EKCs?
Calhoun et al.

41. TAP Benefits Questions? Scalable architecture
October 2004
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.