1. doc.: IEEE 802.11-05/0343r1 Submission May 2005 Kapil Sood, IntelSlide 1 Protection of Management Frames - Protocol Requirements 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, 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date: 2005-05-17 Authors:

2. doc.: IEEE 802.11-05/0343r1 Submission May 2005 Kapil Sood, IntelSlide 2 Motivation Stimulate discussion on behavior and characteristics of the security protocol for protection of Management Frames for IEEE 802.11 Adopt these requirements into 802.11w requirements doc Establishing consistent requirements upfront leads to: –Fast Protocol Design and Convergence –Time-to-Market relevance Doc: 11-05-0404-00-0ads-TGw-Protocol-Security-Requirements

3. doc.: IEEE 802.11-05/0343r1 Submission May 2005 Kapil Sood, IntelSlide 3 Suggested Requirements and Rationale Requirement 100: –The protocol shall provide protection against forgeries Rationale: –This is the ultimate rationale for 802.11w –Needed by Disassociate Deauthenticate 802.11e, 802.11h, 802.11k, 802.11r, 802.11s, 802.11v And maybe others in the future

4. doc.: IEEE 802.11-05/0343r1 Submission May 2005 Kapil Sood, IntelSlide 4 Suggested Requirements and Rationale Requirement 110: –The protocol shall provide confidentiality protection Rationale: –802.11k needs confidentiality protection for Location Report Message –802.11k and 802.11v needs confidentiality protection 802.11k and 802.11v accesses SNMP’s MIB, and 802.11 must not violate security policy configured for SNMPv3

5. doc.: IEEE 802.11-05/0343r1 Submission May 2005 Kapil Sood, IntelSlide 5 Suggested Requirements and Rationale Requirement 120: –The protection scheme shall negotiate the security properties to be enforced for the protection of management frames Rationale: –Interoperate with legacy STA that do not implement management frame protection

6. doc.: IEEE 802.11-05/0343r1 Submission May 2005 Kapil Sood, IntelSlide 6 Suggested Requirements and Rationale Requirement 130: –There shall be a mechanism to protect negotiation of the security properties to be enforced for the protection of management frames Rationale: –Prevent negotiation mechanisms against MITM and downgrade attacks

7. doc.: IEEE 802.11-05/0343r1 Submission May 2005 Kapil Sood, IntelSlide 7 Suggested Requirements and Rationale Requirement 140: –Management frame protection mechanism shall be compatible both with 802.11i and TGr (Fast Roaming) key hierarchies and key management schemes Can 802.11w extend 802.11i/r key hierarchies to derive keys? Can 802.11w use 802.11i/r key hierarchies, as is? –Mechanism shall operate alongside 802.11i and TGr protocols Rationale: –Designing key hierarchies is hard, expensive to implement, constrained environments, and deployment/management complexity and cost –Implementations may support one or both of 802.11i and TGr

8. doc.: IEEE 802.11-05/0343r1 Submission May 2005 Kapil Sood, IntelSlide 8 Suggested Requirements and Rationale Requirement 150: –Protocol shall provide protection for both unicast and broadcast/multicast management frames Rationale: –Any management frame can benefit from protection –Broadcast/multicast management frames may be used for mesh routing TGk Beacon Report Request frames, and Disassociate and Deauthenticate frames

9. doc.: IEEE 802.11-05/0343r1 Submission May 2005 Kapil Sood, IntelSlide 9 Suggested Requirements and Rationale Requirement 160: –Protocol solution may be different for protecting unicast and broadcast/multicast frames Rationale: –Security requirements for unicast and broadcast/multicast management frames are different To be correct, Broadcast/Multicast confidentiality key should be changed when someone joins or leaves the group To be correct, for integrity, either –the broadcast messages are stateless/idempotent (the 802.11i design – not applicable to stateful messages such as mesh routing updates or Disassociate/Deauthenticate), or –the frames must be delivered before the integrity keys are delivered

10. doc.: IEEE 802.11-05/0343r1 Submission May 2005 Kapil Sood, IntelSlide 10 Suggested Requirements and Rationale Requirement 170: –Protection mechanism shall provide for incremental inclusions of management frames, as new management frames are developed by 802.11. Rationale: –Must allow for legacy devices that don’t implement management frame protections –Generic scheme for protection of management frames will greatly improve applicability and deployment

11. doc.: IEEE 802.11-05/0343r1 Submission May 2005 Kapil Sood, IntelSlide 11 Suggested Requirements and Rationale Requirement 180: –Protocol shall provide for selected deployments of categories of management frames Rationale: –Generic scheme for protection of management frames will greatly improve applicability and deployment –Increase policy flexibility at the expense of usability

12. doc.: IEEE 802.11-05/0343r1 Submission May 2005 Kapil Sood, IntelSlide 12 Suggested Requirements and Rationale Requirement 190: –Protocol shall protect the management frames only after establishing transient session keys Rationale: –Else, How do we get keys in place? –There isn’t a way to protect everything…avoid a catch-22 situation –Ex post facto verification of the RSN information element is not a general technique; it works because The AP’s RSN information element is static The STA’s RSN information element is tied to a particular session

13. doc.: IEEE 802.11-05/0343r1 Submission May 2005 Kapil Sood, IntelSlide 13 Suggested Requirements and Rationale Requirement 200: –STA must treat any non-static integrity protected management frames received before the STA gets integrity key as a forgery Rationale: –The STA cannot verify the replay status of non-static integrity protected messages received before deriving the integrity key –Therefore, the STA must assume all such messages are replayed messages.

14. doc.: IEEE 802.11-05/0343r1 Submission May 2005 Kapil Sood, IntelSlide 14 Suggested Requirements and Rationale Requirement 210: –The protocol shall handle fragmented management frames. Rationale: –Base 802.11i spec allows management frames to be fragmented

15. doc.: IEEE 802.11-05/0343r1 Submission May 2005 Kapil Sood, IntelSlide 15 Open Issues Protection for power save messages –A re-sync exchange after STA comes out of power-save mode, to detect messages delayed by an adversary instead of normal operation

16. doc.: IEEE 802.11-05/0343r1 Submission May 2005 Kapil Sood, IntelSlide 16 Motion Instruct the editor to accept the text in the document #xxxx, in 802.11w requirements document

17. doc.: IEEE 802.11-05/0343r1 Submission May 2005 Kapil Sood, IntelSlide 17 Additional Submissions Other requirements submissions: –11-05-0404-00-0ads-TGw-Protocol-Security-Requirements –11-05-0237-00-0ads-requirements-management-frames-protection- schemes –11-05-0139-00-0ads-which-management-frames-need-protection