Broadcast and Unicast Management Protection (BUMP)

Broadcast and Unicast Management Protection (BUMP)
Month Year September 2005 November 2005 Broadcast and Unicast Management Protection (BUMP) 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 BUMP Consortium Emily Qi, Intel Corporation

Month Year September 2005 November 2005 Abstract This submission proposes a set of mechanisms to protect IEEE selected management frames. The submission proposes forgery and confidentiality protection for unicast management frames, and forgery-only protection for broadcast management frames. Proposal Text Doc#: w-normative-text-bump-proposal BUMP Consortium Emily Qi, Intel Corporation

Agenda Design Goals Protected Management Frames Overview
Month Year September 2005 November 2005 Agenda Design Goals Protected Management Frames Overview Protection for Unicast Protection Protection for Broadcast Protection Advertisements Design Choices Proposal Text Walkthrough BUMP Consortium Emily Qi, Intel Corporation

Month Year September 2005 November 2005 Design Goals Protect Unicast Management Frames from forgery and disclosure Protect Broadcast Management Frames from forgery Allow w and non w devices to co-exist 802.11w must be optional for backward compatibility, but policy option must exist to mandate the feature Utilize existing security mechanisms where possible Unify protection schemes where possible Meet the requirement doc # r2 BUMP Consortium Emily Qi, Intel Corporation

Protection Management Frames Overview
Month Year September 2005 November 2005 Protection Management Frames Overview State 3 Management Frames 11r, 11k Robust Management Frames (Insider Forgery protection) Broadcast Management Frames Unicast Management Frames MUP MUP sends Broadcast as Unicast Frames BIP CCMP TKIP (HC IE) Confidentiality, Integrity, Replay, Source Authentication DeAuth, DisAssoc Action Frames Integrity, Replay, Source Authentication Integrity, Replay BUMP Consortium Emily Qi, Intel Corporation

Robust Management Frames
Month Year September 2005 November 2005 Robust Management Frames 802.11w will provide protection scheme for selected Management Frames, called “Robust” Frames which are sent after key establishment Frames which are sent before key establishment are unprotected Can be protected using the key hierarchies, including those from amendments under development The Selected Unicast and Broadcast Management Frames are: State 3 Disassociation and Deauthentication State 3 Action frames, including 802.11e and h Action Frames Other amendments that complete after w can utilize the w mechanisms to protect State 3 Action Frames TGw delegates (Re)association protection to TGr The rest of this presentation refers to the frames noted in this slide as ‘Robust Management Frames' BUMP Consortium Emily Qi, Intel Corporation

Unicast Management Frame Protection Overview
Month Year September 2005 November 2005 Unicast Management Frame Protection Overview Unicast Management Frames are protected by the same cipher suite as a Unicast i data MPDUs AES-CCMP and TKIP Protected Frame Subfield of Header Frame Control Field is set Sender’s Pairwise Temporal Key protects Unicast data as well as Robust Management Frames Transmitter uses a different unique PN as the IV for Management Frame Each receiver implements a new receive counter for Management Frames FC bits 11, 12, 13, SC bits 4-15 set to zero, FC bit 14 set to 1 for the MIC computation BUMP Consortium Emily Qi, Intel Corporation

Protected Unicast Management Frame Format using CCMP
Month Year September 2005 November 2005 Protected Unicast Management Frame Format using CCMP Original Unicast Mgmt Frame: hdr Mgmt frame body FCS Use the same cryptographic algorithm selected for Data MPDUs Protected Unicast Mgmt Frame: hdr 802.11i header Mgmt frame body MIC FCS Authenticated by MIC Encrypted Key ID Cryptographic Message Integrity Code to defeat forgeries IV Encryption used to provide confidentiality IV used as frame sequence space to defeat replay BUMP Consortium Emily Qi, Intel Corporation

Unicast Management Frames Protection Using TKIP
Month Year September 2005 November 2005 Unicast Management Frames Protection Using TKIP Goals Driven by market need, to extend support to existing TKIP deployments To not change the TKIP cipher suite To re-use the same key, as used for data No hardware change, hence, easier field upgrades Capability Used only when TKIP for data is selected, and Robust Management Frame protection is required BUMP Consortium Emily Qi, Intel Corporation

