SA Teardown Protection for 802.11w

1. SA Teardown Protection for 802.11w Date: 2007-9-10

2. Abstract • 802.11w protects Deauthentication and Disassociation • 802.11w does not protect against SA teardown attacks from other sources • This proposal addresses that

3. 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. 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. 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. What to do… • Choice I • Incomplete check for whether the Association request is from the real STA • Modifies 8.4.10 • This prevents the teardown attack from working • But this introduces 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 • Choice II • Have the non-AP STA detect a teardown • This doesn’t prevent the teardown attack at all, but allows for recovery

7. Liveness Test • Both choices would use a liveness 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 Deauthenticates or tears down

8. Ping Request Ping Request Ping Request Ping Request Ping Request X X X X X Ping Example • Ping sent • Ping replied to within timeout period STA1 STA2 STA1 STA2 Ping Request Ping Response Ping Request ResponseTimeout Ping Response ResponseTimeout

9. Ping Request Ping Request Ping Request Ping Request Ping Request Ping Request Ping Request X X X X X X X Ping Example (2) • Ping sent • Response not received within timeout • STA1 initiates Disassociate STA1 STA2 May or may not fall on deaf ears ResponseTimeout Deauthentication SA Terminated

10. Choice I: Remove Association Teardown • Add two new rules • If an AP has an SA for a STA, and it receives an Association frame, test the liveness of the existing PTKSA • If the PTKSA is not live, then drop the SAs before responding • If the PTKSA is live, ignore the Association request • Non-AP STA initiating Associations need to ignore all Ping Requests from the AP the STA is associating to • Now, a refreshed/blank STA coming in will face a small delay after the Association Request before it can begin

11. Choice ILegitimate Case • Non-AP STA sends (Re)association • AP pings the STA • Only failure drops the SA and disables encryption Non-AP STA AP Association Request Ping Request ResponseTimeout Ping Request Ping Request SA Terminated Association Response Pings Ignored EAPOL EAPOL

12. Choice IAttacker Case • Attacker sends (Re)association • AP pings the STA • AP stops processing the Association • AP and STA continue using old association and SA Attacker Non-AP STA AP Association Request Ping Request Ping Response ResponseTimeout AP terminates Association Request, with no change to association or SA state

13. Choice II: STA Liveness Test Remember: we’re keeping the teardown semantics as it is today for this choice • No other way for STA to detect SA Teardown • AP won’t send downlink packets to STA • AP can try to Deauth based on timeouts or uplink packets, but STA will ignore them for lack of a correct MIC • STAs already use an existence test for APs • They usually are Null data packets • Thus, STA needs to ping every now and again • Not needed whenever a downlink data frame—successfully decrypted or not—has been recently received

14. Choice IINormal Case • Pings are sent every so often (STA determined) • Response comes back Non-AP STA AP Ping Request ResponseTimeout Ping Response … Ping Request ResponseTimeout Ping Response … Ping Request ResponseTimeout Ping Response

15. Choice IIAttacker Case • Attacker sends Association Request, terminating the SA • Ping sent • Response not received within timeout • STA (Re)associates Attacker Non-AP STA AP SA Terminated Association Request Disassociation Ignored by integrity check Ignored for no SA Ping Request Ping Request ResponseTimeout Ping Request Reassociation Request Reassociation Response EAPOL

16. Overhead • Per-test overhead can be made very 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 • Question now is on retransmissions to avoid channel loss • This can be tuned similarly to that of other existence tests today

17. Overhead: Choice I • Only requires testing on Association requests • Without this proposal, AP has to respond with some Association Response = 2 frames • With this response, attacker can only elicit one more frame = 3 frames • Thus, packet overhead is negligible • Low time overhead • Ping turnaround can be done in very low millisecond times • Centralized WLAN architectures may have > 10ms Association turnaround times in many cases • Ping can be initiated and handled locally • Thus, overhead can be taken concurrently • Thus, no introduced time overhead in many cases

18. Overhead: Choice II • Requires STA to ping for AP’s existance • The more often, the quicker the STA can recover from teardown • For active clients, there is no added overhead • STA receiving data frame from AP is indication that the SA is still intact • For silent clients that actively check the AP, the overhead is negligible • Instead of Null Data (1 frame), it’s two frames • For silent clients that passively check the AP, the overhead is added, but adjustable

19. Preference • Choice I • Lower overhead in sunny day scenarios • Cleaner, addresses problem directly • STA may still do its own pings if it wishes • It’s just not required to prevent SA teardown attacks

20. Fast Transitions • Association Requests based on FT wouldn’t require pings either • 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

21. Other Alternatives • It’s possible to consider allowing EAPOL exchanges in the clear when an SA is intact • Problem: • 802.1X Uncontrolled Port must be hooked up to either encrypted or unencrypted traffic bidirectionally, not a mix • Strange Solutions: • STAs would be forbidden to send EAPOL encrypted ever, or • STAs would have to send EAPOL unencrypted when told by the AP (in a protected manner) • Thus, I did not consider this path

22. 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)