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

2. Month Year
September 2005
September 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.
Emily Qi, et al
Emily Qi, Intel Corporation

3. Agenda Design Goals and Overview Unicast Management Frame Protection
Month Year
September 2005
September 2005
Agenda
Design Goals and Overview
Unicast Management Frame Protection
Broadcast Management Frame Protection
Discovery and Negotiation
Proposal Summary
Emily Qi, et al
Emily Qi, Intel Corporation

4. Design Goals and Overview
Month Year
September 2005
September 2005
Design Goals and Overview
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
Emily Qi, et al
Emily Qi, Intel Corporation

5. Selected Management Frames
Month Year
September 2005
September 2005
Selected Management Frames
Design Goals and Overview
802.11w will provide protection scheme for selected Management Frames
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:
Class 3 Disassociation and Deauthentication
Class 3 Action frames, including
802.11e and h Action Frames
If k finishes before w, Radio Measurement Action frames for Infrastructure BSS
If v finishes before w, Radio Management Action frames
If r finishes before w, Fast Transitioning Reservation Action Frames
If n finishes before w, High Throughput Action Frames
TGw delegates (Re)association protection to TGr
The rest of this presentation refers to the frames noted in this slide as 'Management Frames'
Emily Qi, et al
Emily Qi, Intel Corporation

6. Feature Summary Approach reuses 802.11i protections
September 2005
Feature Summary
Approach reuses i protections
Capability and policy is advertised and negotiated
Forgery protection
All unicast Managements Frames
All broadcast Management Frames
Protection against insider forgery
All unicast Management Frames
Dissassociate and deauthenticate messages
Optionally available for broadcasts
Confidentiality
Unicast Management Frames
Emily Qi, et al

7. Unicast Management Frame Protection Overview
Month Year
September 2005
September 2005
Unicast Management Frame Protection
Unicast Management Frame Protection Overview
Unicast Management Frames are protected by the same cipher suite as a Unicast i data MPDUs
AES-CCMP is required to comply with specification
Protected Frame Subfield of Header Frame Control Field is set
Sender’s Pairwise Temporal Key protects Unicast data as well as 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
Emily Qi, et al
Emily Qi, Intel Corporation

8. Protected Unicast Management Frame Format
Month Year
September 2005
September 2005
Unicast Management Frame Protection
Protected Unicast Management Frame Format
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
Emily Qi, et al
Emily Qi, Intel Corporation

9. Broadcast Management Frame Protection Overview
September 2005
Broadcast Management Frame Protection
Broadcast Management Frame Protection Overview
Consistent approach for protection of all Broadcast Management Frames through new SAP
Prevent forgery of Broadcast Management Frames
“Basic” mode provides protection against forgery attacks
Insider attacks still feasible on Broadcast Management Frames (NOT on Disassociation/Deauthentication)
No confidentiality protection to enable mixed cell environments
“Advanced” mode provides additional protections
Protect against insider attack
Provide confidentiality protection and reliable delivery
Protection on Management Frames (not on Disassoc/Deauth) against insider attack available as policy option
Emily Qi, et al

10. Protected Broadcast Management Frame Format
Month Year
September 2005
September 2005
Broadcast Management Frame Protection
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
Emily Qi, et al
Emily Qi, Intel Corporation

11. Broadcast Management Frame Protection
September 2005
Broadcast Management Frame Protection
Forgery Protection
Broadcast KDE is used to distribute Integrity GTK (IGTK)
802.11w defines one cipher suite for broadcast management frames:
hash(string) = Truncate-128(SHA-256(string))
MIC(K, string) = AES-128-CMAC(K, string)
Provides a uniform MIC IE structure and encapsulation for all broadcast frames
Replay protection: Each receiver implements a new receive counter for Broadcast Action Frames
Emily Qi, et al

12. Insider Forgery Protection for Disassoc/Deauth
Month Year
September 2005
September 2005
Broadcast Management Frame Protection
Insider Forgery Protection for Disassoc/Deauth
If AP is enabled to enforce protection of broadcast management frames:
Generate a random value BKey whenever it selects a new IGTK (e.g. the key for protecting broadcast management frames). BKey must be unpredictable
Distributes the commitment value BCommit = hash(BSSID | SA | BKey) to w STAs whenever it distributes new BGTK
When AP sends broadcast Disassociation/Deauthenticate:
MIC IE includes BKey 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:
BCommit = hash( BSSID | SA | Bkey)
MIC is valid
Otherwise discard packet
Emily Qi, et al
Emily Qi, Intel Corporation

