doc.: IEEE /0485r0 Submission May 2004 Jesse Walker and Emily Qi, Intel CorporationSlide 1 Management Protection Jesse Walker and Emily Qi Intel Corporation

doc.: IEEE /0485r0 Submission May 2004 Jesse Walker and Emily Qi, Intel CorporationSlide 2 Agenda Motivation Proposal Issues Q&A

doc.: IEEE /0485r0 Submission May 2004 Jesse Walker and Emily Qi, Intel CorporationSlide 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

doc.: IEEE /0485r0 Submission May 2004 Jesse Walker and Emily Qi, Intel CorporationSlide 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

doc.: IEEE /0485r0 Submission May 2004 Jesse Walker and Emily Qi, Intel CorporationSlide 5 Protected Mgmt Frame Format Original Mgmt Frame: Mgmt frame body Protected Mgmt Frame: MICMgmt frame body802.11i header IV Key ID IV used as frame sequence space to defeat replay Authenticated by MIC Cryptographic Message Integrity Code to defeat forgeries Use the same cryptographic algorithm selected for Data MPDUs Encrypted hdrFCS Encryption used to provide confidentiality FCS hdr

doc.: IEEE /0485r0 Submission May 2004 Jesse Walker and Emily Qi, Intel CorporationSlide 6 Protected Frame Bit Protected Frame (“WEP bit”) Subfield of the 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

doc.: IEEE /0485r0 Submission May 2004 Jesse Walker and Emily Qi, Intel CorporationSlide 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

doc.: IEEE /0485r0 Submission May 2004 Jesse Walker and Emily Qi, Intel CorporationSlide 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

doc.: IEEE /0485r0 Submission May 2004 Jesse Walker and Emily Qi, Intel CorporationSlide 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

doc.: IEEE /0485r0 Submission May 2004 Jesse Walker and Emily Qi, Intel CorporationSlide 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

doc.: IEEE /0485r0 Submission May 2004 Jesse Walker and Emily Qi, Intel CorporationSlide 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 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

doc.: IEEE /0485r0 Submission May 2004 Jesse Walker and Emily Qi, Intel CorporationSlide 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

doc.: IEEE /0485r0 Submission May 2004 Jesse Walker and Emily Qi, Intel CorporationSlide 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.)

doc.: IEEE /0485r0 Submission May 2004 Jesse Walker and Emily Qi, Intel CorporationSlide 14 Q&A Why is this work in scope for r? –It is related to transition –If TGr adopts a make-before-break architecture, security will be degraded unless Reassociation exchange is secured

doc.: IEEE /0485r0 Submission May 2004 Jesse Walker and Emily Qi, Intel CorporationSlide 15 Feedback?