1. Options for Protecting Management Frames
Month Year
March 2005
May 2005
Options for Protecting Management Frames
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
Nancy Cam-Winget, Cisco
Emily Qi, Intel Corporation

2. Design Goals Protect Management frames from replay and forgery
Month Year
March 2005
May 2005
Design Goals
Protect Management frames from replay and forgery
Single solution for all Class 3 management frames
Leverage existing security mechanisms (802.11i and TGr)
Advertised and negotiated element is needed
Ensures capability is supported and used
Enables backward compatibility
Allow co-existence of Protection-enabled and legacy STAs
Protect against forgery and replay to allow for co-existence
Adopt a cryptographic algorithm approved for FIPs certification
Providing confidentiality for multicast and broadcast:
prohibits coexistence of STAs who can not Protect Management Frames
May present issues during BSS transitions
Nancy Cam-Winget, Cisco
Emily Qi, Intel Corporation

3. Protection of Management Frame (PMF) Negotiation
Month Year
March 2005
May 2005
Protection of Management Frame (PMF) Negotiation
2 new RSN Capabilities can be used
Bit 6: advertise ability to “Protect Management Frames”
Bit 7: enable Protection of Management Frames
Bit Setting
Beacon / Probe Response Description
Negotiation in (Re)Association
Bit 6
Bit 7
Peer does not support PMF 1
Invalid
PFM is supported & optional
Peer supports PMF but is disabled
PMF is supported and enforced
PMF is supported and enabled
Nancy Cam-Winget, Cisco
Emily Qi, Intel Corporation

4. May 2005
Proposal 1: Overview
Reuse i as is with the following extensions:
KCK is used to protect management frames
KRC is used to protect against replay
EAPOL-Key frame can be encapsulated in IE to transport KRC and MIC
Nancy Cam-Winget, Cisco

5. Reuse KCK (from 802.11i or TGr)
May 2005
Reuse KCK (from i or TGr)
Pairwise Master Key (PMK)
Key used to protect
Management Frames
Pairwise Transient Key (PTK)
Eapol-Key Key Confirmation Key (KCK)
128 bits
Eapol-Key Key Encryption Key (KEK)
Temporal Key (TK)
TKIP: 256 bits
CCMP: 128 bits
Nancy Cam-Winget, Cisco

6. EAPOL-Key IE Order Size (octets) Description 1
May 2005
EAPOL-Key IE
Order
Size (octets)
Description 1
TBD Element ID: Encapsulated 802.1X IE 2
Length of the 802.1X EAPOL-Key message 3 n
802.1X EAPOL-Key message
Nancy Cam-Winget, Cisco

7. Use of KCK, KRC & EAPOL-Key IE
May 2005
Use of KCK, KRC & EAPOL-Key IE
Use of KCK enables:
Full leverage of mechanisms already defined in i and convergence with TGr
Minimization of keys and counters to cache and manage
Use of EAPOL-Key IE enables:
Consistent use of MIC transport
Consistent use of KRC replay rules
Nancy Cam-Winget, Cisco

8. Proposal 2: Overview for OMAC-based MIC
Month Year
March 2005
May 2005
Proposal 2: Overview for OMAC-based MIC
Adopt OMAC as the algorithm to Protect Management Frames (PMF)
Avoid potential security issues in using TKIP or WEP
Avoid use of CCMP as confidentiality is not needed as a whole
Approved by NIST:
Introduce new IE to include replay counter and MIC
New Keys are used to protect Class 3 management frames
Sender includes a new GTK for Protection-enabled STAs
Leverage i RSNIE to negotiate PMF capabilities
Nancy Cam-Winget, Cisco
Emily Qi, Intel Corporation

