Which Management Frames Need Protection? March 2005 doc.: IEEE 802.11-y05/0139r0 March 2005 Which Management Frames Need Protection? Authors: Date: 2005-02-28 Name Organization E-Mail Jon Edney Nokia email@jon.edney.name 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 <http:// 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 <stuart.kerry@philips.com> 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 <patcom@ieee.org>. Jon Edney, Nokia Jon Edney, Nokia

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

Management Frames (Re)Associate Rq/Rsp Probe Rq/Rsp Beacon ATIM March 2005 doc.: IEEE 802.11-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

Discovery: Beacon, Probe Access: Authentication, Association March 2005 doc.: IEEE 802.11-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

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

Issues with protecting Discover Group March 2005 doc.: IEEE 802.11-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

Issues with Power Management March 2005 doc.: IEEE 802.11-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

Protecting Access Messages March 2005 doc.: IEEE 802.11-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

Action Management Frame March 2005 doc.: IEEE 802.11-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

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