Beacon Content Protection Month Year January 2006 March 2006 Beacon Content Protection Date:2006-01-10 Authors: Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. Emily Qi, Intel Corporation Emily Qi, Intel Corporation

Month Year January 2006 March 2006 Abstract This submission examines all the different methods that have been suggested to protect Beacon content from forgery. It concludes that none are worthwhile Emily Qi, Intel Corporation Emily Qi, Intel Corporation

Agenda Problem Statement Suggested method summaries Month Year January 2006 March 2006 Agenda Problem Statement Suggested method summaries Analysis and Conclusions Emily Qi, Intel Corporation Emily Qi, Intel Corporation

Month Year January 2006 March 2006 Problem Statement The Beacon Frame contains valuable information about the BSS BSS capability and network information BSS operation required configuration for STA, etc. The Beacon Frame is subject to forgery However, the IEEE 802.11 design prevents direct protection for Beacon frames A data link protocol can only provide frame protection after a session key is in place, which, for 802.11, is after the 802.11i 4-Way Handshake. Examine ways to protect Beacons from forgery Emily Qi, Intel Corporation Emily Qi, Intel Corporation

Some Suggested Method Summaries Month Year January 2006 March 2006 Some Suggested Method Summaries Brute Force 1: MIC based on a shared key Brute Force 2: MIC based on multiple pair-wise keys Brute Force 3: A signature scheme Indirect protection: Use the 4-Way Handshake to verify Beacon contents, introduce a new “maintenance Beacon” Emily Qi, Intel Corporation Emily Qi, Intel Corporation

Brute Force 1 Create a new MIC IE Month Year January 2006 March 2006 Brute Force 1 Create a new MIC IE Compute MIC IE over Beacon contents using a group key Insert MIC IE into Beacon Receiver discards Beacon if it cannot verify the MIC computed over the Beacon contents using the group key Emily Qi, Intel Corporation Emily Qi, Intel Corporation

Month Year January 2006 March 2006 Brute Force 1 Issues The only valid security decision is to treat all Beacons from unassociated APs as forgeries Because an unassociated STA will make the “wrong” decision when it receives a forgery, because it will not have the current group key Impossible to protect unassociated STAs from replay attacks Because they cannot know the current sequence number The solution is still subject to “insider” forgeries, i.e., a forgery by any STA that knows the group key This makes Brute Force 1 inappropriate for many environments, such as public networks Emily Qi, Intel Corporation Emily Qi, Intel Corporation

Brute Force 2 Create a new MIC IE Month Year January 2006 March 2006 Brute Force 2 Create a new MIC IE Compute n different MIC IEs, one for each STA within range, computed over the Beacon data (non-MIC IEs), using long-lived pair-wise keys Insert all n MIC IEs into the Beacon Each STA verifies the MIC IE by computing a MIC over the Beacon contents using its own pair-wise key and comparing it with the right MIC IE, discarding the Beacon on failure Emily Qi, Intel Corporation Emily Qi, Intel Corporation

Month Year January 2006 March 2006 Brute Force 2 Issues To work, each STA-AP pair needs its own long-lived key separated from all other long-lived keys If the WLAN supports N STAs with M APs, then MN keys need to be provisioned individually Each STA must save the M different keys for the M different APs Each AP must save the N different keys for the N different STAs The Beacon will grow to eat up all available bandwidth Any conceivable implementation will require a MIC, sequence number, key id, and STA MAC address in each IE (at least 8 + 6 + 1 + 6 + 2 = 23 octets), for a total of 23n octets in each Beacon It still does not solve the replay problem for unassociated STAs How does the AP know which unassociated STAs are receiving its Beacons? Emily Qi, Intel Corporation Emily Qi, Intel Corporation

Brute Force 3 Introduce a Signature IE Month Year January 2006 March 2006 Brute Force 3 Introduce a Signature IE The AP uses a private signing key to sign the content of each Beacon The AP puts the Signature IE into each Beacon The STAs use the corresponding public key to verify the signature in the Signature IE Emily Qi, Intel Corporation Emily Qi, Intel Corporation

