1. TAP & JIT Merged Proposal Summary
Month Year
doc.: IEEE yy/xxxxr0
May 2005
TAP & JIT Merged Proposal Summary
Date: May 2005
Authors:
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget
John Doe, Some Company

2. May 2005
Introduction
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

3. Proposal Goals Minimize the transition critical path time.
May 2005
Proposal Goals
Minimize the transition critical path time.
Enable different deployment, usage, and traffic scenarios
Minimize PTK computation and plumbing latencies by enabling the STA to pre-compute prior to re-association
Enable an “Authenticated” re-association exchange
Removes the i 4-way handshake race conditions
Enables allocation of QoS resources at re-association time
Ensure compatibility with non-RSN and non-QoS STA’s and AP’s
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

4. May 2005
Proposal Features
Minimize PTK computation and plumbing latencies by enabling the STA to pre-compute prior to re-association
Enable an “Authenticated” re-association exchange
Removes the i 4-way handshake race conditions
Enables allocation of QoS resources prior to or during re-association time
Ensure compatibility with non-RSN and non-QoS STA’s and AP’s
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

5. Solution Components A new IEEE 802.11r protocol which :
May 2005
Solution Components
A new IEEE r protocol which :
Introduces a transition-enabled capability exchange;
Allows STA and AP to allocate resources prior to or at re-association.
A mechanism for activating resources at re-association time using a modified re-association exchange.
A resource reservation mechanism which:
Is generic to any type of resource (QoS, Security, etc…);
Will work over the air or over the DS to the target AP;
Allows the STA to request resource allocation alternatives.
A new key management framework which allows the STA and the AP to establish an unique PMKSA;
A mechanism which uses the new roaming protocol to perform PTK derivation at or prior to re-association;
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

6. Representative Topology
May 2005
Representative Topology
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

7. May 2005
Mobility Domain
ESS
Security Domain
Mobility Domain
Mobility domain defines the bounds for transition for a STA. Guarantees reachability over the DS.
Mobility domain and the Security domain are the same by default.
Mobility domain could be advertised as a subset of the security domain.
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

8. Communications Prior to Re-association
May 2005
Communications Prior to Re-association
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

9. May 2005
Resource Request SAP
The Resource Request SAP has three principal functions:
Provides a mechanism for a STA to generate a Resource Request frame;
Provides a mechanism for an AP to process a Resource Request;
Provides a mechanism for an AP to forward a Resource Request to another AP over the DS.
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

10. May 2005
Broker Function
The Broker Function provides a mechanism to enforce forwarding policy at an AP through the Resource Request SAP
The Broker function allows the AP to:
Process and apply policy to a Resource Request Action frame
Limit the number of Resource Requests from a STA.
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

11. Resource Request Mechanism Over the Air
May 2005
Resource Request Mechanism Over the Air
Broker
Function
STA goes off channel to issue Resource Request. Resource Request can contain any type of resource.
RRSAP
Current AP
RRSAP
STA
RRSAP
Target AP
Target AP replies with response to STA.
Target AP RRSAP interacts with other AP components to process Resource Request.
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

12. Resource Request Mechanism Over the DS
May 2005
Resource Request Mechanism Over the DS
Broker
Function
Broker function can apply forwarding policy to the Resource Request
STA issues a Resource Request to the current AP with the BSSID of the target AP in the payload.
RRSAP
Current AP forwards the Resource Request to the Target AP over the DS.
Current AP
RRSAP
STA
RRSAP
Target AP
Target AP RRSAP interacts with other AP components to process Resource Request.
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

13. TAP-JIT Protocol Description
May 2005
TAP-JIT Protocol Description
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

14. TAP-JIT Mechanisms Base Mechanism Pre-Reservation schemes
May 2005
TAP-JIT Mechanisms
Base Mechanism
TSTA Transitions without pre-reservation
Pre-Reservation schemes
TSTA performs pre-reservation before re-associating with a TTAP
Over the Air
TSTA makes a pre-reservation of resources directly with TTAP
Over the Wire
TSTA makes a pre-reservation of resources at TTAP, through its existing AP
A new Action Frame: Fast BSS Transition (FBT)
Common Frame format for both cases
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

15. TAP-JIT Reservation Policy
May 2005
TAP-JIT Reservation Policy
Network resources are valuable resources
Network resource policy enforced via:
Fast Transition Resource IE (TRIE)
Specifies the maximum number of APs with which a TSTA can pre-reserve resources
Time Interval IE – Reservation Limit
Specifies a time (Milliseconds) within which a TSTA must perform re-association to claim pre-reserved resources
Resource policy can be statically or dynamically established on the network
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

