July 2005doc.: IEEE 802.11-05/0621r0
IEEE P802.11
Wireless LANs
Date: 2005-06-30
Author(s):
Name / Company / Address / Phone / email
Bill Marshall / TGr Editor / 180 Park Ave, Florham Park, NJ07932 / 973-360-8718 /
Changes to document
Changes of TTAP to TAP, to help them stand out here, are indicated TTAP. Other proposed text changes are likewise highlighted in yellow. Note that numerous sections where “TTAP” appeared are not proposed to be changed, but are still listed here for completeness.
Add to list of acronyms in section 4:
TAPFast BSS Transition Enabled Access Point
Change Section 5.4.5.3 as follows:
This addresses solutions to two classes of network infrastructures from a QoS perspective: one where the TTAP is capable of provisioning QoS resources at re-association time; and another where the TTAP needs to pre-reserve QoS resources prior to reassociation. Thus there are two mechanisms for BSS-Transition:
…
BSS-Transition service provides a generic mechanism to reserve resources at a candidate TTAP called the Resource Information Container (RIC). It provides a mechanism for the STA to build resource requests that could include mandatory and optional resources, or request for alternative resources.
Change Section 7.2.3.6 as follows:
For a Fast BSS Transition, the Reassociation request is used to request or confirm the availability of resources that the STA needs to complete its connection. For a Fast BSS Transition when RSNA is enabled, the TSTA must assert liveness of the PTK by including the ANonce provided by the TTAP, and authenticating the frame by including a valid MIC in the EAPKIE. The MIC shall protect the fields starting with the Count IE up to and including the EAPKIE. The RSN information element in the EAPOL-Key message contained in the EAPKIE must be bitwise identical to the RSN IE presented in the Fast Transition Authentication Request Frame.
Change Section 7.2.3.7 as follows:
For a Fast BSS Transition, the TTAP uses the Reassociation Response frame to respond to the TSTA resource and PTKSA requests. The TTAP will include TRIE, TSIE, RIC IE(s), and EAPKIE in response to the IEs included in the Reassociation request. If RSNA is enabled, the TTAP must assert liveness of the PTK by including the SNonce provided by the TSTA, and authenticate the frame by including a valid MIC in the EAPKIE. The MIC shall protect the fields starting with the Count IE up to and including the EAPKIE. The RSN information element in the EAPOL-Key message contained in the EAPKIE must be bitwise identical to the RSN IE presented in the TTAP Beacon Frame.
Change Section 7.3.2.39 as follows:
The Fast Transition Resource Information Element is defined to enable the advertisement of network infrastructure policy and resource reservation information. This can assist a TSTA in deciding which transition mechanism(s) to use. A TTAP can advertise the TRIE through a Beacon frame and through a Probe Response frame. This information element is defined in Figure 80Y.
Change Section 7.4.3.1 as follows:
The TTAP field shall be set to the BSSID value of the target AP.
Change Section 7.4.3.2 as follows:
The TTAP field shall be set to the BSSID value of the target AP.
…
The RSNIE field is only present when RSN is enabled and shall be set to the RSN Information Element as defined in section 7.3.2.25. When present, the RSN Information Element defines the security policy advertised by the TTAP's beacons. In addition, the TTAP must provide the R2Name used to generate a fresh PTKSA.
Change Section 7.4.3.3 as follows:
The FT Confirm Action frame is used by the TSTA to confirm to the TTAP receipt of the ANonce and to initiate both the liveness of the PTKSA and, if required, to request QoS resources. The FT Confirm action frame body format is as follows:
…
The TTAP field shall be set to the BSSID value of the target AP.
Change Section 7.4.3.4 as follows:
The TTAP field shall be set to the BSSID value of the target AP.
Change Section 8.5A.2 as follows:
4) PTK - the last level of the key hierarchy that defines the 802.11 and 802.1X protection keys. The PTK is mutually derived by the SPA and the TTAP. This key is named by SNonce, ANonce, SPA, and BSSID.
Change Section 8.5A.4 as follows:
The entity that stores this key is typically the NAS that is identified by a 16 octet string referred to as the R0KH-ID. The R0KH-ID must be advertised by the TTAP in the beacons and probe responses.
Change Section 8.5A.5 as follows:
This level enables network topologies where a device is connected to a NAS and to one or many APs, and provides the facility of caching TSTA's keys. The entity that stores this key is identified by a 16 octet string referred to as the R1KH-ID. The R1KH-ID must be advertised by the TTAP in the beacons and probe responses.
Change Section 8.5A.6 as follows:
The entity that stores this key is the TTAP's 802.1X Authenticator and is identified by a 16 octet string referred to as the R2KH-ID. The R2KH-ID must be advertised by the TTAP in the beacons and probe responses.
Change Section 8.5A.8 as follows:
The fourth level of the key hierarchy is the PTK. This key is mutually derived by the SPA and the TTAP with the key length being a function of the negotiated cipher suites as defined by 802.11i. Using the KDF construction defined in Section 8.5A.3, the PTK derivation is as follows:
Change Section 8.5A.9 as follows:
The FT Authentication frame sequence is invoked to initiate a Fast BSS Transition. In a RSNA enabled negotiation, the first two FT Authentication frames are used to allow each TSTA and TTAP to provide their random contributions SNonce and ANonce respectively. These values must be random and are used to generate the PTK. The first two message sequences are used to enable the TTAP to provision the PMK-R2 and for the TSTA and TTAP to compute the PTK. As the PTKSA must be established to protect the resource reservation in a RSNA enabled TSTA, no resources may be requested in the first two FT Authentication frames. If no RSNA is negotiated between the TSTA and TTAP, these first two frames are the equivalent of the Open Authentication sequence.
The third and fourth FT Authentication frames are used to prove liveness of the PTK and to enable authenticated resource reservation. The FT Authentication frame sequence is always initiated by the TSTA and responded by the TTAP.
Change Section 8.5A.9.1 as follows:
The first frame of the FT Authentication frame sequence is used by the TSTA to initiate a Fast BSS Transition. When RSNA is enabled, the TSTA shall, in the TSIE, include the corresponding key names of the key hierarchy it is using to generate the PTK. By including the key names and their respective key holders, the TTAP can use this information to ensure it has the corresponding PMK-R2 or request for the appropriate PMK-R2. Additionally, the TSTA shall also include the SNonce as its random contribution to ensure the derivation of a fresh PTK.
…
- Direction of message: From TSTA to TTAP
Change Section 8.5A.9.2 as follows:
The second frame of the FT Authentication frame sequence is used by the TTAP to respond to the requesting TSTA. When RSNA is enabled, the TTAP shall also, in the TSIE, echo the key holders and key names used to generate the PTK. Additionally it shall also include the ANonce.
…
- Direction of message: From TTAP to TSTA
Change Section 8.5A.9.3 as follows:
- Direction of message: From TSTA to TTAP
Change Section 8.5A.9.4 as follows:
The fourth frame of the FT Authentication frame sequence is used by the TTAP to respond to the requesting TSTA. The fourth message serves as final confirmation of both liveness of the PTK to the TSTA and resource availability. Note however that the EAPOL-IE may be absent if RSNA is disabled; similarly the RIC-IE will be absent if no resources are requested.
…
- Direction of message: From TTAP to TSTA
Change Section 8A.1 as follows:
1) Base Fast BSS Transition: this mechanism is executed when a TSTA must transition to a TTAP and does not require a reservation prior to its transition.
2) Pre-reservation Fast BSS Transition: this mechanism is executed when a TSTA needs assurances that the required security and QoS resources be available prior to a transition.
TAPsAPs must advertise both their capabilities and policies for supporting the Fast BSS Transition mechanisms.
Change Section 8A.1.2 as follows:
Systems capable of Fast BSS Transition must support the Fast BSS Transition Base Mechanism. The base mechanism enables TSTAs to transition to a TTAP in the event that it must transition without expending costs for invoking a reservation or in the event that the deployment policy only enforces the base mechanism.
…
As shown in Figure 121A, the FBT base mechanism defines a new Authentication algorithm, FT. This enables the TSTA and TTAP to specify the PTKSA to be established, and provides the respective SNonce and ANonce to precompute the PTK. This occurs prior to the TTAP committing QoS resources. The PTKSA is established to enable the integrity protection of the QoS resources specified in the (re)association exchange.
Change Section 8A.1.3 as follows:
To further optimize potential delays and latencies incurred in channel switching and messaging over the air, FBT Pre-Reservation can also be invoked using the current AP to relay the pre-reservation exchange to the TTAP. The figure below depicts the message flow for the FBT Pre-Reservation mechanism using the current AP.
Change Section 8A.2 as follows:
The Fast Transition mechanisms optimize the transitions across an ESS under many different conditions. In RSN enabled networks a new key hierarchy is defined to reduce the number of transactions required to establish a fresh PTKSA. In QoS enabled networks a pre-reservation mechanism is defined to reduce the time required to establish QoS attributes for media streams. To obtain the full potential of Fast Transition mechanisms, a TSTA must enable the Fast Transition procedures during (re)association. This enabling is referred to as first contact to ensure that all potential TTAP’s to which a TSTA may transition will affect the appropriate policies and store relevant information to enable Fast Transition.
Change Section 8A.2 as follows:
As shown in Figure 121D, on first contact with the ESS within which the TSTA intends to use Fast BSS Transitions, the packet exchange between the TSTA and the TTAP is similar to that defined by 802.11-2003, 802.11i and 802.11e. In particular, with RSN-enabled, the TSTA first performs an 802.11 Authentication using the Open System Authentication Algorithm. Upon successful 802.11 open authentication, TSTA then sends a (re)association request to the TTAP and includes the TRIE and TSIE to assert the use of Fast BSS Transitions for future transitions. Additionally, it includes its security capabilities in the RSN Information Element. The R2Name is set to 0's (zeroes) as no PMKSA has been negotiated yet.
...
TSTA->TTAP:
TTAP->TSTA:
TSTA->TTAP:
TTAP ->TSTA:
…
On successful (re)association, the SPA on the TSTA and the 802.1X Authenticator on the TTAP then proceed with an 802.1X EAP authentication. The 802.1X EAP exchange is sent between the TSTA and TTAP using EAPOL messages carried in 802.11 data frames.
Upon successful completion of the 802.1X EAP authentication, the 802.1X Authenticator receives the required information to define its PMKSA:
- TTAP's BSSID,
…
While the TTAP's 802.1X Authenticator receives most of the information from its parent (R2KH-ID), the TSTA holds all the information to derive the PMKSA directly. Thus, following a successful 802.1X EAP authentication, the TTAP and TSTA then perform a FT 4-way handshake similar to the 802.11i handshake.
TTAP->TSTA:
TSTA->TTAP:
TTAP->TSTA:
TSTA->TTAP:
…
As in 802.11i, the EAPOL-Key messages are encapsulated in 802.11 Data frames. On a successful 802.1X EAPOL-Key 4-way handshake, the 802.1X port is opened on both the TSTA and the TTAP, data connectivity has been established, and the TSTA can perform negotiation of QoS or other features if desired.
Change Section 8A.3 as follows:
The Fast BSS Transition base mechanism commences when a TSTA has determined its TTAP; that is, it has completed all the discovery and selection criteria for the TSTA to transition to the TTAP.
When a TSTA wishes to move from it's Current AP (CAP) to a Transition Target AP (TTAP) utilizing a Fast BSS Transition without Reservation, the TSTA exchanges nonces with the TTAP and establishes a PTKSA prior to a (re)association exchange.
When a TSTA wishes to perform an Over-the-Air Fast BSS Transition without Reservation to a TTAP, the TSTA and TTAP perform the following exchange:
TSTA->TTAP:
TTAP->TSTA:
(and numerous similar uses of TTAP in this section).
Change Section 8A.4 as follows:
When an TSTA wishes to move from it's Current AP (CAP) to a Transition Target AP (TTAP) utilizing a Fast BSS Transition with Reservation, the TSTA establishes a PTK with the TTAP and reserves resources using one of two methods:
1) "Over-the-Air". In this case, the TSTA communicates directly with the TTAP using 802.11 Authentication frames with the Authentication Algorithm set to Fast BSS Transition.
2) "Over-the-DS". In this case, the TSTA communicates with the TTAP via the CAP. The communication between the TSTA and the TTAP are carried in Fast BSS Transition Action frames between the TSTA and the CAP, and between the CAP and TTAP via an encapsulation method beyond the scope of this specification. The CAP converts between the two encapsulations.
In either mechanism it is feasible for a TSTA to invoke multiple Pre-reservations but only commit to one TTAP. That is, it may invoke the pre-reservation mechanism as defined in this section with more than one BSSID but only invoke the (re)association exchange with a single TTAP.
Change Section 8A.4.1 as follows:
When a TSTA wishes to perform an Over-the-Air Fast BSS Transition with Reservation to a TTAP, the TSTA and TTAP perform the following exchange:
TSTA->TTAP:
TTAP->TSTA:
(and numerous similar uses of TTAP in this section).
Change Section 8A.4.2 as follows:
When a TSTA wishes to perform an Over-the-DS Fast BSS Transition with Reservation to a TTAP, the TSTA and TTAP perform the following exchange via the CAP:
…
TSTA->TTAP:
TTAP->TSTA:
(and numerous similar uses of TTAP in this section).
Change Section 8A.5.4 as follows:
If the AP is unable to meet the resource request then it must fail the re-association request with a status code of RESOURCES_UNAVAILABLE. If the status code is (1) Invalid TSPEC, or (2) QoS resources not available, then the AP may include a RIC in the response indicating a set of TSPECs as a suggestion. This set of suggested TSPECs may include one or more original TSPECs sent in the reassociation message. The STA should expect to receive the suggested set of TSPECs (which could be just a replica of the original set, from a TTAP) but is not required to act on the information. Pre-reserved resources shall remain until the expiry time indicated upon issue.
Change Section 8A.5.5 as follows:
If the (re)-association message contains a fully specified RIC with a different RIC identifier, the TTAP treats the request as a new request and takes into consideration any TSPECs for the pre-reservation when allocating resources for the new TSPECs (as an implementation optimization the TTAP may "transfer" resources from the prior reservation to the new reservation in a way that is transparent to the non-AP TSTA.).
If reservation for any new TSPECs fail, the TTAP shall include in the re-association response an appropriate status code and the RRIE with RIC identifier matching the prior reservation. This is to notify the non-AP TSTA that reservation for the new request has failed and the non-AP TSTA may try to associate with the prior reservation if the holding time for the prior reservation has not expired. If the holding time for the prior reservation has expired, the TTAP shall notify the non-AP TSTA with a status code of RESOURCES_UNAVAILABLE in the re-association response.
Change Section 8A.5.6 as follows:
The intent of the resource reservation request is to enable a non-AP QSTA to reserve resources based on specified TSPECs before the non-AP QSTA actually associates with the new TTAP. The TSPECs in the request need not belong to only active TSIDs. The non-AP QSTA can send TSPECs for any TSIDs that it intends to use after the transition.
Resource reservation can be performed either over-the-air, or over-the-DS. To initiate an over-the-air reservation, the TSTA transmits request to the TTAP. To initiate over-the-DS resource reservation, a non-AP QSTA transmits a reservation request (which is an 802.11 management action frame) to its current AP.
Following a successful resource reservation, it is the responsibility of the non-AP QSTA to initiate a (Re)-Association session to associate with the new TTAP within the specific time indicated in the resource reservation response.