January 2006 doc IEEE 802 11 060038 r

January 2006 doc. : IEEE 802. 11 -06/0038 r 0 Beacon Content Protection Authors: Date: 2006 -01 -10 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: // ieee 802. 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>. Submission 1 Emily Qi, Intel Corporation

January 2006 doc. : IEEE 802. 11 -06/0038 r 0 Abstract This submission proposes methods to protect Beacon content from forgery. Submission 2 Emily Qi, Intel Corporation

January 2006 doc. : IEEE 802. 11 -06/0038 r 0 Agenda • • Problem Statement Characteristics of Beacon Contents Proposal Overview Q&A, Straw Poll Submission 3 Emily Qi, Intel Corporation

January 2006 doc. : IEEE 802. 11 -06/0038 r 0 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. 11 i 4 Way Handshake. Submission 4 Emily Qi, Intel Corporation

January 2006 doc. : IEEE 802. 11 -06/0038 r 0 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 Submission 5 Emily Qi, Intel Corporation

January 2006 doc. : IEEE 802. 11 -06/0038 r 0 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 802. 11 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. 11 w Submission 6 Emily Qi, Intel Corporation

January 2006 doc. : IEEE 802. 11 -06/0038 r 0 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. Submission 7 Emily Qi, Intel Corporation

January 2006 doc. : IEEE 802. 11 -06/0038 r 0 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) Submission RSN IE, GTK, static beacon information fields and IEs 8 Emily Qi, Intel Corporation

January 2006 doc. : IEEE 802. 11 -06/0038 r 0 Proposed Maintenance Beacon • Class 3, Broadcast, Periodic, Action Frames • Frame format: Category Action Length 1 2 2 Order: Dynamic Beacon information elements variables • Dynamic Beacon Information Elements shall include: – TIM – Dynamic. 11 h IEs: Power Constraint, Channel Switch Announcement , Quiet and IBSS DFS – Dynamic. 11 e IEs: QBSS Load, EDCA Parameter Set and Qo. S Capability – Potential. 11 k IEs, . 11 r IEs, . 11 v IEs Submission 9 Emily Qi, Intel Corporation

January 2006 doc. : IEEE 802. 11 -06/0038 r 0 Usages Submission 10 Emily Qi, Intel Corporation

January 2006 doc. : IEEE 802. 11 -06/0038 r 0 Backward and Forward Compatibility • Non-. 11 w 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. 11 w is disabled, the Maintenance Beacon is still sent, but without protection. Submission 11 Emily Qi, Intel Corporation

January 2006 doc. : IEEE 802. 11 -06/0038 r 0 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-. 11 w STA/AP Submission 12 Emily Qi, Intel Corporation

January 2006 doc. : IEEE 802. 11 -06/0038 r 0 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 – 802. 11 unicast is already based on this principle, since every STA can receive any message addressed to another party Submission 13 Emily Qi, Intel Corporation

January 2006 doc. : IEEE 802. 11 -06/0038 r 0 Q&A Submission 14 Emily Qi, Intel Corporation

January 2006 doc. : IEEE 802. 11 -06/0038 r 0 Straw Poll We would like to see normative text for the beacon protection scheme specified herein. Yes: No: Submission 15 Emily Qi, Intel Corporation

January 2006 doc. : IEEE 802. 11 -06/0038 r 0 Backup Submission 16 Emily Qi, Intel Corporation

January 2006 doc. : IEEE 802. 11 -06/0038 r 0 Information in Beacon frame (. 11 ma-D 4. 0) Order Information Static / Require Dynamic Protection? 1 Timestamp D No 2 Beacon interval S Yes 3 Capability S Yes 4 SSID S Yes 5 Supported rates S Yes 6, 7 PHY Parameter Set (FH, DS) S Yes 8 CF Parameter Set S Yes 9 IBSS Parameter Set S Yes 10 Traffic indication map (TIM) D Yes 11 Country (. h) S Yes 12 FH Parameters (. h) S Yes Submission 17 Emily Qi, Intel Corporation

January 2006 doc. : IEEE 802. 11 -06/0038 r 0 Information in Beacon (from. 11 ma-D 4. 0) cont. Order Information Static / Require Dynamic Protection? 13 FH Pattern Table (h) S Yes 14 Power Constraint (h) D Yes 15 Channel Switch Announcement (h) D Yes 16 Quiet (h) D Yes 17 IBSS DFS (h) D Yes 18 TPC Report (h) D Yes 19 ERP Information S Yes 20 Extended Supported Rates S Yes 21 RSN (i) S Yes (done) 22 Vendor Specific S, D Yes Submission 18 Emily Qi, Intel Corporation

January 2006 doc. : IEEE 802. 11 -06/0038 r 0 Information in Beacon frame (. 11 e-D 13. 0) Order Information Static / Dynamic Require Forgery Protection? 14 QBSS Load D Yes 15 EDCA Parameter Set D Yes 23 Qo. S Capability S: B 4 -B 6 D: B 0 -B 3 Yes Submission 19 Emily Qi, Intel Corporation