16. Fast Transition Resource IE (TRIE)
May 2005
Fast Transition Resource IE (TRIE)
Byte 0
Bit 0: Reservation over air
AP supports Reservation over air, which is protected using a separate handshake protocol.
Bit 1: Reservation over DS
AP supports Reservation over DS
Bit 2: Reserve Option
Value 1: Reservation is Mandatory
Value 0: Reservation is Optional
Bit 3-6: Reservation Limit
Number of APs at which a STA can reserve
Bit 7: Reserved
Byte 1-16
Resource Mobility Domain for inter AP communication over DS
Advertised in Beacons and probe responses
Enforced at the current AP, TTAP, or controller
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

17. Time Interval IE A new generic Time Interval IE is introduced
May 2005
Time Interval IE
Order
Size (octets)
Description 1
TBD Element ID: Return Interval IE 2
IE length 3
Type of Time interval and timeout 4
Unsigned 16-bit integer representing the number of TUs (milliseconds).
A new generic Time Interval IE is introduced
The “type” indicates the use of this IE
For pre-reservations: Re-association timeout
Time Interval is included in FBT Action Frames, used for pre-reservations
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

18. MLME-SAP Interfaces MLME-Reservation - New
May 2005
MLME-SAP Interfaces
MLME-Reservation - New
Enact security and QoS reservation method with MAC peers
MLME-Reservation.request
MLME-Reservation.indicate
MLME-Reservation.response
MLME-Reservation.confirm
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

19. MLME-SAP Interfaces MLME-Reassociate – Updated Nonces TRIE TSIE
May 2005
MLME-SAP Interfaces
MLME-Reassociate – Updated
Nonces
TRIE
TSIE
Reservation Responses
Key Lifetimes
Reassociation deadline
MIC
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

20. May 2005
Scalability
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

21. JIT-TAP Merged Key Hierarchies
May 2005
JIT-TAP Merged Key Hierarchies
Scalability of architectures, deployments, infrastructures
R0 Key Holder
(PMK-R0)
R1 Key Holder
(PMK-R1)
R2 Key Holder
(PMK-R2)
Merged 3-Level Key Hierarchy
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

22. Key Hierarchy Scalability
May 2005
Key Hierarchy Scalability
Traditional AP
Controller AP
Multi-Layer Switched AP
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

23. Fast Transition Security IE (TSIE)
May 2005
Fast Transition Security IE (TSIE)
Byte 1-15
Security Mobility Domain Identifier (SMD-ID)
Byte 16-31
Key R0 Key Holder ID (R0KH-ID)
Byte 32-47
Key R1 Key Holder ID (R1KH-ID)
Byte 48-63
Key R2 Key Holder ID (R2KH-ID)
Advertised in probe responses
Advertises the listing of the key holders
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

24. Key Holder IE Advertised in probe responses
May 2005
Key Holder IE
Byte n
RO Holder List
Byte n-p
RO List (p=2 to k)
Advertised in probe responses
Advertises multiple key holder hierarchies
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

25. Scalability Across Deployments
May 2005
Scalability Across Deployments
Mechanisms/
Deployment
Base
Pre-reserve over Air
Pre-reserve over Wire
Enterprise
Operator
SOHO
Home
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

26. Re-Association Request Message
May 2005
Re-Association Request Message
Order
Information
Notes 1
Capability
As defined by standard 2
Listen Interval 3
Current AP address 4
SSID 5
Supported Rates 6
Extended Supported Rates 7
Power Capability 8
Supported Channels 9
IE Count
Specifies the number of IEs succeeding this IE and if present, protected by the EAPKIE 10
TRIE
A Fast Transition Resource IE to convey the Fast Transition resource capabilities. 11
TSIE
A Fast Transition Security IE to convey the Fast Transition security capabilities. 12
RIC Request IEs
The set of IEs that formulate a RIC request, for requesting QoS resources …
Other IEs that may require protection
13 + n +1
EAPKIE
An IE encapsulating EAPOL Key-Message to include the required information for a Fast Transition
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

27. Re-Association Response Message
May 2005
Re-Association Response Message
Order
Information
Notes 1
Capability
As defined by standard 2
Listen Interval 3
Current AP address 4
SSID 5
Supported Rates 6
Extended Supported Rates 7
Power Capability 8
Supported Channels 9
IE Count
Specifies the number of IEs succeeding this IE and if present, protected by the EAPKIE 10
TRIE
A Fast Transition Resource IE to convey the Fast Transition resource capabilities. 11
TSIE
A Fast Transition Security IE to convey the Fast Transition security capabilities. 12
RIC Request IEs
The set of IEs that formulate a RIC request, for requesting QoS resources …
Other IEs that may require protection
13 + n +1
EAPKIE
An IE encapsulating EAPOL Key-Message to include the required information for a Fast Transition
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

28. Resource Allocation May 2005
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

