[PATCH] hostapd: Disassociate client after SA timeout
Jouni Malinen
j at w1.fi
Wed Feb 1 10:57:37 PST 2023
On Tue, Jan 17, 2023 at 10:25:22AM +0100, Jan Fuchs wrote:
> In case of a dot11AssociationSAQueryMaximumTimeout and according to
> "Note 3" in IEEE-802.11-2020 "11.3.5.3 AP or PCP association receipt
> procedures" enumeration "j)" (page 2135), hostapd shall send a protected
> disassocation with ReasonCode "INVALID_AUTHENTICATION".
Please note that this particular step is executed when receiving a new
Association Request frame and deciding that the new association can be
accepted. In other words, this is _not_ supposed to be done when the SA
Query procedure times out, but on the following association attempt.
> This is needed
> when a forged packet (e.g. Re-Assocication Request) is getting injected
> during a longer power save of the station, where the station is not able
> to answer the SA queries. This could lead to a situation, where the AP
> removes the STA due to SA Query Maximum Timeout, while the station
> (after waking up again) believes it's still associated with this AP. To
> prevent this, a protected disassociation by the AP is sent out telling
> the station its association is no longer valid.
It would be appropriate to adjust the SA Query timeout to work with the
STA's power save policy, i.e., potentially increase the timeout if the
STA that has negotiated use of management frame protection for the
association is known to be in a power save state that has prevented it
from receiving the SA Query Request frames.
Dropping the association immediately on SA Query procedure timeout is
not correct behavior. In fact, it will just make it easier and faster
for an attacker to force the real STA to be disconnected.
> diff --git a/src/ap/sta_info.c b/src/ap/sta_info.c
> @@ -1159,6 +1159,12 @@ int ap_check_sa_query_timeout(struct hostapd_data *hapd, struct sta_info *sta)
> sta->sa_query_trans_id = NULL;
> sta->sa_query_count = 0;
> eloop_cancel_timeout(ap_sa_query_timer, hapd, sta);
> +
> + hostapd_logger(hapd, sta->addr, HOSTAPD_MODULE_IEEE80211,
> + HOSTAPD_LEVEL_INFO,
> + "disconnected due to SA Query max timeout");
> + hostapd_drv_sta_disassoc(hapd, sta->addr, WLAN_REASON_PREV_AUTH_NOT_VALID);
> + ap_sta_disassociate(hapd, sta, WLAN_REASON_PREV_AUTH_NOT_VALID);
> return 1;
This must not be done since it is just making the management frame
protection mechanisms easier to bypass. It would be better to delay the
acceptance of the following association attempt if the STA has not
acknowledged the SA Query Request frames.
As far as the specific case of the station not receiving anything for a
long time is concerned, if there is need to work around the part of that
STA not accepting unprotected Deauthentication/Disassociation frames
once it finally wakes up and transmits a Class 3 frame to the AP, the
safest way of doing that would be to remember the current key (TK) and
transmit a protected Deauthentication/Disassociation frame using that
old key when receiving an unexpected frame from the station.
--
Jouni Malinen PGP id EFC895FA
More information about the Hostap
mailing list