TAP (Transition Acceleration Protocol)

1. 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: pcalhoun@airespace.com Calhoun et al.

2. 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? Station Old AP 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 802.11r scope/definition of transition time Calhoun et al.

4. 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 • 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 • 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: • 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. New Key Hierarchy Calhoun et al.

9. 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 Calhoun et al.

11. Case 1: Standalone APs Calhoun et al.

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

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

14. 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 Calhoun et al.

16. 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 • 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 • 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 Calhoun et al.

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

21. 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) • 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.

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

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

25. 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 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: • 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 • 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. 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 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 Root Group Leaf … Leaf Group Leaf Leaf Calhoun et al.

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