29. QoS allocation - why needed?
May 2005
QoS allocation - why needed?
Station may have established streams
Viable transition targets are only those that can support active streams.
A change in stream parameters might be acceptable during the transition
Failure of new AP to allocate QoS resources rapidly may cause loss of stream and broken session
QoS allocation options:
None (no streams required)
pre-reservation: establish QoS resources prior to and attempted transition
Just in time: establish QoS resources during transition
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

30. Phases of allocation Two parts to QoS allocation
May 2005
Phases of allocation
Two parts to QoS allocation
“Accepted” state: allocation by the scheduler of target AP
“Active” state: implementation by the MAC (generate TxOP etc)
Pre-reservation affects the scheduler
Target AP must allocate resources in accepted state
Target AP may coordinate with higher level scheduler.
“Query” gives snapshot from scheduler
Association causes reservation to enter “active” state.
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

31. Paths to reservation May 2005 Current AP Target AP STA Channel A
Beacon / probe rsp
802.11k reports
“Over the DS”
“Over the air”
STA
Channel A
Channel B
Depending on policy STA has options on pre-reservation path
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

32. Need to link with Security
May 2005
Need to link with Security
QoS schedule is a valuable resource
Reservations should not be accepted from unauthorized station
Reservation messages should be immune to tampering and replay
Therefore is pre-reservation is required, it must be combined with pre-key operation to enable authentication of the request
Applies to both “over the air” and “over the DS”
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

33. Describing the required resources
May 2005
Describing the required resources
STA must provide list of TSPECs to target AP
There may be multiple traffic streams
STA may provide list of options for each traffic stream to allow target AP to provide “best fit” allocation
For convenience the set of TSPECs is grouped into a structure: The Resource Information Container (RIC)
The RIC is a series of information elements, including TSPECs, sent together as a group in various handshake messages.
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

34. Basic request & response (Base Mechanism)
May 2005
Basic request & response (Base Mechanism)
Resources are requested during re-association AP
STA
Pre-key exchange here
Re-associate Request
RIC RQ
AP must allocate resources quickly
Re-associate Response
RIC RSP
AP responds “Success” after allocation
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

35. Base mechanism: resource not available
May 2005
Base mechanism: resource not available AP
STA
Pre-key exchange here
Re-associate Request
RIC RQ
AP must allocate resources quickly
Re-associate Response
RIC RSP
AP responds “FAIL”
AP may include suggested
TSPECs in RIC RSP
STA MAY REPEAT ATTEMPT WITH NEW RIC PARAMETERS
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

36. Over the Air Reservation (followed by transition)
May 2005
Over the Air Reservation (followed by transition)
Resources are requested prior to re-association
Pre-key exchange here AP
STA
Sent in MAC
Auth frames
RIC RQ
AP allocates resources
RIC RSP
Re-associate Request
RIC RQ
Re-associate Response
RIC RSP
AP responds “Success”
after commitment
RIC here can just confirm reservation
or it can include changes
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

37. Over the DS Reservation (followed by transition)
May 2005
Over the DS Reservation (followed by transition)
Resources are requested prior to re-association through current AP AP
(cur)
Pre-key exchange here
with new AP
STA
Sent in
Action
frames
RIC RQ
new AP allocates resources
RIC RSP
Re-associate Request AP
(new)
RIC RQ
Re-associate Response
RIC RSP
RIC here can just confirm reservation
or it can include changes
AP responds “Success”
after commitment
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

38. Structure of RIC Request
May 2005
Structure of RIC Request
ROOT
Resource Rq
Resource Rq
optional
RIC DATA
TSPEC
TSPEC
TSPEC
These are choices in order or preference. AP will choose IE
Len
Seq
Ctl
indicates whether resources is required
or optional for successful transition
Identifies R. Rq
by seq num
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

39. Possible RIC Requests May 2005
1) Fully specified: used for initial request in exchange
= new
= confirm
ROOT RD
TSPEC RD
TSPEC
TSPEC
= change
RD = RIC DATA IE
2) Confirmation: used to confirm previously reserved resources at re-association
ROOT RD RD
2) Part specified: used to confirm and change/add others at re-association
ROOT RD
TSPEC RD RD
TSPEC
changed value
confirmed value
addition over reservation
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

40. Structure of RIC Response
May 2005
Structure of RIC Response
1) Simple success: confirmation of allocated resources
ROOT RD RD
2) Simple failure: indicates which resources could not be allocated
ROOT RD RD
3) Failure with suggestion: Suggests values for resources that failed
ROOT RD RD RD
TSPEC RD
= confirm bit set RD
= confirm bit clear
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

41. May 2005
Security
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

42. Key Hierarchy May 2005 NAS (R0-KH) Controller (R1-KH) AP (R2-KH) STA
AAA Server
(AS)
NAS
(R0-KH)
Controller
(R1-KH) AP
(R2-KH)
STA
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

