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

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.

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

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.

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.

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.

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.

October 2004 New Key Hierarchy Calhoun et al.

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.

Distribution of Derived PMKs October 2004 Distribution of Derived PMKs Calhoun et al.

October 2004 Case 1: Standalone APs Calhoun et al.

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

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

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.

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.

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.

TAP Exchange (Request) October 2004 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 STA may optionally return to old AP for service Both AP and STA must pre-compute PTK Calhoun et al.

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.

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.

TAP Exchange (Confirm) October 2004 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 Calhoun et al.

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.

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.

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.

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 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. 0 - 4 5 6 7 Version Pre-Key Pre-Authentication RIC TAP Advertisement Calhoun et al.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.