January 2005doc.: IEEE 802.11-04/1557r0
IEEE P802.11
Wireless LANs
Date: 2004-12-18
Author(s):
Name / Company / Address / Phone / email
Steve Emeott / Motorola, Inc. / 1301 E Algonquin Road, Schaumburg, IL60196 / 847-576-8268 /
Tony Braskich / Motorola, Inc. / 1301 E Algonquin Road, Schaumburg, IL60196 / 847-538-0760 /
Floyd Simpson / Motorola, Inc. / 8000 W Sunrise Boulevard, Plantation, FL33322 / 954-723-5269 /
Stephen Wang / Motorola, Inc. / 8000 W Sunrise Boulevard, Plantation, FL33322 / 954-723-8124 /
[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:
Order / Information / NotesTBD / Fast Transition Capability / The Fast Transition Capability information element is only present when dot11FastTransitionOptionImplemented is true.
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
Order / InformationTBD / TSPEC
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
Order / InformationTBD / TSPEC
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
Order / InformationTBD / Fast Transition Control
TBD / EAPOL-Key Message
TBD / TSPEC
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
Order / InformationTBD / Fast Transition Control
TBD / EAPOL-Key Message
TBD / TSPEC
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
Order / Information / NotesTBD / Fast Transition Capability / The Fast Transition Capability information element is only present when dot11FastTransitionOptionImplemented is true.
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
TBD / Preadmission request acceptedTBD / Request declined – Preadmission is not supported
TBD / Request declined – The current AP is busy, try again
TBD / Request declined – No existing admitted AC_VI or AC_VO traffic streams
TBD / Request declined – Preadmission for AC_BE or AC_BK traffic stream is not permitted
TBD / Request declined – Invalid TSPEC parameter
TBD / Request declined – Invalid transition candidate AP address
TBD / Unable to reach or receives no response from transition candidate AP
TBD / TSPEC admission status unavailable
TBD / TSPEC admitted
TBD / TSPEC admitted with changes
TBD / TSPEC declined
TBD / Association granted without bandwidth reservation
7.3.1.11 Action field
Insert the following row into Table 19a:
Code / Meaning / See SubclauseTBD / Fast Transition / 7.4.5
7.3.2 Information Elements
Insert the element IDs shown in the following table into Table 20:
Information Element / Element IDFast Transition Capability / TBD
Fast Transition Control / TBD
EAPOL-Key Message / TBD
Transition Candidate Report / TBD
Preadmission Control / TBD
Preadmission Status Report / TBD
7.3.2.25 RSN information element
7.3.2.25.3 RSN capabilities
Replace Figure 46tc with the following:
B0 / B1 / B2 / B3 / B4 / B5 / B6 / B7 / B8 / B15Pre-Auth / No Pairwise / PTKSA Replay Counter / GTKSA Replay Counter / Fast Transition / PTA / Reserved
Bits: 1 / 1 / 2 / 2 / 1 / 1 / 8
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.
Element ID /Length
/ Fast Transition InfoOctets: 1 / 1 / 1
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.
B0 / B1 / B2 / B3 / B7Fast Transition / PTA / Preadmissions / Reserved
Bits: 1 / 1 / 1 / 5
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.
Element ID /Length
/ FT Control Info / PTA AddressOctets: 1 / 1 / 1 / 6
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.
B0 / B1 / B2 / B3 / B7Shortened Handshake / PMK in PTA / Activate TS / Reserved
Bits: 1 / 1 / 1 / 5
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.
Element ID /Length
/ EAPOL-Key frameOctets: 1 / 1 / variable
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.
Element ID /Length
/ BSSID / Transition Candidate Information / PTA AddressOctets: 1 / 1 / 6 / 1 / 6
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.
B0 / B1 / B2 / B3 / B4 / B5 / B7Reachable / Fast Transition / PTA Enabled / Preadmissions / Reserved
Bits: 1 / 2 / 1 / 1 / 3
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
Fast Transition / ValueProcedures Supported / 0
Unknown / 1
Procedures Not Supported / 2
Reserved / 3
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.
Element ID /Length
/ Preadmission Policy / AP ListOctets: 1 / 1 / 1 / variable
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.
B0 / B1 / B7Immediate Update / Reserved
Bits: 1 / 7
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