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

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

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

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

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.

What to do… Choice I Choice II 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

Ping Test Both choices would use 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 Deauthenticates or tears down

Ping Example Ping sent Ping replied to within timeout period X X X X X STA1 STA2 STA1 STA2 Ping Request Ping Request X Ping Request X Ping Response Ping Request X Ping Request X Ping Request X Ping Request Response Timeout Ping Response Response Timeout

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

Choice I: Remove Association Teardown Add two new rules If an AP has an SA for a STA, and it receives an Association frame, quickly test for the presence of the existing PTKSA If the PTKSA is not current, then drop the SAs before responding If the PTKSA is current, ignore the Association request Non-AP STA initiating Associations need to ignore all Ping Requests from the AP the STA is associating to This is already implicit in the base text Action frames are Class 3; STAs that send Associations are not If Robust Management frame protection is on, lack of a PTKSA will prevent the Ping from being verified Now, a refreshed/blank STA coming in will face a small delay after the Association Request before it can begin

Choice I Legitimate 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 Response Timeout Ping Request Ping Request SA Terminated Association Response Pings Ignored EAPOL EAPOL

Choice I Attacker 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 Response Timeout AP terminates Association Request, with no change to association or SA state

Choice II: STA Ping 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

Choice II Normal Case … … Pings are sent every so often (STA determined) Response comes back Non-AP STA AP Ping Request Response Timeout Ping Response … Ping Request Response Timeout Ping Response … Ping Request Response Timeout Ping Response

Choice II Attacker 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 Response Timeout Ping Request Reassociation Request Reassociation Response EAPOL

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

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

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

Proposal Choice I Ping Services added as an Extended Capabilities 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 Ping Services added as an Extended Capabilities Introduced in 11w, but Useful in other circumstances as well Robust Management frame protection not required for Pings, but Ping responses are required for Robust Management frame protection

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

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

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)