Protected Unicast Management Frame Format for TKIP
Month Year September 2005 November 2005 Protected Unicast Management Frame Format for TKIP Original Unicast Mgmt Frame: hdr Mgmt frame body FCS Use same TKIP algorithm Create HC IE Protected Unicast Mgmt Frame: hdr TKIP header MIC/ICV FCS Management Frame Body Header Clone (HC) IE Encrypted Integrity (Michael) Michael Message Integrity Code to defeat forgeries BUMP Consortium Emily Qi, Intel Corporation

Steps to process MMPDU with TKIP
Month Year September 2005 November 2005 Steps to process MMPDU with TKIP Steps Create Robust Management Frame (MMPDU), incl. header Create a new Header Clone (HC) Information Element from Robust Management Frame Header Append HC IE to Robust Management Frame Process (Robust Management Frame + HC IE) through TKIP Fragmentation, if needed BUMP Consortium Emily Qi, Intel Corporation

Broadcast Management Frame Protection Overview
Month Year September 2005 November 2005 Broadcast Management Frame Protection Overview Consistent approach for protection of all Broadcast Management Frames through new SAP Prevent forgery of Broadcast Management Frames Insider attacks still feasible on Broadcast Robust Management Frames (NOT on Disassociation/Deauthentication) Multiple Unicast Protocol (MUP) mode provides additional protections MUP sends broadcast frames as confidentiality protected unicast Protect against forgery (including insider attack) MUP is a MIB settable policy option BUMP Consortium Emily Qi, Intel Corporation

Protected Broadcast Management Frame Format
Month Year September 2005 November 2005 Protected Broadcast Management Frame Format Original Broadcast Mgmt Frame: hdr Mgmt frame body FCS Use the advertised mgmt broadcast cipher suite Protected Broadcast Mgmt Frame: hdr Mgmt frame body Management MIC IE FCS Authenticated by MIC (MIC computed through Mgmt MIC IE Sequence Num field) Cryptographic Message Integrity Code to defeat forgeries BUMP Consortium Emily Qi, Intel Corporation

Robust Broadcast Management Protection Cipher Operations
Month Year September 2005 November 2005 Robust Broadcast Management Protection Cipher Operations Broadcast KDE used to distribute Integrity GTK (IGTK) and CV 802.11w defines cipher suite for broadcast management frames: hash(string) = Truncate-128(SHA-256(string)) MIC(K, string) = AES-128-CMAC(K, string) Provides uniform MIC IE structure and encapsulation Replay protection: Each receiver implements a new receive counter for Broadcast Robust Action Management Frames BUMP Consortium Emily Qi, Intel Corporation

Insider Forgery Protection for Broadcast Disassoc/Deauth
Month Year September 2005 November 2005 Insider Forgery Protection for Broadcast Disassoc/Deauth If AP is enabled to enforce protection of broadcast management frames: Generate a random, unpredictable value CGTK whenever it selects a new IGTK (e.g. the key for protecting broadcast management frames). Distributes the commitment value CV = hash(AA | SA | CGTK) to w STAs when it distributes IGTK When AP sends broadcast Disassociation/Deauthenticate: MIC IE includes CGTK as the sequence number, length is updated to 26 Full packet is MIC’ed per the w broadcast protection (except for muted bits per slide 3) When an w STA receives a protected broadcast, accept frame if: CV = hash( AA | SA | CGTK) MIC is valid Otherwise discard packet BUMP Consortium Emily Qi, Intel Corporation

Broadcast: Key KDE and Cipher Suite
Month Year September 2005 November 2005 Broadcast: Key KDE and Cipher Suite Type Length OUI Data Type Code PN KeyID Broadcast Key 1 octet 1 octet 3 octets 1 octet 1 octet 6 octets 2 octets 16 octets Type value = 0xdd Length value = 29 OUI value = 00-0F-AC Data Type value = 5 Code value = SCommit (1), ACommit (2), or BCommit (3) PN = current Sequence Num value in Management MIC IE KeyID = Key ID identifying Broadcast key in Management MIC IE Key ID field (values is in the range – 1) BUMP Consortium Emily Qi, Intel Corporation