9. May 2005
AES-128-OMAC
AES(K, D) : AES 128bit block cipher using a 128bit key, K to encrypt plaintext D
0128: 128bits of zeroes
L = AES( K, 0128)
if MSB(L) = 0 → Lu = L << 1
else Lu = (L << 1) XOR 0x
if MSB(Lu) = 0 → Lu2 = (Lu) << 1
else Lu2 = ((Lu) << 1) XOR 0x
Y[0] = 0128
Partition data stream, M into m blocks: M[1], M[2] … M[m]
If M[m] != 128bits, pad: M*[m] = (Lu2 XOR (M[m] || 10j)) where j= # 0’s to pad to 128bits
M[m] = M[m] XOR (Lu) if the length of M[m] = 128
X[m] = X[m] XOR (Lu2) otherwise
for i = 1 to m do
Y[i] = AES( K, M[i] XOR Y[i-1] )
Nancy Cam-Winget, Cisco

10. Pairwise Key Hierarchy with Management Frame Protection Enabled
May 2005
Pairwise Key Hierarchy with Management Frame Protection Enabled
Pairwise Master Key (PMK)
PRF-Y ( PMK, “Pairwise key expansion”,
Min(AA, SPA) || Max(AA, SPA) ||
Min(ANonce, SNonce) || Max(ANonce, SNonce))
Pairwise Transient Key (PTK)
[Y = X bits; X is as defined in i]
Eapol-Key Key Confirmation Key (KCK)
128 bits
Eapol-Key Key Encryption Key (KEK)
Temporal Key (TK)
TKIP: 256 bits
CCMP: 128 bits
Management Frame Protection Key (MFPK)
Nancy Cam-Winget, Cisco

11. Group Key Hierarchy with Protection of Management Frames Enabled
May 2005
Group Key Hierarchy with Protection of Management Frames Enabled
Group Master Key (GMK)
PRF-Y ( GMK, “Group key expansion”,
AA || GNonce)
Group Transient Key (GTK)
[Y = X bits; X is as defined in i]
Temporal Key (TK)
TKIP: 256 bits
CCMP: 128 bits
Group Management Frame Protection Key (PMFK)
128 bits
Nancy Cam-Winget, Cisco

12. Management Frame MIC IE
May 2005
Management Frame MIC IE
Field
Size
(bytes)
Description
Element ID 1
TBD
Length
Size of this IE
Version
0 : AES-128-OMAC
1-255: Reserved
Key Index
Unique value identifying the key used to protect the management frames
Replay Counter 6
Incrementing value used to protect against frame replays
MIC 8
Message Integrity code protecting the Class 3 management frame
Nancy Cam-Winget, Cisco

13. Protected Management Frame (PMF) Format
May 2005
Protected Management Frame (PMF) Format
Original Mgmt Frame:
hdr
Mgmt frame body
FCS
Protected Mgmt Frame:
Authenticated by MIC
hdr
Management frame body
MIC IE
FCS
Element ID
Len
Version
Key ID
Replay Counter
MIC
Nancy Cam-Winget, Cisco

14. Month Year
March 2005
May 2005
Replay Protection
Each transmitter and receiver implements a new counter for management frames
New counter initialized to zero
If received replay value is less than or equal to last valid value, discard the frame as a replay
If received replay value greater than last valid value and management frame validates correctly, accept packet and set counter value to received replay counter value
Should be “Frames”
Should this be “a”?
Nancy Cam-Winget, Cisco
Emily Qi, Intel Corporation

15. Why not provide confidentiality?
May 2005
Why not provide confidentiality?
Providing confidentiality of management frames raises deployment issues:
No means for co-existence of PMF-enabled and non-PMF-enabled STAs
Current silicon may not correlate BSSID and KeyID field for encryption?
Increases implementation and debugging complexity
Provide Confidentiality for Unicast management frames only?
Leverages reuse of i mechanisms but restrictions and constraints are required to address security (e.g. no WEP, TKIP)
What threat models does Confidentiality address?
Nancy Cam-Winget, Cisco

16. Month Year
March 2005
May 2005
Summary
Adopt a single means for protecting all Class 3 management frames
Adopt a FIPS-certifiable cryptographic algorithm
Leverage existing i security mechanisms
Enable co-existence with non-PMF-enabled STAs
Option 1: enables full reuse of existing i mechanisms
Option 2: offers cheaper and FIPs approved AES function
Nancy Cam-Winget, Cisco
Emily Qi, Intel Corporation

17. May 2005
Comments?
Nancy Cam-Winget, Cisco