1. Beacon Content Protection
Month Year
January 2006
March 2006
Beacon Content Protection
Date:
Authors:
Notice: This document has been prepared to assist IEEE 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
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < 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 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Emily Qi, Intel Corporation
Emily Qi, Intel Corporation

2. Month Year
January 2006
March 2006
Abstract
This submission examines all the 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

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

4. 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 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 , is after the i 4-Way Handshake.
Examine ways to protect Beacons from forgery
Emily Qi, Intel Corporation
Emily Qi, Intel Corporation

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

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

7. 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
An unassociated STA will make the “wrong” decision when it receives a genuine 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
But it is no worse than i in this dimension
Emily Qi, Intel Corporation
Emily Qi, Intel Corporation

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

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

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

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

12. 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
Replicate dynamic parameters in a protected “Maintenance Beacon”
Maintenace Beacons intended only for associated STAs
MICs are dynamic, so can’t be verified until after a session key is in place
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
Emily Qi, Intel Corporation
Emily Qi, Intel Corporation

13. Indirect Protection Issues
Month Year
January 2006
March 2006
Indirect Protection Issues
Affords unassociated STAs with some protection, but only after association
STA still have to commit to association before learning the Beacon is from a rogue
Hence STAs can still make “wrong” decisions on the basis of forgeries, but can recover and look for alternate AP
The lack of access to dynamic fields in the Beacon is a serious loss of functionality
Emily Qi, Intel Corporation
Emily Qi, Intel Corporation

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

15. 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
No good reason exists to protect hints, because the STA can choose an alternate AP if it is forged
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
There is great benefit from protecting this information
Emily Qi, Intel Corporation
Emily Qi, Intel Corporation

16. Is Protection Necessary?
Month Year
January 2006
March 2006
Is Protection Necessary?
If static Beacon parameters are forged, then
An associated STA doesn’t care if static parameters are changed, because it won’t look at or adjust the static values
If an unassociated STA relies on a forged static parameter value that prevents it from associating, the STA will go to another AP
If an unassociated STA relies on a forged static parameter value that 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
The “real” Beacon will appear within one Beacon interval, and it will get the “right” parameter value
However, an associated STA will oscillate between the correct and incorrect value
Emily Qi, Intel Corporation
Emily Qi, Intel Corporation

17. Month Year
January 2006
March 2006
Analysis Conclusions
No mechanism has been suggested to protect dynamic Beacon contents for unassociated STAs
There appears to be little value in protecting static Beacon parameters for any STA
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

18. 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 this seems to have little value
Replicate critical dynamic parameters in another message than can be protected by w
E.g., the k Neighbor Report
STAs receive the neighbor report after the 4-Way Handshake, so it can be protected by normal w 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

19. 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 proposed Beacon protection scheme meets its alleged goals
All fall to replay, and either reduce functionality or fail to meet some protection goal
The dual usage of Beacons makes them the wrong delivery vehicle for conveying dynamic Beacon parameters
Alternate mechanisms like k Neighbor Report are more plausible vehicles for conveying protected dynamic parameters
Emily Qi, Intel Corporation
Emily Qi, Intel Corporation

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

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

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

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

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