Month Year September 2005 November 2005 RSN IE Updates Allocate bits of the RSN IE Capability field for w Add a Broadcast management cipher suite field Element ID Len Ver Group Cipher Pairwise Cipher Suite Count Pairwise Cipher Suite List AKM count AKM List RSN capabilities PMKID count PMKID List BUMP Group Cipher 1 2 4 4*m 4*n 3 16*s RSN Capability fields Bits Pre-auth No pairwise 1 PTKSA replay counter 2:3 GTKSA replay counter 4:5 BUMP supported 6 BUMP mandatory 7 BUMP Broadcast Protection 8 Reserved 9:15 Suite Broadcast Cipher Suite Selector 00-0F-AC Reserved 1 AES-128-CMAC – default for BIP in Robust Management RSNA 2-255 Vendor OUI Other Vendor specific Any BUMP Consortium Emily Qi, Intel Corporation

BUMP Advertisements November 2005
Month Year September 2005 November 2005 BUMP Advertisements 2 new RSN Capabilities to enable and enforce BUMP: Bit 6: advertise ability to protect management frames Bit 7: enable Protection of Management Frames MUP policy set through a MIB variable Bit Setting Advertisement in Beacon, Probe Response and 3rd message of the 4-way handshake Description Negotiation in (Re)association request and 2nd message of the 4-way handshake Description Robust management frame protection supported Robust management frame protection required Bit 6 Bit 7 No support for Robust management frame protection is provided. No support for Robust management frame protection is negotiated. 1 Invalid Support for Robust management frame protection is optional. Support for Robust management frame protection is disabled. Support for Robust management frame protection is required.. Support for Robust management frame protection is enabled. BUMP Consortium Emily Qi, Intel Corporation

Month Year September 2005 November 2005 Proposal Summary Extend i Unicast data protection for Unicast Robust Management Frame protection - forgery and confidentiality protection Consistent approach for protection of all broadcast management frames from forgery Allow w and non w devices to co-exist Policy discovery and advertisements for Management Frames Protection BUMP Consortium Emily Qi, Intel Corporation

Design choices General approach
Month Year September 2005 November 2005 Design choices General approach An extensive proposal covering all the requirements from doc Proposed algorithms to cover those requirements Reduced the number of mechanisms for simplicity Unified unicast solution fairly straightforward Extension of i for all unicast management frames Use of commitment values in pre i 4-whs messages discussed, but… Coexistence with legacy devices an issue Secure negotiation of 11w impossible before the 4WHS BUMP Consortium Emily Qi, Intel Corporation

Design choices Unified broadcast protection more problematic
Month Year September 2005 November 2005 Design choices Unified broadcast protection more problematic r0 (Protecting Broadcast Management Frames) introduced the difficulties and possible algorithms No good algorithm to provide forgery protection against insider attackers Confidentiality doable, but the key needs to be updated every time somebody joins or leaves the group Alternative algorithms to BIP and MUP either Presented weaknesses Had too high an overhead for current broadcast management frames Introduced delays potentially unacceptable Weren't compatible with the frame loss rates in real deployments BUMP Consortium Emily Qi, Intel Corporation

Month Year September 2005 November 2005 Design choices No good “single” solution for all broadcast management frames, but… Commitment value (CV) protection mechanism simple and efficient for broadcast deauth and disassociate Not extensible to all broadcast management messages Optimized the "most likely deployment" with simple mechanisms AES-CMAC for forgery protection against outsider attacks CV for forgery protection with source authentication for broadcast deauth and disassociate MUP Option for full protection with broadcast sent as unicast Most efficient algorithm, or so it seems… BUMP Consortium Emily Qi, Intel Corporation

Feedback? November 2005 Month Year September 2005 BUMP Consortium
Emily Qi, Intel Corporation

Backup November 2005 Month Year September 2005 BUMP Consortium
Emily Qi, Intel Corporation

Comparison of broadcast protection mechanisms
Month Year September 2005 November 2005 Comparison of broadcast protection mechanisms AES-CMAC Commitment Value MUP Tesla ACK'ed broadcast Overview Use IGTK to compute MIC Key chain based on a one-way function Send broadcast as multiple unicast Key chains based on a one-way function Send a broadcast, and confirm it by sending hashes (either unicast or broadcast) Pros Forgery protection against outsider attacks FIPS approved Forgery protection against all attacks - Forgery protection against all attacks Trivial implementation Reliable broadcast - Reliable broadcast possible Cons No protection against insider attacks Only applicable to Deauth and Disassociation Is equivalent to forbidding broadcast… Can be defeated Need to buffer frames and keys New hardware needed - Unicast less efficient than MUP for current management frames Reliability issues New hardware potentially needed BUMP Consortium Emily Qi, Intel Corporation

