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

2. July 2018
doc.: IEEE /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

3. Agenda Problem Statement Design Goal and Proposed Solutions
July 2018
doc.: IEEE /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

4. July 2018
doc.: IEEE /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 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

5. Design Goal and Proposed Solution
July 2018
doc.: IEEE /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

6. Use BIP for Beacon Protection
July 2018
doc.: IEEE /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

7. Beacon Protection Capability and STA Behaviours
July 2018
doc.: IEEE /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

8. Notify AP STA when a forgery is detected
July 2018
doc.: IEEE /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

9. Multiple BSSID Beacon Protection
July 2018
doc.: IEEE /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

10. Known Issues Proposed solution is subject to “insider” forgeries
July 2018
doc.: IEEE /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

11. July 2018
doc.: IEEE /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

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