1. IGTK Switch Announcement
January 2018
doc.: IEEE /xxxxr0
July 2018
IGTK Switch Announcement
Date:
Authors:
Emily Qi, et al
Emily Qi, et al

2. January 2018
doc.: IEEE /xxxxr0
July 2018
Abstract
This submission identifies some issues with IGTK update and provides a solution to address the issues. The submission also provides a solution to address LB232 CID 1067
Emily Qi, et al
Emily Qi, et al

3. Agenda Problem Statement Proposed Solutions Solution Details
January 2018
doc.: IEEE /xxxxr0
July 2018
Agenda
Problem Statement
Proposed Solutions
Solution Details
An Example
Emily Qi, et al
Emily Qi, et al

4. November 2017
doc.: IEEE /xxxxr0
July 2018
Background
Since both GTK and IGTK are shared by all associated STAs, the AP typically updates their value on a regular basis as well as when an STA disassociates from AP.
This is achieved by
First, updating all associated STAs, one by one via unicast frame
Once the new non-active GTK and IGTK are set in all STAs, the AP will start using the new Key IDs as the ‘active’ GTK and IGTK for the following group-addressed Data frame and Management frames protection, respectively.
Which means that there is a delay between the time the new keys were set by AP in the STA and the time where AP actually starts using the new keys instead of the old ones.
Emily Qi, et al
Emily Qi, et al

5. Problem Statements July 2018
November 2017
doc.: IEEE /xxxxr0
July 2018
Problem Statements
For group addressed data frame, the used GTK Key ID is indicated in the beginning of the frame (e.g. the Key ID field in the CCMP header), so that the STA knows quiet early which GTK to use.
However, for group addressed management frame, the used IGTK Key ID is indicated in the MMIE (Management MIC Information Element), which is located at the end of the Protected Group addressed Management Frame.
The receiving STA won't be able to start computing MIC value until reaching the end of management frame body.
Emily Qi, et al
Emily Qi, et al

6. November 2017
doc.: IEEE /xxxxr0
July 2018
Proposed Solution
Following GTK/IGTK rekeying, AP notifies all associated STAs on when it will start using the new IGTK prior to switch to the new IGTK when AP is still using the old IGTK key
The notification can be included in the Beacon frame.
Proposed solution is similar to Channel Switch announcement
Emily Qi, et al
Emily Qi, et al

7. November 2017
doc.: IEEE /xxxxr0
July 2018
Solution Details
Include a new IE “IGTK Switch Announcement IE” in the Beacon frame:
New Key ID
The New Key ID field identifies the new IGTK to be used to compute the MIC. The IGTK Key ID is either 4 or 5, as defined in
IGTK Switch Count
the IGTK Switch Count field is set to the number of TBTTs until the STA starts to use the new IGTK.
A value of 1 indicates that the switch occurs immediately after the next TBTT. The new IGTK will be used immediately after the next Beacon transmission.
Emily Qi, et al
Emily Qi, et al

8. Example of using IGTK Switch Announcement
November 2017
doc.: IEEE /xxxxr0
July 2018
Example of using IGTK Switch Announcement
Emily Qi, et al
Emily Qi, et al

9. Summary Proposed solution solves IGTK synch-up issues
November 2017
doc.: IEEE /xxxxr0
July 2018
Summary
Proposed solution solves IGTK synch-up issues
Proposed solution is similar to channel switch announcement
There is no backward compatibility issue with this solution:
When a legacy AP doesn’t indicate that it switched key, a STA shall still identify the switch using the old mechanism.
When an AP indicates that it switched key, a legacy STA may ignore the announcement and identify the switch using the old mechanism.
Emily Qi, et al
Emily Qi, et al

10. Backup July 2018 January 2018 doc.: IEEE 802.11-18/xxxxr0
Emily Qi, et al
Emily Qi, et al