Month Year January 2006 March 2006 Brute Force 3 Issues Any reasonable signature scheme will cost at least O(225) instructions at the AP This cost will be incurred every time a Beacon parameter changes Any reasonable signature scheme will cost at least at least O(223) instructions at each receiving STA for every Beacon Any reasonable Signature IE will require at least 64 + 20 + 2 = 86 octets for its encoding (most will require much more) The verification key either has to be pre-provisioned, or the Beacon will have to carry a Certificate IE, which will convey an O(210) octet certificate And a different verification key is required for each AP It still does not solve the replay problem for unassociated STAs Emily Qi, Intel Corporation Emily Qi, Intel Corporation

Month Year January 2006 March 2006 Indirect Protection Confirm the static Beacon contents in 4-Way Handshake Message 3 Insert the static information into Message 3 of 4-way handshake Messages Similar to the RSN IE protection Cannot protect dynamic Beacon contents, because they might change between Beacon reception and 4-Way Handshake 802.11w STAs no longer look at any dynamic fields in Beacons received prior to 4-Way Handshake completion E.g. QBSS Load IE not available prior to 4-Way Handshake under this scheme Otherwise associated STAs will react differently to a forgery than unassociated STAs and security is lost Any possible MIC and sequence number are unreliable before a session key is in place Protect Beacon by adding a MIC IE to existing Beacon MICs are dynamic, so can’t be verified until after a session key is in place Enables access to all Beacon fields Emily Qi, Intel Corporation Emily Qi, Intel Corporation

Indirect Protection Issues Month Year January 2006 March 2006 Indirect Protection Issues Affords unassociated STAs with some protection, but only after association This will not protect a STA from making “wrong” decisions on the basis of forgeries Approximately doubles the amount of bandwidth consumed by Beacons Backward compatibility says the maintenance Beacon must replicate Beacon parameters, not replace Emily Qi, Intel Corporation Emily Qi, Intel Corporation

Analysis Beacons are dual purpose Is Beacon Protection Necessary? Month Year January 2006 March 2006 Analysis Beacons are dual purpose Is Beacon Protection Necessary? Emily Qi, Intel Corporation Emily Qi, Intel Corporation

Beacons Are Dual Purpose Month Year January 2006 March 2006 Beacons Are Dual Purpose Before Association STAs use Beacons to Gain hints about an AP’s capabilities and configuration Most of this information is static and not changed at runtime, except QBSS Load IE After Association STAs use Beacons to Reconfigure the STA to adapt to changes in the BSS Most of this information is dynamic and changes at runtime, e.g., DTIM, STA configuration, and BSS operation Emily Qi, Intel Corporation Emily Qi, Intel Corporation

Is Protection Necessary? Month Year January 2006 March 2006 Is Protection Necessary? If a static Beacon parameters is forged, then A STA doesn’t care if it are already associated, because it won’t look at or adjust the static values If a STA is not associated and a forged static parameter value prevents the STA from associating, it will go to another AP If a STA is not associated and a forged static parameter value does not prevent the STA from associating, it won’t care If a dynamic Beacon parameter is forged, a STA can wait for the next Beacon But how will it know which parameter is correct, the forged or the real? Emily Qi, Intel Corporation Emily Qi, Intel Corporation

Month Year January 2006 March 2006 Analysis Conclusions It appears there is nothing of value that can be done to protect Beacon contents for unassociated STAs There does not appear to be any value in protecting static Beacon parameters There is value in protecting the dynamic Beacon parameters, like QBSS Load Because of Beacon’s dual usage, Beacons are architecturally the wrong vehicle to convey dynamic parameters requiring protection Emily Qi, Intel Corporation Emily Qi, Intel Corporation

Month Year January 2006 March 2006 What Can Be Done? It is possible to protect the static Beacon contents in the 4-Way Handshake, but there seems little value in doing so Move critical dynamic parameters to the 802.11k Neighbor Report STAs receive the neighbor report after the 4-Way Handshake, so it can be protected by normal 802.11w mechanism This helps STAs that have made first contact with an ESS, but not STAs that have not Emily Qi, Intel Corporation Emily Qi, Intel Corporation

Month Year January 2006 March 2006 Summary It makes no sense to implement “security” methods that do not meet their alleged goals Recall WEP No Beacon protection that has been proposed scheme meets its alleged goals The dual usage of Beacons makes them the wrong delivery vehicle for conveying dynamic Beacon parameters The 802.11k Neighbor Report is a more plausible vehicle for conveying protected dynamic parameters Emily Qi, Intel Corporation Emily Qi, Intel Corporation

