1 / 15

Management Protection

Management Protection. Jesse Walker and Emily Qi Intel Corporation. Agenda. Motivation Proposal Issues Q&A. Motivation. Availability = the most important security attribute for commercial applications Hence, important to protect against DoS when possible

tamekah-marshall
Download Presentation

Management Protection

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Management Protection Jesse Walker and Emily Qi Intel Corporation Jesse Walker and Emily Qi, Intel Corporation

  2. Agenda • Motivation • Proposal • Issues • Q&A Jesse Walker and Emily Qi, Intel Corporation

  3. Motivation • Availability = the most important security attribute for commercial applications • Hence, important to protect against DoS when possible • Well known that attacker can disconnect a STA by forging Disassociation or Deauthentication • Well known that unprotected Reassociation coupled with IAPPs introduce new DoS attack • Attacking STA sends Reassociation Request to new AP • New AP sends IAPP message to old AP • Old AP disconnects real STA Jesse Walker and Emily Qi, Intel Corporation

  4. Proposal Overview • Use CCMP or TKIP to protect Reassociate, Disassociation, and Deauthentication messages • Doc 04/264 proposes similar approach to protect Action Frames • If keys can be put in place prior to AP-to-AP transition, this can work • Doc 04/476 proposes mechanism to put CCMP/TKIP keys in place Jesse Walker and Emily Qi, Intel Corporation

  5. Authenticated by MIC Encrypted 802.11 hdr 802.11 hdr FCS FCS Protected Mgmt Frame Format Original Mgmt Frame: Use the same cryptographic algorithm selected for Data MPDUs Protected Mgmt Frame: 802.11i header Mgmt frame body MIC Cryptographic Message Integrity Code to defeat forgeries Key ID IV Encryption used to provide confidentiality IV used as frame sequence space to defeat replay Jesse Walker and Emily Qi, Intel Corporation

  6. Protected Frame Bit • Protected Frame (“WEP bit”) Subfield of the 802.11 Frame Control Field indicates whether the Management Frame is protected or unprotected • “Protected Frame” bit = 1 for Protected Management Frame • “Protected Frame” bit = 0 for Unprotected Management Frame Jesse Walker and Emily Qi, Intel Corporation

  7. Negotiation • AP sets RSN capabilities bit if it supports Protected Mgmt Messages; clears bit otherwise • RSN IE advertised in Beacons, Probe Responses • STA sets RSN capabilities bit if AP set it and if STA supports Protected Mgmt Messages; clears bit otherwise • Needed for backward compatibility • AP and STA use Protected Mgmt Messages only if both agree to use it Jesse Walker and Emily Qi, Intel Corporation

  8. Cryptographic Key • Scheme requires that a PTK be established for CCMP or for TKIP • MM IE key = TK portion of PTK • Doc 04/476 suggests a way to put PTK in place • Reassociation, Disassociation, Deauthentication use the same TK and cipher suite as data Jesse Walker and Emily Qi, Intel Corporation

  9. Replay Protection • Transmitter uses next CCMP PN or TKIP TSC as the IV/Extended IV • Use sequence number given by PN/TSC to protect payload and increment counter • Each receiver implements a new receive counter for management frames • New counter initialized to zero • Sequence number in received protected management frame compared with new counter value • If received sequence number does not exceed last valid value, discard the frame as a replay • If received sequence number exceeds last valid value and management frame validates correctly, accept packet and set counter value to received sequence number value • Note: Receive counter is shared with Protected Action Frames, doc 04/264 Jesse Walker and Emily Qi, Intel Corporation

  10. Usage • Can only be used if both systems support CCMP or TKIP • If an AP or STA have agreed to protect mgmt frames and have established a fresh PTK with its peer, it shall protect: • Reassociate Request Frame • Reassociate Response Frame • Disassociation Frame • Deauthentication Frame • And shall require its peer to include MM IE as well • If an AP or STA has not established a fresh PTK or agreed to protect mgmt frames, it shall not protect these messages • In case of synchronization loss, the STA may • Associate to resynchronize, i.e, STA and ESS must undergo full reauthentication and PMK establishment • Re-establish a fresh PTK via some other channel Jesse Walker and Emily Qi, Intel Corporation

  11. Issues • Depends on a mechanism to provision fresh PTKs prior to reassociation • Example: doc 04/476 “Pre-keying” • Negotiation dependent on pre-keying like mechanism • Necessary to negotiate via RSN IE during PTK set up • Does not tolerate reordering among Protected Action Frames, Reassociate Frames, Disassociation Frames, Deauthentication Frames, and Protected Action Frames • All use the same replay counter • Don’t know whether encryption of message payload will cause problems for 802.11 implementations • Must prevent TK reuse • If any data replay counter for this TK is non-zero when Reassociate message received, then TK has been used already • If Protected Mgmt frames in use and STA declines use, AP must either • Reject STA Reassociate Requests or • Delay IAPP messages until STA demonstrates possession of the PTK Jesse Walker and Emily Qi, Intel Corporation

  12. Q&A • Is there anything new here? • No; essentially a restructuring of ideas presented in TGi • Then why bring it up again? • A proposal exists to puts keys in place at a suitable time (04/476) • Why not an “Integrity IE” instead of reusing CCMP/TKIP? • Would require separate key for protected mgmt messages and other frames • Would require separate replay counter for Protected Management Messages and other frames • The scheme would have to be designed and reviewed from scratch Jesse Walker and Emily Qi, Intel Corporation

  13. Q&A • Why is this proposal sound? • CCMP/TKIP PN/TSC usage allows key sharing between data and management messages • Important that same cipher and PN/TSC used for both! • Important that different replay counters used for both! • Why not protect Association Request/Response as well? • 802.11i does not instantiate a PMK in time • Why not other Mgmt Messages? • 04/264 already proposes same technique to protect Action Frames • Probes, Beacons not easily protectable – no keys in place • No value perceived in protecting other mgmt frames • And counter-productive to protect others (e.g. CTS, ACK, etc.) Jesse Walker and Emily Qi, Intel Corporation

  14. Q&A • Why is this work in scope for 802.11r? • It is related to transition • If TGr adopts a make-before-break architecture, security will be degraded unless Reassociation exchange is secured Jesse Walker and Emily Qi, Intel Corporation

  15. Feedback? Jesse Walker and Emily Qi, Intel Corporation

More Related