Insert the Following Definitions in Alphabetical Order Into Clause 3, Renumbering As Necessary

January 2005doc.: IEEE 802.11-04/1557r0

IEEE P802.11
Wireless LANs

[This amendment is based on IEEE Std 802.11(tm), 1999 Edition (Reaff 2003), as amended by IEEE Std 802.11a(tm)-1999, IEEE Std 802.11b(tm)-1999, IEEE Std 802.11b-1999/Cor 1-2001, IEEE Std 802.11d(tm)-2001, IEEE Std 802.11g(tm)-2003, IEEE Std 802.11h(tm)-2003, IEEE Std 802.11i(tm)-2004, and IEEE Std802.11j(tm)-2004.]

NOTE -- The editing instructions contained in this amendment define how to merge the material contained herein into the existing base standard and its amendments to form the comprehensive standard.

The editing instructions are shown in bold italic. Three editing instructions are used: change, delete, and insert. Changeis used to make small corrections in existing text or tables. The editing instruction specifies the location of the change and describes what is being changed either by using strikethrough(to remove old material) or underscore(to add new material). Deleteremoves existing material. Insertadds new material without disturbing the existing material. Insertions may require renumbering. If so, renumbering instructions are given in the editing instructions. Editorial notes will not be carried over into future editions.

3. Definitions

Insert the following definitions in alphabetical order into Clause 3, renumbering as necessary:

3.122 pre-transition authenticator: An entity that enables a station to preauthenticate prior to a BSS transition and before the station chooses a destination. This entity stores cryptographic key material obtained during preauthentication and required by a station to complete a key confirmation handshake with an access point until the station is ready to reassociate, at which point it forwards this material to a destination access point.

4. Abbreviations and acronyms

Insert the following new acronyms at appropriate locations in clause 4:

PTApre-transition authenticator

5. General Description

5.4 Overview of the services

5.4.3 Access and confidentiality control services

5.4.3.1 Authentication

After 5.4.3.1.1, insert 5.4.3.1.2

5.4.3.1.2 Preauthentication with a PTA

Because many BSS transition candidates may exist within an ESS, the STA may opt to preauthenticate with a PTA, instead of an AP, in advance of a transition.

Preauthentication with a PTA may be invoked by a STA while it is associated with an AP (with which it previously authenticated) that advertises support of fast transition services. To Preauthenticate with a PTA, the STA communicates with the PTA using the DS.

Preauthentication with a PTA allows a STA to establish cryptographic keys for later use with an AP in the ESS network. Association and key management procedures for use with a PTA are defined to reduce the authentication service overhead during a BSS transition.

5.4.3.4 Key management

Insert the following paragraphs at the end of 5.4.3.4:

Procedures are also defined to reduce BSS transition times when stations that have previously authenticated prepare to reassociate with a new access point. In particular, when a station has preauthenticated or when key material is cached at the destination AP, the station may split the 4-way handshake into messages exchanged via the DS before the transition and messages that are conveyed to the destination AP during reassociation. Streamlining the 4-way handshake using these procedures helps minimize the length of time during a BSS transition when a station lacks a RSNA and is unreachable.

5.9 IEEE 802.11 and IEEE 802.1X

After 5.9.2.2, insert 5.9.2.3

5.9.2.3 AKM optimizations supporting a fast BSS transition

When an AP supports fast transition services, a STA may split the 4-way key confirmation handshake into messages exchanged between the Supplicant and an Authenticator over the DS before the transition and messages that are conveyed to the destination AP during reassociation.

It is assumed that both the Supplicant and AS authenticate each other and generate a PMK. The STA chooses either the PTA or an Authenticator (AP) to facilitate IEEE 802.1X authentication and receive the generated PMK from the AS. Once a PMK has been generated, the station may proceed with the following AKM operations:

a)A STA that is associated with an AP (with which it previously authenticated) may request the contents of EAPOL-Key message #1 from either a PTA or an Authenticator through the DS. Upon receiving this information, the STA may continue AKM operations starting from EAPOL-Key frame message #2 after selecting a destination access point.

b)Once the STA has selected a destination access point for its BSS transition, it resumes the 4-way handshake, starting with a message that conveys the contents of EAPOL-Key message #2 to the Authenticator or the PTA. The STA may combine the information in message #2 with a reassociation request, or it may encapsulate this information into an EAPOL-Key message.

c)The Authenticator or PTA replies to message #2 with the contents of message #3. This information may be transmitted to the Supplicant in a reassociation response, or it may be encapsulated in an EAPOL-Key message.

The fourth message in the 4-way handshake is optional, and may be omitted if the AP has the capability to install keys without the final message and if the STA signals its intent to skip the message #4 in its reassociation request.

Upon successful completion of the key confirmation handshake, the Authenticator and Supplicant have authenticated with each other, and the IEEE 802.1X Controlled Ports are unblocked to permit general data transfer.

