Broadcast Management Frame Protection Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2006 Broadcast Management Frame Protection Date: March 06, 2006 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>. S. Bezzateev, A. Fomin, M. Wong John Doe, Some Company

Main Idea Authentication of Broadcast Management Frames (BMF) Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2006 Main Idea Authentication of Broadcast Management Frames (BMF) MIC for Broadcast Management Frames are sent in Maintenance Beacon Key for MIC is disclosed in Broadcast Management Frames Keys form hash chain and are assigned to the Beacon Intervals Key should be sent in different interval than MIC (after) Two intervals should be defined Maintenance Beacon waiting period Broadcast Frames waiting period If MIC or Key is received in the wrong interval, then they should be ignored S. Bezzateev, A. Fomin, M. Wong John Doe, Some Company

Waiting Periods Maintenance Beacon is sent immediately after Beacon Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2006 Waiting Periods Maintenance Beacon is sent immediately after Beacon Beacon could be delayed Delay is caused by unfinished transmission started in previous Beacon Interval (medium is busy) Maintenance Beacon waiting period Start: nominal beacon transmission time End: max delay + PIFS + max Beacon + SIFS + Maintenance Beacon Max delay = RTS + CTS + MPDU of maximum length + ACK + 3*SIFS Broadcast Management Frames waiting period Start: end of Maintenance Beacon waiting period End: end of Beacon interval S. Bezzateev, A. Fomin, M. Wong John Doe, Some Company

Authentication Details Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2006 Authentication Details BMi – beacon sent in i-th beacon interval BMFij – j-th broadcast management frame sent in i-th beacon interval Check that Maintenance Beacon was received during appropriate Maintenance Beacon waiting period Broadcast Management Frames were received during appropriate Broadcast Management Frames waiting period Disclosed key belongs to the hash chain Disclosed key is assigned to the current Beacon Interval MIC is valid and was calculated using disclosed key Otherwise all received BMFs are dropped S. Bezzateev, A. Fomin, M. Wong John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2006 Hash Chain - I Keys t Kj-1 Kj K0 Kj-1=H(Kj) K0 – public key j-1 j 1 Kn IGTK is used as a seed to calculate a “seed” chain SKn such that SKn = H(IGTK, n) The SKs are used as pseudo random seeds to precompute the hash chain such that Ki=H(Ki+1) Kn = seed from the “seed” chain AP discloses one key during each beacon interval S. Bezzateev, A. Fomin, M. Wong John Doe, Some Company

Hash Chain - II Trivial approaches for calculating current key Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2006 Hash Chain - II Trivial approaches for calculating current key Store only Kn and calculate Ki=Hi(Kn) (high complexity) Store the whole chain (high memory requirements) Alternative Approach Markus Jakobsson, Fractal Hash Sequence Representation and Traversal Memory requirements: O(logn) Complexity: O(logn) hash function evaluation per key S. Bezzateev, A. Fomin, M. Wong John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2006 Time Synchronization Synchronization is performed using timestamp received in Beacon But Beacon is not protected Attacker could sent bogus Beacon, which desynchronizes AP and STAs inject bogus BMFs using keys from valid Beacon Protected synchronization is needed S. Bezzateev, A. Fomin, M. Wong John Doe, Some Company

Proposed Synchronization Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2006 Proposed Synchronization Add new timer, which is used for security purposes, i.e. for controlling of waiting periods assignment between keys and beacon interval Add MIC of Beacon calculated using current key from hash chain into the Maintenance Beacon Adjust security timer only when MIC of Beacon is verified S. Bezzateev, A. Fomin, M. Wong John Doe, Some Company

Disclosing of Previous Key Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2006 Disclosing of Previous Key We need to include previous key into the Maintenance Beacon To synchronize security timer, when no BMFs are sent To decrease complexity of verification of disclosed key, if BMFs were not received during long time S. Bezzateev, A. Fomin, M. Wong John Doe, Some Company

Maintenance Beacon Format Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2006 Maintenance Beacon Format Order Information 1 Previous Key 2 Beacon MIC 3 BMFs Number 4 BMFs MIC 5 Management MIC IE Beacon MIC and BMFs MIC are calculated on the current key from the hash chain MIC from Management MIC IE is calculated on the IGTK S. Bezzateev, A. Fomin, M. Wong John Doe, Some Company

Broadcast Management Frame Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2006 Broadcast Management Frame 802.11 Header Management Frame Body Management MIC IE FCS Element ID Length Key SN Key ID MIC Octets 1 0 or 16 6 2 8 Management MIC IE Key is the current key from the hash chain MIC from Management MIC IE is calculated on the IGTK S. Bezzateev, A. Fomin, M. Wong John Doe, Some Company