January 2006doc.: IEEE 802.11-y5/1258r0
IEEE P802.11
Wireless LANs
Date: 2006-01-05
Author(s):
Name / Company / Address / Phone / email
Suman Sharma / Intel Corp / 2111 NE 25th Ave, HillsboroOR97124 / 503-264-6015 /
Jesse Walker / Intel Corp / 2111 NE 25th Ave, HillsboroOR97124 / 503-712-1849 /
Jon Edney / Nokia / Cambridge, UK / +441353648567 /
Paul Panish / Meetinghouse / Portsmouth, NH 03801 / 603-610-8657 /
Jouni Malinen / Devicescape / 1000 Marina Blvd Suite 400, BrisbaneCA94005 / 650-829-2630 /
Mike Saal / Meetinghouse / Portsmouth, NH 03801 / 603-610-8644 /
Bart Westgeest / Meetinghouse / Portsmouth, NH 03801 / 603-610-8667 /
Shlomo Ovadia / Intel Corp / 2200 Mission College Blvd.,
Santa Clara, CA 95054 / +1 408 7651844 /
Kevin Karcz / Meetinghouse / Portsmouth, NH 03801 / 603-766-7508 /
3. Definitions
Delete Clause 3.100, 3.101, and 3.102.
Update the following text for Clause 3.97 as shwon below:
3.97 robust security network association (RSNA) key management:Key management that includes the4-Way Handshake, the Group Key Handshake, STAKey Handshake, and PeerKeyHandshake.
Insert the following definitions in alphabetical order into Clause 3, renumbering as necessary:
3.122 Station to station link (STSL):Direct link established between two STAs while associated to a common AP. This term refers to a generic mechanism which may be implemented to allow direct STA to STA communication while remaining in Infrastructure Mode. The only example of this procedure currently specified is DLS. Establishment of an STSL will be expected to be include an initialization step similar to that specified by DLS, however it is not intended that the procedure be limited to DLS should other needs be established in the future. Any mechanism developed for this purpose must specify teardown procedures which may be used by the STSL to terminate the link under the conditions discussed in this text.
3.124 PeerKeyhandshake:Comprised of the SMK handshake and the 4-Way STK handshake. Key management protocol used to create new SMKSA and STKSA to secure the STSL.
3.125 SMK handshake:A pairwise key management protocol defined by this standard. It creates newSTSLmaster key (SMK) by two parties.
3.126 4-Way STK handshake:A pairwise key management protocol defined by this amendment. It confirmsmutual possession of a STSL master key (SMK) by two parties and distributes a STSL transient key (STK).
3.127 STSL master key (SMK):A random value generated by AP during SMK handshake, used for deriving STSL transient key (STK).
3.128 STSL master key security association (SMKSA):The context resulting from a successful SMKhandshake.
3.129 STSL transient key (STK):A value that is derived from the STSL master key (SMK), initiator mac address (MAC_I), peer mac address (MAC_P), initiator nonce (INonce), and peer nonce (PNonce) using the pseudo-random function (PRF) and that is split up into as many as five keys, i.e., temporal encryption key, two temporal message integrity code (MIC) keys, EAPOL-Key encryption key (SKEK), EAPOL-Key confirmation key (SKCK).
3.130 STSL transient key security association (STKSA):The context resulting from a successful 4-Way STK exchange.
4. Abbreviations and acronyms
Insert the following new abbreviations and acronyms in alphabetical order:
STSLStation to station linkin infrastructure BSS
SMKSTSL master key
SMKSASMK security association
STKSTSL transient key
STKSASTK security association
SKEKSTSL key encryption key
SKCKSTSL key confirmation key
MUIMessage unique identifier
5. General description
5.4.3.2 Deauthentication
Change the text in fourth paragraph in Clause 5.4.3.2 as follows:
In an RSNA, deauthentication also destroys any related PTKSA, group temporal key security association(GTKSA), STAKey security associations (STAKeySAs),STSL master key security association (SMKSA), and STSL transient key security association (STKSA)thatexist in the STA and closes the associated IEEE 802.1X Controlled Port. If pairwise master key (PMK) caching isnot enabled, deauthentication also destroys the pairwise master key security association (PMKSA) from which thedeleted PTKSA wasderived.
7. Frame formats
7.3.2.25.3 RSN capabilities
Change the Figure 79 in Clause 7.3.25.3 as follows:
Figure 79: RSN Capabilities field format
Change the text in paragraph before Table 31 and Table 31 in Clause 7.3.25.3 as follows:
— Bits 2–3: PTKSA Replay Counter. A STA sets the PTKSA Replay Counter subfield of the RSNCapabilities field to the value contained in dot11RSNAConfigNumberofPTKSAReplay-Counters. The least significant bit (LSB) of dot11RSNAConfigNumberofPTKSAReplayCountersis put in bit 2. See 8.3.2.6 and 8.3.3.4.3. The meaning of thevalue in thePTKSA/GTKSA/STAKeySA/STKSA Replay Counter subfield is defined in Table 31. The number ofreplay counters per STAKeySASTKSA is the same as the number of replay counters per PTKSA orGTKSA.
Table 31—PTKSA/GTKSA/STAKeySA/STKSA replay counters usage
Replay countervalue / Meaning
0 / 1 replay counter per PTKSA/GTKSA/STAKeySA/STKSA
1 / 1 replay counter per PTKSA/GTKSA/STAKeySA/STKSA
2 / 1 replay counter per PTKSA/GTKSA/STAKeySA/STKSA
3 / 1 replay counter per PTKSA/GTKSA/STAKeySA/STKSA
Insert thistext in place of last bullet (starting with Bit 6-15.) in Clause7.3.25.3 as follows:
— Bits 9: PeerKey Enabled. An AP STA sets the PeerKeyEnabled subfield of the RSN Capabilities fieldto 1 to signal it supports PeerKeyHandshake (see 8.5.9). This field is used by AP STA to describe its ability to support PeerKey Handshake.
— Bits 6–8 & 10–15: Reserved. The remaining subfields of the RSN Capabilities field are reserved and shall beset to 0 on transmission and ignored on reception.
8. Security
Add following text at the end of Clause 8.1.3:
8.1.3A RSNA PeerKey Support
The PeerKey protocol is provided to allow for establishment of STA to STA connectivity within a BSS while providing mutual authentication, session identification, and data confidentiality. A PeerKey association, comprised of an SMKSA and an STKSA, shall only be allowed within the context of an existing RSNA by both peers with a common AP. It is the intent of the PeerKey protocol to allow only protected communication between STAs. Both Initiator and Peer STA shall ensure that dot11RSNAEnabled is true in order to proceed with the SMK and STK Handshakes and allow establishment of their respective security associations.
An STSL session (such as DLS) may chose to allow unprotected communication between STAs, however such communications are outside the scope of the PeerKey specification and are not supported by the PeerKey protocol.
8.3.2.4 TKIP countermeasures procedures
Add following text as second last paragraph before section 8.3.2.4.1 in section 8.3.2.4:
SameTKIP countermeasures are applicable for secure DLS data frame exchange as well.
8.3.2.6 TKIP replay protection procedures
Change the text of sub-number b), e) and g) text below as follows:
b) Each transmitter shall maintain a single TSC (48 bit counter) for each PTKSA, GTKSA, andSTAKeySASTKSA.
e) A receiver shall maintain a separate set of TKIP TSC replay counters for each PTKSA, GTKSA, andSTAKeySA STKSA.
g) For each PTKSA, GTKSA, andSTAKeySA STKSA, the receiver shall maintain a separate replay counterfor each frame priority and shall use the TSC recovered from a received frame to detect replayedframes, subject to the limitations on the number of supported replay counters indicated in the RSNCapabilities field, as described in 7.3.2.25. A replayed frame occurs when the TSC extracted from areceived frame is less than or equal to the current replay counter value for the frame’s priority. Atransmitter shall not reorder frames with different priorities without ensuring that the receiver supportsthe required number of replay counters. The transmitter shall not reorder frames within areplay counter, but may reorder frames across replay counters. One possible reason for reorderingframes is the IEEE 802.11 MSDU priority.IEEE 802.11 does not define a method to signal frame priority.
8.3.3.4.3 PN and replay detection
Change the text of sub-number b), d) and e) text below as follows:
b) Each transmitter shall maintain a single PN (48-bit counter) for each PTKSA, GTKSA, and STAKeySA STKSA.
d) A receiver shall maintain a separate set of PN replay counters for each PTKSA, GTKSA,andSTAKeySA STKSA. The receiver initializes these replay counters to 0 when it resets the temporal key for apeer. The replay counter is set to the PN value of accepted CCMP MPDUs.
e) For each PTKSA, GTKSA, andSTAKeySASTKSA, the recipient shall maintain a separate replay counterfor each IEEE 802.11 MSDU priority and shall use the PN recovered from a received frame to detectreplayed frames, subject to the limitation of the number of supported replay counters indicated in theRSN Capabilities field (see 7.3.2.25). A replayed frame occurs when the PN extracted from areceived frame is less that or equal to the current replay counter value for the frame’s MSDU priority.
A transmitter shall not use IEEE 802.11 MSDU priorities without ensuring that the receiver supportsthe required number of replay counters. The transmitter shall not reorder frames within areplay counter, but may reorder frames across replay counters. One possible reason for reorderingframes is the IEEE 802.11 MSDU priority.
8.4.1.1 Security association definitions
Insert the following sub item as last sub item before the start of Claus 8.4.1.1.1:
— STAKeySA: A result of a successful STAKey Handshake.
— SMKSA: A result of a successful initial SMKHandshake.
— STKSA: A result of a successful 4-way STKHandshake following the initial SMK Handshake or subsequent rekeying.
Delete STAKeySA Clause 8.4.1.1.4.
Insert the following sub items at the end of Clause 8.4.1.1.3:
8.4.1.1.4 SMKSA
An SMKSA is the result of a successful SMK Handshake by the initiator STA (described in 8.5.9).It is derived from parameters provided by the STAs and AP. This security association is bidirectional between the initiator and the peer STA. Inother words, both parties use the information in the security association for both sending and receiving. An SMKSA is created as a result of a successful SMK Handshake (see section 8.5.9).The SMKSA is used to create theSTKSA. SMKSAs are cached for up to their lifetimes. The SMKSA consists of the following elements:
—SMKID, as defined in 8.5.9. The SMKID identifies the security association.
—BSSID
—Initiator MAC address
—Peer MAC address
—SMK.
—Lifetime, as defined in 8.5.9.
—Pairwise cipher suite selector list, as proposed by initiator STA
—Pairwise cipher suite selector, as selected by peer STA
8.4.1.1.5 STKSA
The STKSA is a result of successful completion of the 4-WaySTKHandshake. This security association is bidirectional between the initiator and the peer STAs. The STKSAis used to create session keys to protect this STSL. STKSAs are cached for the life of the SMKSA or when the STSL ends, whichever comes first. There shall be onlyone STKSA with the same initiatorSTA and peer MAC addresses at any one time. STKSA is created as a result of PeerKey Handshake (see section 8.5.9). The STKSA consists of the followingelements:
—STK
—Pairwise cipher suite selector
—Initiator MAC address
—Peer MAC address
8.4.10 RSNA security association termination
Change the text in following Clause 8.4.10 as follows:
When a non-AP STA SME receives a successful MLME association or reassociation confirm primitive or receives or invokes an MLME disassociation or deauthentication primitive, it will delete some security associations.Similarly, when an AP SME receives an MLME association or reassociation indication primitive, or receives or invokes an MLME disassociation or deauthentication primitive it will delete some security associations. In the case of an ESS, the non-AP STA’s SME shall delete the PTKSA,and the GTKSA, SMKSA, and any STKSA and the AP’s SME shall delete the PTKSA and invoke an STSL Teardown for any of its STKSAs. In the case of an IBSS, the STA’s SME shall delete the PTKSA and the receive GTKSA. Once the security associations have been deleted, the SME then invokes MLMEDELETEKEYS request primitive to delete all temporal keys associated with the deleted security associations. The IEEE 802.1X Controlled Port returns to being blocked. As a result, all data frames are unauthorized before invocation of an MLME-DELETEKEYS.request primitive.
If a STA loses key state synchronization, it can apply the following rules to recover:
a)Any protected frame(s) received shall be discarded, and MLME-PROTECTEDFRAMEDROPPED.indication primitive is invoked.
b)If the STA is RSNA-enabled and has joined an IBSS, the SME shall execute the authentication procedureas described in 11.3.1.
c)If the STA is RSNA-enabled and has joined an ESS, the SME shall execute the deauthentication proceduresas described in 11.3.3. However, if the STA has initiated the RSN security association, buthas not yet invoked the MLME-SETPROTECTION.request primitive, then no additional action isrequired.
NOTES
—There is a race condition between when MLME-SETPROTECTION.request primitive is invoked on theSupplicant and when it is invoked on the Authenticator. During this time, an encrypted MPDU may be receivedthat cannot be decrypted; and the MPDU will be discarded without a deauthentication occurring.
—Because the IEEE 802.11 null data MPDU does not derive from an MA-UNITDATA.request, it is notprotected.
If the selected AKMP fails between a STA and an AP that are associated, then both the STA and the AP shall
invoke the MAC deauthentication procedure described in 11.3.3.
If the SMK handshake fails between a pair of associated STA and AP, then the STAs and the AP shall invoke an STSL Teardown.
8.5.1 Key hierarchy
Insert the following sub items at the end of Clause 8.5.1.3:
8.5.1.4PeerKey key hierarchy
The station to station key hierarchy utilizes PRF-384 or PRF-512 to derive session-specific keys from a SMK, as
depicted in Figure 106a. The SMK shall be 256 bits. The pairwise key hierarchy takes a SMK and generates a
STK. The STK is partitioned into SKCK and SKEK, and temporal keys used by the MAC to protect unicastcommunication between the initiator and peer respective STAs. STKs are used between asingle initiatorSTA and a single peer STA.
Figure 106a: PeerKey hierarchy
Here, the following assumptions apply:
a)INonce is a random or pseudo-random value contributed by the initiator STA.
b)PNonce is a random or pseudo-random value contributed by the peer STA.
c)The STK shall be derived from the SMK by
STK ← PRF-X(SMK, “Peer key expansion”, Min(MAC_I,MAC_P) || Max(MAC_I,MAC_P) || Min(INonce,PNonce) || Max(INonce,PNonce))
TKIP uses X = 512 and CCMP uses X = 384. The Min and Max operations for IEEE 802 addressesare with the address converted to a positive integer treating the first transmitted octet as the most significant octet of the integer. The Min and Max operations for nonces are with the nonces treated aspositive integers converted as specified in 7.1.1.
d)The SKCK shall be computed as the first 128 bits (bits 0–127) of the STK:
SKCK ← L(STK, 0, 128)
The SKCK is used to provide data origin authenticity in the STK 4-Way Handshake.
e)The SKEK shall be computed as bits 128–255 of the STK:
SKEK ← L(STK, 128, 128)
The SKEK is used by the EAPOL-Key frames to provide confidentiality in the STK 4-Way Handshake.
f)The temporal key (TK) shall be computed as bits 256–383 (for CCMP) or bits 256–511 (for TKIP)of the STK:
TK ← L(STK, 256, 128) or
TK ← L(STK, 256, 256)
The EAPOL-Key state machines (see 8.5.6 and 8.5.7) use the MLME-SETKEYS.request primitive to configurethe temporal key into the STA. The STA uses the temporal key with the pairwise cipher suite; interpretationof this value is cipher-suite-specific.
A SMK identifier is defined as
SMKID = HMAC-SHA1-128(SMK, "SMK Name" || PNonce || MAC_P || INonce || MAC_I)
Here, HMAC-SHA1-128 is the first 128 bits of the HMAC-SHA1 of its argument list.
8.5.2 EAPOL-Key frames
Change the text in following Clause 8.5.2 as follows:
IEEE 802.11 uses EAPOL-Key frames to exchange information between STAs’ Supplicants and Authenticators.
These exchanges result in cryptographic keys and synchronization of security association state.EAPOL-Key frames are used to implement three different exchanges:
—4-Way Handshake, to confirm that the PMK between associated STAs is the same and live and to
—transfer the GTK to the STA.
—Group Key Handshake, to update the GTK at the STA.
—STAKey Handshake, to deliver the STAKey to the initiating and peer STAs.
—PeerKeyinitial SMKhandshake to deliver SMK and final 4-way STK Handshake to deliver the STK, to the initiating and peer STAs.
Replace Figure 108 with following Figure:
Figure 108—Key Information bit layout
Change the text in following Clause 8.5.2 sub-number b)->2)->i) as follows:
i)The value 0 (Group/STAKey/SMK) indicates the message is not part of a PTK derivation.
Change the text in following Clause 8.5.2 sub-number b)->8) as follows:
8) Error (bit 10) is set by a Supplicant to report that a MIC failure occurred in a TKIP MSDUorSMKhandshake failure. In case of MIC failure Supplicant shall set this bit only when the Request (bit 11) is set.In case SMKMessage bit is set, this shall be set to indicate thekey data field contains an Error KDE.
Change the text in following Clause 8.5.2 sub-number b)->9) as follows:
9) Request (bit 11) is set by a Supplicant to request that the Authenticator initiate either a 4-WayHandshake or Group Key Handshake, is set by a Supplicant in a Michael MIC FailureReport and is set by STSL peer STA to request initiator STA rekeying of STK. The Supplicant shall not set this bit in on-going 4-Way Handshakes, i.e., the Key Ack bit (bit 7) shall not be set in any message with the Request bit set. The Authenticator shall never set this bit.
In a Michael MIC Failure Report, setting the bit is not a request to initiate a new handshake.However the recipient may initiate a new handshake on receiving such a message.If the EAPOL-Key frame with Request bit set has a key type of Pairwise, the Authenticatorshall initiate a 4-Way Handshake.
If the EAPOL-Key frame with Request bit set has a key typeof Group/STAKey, the Authenticator shall change the GTK, initiate a 4-Way Handshake withthe Supplicant, and then execute the Group Key Handshake to all Supplicants.
If the EAPOL-Key frame with Request bit set has SMK Message bit set, initiator STA shall take appropriateaction to create new STK (based on section 8.5.9).
Change the text in following Clause 8.5.2 sub-number b)->10) as follows:
10) Encrypted Key Data (bit 12) is set if the Key Data field is encrypted and is clear if the Key Datafield is not encrypted. This subfield shall be set, and the Key Data field shall be encrypted, ifany key material (e.g., GTK or STAKeySMK) is included in the frame.