1. SubmissionJoe Kwak, InterDigital1 Simplified 11k Security Joe Kwak InterDigital Communications Corporation doc: IEEE 802.11-04/552r0May 2004

2. doc: IEEE 802.11-04/552r0May 2004 Submission Joe Kwak, InterDigital 2 Problem statement For the purpose of optimizing O&M and radio performance, 802.11k, Introduces many new MAC management action frames Adds couple of new IEs to several existing frames Those new 11k contents exchanged over the air currently do not provide any security (source integrity, encryption) It is thinkable that this may become a security threat to 11k enabled WLAN in the future, Threat 1: No security, 11k may repeat another WEP experience Threat 2: Resolution of 11k security issue delays 11k as a whole Threat 3: 11k solution too complex to implement and/or not aligned with 11i hardware changes Requirement to create a mechanism that (optionally) provides security of the new TGk information contents

3. doc: IEEE 802.11-04/552r0May 2004 Submission Joe Kwak, InterDigital 3 Some thoughts… We anticipate there is a potential security problem if 11k specification does not provide any source integrity and encryption But it is unclear if there is a real danger and if yes, to which extent it would jeopardize system operation 11k security will need to operate in the general framework given by WPA and 11i No need to have a tighter security concept in 11k than in WPA and 11i 11k security must not preclude operation of WPA or 11i security

4. doc: IEEE 802.11-04/552r0May 2004 Submission Joe Kwak, InterDigital 4 Options to solve the problem 1. Do nothing (like 11h, and let some other group address this issue when/if it becomes problem) 2. Try to address the 11k security issue: 802.11-04/1003r2 Nokia, 01/04 802.11-04/0264r2 Intel, 03/04 3. Simplify the security issues using elements from the above two proposals InterDigital believes the third option is possible.

5. doc: IEEE 802.11-04/552r0May 2004 Submission Joe Kwak, InterDigital 5 InterDigital’s perception 11k should provide security more for future-proofness than for any actual perceived threat from disclosing or forging radio resource measurement information For 11k, providing source/message integrity protection is the most important security mechanism and should be required: Source integrity comes at relatively low cost, compute and append TKIP MIC Offers the most basic of all protection mechanisms, “if someone tampered with the frame contents, then discard” Encryption should be optional for all frames using Nokia or Intel proposal Legacy or not-yet-authenticated STAs can still read unencrypted information on broadcast frames and will ignore the TKIP MIC Nokia proposal for encryption is more flexible but seems to be misaligned with 11i and the 11i per-frame encryption engine Intel proposal is straightforward (works like for data frames in 11i, so encryption engine the same), but it may not address all scenarios

6. doc: IEEE 802.11-04/552r0May 2004 Submission Joe Kwak, InterDigital 6 Simplifying Assumptions IEEE802.11i is completed as per current draft 10.0 and provides the mechanisms (but not to forget WPA…) Good keys are available and managed under IEEE802.11i Group key (common key) Session keys (STA-specific) A STA does not know any key before it gets authenticated Any authenticated STA can be trusted, therefore, group keys are useful and used for all broadcast/multicast 11k security is an optional feature Must be implemented in all TGk STAs, but can be enabled or disabled based on local BSS policy

7. doc: IEEE 802.11-04/552r0May 2004 Submission Joe Kwak, InterDigital 7 Simplified Proposal for TGk Security 1. Require TKIP MIC in all action frames: Transmitting STA computes/encrypts/appends TKIP MIC to allow receiving STA to authenticate both message and sender before acting on contents of received frame. TKIP MIC mechanism is modified for use with group key(s) for broadcast/multicast frames. 2. Use frame-based encryption as option for all action frames: New security header bit indicates encrypted/unencrypted. All frame formats include security header and TKIP MIC. Frames which carry useful information for STAs not yet associated should not be encrypted, e.g. Beacons, Probe Responses, Site Report, new System Information, etc. The transmitter of the action frame decides when to encrypt. The receiver of the action frame uses TKIP MIC to decides whether to respond or take any action.

8. doc: IEEE 802.11-04/552r0May 2004 Submission Joe Kwak, InterDigital 8 Extend TKIP MIC to Broadcast/Multicast Need to accept limitations of defined 11i mechanisms: 11i 5.4.3.5: “Data origin authenticity is only applicable to unicast data frames. The protocols do not guarantee data origin authenticity for broadcast/multicast data frames, as this cannot be accomplished using symmetric keys, and public key methods are too computationally expensive.” 11i 8.3.2.3.1: “It should be noted that a MIC alone cannot provide complete forgery protection, as it cannot defend against replay attacks. TKIP provides replay detection by TSC sequencing and ICV validation. Furthermore, if TKIP is utilized with a group key, an “insider” STA can masquerade as any other STA belonging to the group.” Run 11i encryption engine on frame using group key to compute and encrypt TKIP MIC for every broadcast/multicast action frame. Encryption engine also produces encrypted frame using group key. The encrypted frame body is discarded when transmitting unencrypted action frame with TKIP MIC.

9. doc: IEEE 802.11-04/552r0May 2004 Submission Joe Kwak, InterDigital 9 Benefits of Proposal Avoids discussions/disagreements concerning mandatory data encryption: Do not need to poll/vote on encryption of each action frame type or IE and conditions in which encryption should be used. Do not need to “impose” encryption on operators or users. Relies on integrity of existing security protocols: Uses 802.x for strong authentication and key distribution at association time, STA is trusted thereafter. Uses defined 11i mechanisms with extension for TKIP MIC with group key for broadcast/multicast. Relatively easy to draft text: All TGK action frames and frame formats treated identically. Procedures section describes intended use of data encryption but includes no requirement “shalls”.

10. doc: IEEE 802.11-04/552r0May 2004 Submission Joe Kwak, InterDigital 10 Proposal for a way forward Strawpoll to agree on two security decisions: Require security header and TKIP MIC on all 11k action frames Security header shall contain Encrypted/Clear bit to permit optional encryption of frame body for all 11k action frames Drafting group to produce normative text this week. Vote on normative text on Thursday, if possible. Extending these 11k decisions to 11h to be discussed for next meeting.

11. doc: IEEE 802.11-04/552r0May 2004 Submission Joe Kwak, InterDigital 11 Security Question #1 Should TGk require a security header and TKIP MIC on all 11k action frames ? YES _______ NO _______ ABSTAIN _______

12. doc: IEEE 802.11-04/552r0May 2004 Submission Joe Kwak, InterDigital 12 Security Question #2 Should the TGk security header contain an Encrypted/Clear bit to permit optional encryption of frame body for all 11k action frames? YES _______ NO _______ ABSTAIN _______

13. doc: IEEE 802.11-04/552r0May 2004 Submission Joe Kwak, InterDigital 13