Backup March 2006 Month Year January 2006 Emily Qi, Intel Corporation

What’s Wrong with Looking at Dynamic fields prior to 4-Wau Handshake? Month Year January 2006 March 2006 What’s Wrong with Looking at Dynamic fields prior to 4-Wau Handshake? Here is an attack: Suppose the AP broadcasts a valid Beacon The Adversary catches the valid Beacon with a sniffer, changes, e.g., the QBSS Load field, and rebroadcasts All associated STAs drop the altered Beacon as a forgery because the altered QBSS Load field is inconsistent with the MIC An unassociated STA will accept the altered Beacon as genuine To act consistently with the BSS security policy, the STA must ignore fields that force it to behave inconsistently with the policy Protecting Beacons changes their information from hints to authenticated data The BSS security policy says that STAs should not use on unauthenticated data Emily Qi, Intel Corporation Emily Qi, Intel Corporation

Information in Beacon frame (.11ma-D4.0) Month Year January 2006 March 2006 Information in Beacon frame (.11ma-D4.0) Order Information Static / Dynamic Require Protection? 1 Timestamp D No 2 Beacon interval S Yes 3 Capability 4 SSID 5 Supported rates 6, 7 PHY Parameter Set (FH, DS) 8 CF Parameter Set 9 IBSS Parameter Set 10 Traffic indication map (TIM) 11 Country (.h) 12 FH Parameters (.h) The Supported Rates element specifies up to eight rates in the Operational-Rate-Set parameter, The FH Parameter Set element contains the set of parameters necessary to allow synchronization for STAs using a FH PHY. The information field contains Dwell Time, Hop Set, Hop Pattern, and Hop Index parameters. The DS Parameter Set element contains information to allow channel number identification for STAs using a direct sequence spread spectrum (DSSS) PHY. The CF Parameter Set element contains the set of parameters necessary to support the PCF. The TIM element contains four fields: DTIM Count, DTIM Period, Bitmap Control, and Partial Virtual Bitmap. The Country information element contains the information required to allow a station to identify the regulatory domain in which the station is located and to configure its PHY for operation in that regulatory domain. Emily Qi, Intel Corporation Emily Qi, Intel Corporation

Information in Beacon (from .11ma-D4.0) cont. Month Year January 2006 March 2006 Information in Beacon (from .11ma-D4.0) cont. Order Information Static / Dynamic Require Protection? 13 FH Pattern Table (h) S Yes 14 Power Constraint (h) D 15 Channel Switch Announcement (h) 16 Quiet (h) 17 IBSS DFS (h) 18 TPC Report (h) 19 ERP Information 20 Extended Supported Rates 21 RSN (i) Yes (done) 22 Vendor Specific S, D The Power Constraint element contains the information necessary to allow a STA to determine the local maximum transmit power in the current channel. The TPC Report element contains transmit power and link margin information sent in response to a TPC Request element. A TPC Report element is included in a Beacon frame or Probe Response frame without a corresponding request. The Channel Switch Announcement element is used by an AP in a BSS or a STA in an IBSS to advertise when it is changing to a new channel and the channel number of the new channel. The Quiet element defines an interval during which no transmission shall occur in the current channel. This interval may The IBSS DFS element contains information for DFS operation in an IBSS. Emily Qi, Intel Corporation Emily Qi, Intel Corporation

Information in Beacon frame (.11e-D13.0) Month Year January 2006 March 2006 Information in Beacon frame (.11e-D13.0) Order Information Static / Dynamic Require Forgery Protection? 14 QBSS Load D Yes 15 EDCA Parameter Set 23 QoS Capability S: B4-B6 D: B0-B3 14 QBSS Load The QBSS Load information element is only present within Beacon frames generated by QAPs. The QBSS Load element is present when dot11QosOptionImplemented and dot11QBSSLoadImplemented are both true. 15 EDCA Parameter Set The EDCA Parameter Set information element is only present within Beacon frames generated by QAPs. The EDCA Parameter Set element is present when dot11QosOptionImplemented is true and the QoS Capability element is not present. 23 QoS Capability The QoS Capability information element is only present within Beacon frames generated by QAPs. The QoS Capability element is present when dot11QosOptionImplemented is true and EDCA Emily Qi, Intel Corporation Emily Qi, Intel Corporation