(oops.. managed to miss a cc to the list in my response.. sorry
about the duplicate message Dennis)
On Thu, Jan 03, 2019 at 08:17:11PM -0700, Dennis Bland wrote:
> When hostapd 2.7 is configured for FT over-the-DS mode, performing an
> FT roam back to a previously-connected AP gives the following error in
> hostapd:
>
> nl80211: NL80211_CMD_SET_STATION result: -22 (Invalid argument)
> wlan01: STA 06:05:04:03:02:01 IEEE 802.11: Could not set STA to kernel driver
>
> This results in hostapd refusing the reassociation request with code
> 17 (Association denied because AP is unable to handle additional
> associated stations). The kernel driver in this case is the ath10k
> (4.19).
>
> In add_associated_sta() in ieee802_11.c, there is a conditional that
> resets the wpa sm (required for FT over-the-DS mode as there is no
> authentication frame to reset the wpa sm), but only if the STA is not
> authorized. The STA is not authorized when performing an FT roam to a
> new AP, but it is authorized when roaming back to a
> previously-connected AP. Therefore, any FT over-the-DS roams to new
> APs will work correctly, and FT over-the-DS roams to
> previously-connected (authorized) APs will fail.
mac80211 is quite unhappy in this particular case since there is no STA
entry in the kernel and hostapd ends up trying to work around key
reinstallation issues by refusing to clear and re-add a STA entry here.
> The patch below appears to fix this issue, validated after performing
> several thousand FT over-the-air and over-the-DS roams with our
> automated test bed. However, I am hesitant to submit it in this form
> as it may affect FILS (which we are not currently using) or possibly
> KRACK:
>
> diff -Naur orig/hostap_2_7/src/ap/ieee802_11.c
> new/hostap_2_7/src/ap/ieee802_11.c
> --- orig/hostap_2_7/src/ap/ieee802_11.c 2018-12-02 12:34:59.000000000 -0700
> +++ new/hostap_2_7/src/ap/ieee802_11.c 2018-12-28 23:41:00.394507047 -0700
> @@ -2808,10 +2808,11 @@
> * TK has been configured since the TX/RX PN must not be reset to 0 for
> * the same key.
> */
> - if (!sta->added_unassoc &&
> - (!(sta->flags & WLAN_STA_AUTHORIZED) ||
> +
> + /* do not check for WLAN_STA_AUTHORIZED for FT-over-the-DS */
> + if (!sta->added_unassoc ||
> (!wpa_auth_sta_ft_tk_already_set(sta->wpa_sm) &&
> - !wpa_auth_sta_fils_tk_already_set(sta->wpa_sm)))) {
> + !wpa_auth_sta_fils_tk_already_set(sta->wpa_sm))) {
This would seem to break key reinstallation checks completely, so this
is clearly not a good way of fixing this.
This is unfortunately a very inconvenient case to handle with mac80211
and that's why this ended up the way it did with the security fixes.
However, I did not realize it broke more cases than the potential corner
cases I was thinking of earlier.
There is a case here in which it is safe to add the STA entry "again"
since the encryption key (TK) is known to have changes during the
FT-over-the-DS exchange. That is the case that you are most likely to
hit here. I applied following changing to address this:
https://w1.fi/cgit/hostap/commit/?id=4cf5efece394067542673a252d6ea67b898b8eb9
> Not sure if FT roaming to a previous AP is included in the unit tests.
> If not, it might be a good idea to add it.
ap_ft_over_ds did indeed cover this sequence and that's what I used to
test the key reinstallation fixes in order to try to avoid regressions
here. Alas, that test case did not cover this particular detail since it
was using a single hostapd process that ended up clearing the old
association during reassociation to the other AP. I implemented a more
complex test case with two hostapd processes to cover this particular
sequence in more detail and that was indeed able to reproduce the issue.
The commit mentioned above got rid of the issue that I was able to
reproduce.
--
Jouni Malinen PGP id EFC895FA
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
