1. doc.: IEEE 802.11-07/2441r2 Submission SA Teardown Protection for 802.11w Date: 2007-11-05

2. doc.: IEEE 802.11-07/2441r2 Submission Abstract 802.11w protects Deauthentication and Disassociation 802.11w does not protect against SA teardown attacks from other sources This proposal addresses that

3. doc.: IEEE 802.11-07/2441r2 Submission SA Teardown Section 8.4.10, paraphrased –The SA is torn down when any of the following occurs Successful (Re)association Confirm primitive for STA –STA sent Non-FT (Re)association Request and got a response (Re)association Indication primitive for AP –AP received a Non-FT (Re)association Request Invocation of Disassociation or Deauthentication primitive for everyone Thus, an attacker can teardown the SA on the AP by pretending to be the client and sending an Association message

4. doc.: IEEE 802.11-07/2441r2 Submission Analysis of Deauth/Disassoc (for comparison) Deauthing a Non-AP STA will cause the STA to reconnect somewhere quickly Deauthing the AP will cause the class to drop, and the next uplink packet will cause a Disassoc in the opposite direction. –All active methods a client use to check that the AP is still in radio range will trigger this, including Null Data A new association and SA will be reestablished quickly

5. doc.: IEEE 802.11-07/2441r2 Submission Analysis of SA Teardown Tearing down the STA’s side is generally not possible, except at the time of Association itself. –Though STA could potentially go out of sync…this is still a problem Tearing down the AP’s side, however, will cause major problems –AP will think the client is associating –EAPOL timers will start. These will wait for many seconds before kicking off the client with a Deauth –Upstream frames from the client will not cause any resynchronization at all Section 8.4.10 list item c) states that no Deauth will occur in this case –Wouldn’t matter anyway: without an SA, all Deauths are lame and take no effect –Thus, there’s no way to recover. The STA is happily in limbo.

6. doc.: IEEE 802.11-07/2441r2 Submission Analysis of SA Teardown (2) Conclusion: –Protecting Deauth and Disassoc important step in reducing DoS attacks –However, it also introduced a new form of silent teardown attacks that has an even worse DoS problem –This proposal addresses that problem

7. doc.: IEEE 802.11-07/2441r2 Submission What to do… Proposal –Incomplete check for whether the Association request is from the real STA –Modifies 8.4.10 –This prevents the teardown attack from working –Avoids introducing a lockout problem Station that lose key state synchronization can never come back in Specific case: STA loses SA; AP retains it (Re)association SA clearing was what let the STA send and receive unencrypted EAPOL frames from the AP The STA may still use Pings for its own purposes –For example: having the non-AP STA detect a teardown –This doesn’t prevent the teardown attack at all, but allows for recovery

8. doc.: IEEE 802.11-07/2441r2 Submission Ping Test What is a Ping test? –Create a Ping Action frame, with two protected unicast types Ping Request Ping Response –When a STA initiates a test, it starts a timer and sends some number of Ping Requests –If no Ping Response comes after the timeout, the initiator may take additional action (not specified in definition of Ping itself) Note that Ping is a protected Action frame

9. doc.: IEEE 802.11-07/2441r2 Submission Ping Example Ping sent Ping replied to within timeout period STA1STA2 Ping Request Response Timeout Ping Response STA1STA2 Response Timeout Ping Response Ping Request X X X X X

10. doc.: IEEE 802.11-07/2441r2 Submission Ping Example (2) Ping sent Response not received within timeout STA1 takes additional action, if desired STA1STA2 Response Timeout Ping Request X X X X X X X Additional action

11. doc.: IEEE 802.11-07/2441r2 Submission Proposal: Remove Association Teardown Add two new rules –If an AP has an SA for a STA, and it receives an Association frame, it rejects the Association with a new Status Code Code xx: “Testing existing security association; try again later” Informative IE also holds Association comeback time With this specific rejection, the AP shall not modify the association state or STA parameters –AP then sends Pings protected under the SA Asks STA for permission, under different cover, to keep SA alive –STA may reassociate after the ping test is complete Now, a refreshed/blank STA coming in will face a small delay and will have to associate twice

12. doc.: IEEE 802.11-07/2441r2 Submission Proposal Legitimate Case Non-AP STA sends (Re)association AP rejects association, but starts ping AP pings the STA Only failure drops the SA and disables encryption STA tries again Non-AP STAAP Response Timeout Ping Request SA Terminated Association Request Association Response Reject: Try Again Later EAPOL Pings Ignored Association Request Association Response

13. doc.: IEEE 802.11-07/2441r2 Submission Proposal Attacker Case Attacker sends (Re)association AP pings the STA AP stops processing the Association AP and STA continue using old association and SA Non-AP STAAP Response Timeout Ping Request Ping Response Association Request Attacker Association Response Reject: Try Again Later

14. doc.: IEEE 802.11-07/2441r2 Submission Overhead Per-test overhead can be made small –Teardown attack only requires ability to transmit frames No need to assume that the attacker can jam/delete –Thus, even one ping protects –Tradeoff between speed and resiliency STA still receives proof that the AP exists and could be willing to take the STA –Helps scanning behavior –Comeback time identifies when the STA can next try again

15. doc.: IEEE 802.11-07/2441r2 Submission Furthermore Ping Services added as an Extended Capabilities –Introduced in 11w, but –Useful in other circumstances as well –Robust Management frame protection not required to be on for a STA to use Pings itself, but Ping Responses are required to be generated for Robust Management frame protection

16. doc.: IEEE 802.11-07/2441r2 Submission What About Fast Transitions? Association Requests based on FT don’t need to be changed –Currently, SAs are not torn down on an FT Association –The liveness test is built in, of course But Pings still needed elsewhere –Attackers can always send non-FT Association Requests, and the AP still needs to handle that case Could limit modifications entirely to just 8.4.10: always disregard Assoc for teardown –Would let 802.11r + 802.11w be a solution when bundled together –But requiring FT support is extreme and unwarranted just to solve this problem End result: 802.11r helps by removing all overhead on FT, but non-FT case still requires Choice I

17. doc.: IEEE 802.11-07/2441r2 Submission Postscript Proposal addresses flaky text in IEEE 802.11-2007 Section 11.3.1.2: Authentication –The STA’s SME shall delete any PTKSA and temporal keys held for communication with the indicated STA by using the MLME- DELETEKEYS.request primitive (see 8.4.10) upon receiving a MLMEAUTHENTICATE.indication primitive. Strike that text out (and from 11.3.1.1 as well)