1. Which Management Frames Need Protection?
March 2005
doc.: IEEE y05/0139r0
March 2005
Which Management Frames Need Protection?
Authors:
Date:
Name
Organization
Jon Edney
Nokia
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
Jon Edney, Nokia
Jon Edney, Nokia

2. March 2005
doc.: IEEE y05/0139r0
March 2005
Abstract
Considers the requirements for protection management frames and proposes a set of protections
Jon Edney, Nokia
Jon Edney, Nokia

3. Management Frames (Re)Associate Rq/Rsp Probe Rq/Rsp Beacon ATIM
March 2005
doc.: IEEE y05/0139r0
March 2005
Management Frames
(Re)Associate Rq/Rsp
Probe Rq/Rsp
Beacon
ATIM
Disassociate
Authenticate / De-authenticate
Action
Jon Edney, Nokia
Jon Edney, Nokia

4. Discovery: Beacon, Probe Access: Authentication, Association
March 2005
doc.: IEEE y05/0139r0
March 2005
Functional Groups
Discovery: Beacon, Probe
Access: Authentication, Association
Power management: ATIM (IBSS only)
Data transfer: Action
Jon Edney, Nokia
Jon Edney, Nokia

5. Protection requirements (proposal)
March 2005
doc.: IEEE y05/0139r0
March 2005
Protection requirements (proposal)
Jon Edney, Nokia
Jon Edney, Nokia

6. Issues with protecting Discover Group
March 2005
doc.: IEEE y05/0139r0
March 2005
Issues with protecting Discover Group
Would like to:
verify sender
verify that information is not modified
verify information is not replay
Cost of such protections is high
solutions are based on public key cryptography
Issues related to service discovery are currently under discussion in TGu
TGu discovery may be linked to higher layer protocols
We postulate: it is inappropriate to create a general protection mechanism for beacons and probe requests without considering application requirements. This is work of TGu
Jon Edney, Nokia
Jon Edney, Nokia

7. Issues with Power Management
March 2005
doc.: IEEE y05/0139r0
March 2005
Issues with Power Management
Tampering with ATIM frame causes potential DOS attack.
However ATIM is only used in IBSS
IBSS power save is not widely supported
We postulate that it is not worth protecting ATIM
Jon Edney, Nokia
Jon Edney, Nokia

8. Protecting Access Messages
March 2005
doc.: IEEE y05/0139r0
March 2005
Protecting Access Messages
(re)Associate message. We would like to protect but:
conventional systems do not have PTK prior to association
Tgr will (likely) provide protection since PTK is computed prior to associate.
conclusion: No action needed
Authenticate.
Open auth. in conventional systems does not need protection
Tgr may redefine auth. messages but proposals include protections mechanisms
Deauthenticate, Dissassociate:
Forgery of these messages is an easy and major DOS attack
conclusion: we must have data integrity & data origin authenticity
Jon Edney, Nokia
Jon Edney, Nokia

9. Action Management Frame
March 2005
doc.: IEEE y05/0139r0
March 2005
Action Management Frame
requirements differ
Some applications need no protection – action frame is informative only and false information is not damaging
Most applications want to protect against forgery or tampering of action frames
Some applications want confidentiality of the information in action frames
Conclusion: we need a mechanism to provide data integrity, data origin authenticity, replay protection, and data confidentiality
Jon Edney, Nokia
Jon Edney, Nokia

10. Summary of Mandatory Protections
March 2005
doc.: IEEE y05/0139r0
March 2005
Summary of Mandatory Protections
Jon Edney, Nokia
Jon Edney, Nokia