7.3.2.46 Fast BSS Transition Information Element

January 2007 doc.: IEEE 802.11-07/0180r0

IEEE P802.11 Wireless LANs

FT GTK Encapsulation

Date: 2007-01-18

Author(s): Name Company Address Phone email Jouni Devicescape Software, 900 Cherry Ave, 6th Floor, San +1 650-829-2630 [email protected] Malinen Inc. Bruno, CA 94066, USA

Abstract IEEE 802.11r/D4.0 reuses GTK KDE (of EAPOL-Key frames) from 8.5.2 (as defined in Figure 143 and Figure 144) for GTK sub-element of FTIE. However, this construction does not take into account that two of EAPOL-Key fields are also needed for GTK delivery: EAPOL-Key IV (for ARC4) and Key RSC. In order to make FT encapsulation work, it looks like an FT-specific definition of GTK sub-element would be needed.

Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.

Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11.

Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures , including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at .

FT GTK Encapsulation page 1 Jouni Malinen, Devicescape January 2007 doc.: IEEE 802.11-07/0180r0

Proposed changes

7.3.2.46 Fast BSS transition information element

Change:

GTK contains the Group Key; it is encrypted (see procedures in 8A.6.4), and is defined in Figure 143 and Figure 144 of 8.5.2 112wa.

Insert a new figure, Figure 112wa, into the end of 7.3.2.46 with the title “GTK sub-element format”, in the style of Figure 112w, and with following fields: – Key Info (1 octet) – Key Length (1 octet) – RSC (8 octets) – IV (0 or 16 octets) – Key (5-32 octets)

Insert the following text after the added Figure 112wa:

Key Info field is defined in Figure 112wb. IV Present field is set to 1 if the used GTK encryption requires an IV, otherwise it is set to 0.

Insert a new figure, Figure 112wb, after the added Figure 112wb with the title “GTK Key Info field”, in the style of Figure 112v, and with following fields: – KeyID (B0-B1) – IV Present (B2) – Reserved (B3-B7)

Insert the following text after the added Figure 112wb:

Key Length field is the length of the Key field in octets. This length value does not include the possible padding (see 8A.6.4).

RSC field contains the receive sequence counter (RSC) for the GTK being installed in IEEE 802.11. The Key RSC field gives the current message number for the GTK, to allow a STA to identify replayed MPDUs. If the Key RSC field value is less than 8 octets in length, the remaining octets shall be set to 0. The least significant octet of the TSC or PN should be in the first octet of the Key RSC field.

NOTE—The Key RSC field value for TKIP is the TSC in the first 6 octets and for CCMP is the PN in the first 6 octets. See Table 61.

For WEP, the Key RSC value shall be set to 0 on transmit and shall not be used at the receiver.

IV field, if present (as determined by IV Present subfield of Key Info), contains the IV used with the KEK. It should be initialized by taking the current value of the global key counter (see 8.5.6) and then incrementing the counter. Note that only the lower 16 octets of the counter value will be used.

8A.6.4 FT authentication sequence: contents of fast BSS transition acknowledgement

Change:

When this message of the authentication sequence appears in a Reassociation Response, the Optional

FT GTK Encapsulation page 2 Jouni Malinen, Devicescape January 2007 doc.: IEEE 802.11-07/0180r0 parameters in FTIE may include a GTK sub-element. If a GTK is included, itthe Key field of the sub- element shall be encrypted using ARC4 when neither the pairwise nor the group cipher is AES-CCMP. It shall be encrypted using the NIST AES Key Wrap algorithm when either the pairwise or group cipher is AES-CCMP. When using the NIST AES key wrap, the KDE DataKey field shall be padded before encrypting if the key data length is less than 16 octets or if it is not a multiple of 8. The padding consists of appending a single octet 0xdd followed by zero or more 0x00 octets. When processing a received message, the receiver shall ignore this trailing padding. Addition of padding does not change the value of Key Length field. Note: The length of the encrypted Key field can be determined from the length of the GTK sub-element.

FT GTK Encapsulation page 3 Jouni Malinen, Devicescape