doc.: IEEE /0467r1 Submission May 2005 Richard Paine, BoeingSlide 1 11k LB73 Security Resolutions 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, 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. Date: Authors:

doc.: IEEE /0467r1 Submission May 2005 Richard Paine, BoeingSlide 2 Comment #309 Comment: Security is needed - even if it is not specified in k, there should be a clause limiting to use of certain functions such that they are only allowed where appropriate security services are available Resolution: Asked Jon Edney by to provide what functions need to be constrained and where he thinks this should go. Peter E.: Location might be one of those functions

doc.: IEEE /0467r1 Submission May 2005 Richard Paine, BoeingSlide 3 Comment #353 Comment: IEEE F-2003 called secure even though this recommended practice does not define security measures for the IAPP packets. IEEE F contains a comment saying that ESP can be used to protect MOVEs, but leaves the encryption details quite open. Resolution: Remove reference to 11F, even though he is wrong.

doc.: IEEE /0467r1 Submission May 2005 Richard Paine, BoeingSlide 4 Comment #358 Comment: Number of comments asking for security in LB71 were declined with a statement that "telecon participants do not agree". It looks like more than one commenter believed that security should be included for IEEE k additions, e.g., for Action frames. I strongly believe that all new amendments to IEEE should take security considerations into account. Is there a consensus on this not being the case for IEEE k? Recommended Resolution: Declined. TG11w has the charter and scope to secure action frames.

doc.: IEEE /0467r1 Submission May 2005 Richard Paine, BoeingSlide 5 Comment #378, #1385, and #1386 Comment: Lefkowitz: Table k12 is the first place preauth is mentioned. Preauth is an i concept i has not been ratified and thus this reference should not be in the specification. Moreton: If the current AP doesn't support pre-auth there is no way of telling if the remote one does. As most current APs will not know whether the new AP uses the same authenticator (authentication server), it's important to distinguish between this case and the case where the new AP is known not to have the same authenticator (Authentication server). Recommended Resolution: Accept resolution of #1385 and #1386 as the resolution for #378: Add a bit to the capabilities field. Exclude pre-auth from the check for the security bit. 11k misused the authenticator definition - change authenticator to authentication server in all cases. Action: Defer and have a Simon Black discussion with Mike Moreton

doc.: IEEE /0467r1 Submission May 2005 Richard Paine, BoeingSlide 6 Comment #628 Comment: The draft appears to contain no mechanisms to secure measurement requests and responses Recommended Resolution: Declined. TG11w has the charter and scope to secure measurement requests and responses, 11k does not.

doc.: IEEE /0467r1 Submission May 2005 Richard Paine, BoeingSlide 7 Comment #830, #1339, and #1394 Comment: Security bit should be set when the reported BSSID supports all of the security elements used by the associated STA, not all of the possible security settings of the current AP Recommended Resolution: Change text to: The Security bit, if set, indicates that the AP represented by this BSSID supports the security settings of the associated STA. Decline – the STA is aware of the current security capabilities and itself, so is in the best position to make the determination.

doc.: IEEE /0467r1 Submission May 2005 Richard Paine, BoeingSlide 8 Comment #1340 Comment: The Key Scope bit is ill defined if it's meant to facilitate roaming. I believe the intent was to specify the same "Authentication Server", not authenticator. Even then this is of somewhat limited use since two APs may not have the same AS but this bit should be set for roaming. Recommended Resolution: Accepted. Leave the bit as reserved and let TGr define it since some of the concepts of TGr may map directly to what this bit was intended for (as I understand it): Remove key scope bit from 11k (lines on Page 31 and figure k24 bit 3, remove from MIB P108 & P109 (3 places in the MIB))