| Message ID | 20231027073432.11915-1-jianling.fu@mediatek.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | Display error on SAE connection with incorrect key | expand |
On Fri, Oct 27, 2023 at 03:34:32PM +0800, Jianling.Fu wrote: > If a failure occurs at sae "auth confirm" step, > the most probable cause is an error related to the key. Well, it depends.. I guess that might be the case when adding a new network for the first time and there having been no successful authentications before this. However, if there has been a successful authentication, I would be quite careful on how to interpret failures during SAE authentication since they could be caused by active attacks and should not result in something like dropping the password and asking using to enter a different one. > Correspondingly, in the case of handling SME in wpa_supplicant, > a similar way to internally trigger an association reject > event is used. We do this through calling sme_event_assoc_reject > to trigger upper layer processing with the WRONG_PASSWORD event. This feels really wrong. SAE authentication failing has nothing to do with the AP explicitly rejecting association. This could result in unexpected behavior and issues when sme_event_assoc_reject() might do something now, or in the future after some change, that is not appropriate for the authentication step.
On Sun, 2023-10-29 at 18:13 +0200, Jouni Malinen wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > On Fri, Oct 27, 2023 at 03:34:32PM +0800, Jianling.Fu wrote: > > If a failure occurs at sae "auth confirm" step, > > the most probable cause is an error related to the key. > > Well, it depends.. I guess that might be the case when adding a new > network for the first time and there having been no successful > authentications before this. However, if there has been a successful > authentication, I would be quite careful on how to interpret failures > during SAE authentication since they could be caused by active > attacks > and should not result in something like dropping the password and > asking > using to enter a different one. > > > Correspondingly, in the case of handling SME in wpa_supplicant, > > a similar way to internally trigger an association reject > > event is used. We do this through calling sme_event_assoc_reject > > to trigger upper layer processing with the WRONG_PASSWORD event. > > This feels really wrong. SAE authentication failing has nothing to do > with the AP explicitly rejecting association. This could result in > unexpected behavior and issues when sme_event_assoc_reject() might do > something now, or in the future after some change, that is not > appropriate for the authentication step. > > -- > Jouni Malinen PGP id > EFC895FA How about this modification? I add "had_been_connected" to identify the network whether connected. And notify wrong key only under the below situations: 1. return -2 when "sae_check_confirm" failed if (sae_check_confirm(&wpa_s->sme.sae, data, len, ie_offset) < 0) - return -1; + return -2; 2. notify wrongkey when "never connected" && (auth reject || sae confirm check fail) + if (wpa_s->drv_flags & WPA_DRIVER_FLAGS_SME + && data->auth.auth_transaction == 2 + && ssid->had_been_connected == 0 + && (data->auth.status_code == + WLAN_STATUS_UNSPECIFIED_FAILURE + || res == -2)) { ....... }
diff --git a/wpa_supplicant/sme.c b/wpa_supplicant/sme.c index bb04652f5..fdd8b331c 100644 --- a/wpa_supplicant/sme.c +++ b/wpa_supplicant/sme.c @@ -2038,6 +2038,30 @@ void sme_event_auth(struct wpa_supplicant *wpa_s, union wpa_event_data *data) data->auth.ies_len, 0, data->auth.peer, &ie_offset); if (res < 0) { + /* + * Based on the 'auth confirm' process, this is a confirmation message + * indicating that it has successfully received and verified the key + * from the router, and has acknowledged the connection. Thus, if a + * failure occurs at this step, the most probable cause is an error + * related to the key. Correspondingly, in the case of handling SME + * in wpa_supplicant, a similar way to internally trigger an association + * reject event is used. We do this through calling sme_event_assoc_reject + * to trigger upper layer processing with the WRONG_PASSWORD event + */ + if (wpa_s->drv_flags & WPA_DRIVER_FLAGS_SME + && data->auth.auth_transaction == 2) { + union wpa_event_data event; + + os_memset(&event, 0, sizeof(event)); + event.assoc_reject.bssid = wpa_s->pending_bssid; + event.assoc_reject.status_code = WLAN_STATUS_UNSPECIFIED_FAILURE; + wpa_s->assoc_status_code = event.assoc_reject.status_code; + wpas_notify_assoc_status_code(wpa_s); + wpa_dbg(wpa_s, MSG_DEBUG, + "SME: SAE Authentication failure，indicate assoc reject"); + sme_event_assoc_reject(wpa_s, &event); + + return; + } wpas_connection_failed(wpa_s, wpa_s->pending_bssid); wpa_supplicant_set_state(wpa_s, WPA_DISCONNECTED);
If a failure occurs at sae "auth confirm" step, the most probable cause is an error related to the key. Correspondingly, in the case of handling SME in wpa_supplicant, a similar way to internally trigger an association reject event is used. We do this through calling sme_event_assoc_reject to trigger upper layer processing with the WRONG_PASSWORD event. Signed-off-by: Jianling.Fu <jianling.fu@mediatek.com> --- wpa_supplicant/sme.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)