43. Key Hierarchy: Supports multiple topologies
May 2005
Key Hierarchy: Supports multiple topologies
AAA Server
(AS)
NAS
(R0-KH)
NAS
(R0-KH)
NAS
(R0-KH)
Security Mobility Domain
Controller
(R1-KH)
Controller
(R1-KH)
Controller
(R1-KH) AP
(R2-KH) AP
(R2-KH) AP
(R2-KH)
STA
STA
STA
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

44. Keying Hierarchy (cont’d)
May 2005
Keying Hierarchy (cont’d)
AAA Server
(AS)
Security Mobility Domain
MSK
NAS
(R0-KH)
PMK-R1-A
PMK-R1-C
PMK-R1-B
ControllerA
R1-KHA
ControllerB
R1-KHB
ControllerC
R1-KHC
PMK-R2-3
PMK-R2-1
PMK-R2-2
PMK-R2-4
AP1
R2-KH1
AP2
R2-KH2
AP3
R2-KH3
AP4
R2-KH4
PTK-I
PTK-J
PTK-K
PTK-L
STAI
STAJ
STAK
STAL
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

45. May 2005
Keying Hierarchy
R0KH-ID
PMK-R0 = KDF-256 (MSK, “R0 Key Derivation” || SSID || SPA) R0Name = SHA-256(PMK-R0, “R0 Key Name” || SSID|| R0KH-ID || SPA)
PMK-R1 = KDF-256( PMK-R0, “R1 Key Derivation” || R0KH-ID ||
R1KH-ID || SPA)
R1Name = SHA-256( R0Name || R0KH-ID || R1KH-ID || SPA)
R1KH-ID
R2KH-ID
PMK-R2 = KDF-256( PMK-R1, “R2 Key Derivation” || R0KH-ID || R1KH-ID || R2KH-ID || SPA) R2Name = SHA-256( R0-Name || R0KH-ID || R1KH-ID || R2KH-ID || SPA
PTK = KDF-PTKLen(PMK-R2, “PTK Key derivation” || SNonce || ANonce || R0KH-ID || R1KH-ID || R2KH-ID || AA || SPA)
BSSID
&
STA
Key Confirmation Key (KCK) – PTK bits 0–127
Key Encryption Key (KEK) – PTK bits 128–255
TemporalKey – (PTK bits -256) ciphersuite-specific structure
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

46. Key Hierarchy Construction
May 2005
Key Hierarchy Construction
3-level PMK hierarchy to enable multiple network infrastructure topologies
Single Key Hierarchy
Negotiated as new RSNIE AKM
To be reviewed by NIST
Uses new KDF construction to allow for variable length inputs
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

47. KDF May 2005 Output = KDF-Length( K, label, Context) where Input:
K, a 256 bit key derivation key
label, a unique label for each different purpose of the KDF
Context, a bit string that provides context to identify the derived key
Length, the length of the derived key in bits
0x00, a single octet containing the value of zero
Output: a Length-bit derived key
result = “”
iterations = (Length+159)/160
do i = 1 to iterations
result = result || HMAC-SHA1(K, i || Label || 0x00 || Context || Length) od
return first Length bits of result and securely delete all unused bits
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

48. …Putting it all together: Transition Protocol Message Flows
May 2005
…Putting it all together: Transition Protocol Message Flows
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

49. Base Fast BSS Transition
May 2005
Base Fast BSS Transition
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

50. Over the air Reservation and FBT
May 2005
Over the air Reservation and FBT
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

51. Reservation using current BSSID
May 2005
Reservation using current BSSID
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

52. First FBT Association May 2005
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

53. May 2005
Summary
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

54. Fast BSS Transition Summary
May 2005
Fast BSS Transition Summary
Pre-establishment of Resources to minimize setup
Minimize packet exchange by piggybacking QoS reource requests
Use of new Key Hierarchy enables Pre-Keying
Different mechanisms further enable optimizations based on network topologies and usage scenarios:
Base Mechanism is the fallback for when STA must transition or policies inhibit use of reservation mechanism
Reservation Mechanisms decouples resource establishment setup from critical switchover path
Reservation Over the air enables STAs who require reachability
Reservation Over the wire minimizes channel switch
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

55. Fast BSS Transition Summary
May 2005
Fast BSS Transition Summary
Policy mechanisms enable:
Tuning for FBT based on deployment scenarios
Enforcement of reservation limitations
Explicit negotiation of network infrastructure capabilities
3-level PMK Key Hierarchy enables Scalable network architectures to support FBT
Minimize message exchange by piggybacking SNonce and ANonce in new Authentication Algorithm
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget

56. Questions? Comments? May 2005
M. Montemurro, J. Edney, K. Sood, N. Cam-Winget