1 / 12

Beacon Protection

Beacon Protection. Date: 2018-07-31. Authors:. Abstract. This submission provides solution to protect Beacon frame from “outsider” forgery. LB 232 CID #1066. Agenda. Problem Statement Design Goal and Proposed Solutions Solution Details Mitigation MultipleBSSID Scenarios Summary.

quon
Download Presentation

Beacon Protection

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Beacon Protection Date: 2018-07-31 Authors: Emily Qi, et al

  2. Abstract This submission provides solution to protect Beacon frame from “outsider” forgery. LB 232 CID #1066 Emily Qi, et al

  3. Agenda • Problem Statement • Design Goal and Proposed Solutions • Solution Details • Mitigation • MultipleBSSID Scenarios • Summary Emily Qi, et al

  4. 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

  5. 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

  6. 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 Element ID Length Key ID IPN MIC IEEE 802 . 11 Header Beacon frame body FCS MME Emily Qi, et al

  7. 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 validated following association based on the protected Beacon. Emily Qi, et al

  8. 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 • WNM Notification Type Emily Qi, et al

  9. 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

  10. 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 will 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 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

  11. 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

  12. Backup Emily Qi, et al

More Related