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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
