TAP (Transition Acceleration Protocol)

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

13. Case 3: Concentrator with Radios 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. • 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) • Request Phase • Sent in 802.11 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 • Max ms before association must occur (clear state) • STA may optionally return to old AP for service • Both AP and STA must pre-compute PTK Calhoun et al.

18. AP Authenticator Pre-Key Exchange (Request) Client 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. AP Authenticator Pre-Key Exchange (Reissued Request) Client 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) • Confirm Phase • Sent in 802.11 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 • Includes SNonce Calhoun et al.

21. AP Authenticator Pre-Key Exchange (Confirm) Client 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 • 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 • Binds the association to the pre-key transactions • Includes current GTK encrypted using AES-KeyWrap • Includes MIC, which station validates Calhoun et al.

23. AP Authenticator Association (Commit) Client 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 • 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) • RIC (Resource Information Container) indicates AP’s ability to pre-allocate resources. TAP Advertisement Calhoun et al.

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

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

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

34. Pre-Key Initiation Response (PIS) Calhoun et al.

35. Pre-Key Establishment Request (PEQ) Calhoun et al.

36. Pre-Key Establishment Response (PES) Calhoun et al.

37. Pre-Key Confirmation Request (PCQ) Calhoun et al.

38. Pre-Key Confirmation Response (PCS) Calhoun et al.

39. TAP MIC (PEQ, PES, PCQ,PCS) Calhoun et al.

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