13. Transparent Handling of broadcast using a new SAP (MGMT_BCAST)
September 2005
Broadcast Management Frame Protection
Transparent Handling of broadcast using a new SAP (MGMT_BCAST)
SME
Broadcast Action Frame generated
(e.g. by TGk,TGv implementation)
MGMT_BCAST SAP
SAP
Protection mechanism applied according to selected policy
TGw Implementation
Frame(s) queued for transmission
Emily Qi, et al

14. Discovery and Negotiation
September 2005
Discovery and Negotiation
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 w broadcast
2-255
Vendor OUI
Other
Vendor specific
Any
Emily Qi, et al

15. Discovery and Negotiation
Month Year
September 2005
September 2005
Discovery and Negotiation
BUMP Negotiation
3 new RSN Capabilities to enable and enforce BUMP:
Bit 6: advertise ability to protect management frames
Bit 7: enable Protection of Management Frames
Bit 8: advertise policy for Broadcast Management Frames Protection
Bit Setting
Beacon / Probe Response Description
Negotiation in (Re)Association
Bit 6
Bit 7
Bit 8 x
Peer does not support BUMP 1
Invalid
BUMP is supported & optional
Peer supports BUMP but is disabled
BUMP is supported and enforced.
Broadcast Action frames are transmitted as unicast.
BUMP is supported and enabled.
Broadcast Action Frames are discarded (protected or not).
BUMP is supported and enforced. Broadcast Action frames are allowed and transmitted with potential insider attack.
BUMP is supported and enabled. Accepts protected Broadcast Action frames.
Emily Qi, et al
Emily Qi, Intel Corporation

16. Month Year
September 2005
September 2005
Proposal Summary
Highlights
Extend i Unicast data protection for Unicast 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 negotiation for Management Frames Protection
Emily Qi, et al
Emily Qi, Intel Corporation

17. Month Year
September 2005
September 2005
Proposal Summary
Work-in-Progress
TKIP: If STA only supports TKIP for data protection, the possible solutions for Unicast Management Frames are:
No protection for Management Frames
Extending TKIP to Management Frame Protection
Association MAC Address (AMID)
Commitment value in Open Authentication for Class 2 Disassociation protection
Emily Qi, et al
Emily Qi, Intel Corporation

18. September 2005
Feedback?
Emily Qi, et al

19. Unicast: Cipher Suites and Keys
September 2005
Unicast Management Frame Protection
Unicast: Cipher Suites and Keys
Support for the AES-CCMP cipher suite is required to comply with w
AES-CCMP support must be 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 or TKIP to protect Management Frames - TKIP support issue is open to discuss
WEP is not secure
TKIP has already passed through about half of the five years we expected it to resist attack.
Emily Qi, et al

20. Unicast: Replay Protection
Month Year
September 2005
September 2005
Unicast Management Frame Protection
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
Emily Qi, et al
Emily Qi, Intel Corporation

21. Broadcast Management Frame Protection
September 2005
Broadcast Management Frame Protection
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 octets) = – 1
For disassociate/deauthenticate BKey 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
Emily Qi, et al

22. Broadcast: Key KDE and Cipher Suite
Month Year
September 2005
September 2005
Broadcast Management Frame Protection
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)
802.11w defines one cipher suite for broadcast management frames:
hash(string) = Truncate-128(SHA-256(string))
MIC(K, string) = AES-128-CMAC(K, string)
Emily Qi, et al
Emily Qi, Intel Corporation

23. Broadcast: Replay protection
September 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
Emily Qi, et al

24. Broadcast Management Frame Protection
Month Year
September 2005
September 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.
Emily Qi, et al
Emily Qi, Intel Corporation

25. Negotiation: Message Flow 1 (802.11i classic)
Month Year
September 2005
September 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
Emily Qi, et al
Emily Qi, Intel Corporation

26. Negotiation: Message Flow 2 (802.11r)
September 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
Emily Qi, et al