March 2010
doc.: IEEE 802.11-10/314r0
IEEE P802.11
Wireless LANs
Rekeying Protocol Fix Text
Date: 2010-03-12
Author(s):
Name
Affiliation
Robert Stacey
Intel
Adrian Stephens
Jesse Walker
Herbert Liondas
Emily Qi
Intel
Intel
Intel
Intel
Address
2111 NE 25th Ave, Hillsboro
OR 97124, USA
Phone
email
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
Abstract
This submission provides instructions for editing REVmb Draft 2.01 for the purpose of adding a fix to the
rekeying protocol.
Submission
page 1
Robert Stacey, Intel
March 2010
doc.: IEEE 802.11-10/314r0
7 Frame formats
7.3.2.25 RSN information element
7.3.2.25.3 RSN capabilities
Editor – Replaced reserved bit B13 the Extended Key ID for Unicast field as shown below (only the
second half of the figure is edited)
B8
Reserved
B9
Peerkey
enabled
Bits: 1
1
B10
B11
B12
SPP ASPP APBAC
MSDU
MSDU
Capable
Required
1
1
1
Figure 7-74 – RSN Capabilities field format
B13
Extended
Key ID for
Unicast
1
B134 B15
Reserved
32
Editor – Insert description for Bit 13 and change “B13” to “B14” in following bullet
— Bit 12: PBAC (protected block ack agreement capable). A STA sets the PBAC subfield of RSN
Capabilities field to 1 to indicate it supports PBAC. Otherwise, this subfield is set to 0.
— Bit 13: Extended Key ID for Unicast. This subfield is set to 1 to indicate that the STA supports Key ID
values in the range 0 through 1 for a PTKSA and STKSA when the cipher suite is CCMP. A value of 0
indicates that the STA only supports Key ID 0 for a PTKSA and STKSA.
— Bits 8 and 134–15: Reserved. The remaining subfields of the RSN Capabilities field are
reserved.
7.4a.3 A-MPDU contents
Editor – Add the underlined text below as the third paragraph in this section:
All the MPDUs within an A-MPDU are addressed to the same RA. All QoS data frames within an AMPDU that have a TID for which an HT-immediate Block Ack agreement exists have the same value for
the Ack Policy subfield of the QoS Control field.
All protected MPDUs within an A-MPDU have the same Key ID.
An A-MPDU is transmitted in one of the contexts specified in Table 7-57x (A-MPDU Contexts).
Ordering of MPDUs within an A-MPDU is not constrained, except where noted in these tables. See
9.7d.1 (A-MPDU contents).
Submission
page 2
Robert Stacey, Intel
March 2010
doc.: IEEE 802.11-10/314r0
8 Security
8.4 RSNA security association management
8.4.1 Security associations
8.4.1.1 Security association definitions
8.4.1.1.2 PTKSA
Editor – Edit the bulleted list as follows (inserting Key ID)
The PTKSA consists of the following elements:
— PTK
— Pairwise cipher suite selector
— Supplicant MAC address or STA’s MAC address
— Authenticator MAC address or BSSID
— Key ID
— If FT key hierarchy is used,
— R1KH-ID
— S1KH-ID
— PTKName
8.4.1.1.3 GTKSA
Editor – Edit the bulleted list as follows (inserting Key ID)
A GTKSA consists of the following elements:
— Direction vector (whether the GTK is used for transmit or receive).
— Group cipher suite selector.
— GTK.
— Authenticator MAC address.
— Key ID
— All authorization parameters specified by local configuration. This can include parameters such as
— the STA’s authorized SSID.
8.4.1.1.5 STKSA
Editor – Edit the bulleted list as follows (inserting Key ID)
The STKSA consists of the following elements:
— STK
— Pairwise cipher suite selector
— Initiator MAC address
— Peer MAC address
— Key ID
Submission
page 3
Robert Stacey, Intel
March 2010
doc.: IEEE 802.11-10/314r0
8.5 Keys and key distribution
8.5.2 EAPOL-Key frames
Editor – Add the Key ID KDE to Table 8-4 at the appropriate position:
OUI
00-0F-AC
Table 8-4 – KDE
Data type
Meaning
<ANA>
Key ID KDE
Editor – Append the following to section (8.5.2):
The format of the Key ID KDE is shown in Figure 8-32b.
KeyID
Reserved (0)
bits 0-1
bits 2-15
Figure 8-32b – Key ID KDE
The KeyID field contains the Authenticator selected Key ID.
8.5.4 4-Way Handshake
8.5.3.3 4-Way Handshake Message 3
Editor – Edit the Key Data field description as follows:
Key Data = For PTK generation, the AP’s Beacon/Probe Response frame’s RSN element,
and, optionally, a second RSN element that is the Authenticator’s pairwise cipher suite
assignment, and, if a group cipher has been negotiated, the encapsulated GTK and the
GTK’s key identifier (see 8.5.2 (EAPOL-Key frames)), and if Management Frame
Protection is negotiated, the IGTK KDE. For STK generation Initiator RSNE, Lifetime of
SMK is used. If the Extended Key ID for Unicast subfield of the RSN Capabilities field
is set to 1 for both the Authenticator/STA_I and Supplicant/STA_P, then the
Authenticator/STA_I includes the Key ID KDE with the assigned key identifier.
Editor – Edit subsequent paragraphs as follows:
Processing for PTK generation is as follows:
If the Extended Key ID for Unicast subfield of the RSN Capabilities field is set to 1 for both the
Authenticator and the Supplicant, then the Authenticator assigns a new Key ID for the PTKSA in the
range 0 through 1 that is different from the Key ID assigned in the previous handshake and uses the
MLME-SETKEYS.request primitive to install the new key in the IEEE 802.11 MAC to receive Class 3
individually addressed MPDUs protected by the PTK with the assigned Key ID. Otherwise the Key ID 0
is used and installation of the key is deferred until after Message 4 has been received. The Authenticator
sends Message 3 to the Supplicant.
Note -- If an existing PTK is still in effect, the Authenticator IEEE 802.11 MAC continues to transmit
Class 3 individually addressed MPDUs (if any) using the existing key. With the installation of the new
Submission
page 4
Robert Stacey, Intel
March 2010
doc.: IEEE 802.11-10/314r0
key for receive, the Authenticator is able to receive Class 3 individually addressed MPDUs using either
the old key (if present) or the new key.
On reception of Message 3, the Supplicant silently discards the message if the Key Replay Counter field
value has already been used or if the ANonce value in Message 3 differs from the ANonce value in
Message 1. The Supplicant also
a) Verifies the RSNE. If it is not identical to that the STA received in the Beacon or Probe
Response frame, the STA shall disassociate. If a second RSN element is provided in the message,
the Supplicant uses the pairwise cipher suite specified in the second RSNE or deauthenticates.
b) Verifies the Message 3 MIC. If the calculated MIC does not match the MIC that the
Authenticator included in the EAPOL-Key frame, the Supplicant silently discards Message 3.
c) Updates the last-seen value of the Key Replay Counter field.
d) If the Extended Key ID for Unicast subfield of the RSN Capabilities field is set to 1 for both
the Authenticator and Supplicant: Uses the MLME-SETKEYS.request primitive to configure the
IEEE 802.11 MAC to receive Class 3 individually addressed MPDUs protected by the PTK with
the assigned Key ID.
de) Constructs Message 4.
ef) Sends Message 4 to the Authenticator.
fg) Uses the MLME-SETKEYS.request primitive to configure the IEEE 802.11 MAC to send
and, if the receive key has not yet been installed, to receive Class 3 individually addressed
MPDUs protected by the PTK. The GTK is also configured by MLMESETKEYS primitive.
Processing for STK generation is as follows:
If the Extended Key ID for Unicast subfield of the RSN Capabilities field is set to 1 for both the STA_I
and the STA_P, then the Authenticator assigns a new Key ID for the STKSA in the range 0 through 1 that
is different from the Key ID assigned in the previous handshake and uses the MLME-SETKEYS.request
primitive to install the new key in the IEEE 802.11 MAC to receive Class 3 individually addressed
MPDUs protected by the STK with the assigned Key ID. Otherwise the Key ID 0 is used and installation
of the key is deferred until after Message 4 has been received. The STA_I sends Message 3 to the STA_P.
Note -- If an existing STK is still in effect, the STA_I IEEE 802.11 MAC continues to transmit Class 3
individually addressed MPDUs (if any) using the existing key. With the installation of the new key for
receive, the STA_I is able to receive Class 3 individually addressed MPDUs using both the old key (if
present) or the new key.
On reception of Message 3, the STA_P silently discards the message if the Key Replay Counter field
value has already been used or if the INonce value in Message 3 differs form the INonce value in
Message 1. Otherwise,
a) The STA_P verifies the Message 3 MIC using SKCK key in SMKSA. If the calculated MIC
does not match the MIC that the STA_P included in the EAPOL-Key frame, the STA_I
silently discards Message 3.
b) If the MIC is valid, the STA_P checks that the RSNIE bit-wise matches that from the 4-Way
Handshake Message 2. If these are not exactly the same, STA_P silently discards the message
and deletes existing 4-Way Handshake states.
c) If they do match, the STA_P constructs Message 4. It also compares the Key Lifetime value
from KDE with value in its SMKSA. If value in SMKSA is less, it discards the value
received in Message 3. Otherwise, it updates the value in SMKSA with value in Message 3.
d) If the Extended Key ID for Unicast subfield of the RSN Capabilities field is set to 1 for both
the Authenticator and Supplicant then prior to sending Message 4, STA_P uses the MLMESETKEYS.request primitive to configure the IEEE 802.11 MAC to receive Class 3
individually addressed MPDUs protected by the STK with the assigned Key ID.
Submission
page 5
Robert Stacey, Intel
March 2010
doc.: IEEE 802.11-10/314r0
e) After sending Message 4, STA_P uses the MLME-SETKEYS.request primitive to configure
the IEEE 802.11 MAC to send and, if the receive key has not yet been installed, to receive
Class 3 individually addressed MPDUs protected by the STK with the assigned Key ID.
8.5.3.4.4 4-Way Handshake Message 4
Editor: Update the “processing for PTK generation” and “processing for STK generation” sections as
follows:
Processing for PTK generation is as follows:
The Supplicant sends Message 4 to the Authenticator. Note that when the 4-Way Handshake is first used,
Message 4 is sent in the clear.
On reception of Message 4, the Authenticator verifies that the Key Replay Counter field value is one that
it used on this 4-Way Handshake; if it is not, it silently discards the message. Otherwise:
a) The Authenticator checks the MIC. If the calculated MIC does not match the MIC that the
Supplicant included in the EAPOL-Key frame, the Authenticator silently discards Message 4.
b) If the MIC is valid, the Authenticator uses the MLME-SETKEYS.request primitive to configure
the PTK into the IEEE 802.11 MAC to send and, if the receive key has not yet been installed, to
receive Class 3 individually addressed MPDUs using for the new PTK.
c) The Authenticator updates the Key Replay Counter field so that it will use a fresh value if a rekey
becomes necessary.
Processing for STK generation is as follows:
The STA_P sends Message 4 to the STA_I. On reception of Message 4, the STA_I verifies that the Key
Replay Counter field value is one that it used on this 4-Way Handshake; if it is not, it silently discards the
message. Otherwise,
a) The STA_I checks the MIC. If the calculated MIC does not match the MIC that the STA_P
included in the EAPOL-Key frame, the STA_I silently discards Message 4.
b) If the MIC is valid, the STA_I configures the STK into the IEEE 802.11 MAC uses the MLMESETKEYS.request primitive to configure the 802.11 MAC to send and, if the receive key has not
yet been installed, to receive Class 3 individually addressed MPDUs using for the new STK.
c) The STA_I updates the Key Replay Counter field so that it will use a fresh value if a rekey
becomes necessary.
8.7.2 RSNA frame pseudo-code
8.7.2.3 Per-MPDU Rx pseudo-code
Editor – Edit the pseudo-code as follows (insert underlined text):
if ((MPDU has individual RA and Pairwise key exists for the MPDU’s TA) or
(MPDU has a group addressed RA and network type is IBSS and IBSS GTK
exists for MPDU’s RA)) then
if MPDU has individual RA then
lookup pairwise key using Key ID from MPDU
else
lookup group key using Key ID from MPDU
Submission
page 6
Robert Stacey, Intel
March 2010
doc.: IEEE 802.11-10/314r0
endif
if key is null then
discard the frame body and increment
dot11WEPUndecryptableCount
10.3.17 SetKeys
10.3.17.1 MLME-SETKEYS.request
Editor -- Add the “Direction” parameter at the end of the SetKeyDescriptor table:
Name
Direction
Type
Integer
Valid range
Receive, Transmit, Both
Description
Indicates the direction for which the keys
are to be installed. Receive indicates that
the keys are being installed for the receive
direction. Transmit indicates that the keys
are being installed for the transmit
direction. Both indicates that the keys are
being installed for both the receive and
transmit directions.
10.3.17.1.4 Effect of receipt
Editor – Replace the single paragraph of this section as follows:
Receipt of this primitive causes the MAC to set the appropriate keys and to begin using them for future
MA-UNITDATA.request and MA-UNITDATA.indication primitives provided the MLMESETPROTECTION.
request primitive has been issued.
Receipt of this primitive causes the MAC to apply the keys as follows provided the
MLMESETPROTECTION.request primitive has been issued:
 If the Direction element indicates Transmit or Both then the MAC uses the key information for the
transmission of all subsequent frames to which the key applies.
 If the Direction element indicates Receive or Both then the MAC installs the key with the associated Key
ID such that received frames of the appropriate type and containing the matching Key ID will be processed
using that key and its associated state information.
Submission
page 7
Robert Stacey, Intel