After 5.9.5, insert 5.9.6

5.9.6 PTA to AP protocol

The PTA to AP authentication definition is out of scope of this amendment, but, to provide security assurances, the protocol must support the same authentication and key management functions as the Authenticator-to-AS protocol, namely mutual authentication between the PTA and the AP and the ability to pass the generated key from the PTA to the AP in a manner that provides authentication of the key source, ensures integrity of the key transfer, and preserves confidentiality of the key from all other parties.

7. Frame formats

7.2 Format of individual frame types

7.2.3 Management frames

7.2.3.1 Beacon frame format

Insert the following rows at the appropriate location in Table 5:

7.2.3.4 Association Request frame format

Insert the following rows at the appropriate location in Table 7 in 7.2.3.4 as shown:

Table 7 – Association Request frame body

7.2.3.5 Association Response frame format

Insert the following rows at the appropriate location in Table 8 in 7.2.3.5 as shown:

Table 8 – Association Response frame body

7.2.3.6 Reassociation Request frame format

Insert the following rows at the appropriate location in Table 9 in 7.2.3.6 as shown:

Table 9 – Reassociation Request frame body

7.2.3.7 Reassociation Response frame format

Insert the following rows at the appropriate location in Table 10 in 7.2.3.7 as shown:

Table 10 – Reassociation Response frame body

7.2.3.9 Probe Response frame format

Insert the following rows at the appropriate location in Table 12 in 7.2.3.9 as shown:

Table 12 – Probe Response frame body

7.3 Management frame body components

7.3.1 Fixed fields

7.3.1.9 Status Code field

Insert the Status codes shown in the following table into Table 19

7.3.1.11 Action field

Insert the following row into Table 19a:

7.3.2 Information Elements

Insert the element IDs shown in the following table into Table 20:

7.3.2.25 RSN information element

7.3.2.25.3 RSN capabilities

Replace Figure 46tc with the following:

Figure 46tc—RSN Capabilities field format

Change the text in 7.3.2.25.3 as follows:

—Bit 6: Fast Transition. An AP sets the Fast Transition subfield of the RSN Capabilities field to 1 to signal it supports the Fast Transition procedures described in 8.5.4 and 8.5.5 and sets the subfield to 0 when it does not support Fast Transition. A non-AP STA sets the Fast Transition subfield to 0.

—Bit 7: PTA. An AP sets the PTA subfield of the RSN Capabilities field to 1 to signal it supports communicating with a PTA and retrieving a PMK from a PTA during reassociation. If the bit is set to 1, the AP implements a PTA to AP protocol and accepts reassociation requests from STA that have preauthenticated with a PTA. Otherwise, the bit is set to 0.

—Bits 68-15: Reserved. The remaining subfields of the RSN Capabilities field are reserved and shall be set to 0 on transmission and ignored on reception.

After 7.3.2.25, insert 7.3.2.26 through 7.3.2.31 and renumber tables and figures as necessary:

7.3.2.26 Fast Transition Capability element

The Fast Transition Capability element contains capability information bits and is transmitted in beacon and probe response frames by an AP providing Fast Transition services. The Fast Transition Capability element is defined in Figure R1.

Length

Figure R1 – Fast Transition Capability element format

The Element ID field shall be equal to the Fast Transition Capability value in Table 20.

The Fast Transition Info field is 1 octet and contains subfields advertising which Fast Transition services an AP supports. The format of the Fast Transition Info field is defined in Figure R2.

Figure R2 – Fast Transition Info field

The Fast Transition subfield is 1 bit in length and indicates, when set by an AP, support for the Fast Transition procedures described in 8.5.4, 8.5.5 and 11.9.

The PTA subfield is 1 bit in length and indicates whether an AP is capable of communicating with a PTA and retrieving a PMK from a PTA during reassociation. If the bit is set to 1, the AP implements a PTA to AP protocol and accepts reassociation requests from STA that have preauthenticated with a PTA. Otherwise, the bit is set to 0.

The Preadmissions subfield is 1 bit in length and indicates whether an AP supports preadmissions services. The bit, if set, indicates that the AP supports admissions control services and is capable of processing preadmissions requests and accepting preadmissions requests from STA that are associated with a different AP.

All other subfields are reserved and shall be set to zero.

7.3.2.27 Fast Transition Control element

The Fast Transition Control information element contains information needed to perform key management and admissions control procedures during the reassociation step of a fast BSS transition. The format of the Fast Transition Control element is defined in Figure R3.

Length

Figure R3 – Fast Transition Control element format

The Element ID field shall be equal to the Fast Transition Control value in Table 20.

The FT Control Info field is 1 octet long and provides information used to control the behavior of the fast transition key confirmation handshake and admissions control procedures. The structure of the FT Control Info field is defined in Figure R4.

Figure R4 – FT Control Info field

