IGTK Switch Announcement January 2018 doc.: IEEE 802.11-18/xxxxr0 July 2018 IGTK Switch Announcement Date: 2018-05-06 Authors: Emily Qi, et al Emily Qi, et al

January 2018 doc.: IEEE 802.11-18/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

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

November 2017 doc.: IEEE 802.11-18/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

Problem Statements July 2018 November 2017 doc.: IEEE 802.11-18/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

November 2017 doc.: IEEE 802.11-18/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

November 2017 doc.: IEEE 802.11-18/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 9.4.2.54. 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

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

Summary Proposed solution solves IGTK synch-up issues November 2017 doc.: IEEE 802.11-18/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

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