Clause 7 Comment Resolutions Month Year doc.: IEEE 802.11-yy/xxxxr0 March 2006 Clause 7 Comment Resolutions Date: 2006-03-08 Authors: 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>. Cam-Winget, Eastlake, Edney John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 March 2006 Comment 58, 59, 60, 61 Comment: “what should we set the bit to if data confidentiality is required but robust management frame protection isn't? From the text it isn't clear.” Resolution: Accept in principle. The privacy bit is for advertising protection of data frames and potentially the use of RSN to protect such data. The protection of management frames capability is begotten by the RSNIE Robust management frame protection bit(s). The proposed text will be removed so that the existing text in the TGma draft remains unchanged. Cam-Winget, Eastlake, Edney John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 March 2006 Comment 63, 64 Comment: “This changes the meaning of a reason code. This breaks between 100 million and 200 million deployed devices” Resolution: Rejected. Existing devices can only protect data so the semantic clarification is there only for TGw-enabled devices. Also, since group ciphers for protecting data versus management frames are different, they should be afforded distinct reason codes. Cam-Winget, Eastlake, Edney John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 March 2006 Comment 67 Comment: “Is there a problem with extending the RSN IE given that this is sent in associate request before capabilities are negotiated. Will this break legacy implementations?” Proposed Resolution: Should we straw poll to see if there are current implementations that will break? Should we add text specifying behavior for length that exceed the current 802.11i implementation to ensure that further extensions like TGw can be safely defined? Cam-Winget, Eastlake, Edney John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 March 2006 Comment 71 Comment: “Use of AES-128-CMAC is only valid as a management group cipher suite." While I agree that this is the right thing to do, is it justified? It seems like it implies new testing to assure interoperability?” Commenter’s resolution: “I think the right justification is that permitting it to be used with data would introduce configuration issues that would tax even cryptographers. 802.11w is meant to be useful by everyone. Vendors can define their own version of AES-128-CMAC that extends the 802.11w mechanism to data if this is an important function.” Should restriction on management frame only be removed or should an informative note be added to justify use of AES-128-CMAC for management frame only? Cam-Winget, Eastlake, Edney John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 March 2006 Comment 72 Comment: “There is not encryption provided for broadcast Robust management frames. I think this is the right decision, but why is it justificated?” Commenter’s query: “I think the justification is that broadcast management frames deal with the operation of the WLAN only and do not convey information related to user privacy. Does the 802.11w draft therefore need to prohibit the inclusion of data related to user privacy in the 802.11 spec?” Cam-Winget, Eastlake, Edney John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 March 2006 Comment 74 Comment: “Not allowing management frame protection for TSN sounds like an arbitrary requirement and extra complexity. Is it really needed? WEP can only be used for broadcast/multicast data frames, so it would not be used for management frames.” Resolution: Rejected. Protection of management frames in a TSN may imply using WEP for unicast management frames which would be extending bad security practices to the management realm. Cam-Winget, Eastlake, Edney John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 March 2006 Comment 76, 77, 78, 79,81 One bit to advertise Robust Management Frame Protection should be sufficient. Document 06/492 provides more details. Approval for proposal in submission 06/492 proposal will resolve these comments Cam-Winget, Eastlake, Edney John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 March 2006 Comment 95 Comment: “HC includes DA and SA fields which are already protected by TKIP as part of key generation. Do we really need to copy them into HC?” Proposed resolution: “Remove HC DA and HC SA from HC.” Cam-Winget, Eastlake, Edney John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 March 2006 Motion A Move to accept resolutions for comments 58, 59, 60, 61, 63, 64, 74, 76, 77 ,78, 79, 81, 95 Cam-Winget, Eastlake, Edney John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 March 2006 Motion B Move to accept resolutions for comments 58, 59, 60, 61, 63, 64, 74, 95 Cam-Winget, Eastlake, Edney John Doe, Some Company