Unicast: Cipher Suites and Keys
Month Year September 2005 November 2005 Unicast: Cipher Suites and Keys AES-CCMP and TKIP support is extended to protect unicast Management Frames Management Frame unicast Key = same Temporal Key as used by the pairwise cipher suite The proposal is to not extend WEP to protect Management Frames WEP is not secure BUMP Consortium Emily Qi, Intel Corporation

Unicast: Replay Protection
Month Year September 2005 November 2005 Unicast: Replay Protection Transmitter uses next PN as the IV Use sequence number given by PN/TSC to protect payload and increment counter Each receiver implements a new receive counter for Management Frames The new receive counter initialized to zero during the 4-Way Handshake Sequence number in received protected Management Frame is compared with new counter value If received sequence number does not exceed last valid value, discard the frame as a replay If received sequence number exceeds last valid value and the Management Frame validates correctly, accept the frame and set counter value to received sequence number value BUMP Consortium Emily Qi, Intel Corporation

Management MIC IE Element ID (1 octet) = TBD
Month Year September 2005 November 2005 Management MIC IE Element ID Length = 16 or 26 Key ID Sequence Num/ BKey MIC Value Element ID (1 octet) = TBD Length (1 octet) = size of this IE Key ID (2 octet) = broadcast key identifier Bits – key id: 213 = 8192 key identifiers (4096 multicast groups) Bits 13, 14, 15 – reserved and set to 0 Sequence Num (6 or 16 octets) = – 1 For disassociate/deauthenticate CGTK is used (16 octets) MIC Value (8 octets) = MIC of the packet FC bits 11, 12, 13, SC bits 4-15 set to zero, FC bit 14 set to 1 BUMP Consortium Emily Qi, Intel Corporation

Broadcast: Replay protection
Month Year September 2005 November 2005 Broadcast Management Frame Protection Broadcast: Replay protection Each receiver implements a new receive counter for Broadcast Action Frames The new receive counter initialized to PN field in the received broadcast key Sequence number in broadcast protected broadcast management frame is compared with new counter value If received sequence number does not exceed last valid value, discard the frame as a replay If received sequence number exceeds last valid value and the broadcast management Frame validates correctly, accept the frame and set counter value to received sequence number value BUMP Consortium Emily Qi, Intel Corporation

Broadcast Management Frame Protection
Month Year September 2005 November 2005 Broadcast Management Frame Protection Transparency Use of the MGMT_SAP means that implementations of new management functions (e.g. TGk, TGv) do not need to change behaviour depending on negotiated protection mechanism If normal security option is selected (MIC only and no insider protection) frame is protected according to TGw and forwarded If Advanced security option is selected (copy of broadcast sent to each station via unicast protection) then the TGw implementation makes one copy of the broadcast for each connected station. BUMP Consortium Emily Qi, Intel Corporation

Negotiation: Message Flow 1 (802.11i classic)
Month Year September 2005 November 2005 Discovery and Negotiation Negotiation: Message Flow 1 (802.11i classic) Access Point Station Probe Request Beacon or Probe Response + AP RSN-IE Association Req + STA RSN-IE Association Response (success) 4-Way HS Msg 2 + STA RSN-IE 4-Way HS Msg 3 + AP RSN-IE BUMP Consortium Emily Qi, Intel Corporation

Negotiation: Message Flow 2 (802.11r)
Month Year September 2005 November 2005 Discovery and Negotiation Negotiation: Message Flow 2 (802.11r) Access Point Station Probe Request Beacon or Probe Response + AP RSN-IE Reassociation Req + STA RSN-IE Ressociation Response + AP RSN-IE BUMP Consortium Emily Qi, Intel Corporation

Broadcast and Unicast Management Protection (BUMP)

Similar presentations

Presentation on theme: "Broadcast and Unicast Management Protection (BUMP)"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Broadcast and Unicast Management Protection (BUMP)

Similar presentations

Presentation on theme: "Broadcast and Unicast Management Protection (BUMP)"— Presentation transcript:

Similar presentations

About project

Feedback