1. Beacon Content Protection
Month Year
January 2006
January 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
January 2006
Abstract
This submission proposes methods to protect Beacon content from forgery.
Emily Qi, Intel Corporation
Emily Qi, Intel Corporation

3. Agenda Problem Statement Characteristics of Beacon Contents
Month Year
January 2006
January 2006
Agenda
Problem Statement
Characteristics of Beacon Contents
Proposal Overview
Q&A, Straw Poll
Emily Qi, Intel Corporation
Emily Qi, Intel Corporation

4. Month Year
January 2006
January 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.
Emily Qi, Intel Corporation
Emily Qi, Intel Corporation

5. Characteristics of Beacon Contents
Month Year
January 2006
January 2006
Characteristics of Beacon Contents
Static Information that is not changed at runtime
Capability and network information
Tells a STA not associated with this BSS about the BSS
Dynamic Information that changes at runtime
e.g., TIM, STA configuration, and BSS operation
Required STA configuration
BSS operation and maintenances
Tells any STA about the changing environment around this BSS, including associated STAs
Emily Qi, Intel Corporation
Emily Qi, Intel Corporation

6. Month Year
January 2006
January 2006
Proposal Overview
Convey the static Beacon information in 4-way handshake Messages
Similar to the RSN IE protection
Insert the static information into Message 3 of 4-way handshake Messages
It is inappropriate to protect dynamic BSS information in this way
Send the updated or dynamic information elements in Maintenance Beacon
Maintenance Beacon is Class 3 broadcast Action Frame
Protected by w
Maintenance Beacon will be sent periodically
Maintenance Beacon Interval field
Advertised in the Beacon, indicates how often Maintenance Beacon is sent
An AP shall advertise it sends maintenance beacons by setting bit X of the RSN IE Capabilities field if Beacon Content Protection is designed as an optional feature in .11w
Emily Qi, Intel Corporation
Emily Qi, Intel Corporation

7. Static Beacon Information Protection
Month Year
January 2006
January 2006
Static Beacon Information Protection
In the Key Data field of 4-Way Handshake Message 3, the authenticator’s SME inserts the static beacon information.
The Supplicant’s SME validates the static Beacon fields against the information received in Message 3.
If the values do not match, the receiving STA considers the Beacon as a forgery and may de-authenticate
Deauthentication is not mandatory, as the authenticated Beacon parameters may meet the STA’s needs
If the values match, the receiver considers the Beacon as genuine.
The same mechanism can be applied to the static fields from a Probe Response.
Emily Qi, Intel Corporation
Emily Qi, Intel Corporation

8. Proposed New Message 3 Format
Month Year
January 2006
January 2006
Proposed New Message 3 Format
Key Descriptor Type (1 octet)
Key Information (2 octets)
Key Length (2 octets)
NEKey Replay Counter (8 octets)
ANonce (32 octets)
Key MIC (16 octets)
Key Data Length (2 octets)
RSN IE, GTK, static beacon information fields and IEs
Emily Qi, Intel Corporation
Emily Qi, Intel Corporation

9. Proposed Maintenance Beacon
Month Year
January 2006
January 2006
Proposed Maintenance Beacon
Class 3, Broadcast, Periodic, Action Frames
Frame format:
Category
Action
Length
Dynamic Beacon information elements
Order: 1 2
variables
Dynamic Beacon Information Elements shall include:
TIM
Dynamic .11h IEs: Power Constraint, Channel Switch Announcement , Quiet and IBSS DFS
Dynamic .11e IEs: QBSS Load, EDCA Parameter Set and QoS Capability
Potential .11k IEs, .11r IEs, .11v IEs
Emily Qi, Intel Corporation
Emily Qi, Intel Corporation

10. Usages January 2006 Month Year January 2006
Emily Qi, Intel Corporation
Emily Qi, Intel Corporation

11. Backward and Forward Compatibility
Month Year
January 2006
January 2006
Backward and Forward Compatibility
Non-.11w STA will use the information received from the regular beacon
The other Task Groups (TGr, TGu, TGv, etc.) should consider
Including new dynamic Beacon information in the Maintenance Beacon
Including new static Beacon information in the Message 3 of 4-way handshake messages, as well as the regular Beacon
If .11w is disabled, the Maintenance Beacon is still sent, but without protection.
Emily Qi, Intel Corporation
Emily Qi, Intel Corporation

12. Proposal Value Proposition
Month Year
January 2006
January 2006
Proposal Value Proposition
Provides a function that other Task Groups have been asking for
Protect Beacon and Probe Response contents from Forgery
Utilizes existing security mechanisms and doesn’t need new key hierarchy
Can be extended for new “Beacon” contents
Backward compatible with non-.11w STA/AP
Emily Qi, Intel Corporation
Emily Qi, Intel Corporation

13. Why Not add a MIC IE to Existing Beacon?
Month Year
January 2006
January 2006
Why Not add a MIC IE to Existing Beacon?
If the receiving STA can recognize the MIC IE, then it is obligated to either verify the MIC are else discard the message as a forgery
But it cannot verify the MIC prior to session key establishment
Even if it had a key, it could not distinguish the message from a replay, so security says it must treat the message as a forgery
Replay counters are established at session setup
If the receiving STA can recognize the MIC IE, then it knows the message was not intended for it when it does not have the session key
The only proper action is to ignore messages intended for someone else
unicast is already based on this principle, since every STA can receive any message addressed to another party
Emily Qi, Intel Corporation
Emily Qi, Intel Corporation

14. Q&A January 2006 Month Year January 2006 Emily Qi, Intel Corporation

15. Month Year
January 2006
January 2006
Straw Poll
We would like to see normative text for the beacon protection scheme specified herein.
Yes:
No:
Emily Qi, Intel Corporation
Emily Qi, Intel Corporation

16. Backup January 2006 Month Year January 2006
Emily Qi, Intel Corporation
Emily Qi, Intel Corporation

17. Information in Beacon frame (.11ma-D4.0)
Month Year
January 2006
January 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

18. Information in Beacon (from .11ma-D4.0) cont.
Month Year
January 2006
January 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

19. Information in Beacon frame (.11e-D13.0)
Month Year
January 2006
January 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