1. Beacon Protection Date: 2018-05-08 Authors: May 2018 January 2018
doc.: IEEE /0865r0
May 2018
Beacon Protection
Date:
Authors:
Emily Qi, et al
Emily Qi, et al

2. January 2018
doc.: IEEE /0865r0
May 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
January 2018
doc.: IEEE /0865r0
May 2018
Agenda
Problem Statement
Design Goal and Proposed Solutions
Solution Details
Summary
Emily Qi, et al
Emily Qi, et al

4. November 2017
doc.: IEEE /0865r0
May 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
November 2017
doc.: IEEE /0865r0
May 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 entire the Beacon frame body (after MAC header, including Timestamp field)
All beacon contents prior to association should be treated as unreliable and validated following association based on the protected Beacon.
Emily Qi, et al
Emily Qi, et al

6. Use BIP for Beacon Protection
November 2017
doc.: IEEE /0865r0
May 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
November 2017
doc.: IEEE /0865r0
May 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”= enabled; “0” = not enabled.
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 capability bit (from AP) is set to “1”, 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 capability bit (from AP) is set to “0”, 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 treated as unreliable and validated following association based on the protected Beacon.
Emily Qi, et al
Emily Qi, et al

8. Known Issues Proposed solution is subject to “insider” forgeries
November 2017
doc.: IEEE /0865r0
May 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.
Since MME is added at the end of Beacon frame body, the receiving STA won’t know the Key ID and IPN 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

9. November 2017
doc.: IEEE /0865r0
May 2018
Summary
Proposed solution leverages the existing RSN security and reuses BIP
Simple and easy to deploy
Proposed solution protects Beacon frames for associated STAs from “outsider” forgery
All beacon contents prior to association should be treated as unreliable and validated following association based on the protected Beacon.
Emily Qi, et al
Emily Qi, et al

10. Backup May 2018 January 2018 doc.: IEEE 802.11-18/0865r0
Emily Qi, et al
Emily Qi, et al