Beacon Protection Date: 2018-07-31 Authors: July 2018 July 2018 doc.: IEEE 802.11-18/0865r2 July 2018 Beacon Protection Date: 2018-07-31 Authors: Emily Qi, et al Emily Qi, et al

July 2018 doc.: IEEE 802.11-18/0865r2 July 2018 Abstract This submission provides solution to protect Beacon frame from “outsider” forgery. LB 232 CID #1066 Emily Qi, et al Emily Qi, et al

Agenda Problem Statement Design Goal and Proposed Solutions July 2018 doc.: IEEE 802.11-18/0865r2 July 2018 Agenda Problem Statement Design Goal and Proposed Solutions Solution Details Notify AP STA when a forgery is detected MultipleBSSID Scenarios Summary Emily Qi, et al Emily Qi, et al

July 2018 doc.: IEEE 802.11-18/0865r2 July 2018 Problem Statement The Beacon frame contains valuable information about the BSS BSS capability, Supported rates and operating channel information, network information, TIM, TSF, etc. IEEE 802.11 doesn’t provide direct protection for Beacon frame Beacon RSNE contents are included in 4-ways handshake messages for verification, but it won’t protect Beacon frame from forgery after the association. Broadcast/Multicast integrity protocol (BIP) provides protection for group addressed robust management frames, but Beacon frames are excluded. The Beacon frame is subject to forgery Attacker can impersonate an AP and transmit Beacon frames STAs may change their behavior in such manner that will result with disconnections and even switch channels. Forged TIM may result with that STAs are unable to wake up to receive the packet or wake up frequently so that waste battery Forged TSF may result with that STAs are unable to receive group addressed frames Emily Qi, et al Emily Qi, et al

Design Goal and Proposed Solution July 2018 doc.: IEEE 802.11-18/0865r2 July 2018 Design Goal and Proposed Solution Design Goals Keep it simple Leverage existing RSN security Proposed Solution Use BIP to provide Beacon integrity protection for associated STAs Similar to group addressed management frame protection MIC calculation is over the Beacon frame body excluding the Timestamp field The value of the Timestamp field is added the last stage of the beacon transmission and could be changed if the Tx sequence is changed. Note that current CCMP/GCMP designs mask out certain fields that can change if frame transmission needs to be rescheduled/reordered. All beacon contents prior to association should be validated following association based on the protected Beacon. Emily Qi, et al Emily Qi, et al

Use BIP for Beacon Protection July 2018 doc.: IEEE 802.11-18/0865r2 July 2018 Use BIP for Beacon Protection Add Management MIC IE (MME) in the Beacon frame Using CMAC/GMAC for MIC calculation Using an integrity group key (i.e. IGTK) to compute MIC. IPN is used for Beacon frame replay protection The receiving STA shall keep a different counter (from robust management frames) due to QMF reordering, transmitting priority, and system considerations. Receiver discards Beacon in case of mismatch between calculated MIC and reported MIC when QMF (Qos Management Frames) is supported, the transmitter may re-order the IGTK protected frames within an ACI. IEEE 802 . 11 Header Beacon frame body FCS MME Element ID Length Key ID IPN MIC Emily Qi, et al Emily Qi, et al

Beacon Protection Capability and STA Behaviours July 2018 doc.: IEEE 802.11-18/0865r2 July 2018 Beacon Protection Capability and STA Behaviours Add one bit (“Beacon Protection”) in the RSN capabilities field of RSNE to indicate whether the Beacon Protection is enabled or not by the AP: “1”= activated; “0” = not activated. AP STA behaviors If AP supports Beacon Protection, AP shall indicates it in the Capabilities field of RSNE element and insert MME in the Beacon frame. Otherwise, the AP acts as a legacy AP. Non-AP STA behaviors If STA supports Beacon Protection and beacon protection is activated by AP, the STA calculates the MIC and compares it with the MIC included in MME. If not matched, the STA shall ignore the receiving Beacon frame. If STA supports Beacon Protection and beacon protection is not activated, there will be no MME in the beacon frame and the STA acts as legacy STA. If STA doesn’t support Beacon Protection (legacy STA), the STA ignores the MME in the Beacon frame. All beacon contents prior to association should be validated following association based on the protected Beacon. Emily Qi, et al Emily Qi, et al

Notify AP STA when a forgery is detected July 2018 doc.: IEEE 802.11-18/0865r2 July 2018 Notify AP STA when a forgery is detected When a forgery or bad Beacon is detected, the STA can use WNM Notification Request frame to report “forged/bad” Beacon so that AP knows there is a “bad” guy in the area and may take some actions for mitigation. WNM Notification Request frame Category WNM Action Dialog Token Type Subelements Optional WNM Notification Type Value Description Firmware Update Notification 1 Bad Beacon Notification 2-220 Reserved 221 Vendor Specific 222–255 Emily Qi, et al Emily Qi, et al

Multiple BSSID Beacon Protection July 2018 doc.: IEEE 802.11-18/0865r2 July 2018 Multiple BSSID Beacon Protection Multiple BSSID Scenario The Multiple BSSID capability enables the advertisement of beacon information for multiple BSSIDs using a single Beacon. Proposed Solution For the “transmitted BSSID”, the Beacon frame is protected with the IGTK of the BSS with “transmitted BSSID” by using BIP and advertising support for it. For the “nontransmitted BSSIDs”, the Beacon protection will not apply.   STAs that are associated with "transmitted BSSID" and support Beacon protection will check the MIC.  STAs that are associated with "nontransmitted BSSIDs" will ignore the MME in the Beacon frame. If a forgery/bad is detected, the STA (that is associated with "transmitted BSSID“) can report forgery to AP using WNM Notification. So that AP knows there is a “bad” guy in the area and can take some actions for mitigation, which is benefit for STAs that are associated with “nontransmitted BSSIDs”. Emily Qi, et al Emily Qi, et al

Known Issues Proposed solution is subject to “insider” forgeries July 2018 doc.: IEEE 802.11-18/0865r2 July 2018 Known Issues Proposed solution is subject to “insider” forgeries this issue also applies to group address robust management frame protection. A public key scheme might be considered for future study. The Timestamp field is not included in the MIC calculation. Including Timestamp field may introduce more strict requirements for hardware implementation. Since MME is added at the end of Beacon frame body, the receiving STA won’t know the Key ID until the end of the frame. Possible Solutions: Use current IGTK and switch to the next IGTK if Key ID mismatches (at the end) or use IGTK Switch Announcement. IPN: For CMAC, there is no issue; IV and PN won’t be needed at the beginning. For GMAC, there is no needed at the beginning. it is only needed to complete the last step of the GMAC MIC calculation. Since the MIC size is known and the MMIE is the last IE, the IPN can be easily identified. Emily Qi, et al Emily Qi, et al

July 2018 doc.: IEEE 802.11-18/0865r2 July 2018 Summary Proposed solution leverages the existing RSN security and reuses BIP Proposed solution protects Beacon frames for associated STAs from “outsider” forgery All beacon contents prior to association should be validated following association based on the protected Beacon. Proposed solution leverages WNM Notification feature to allow STAs to notify the AP when a forgery/bad beacon is detected Emily Qi, et al Emily Qi, et al

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