The Shortened Handshake subfield is 1 bit in length and specifies the requested type of key confirmation handshake for reassociation. A non-AP STA requests to shorten the key confirmation handshake and complete AKM without transmitting the final message of the 4-way handshake by setting the Shortened Handshake subfield to 1. If the AP sets the Shortened Handshake subfield to 1, the non-AP STA may complete the key confirmation handshake and without transmitting the final message of the 4-way handshake. Otherwise, the non-AP STA shall complete the entire 4-way key confirmation handshake.

The PMK in PTA subfield is 1 bit in length and specifies the requested location of the PMK to be used for AKM. The STA requests to use a PMK that is cached at a PTA by setting the PMK in PTA subfield to 1. Otherwise, the PMK in PTA subfield is set to 0.

The Activate TS subfield is 1 bit in length and contains a request that the AP activate admitted TSPECs. The STA requests the AP to activate any admitted TSPECs belonging to the STA by setting the Activate TS subfield to 1.

All other subfields are reserved and shall be set to zero.

The PTA Address field is 6 octets in length and contains an IEEE MAC individual address of a PTA. A non-AP STA sets the PTA Address field to the IEEE MAC individual address of the PTA at which it has stored a spare PMK for use during a fast BSS transition. An AP sets the PTA Address field to the IEEE MAC individual address of the PTA from which STAs associated with this AP may obtain preauthentication services.

7.3.2.28 EAPOL-Key Message element

The EAPOL-Key Message information element contains an EAPOL-Key frame to enable IEEE 802.1X messaging in management frames. The format of the EAPOL-Key Message element is defined in Figure R5.

Length

Figure R5 – EAPOL-Key Message Information Element

The Element ID field shall be equal to the EAPOL-Key Message value in Table 20.

The EAPOL-Key frame field contains an EAPOL-Key frame as defined in 8.5.2.

7.3.2.29 Transition Candidate Report element

The Transition Candidate Report information element contains fast transition information about a neighboring AP. The format of the Transition Candidate Report element is defined in Figure R6.

Length

Figure R6 – Transition Candidate Report element format

The BSSID field is 6 octets in length and contains an IEEE MAC individual address of an AP that provides AKM services.

The Transition Candidate Information field is 1 octet in length and indicates the capabilities of the AP having the address in the BSSID field. The structure of the Transition Candidate Information field is defined in Figure R7.

Figure R7 – Transition Candidate Information field

The Reachable subfield indicates whether the AP having the address in the BSSID field is reachable by the STA for the purposes of preauthentication. If the bit is set to 1, it indicates that the AP having the address in the BSSID field is reachable for the purposes of preauthentication. Otherwise, the bit is set to 0.

The Fast Transition subfield indicates whether the AP having the address in the BSSID field supports Fast Transition procedures described in 8.5.4. The values are as follows:

Table R1 – Fast Transition subfield

The PTA Enabled subfield indicates whether the AP having the address in the BSSID field is capable of communicating with a PTA and retrieving a PMK from a PTA during reassociation. If the bit is set to 1, the AP is known to implement a PTA to AP protocol and accepts reassociation requests from stations that have preauthenticated with a PTA. Otherwise, the bit is set to 0.

The Preadmissions subfield indicates whether the AP having the address in the BSSID field supports preadmissions services. The bit, if set, indicates that the AP is known to support admissions control services and is capable of accepting preadmissions requests from STA that are associated with a different AP. Otherwise, the bit is set to 0.

The PTA Address field is 6 octets in length and contains an IEEE MAC individual address of a PTA from which STAs associated with the AP having the address in the BSSID field may obtain preauthentication and fast transition services.

7.3.2.30 Preadmission Control element

The Preadmission Control element contains preadmission policy information and a list of neighboring APs to which the STA wishes to submit a preadmission request. The format of the Preadmission Control element is defined in Figure R8.

Length

Figure R8 – Preadmission AP Control element format

The Element ID field shall be equal to the Preadmission Control value in Table 20.

The Preadmission Policy field specifies a requested set of status update options for a STA submitting a Preadmissions Request. The format of the Preadmission Info field is defined in Figure R9.

Figure R9 – Preadmission Policy field

The Immediate Update subfield is 1 bit in length and specifies the requested Preadmissions Status Update mode to be used with a STA that submits a Preadmissions Request. A non-AP QSTA sets the Immediate Update subfield to 0 to request the current AP to buffer Preadmissions Status Reports from neighboring AP until a Preadmissions Status Inquiry request is received. A non-AP QSTA sets the Immediate Update subfield to 1 to request the current AP to deliver Preadmissions Status Reports without waiting for a Preadmissions Status Inquiry request.

All other subfields are reserved and shall be set to zero.

The AP List subfield contains a list of BSSIDs of intended preadmission transition candidate APs.

7.3.2.31 Preadmission Status Report element