On Wed, Nov 08, 2023 at 09:44:32PM +0800, Jianling.Fu wrote:
> If the status code is not 'success' during the SAE 'auth confirm' step,
> or if the auth confirm check encounters a mismatch, this would be
> related to the key. In such cases, we would trigger an
> 'association reject' event, which is used to prompt the
> upper layer to process the event as a 'WRONG_PASSWORD' event
This is not an association rejection and should not be claimed to be
that. I'm not sure what 'WRONG_PASSWORD' event means in this context.
There is no such string in this patch or baseline implementation.
For the case where the SAE Confirm is sent first by the STA, the status
code from the AP is already reported with this:
CTRL-EVENT-AUTH-REJECT 02:00:00:00:03:00 auth_type=3 auth_transaction=2 status_code=15
For the case where the SAE Confirm is sent first by the AP, an
additional indication about the SAE Confirm message validation failing
might be of some use. However, that should not be reporting association
failure since association was not even attempted in this case. Instead,
a new indication should be used for this specific case instead of trying
to use an existing association related event.
This patch did not result in WRONG_PASSWORD being indicated in my test.
Instead, this looked as follows:
SME: Authentication response: peer=02:00:00:00:03:00 auth_type=3 auth_transaction=2 status_code=0
SAE: Confirm mismatch
SME: SAE Authentication failure indicate assoc reject
SME: Association with 02:00:00:00:03:00 failed: status code 1
wpa_driver_nl80211_deauthenticate(addr=02:00:00:00:03:00 reason_code=3)
This is quite confusing since there was no association failure and there
was no status code 1 anywhere either. Furthermore, there was this extra
deauthentication.
> diff --git a/wpa_supplicant/config_ssid.h b/wpa_supplicant/config_ssid.h
> @@ -1265,6 +1265,11 @@ struct wpa_ssid {
> + /**
> + * New variable to track if the network
> + * has been successfully connected
> + */
> + int had_been_connected;
This would not be maintained over restarting of a wpa_supplicant
process. It would be better to not to try to reuse some existing
mechanism for indicating potential password failures. Instead, a new
event that could be indicated on all local verification failures for
received SAE confirm messages could be used without having to try to
track success within wpa_supplicant if this is targeting a case where an
external component is adding a network profile and observing what
happens during the first connection attempt.
--
Jouni Malinen PGP id EFC895FA
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
