jeltz/hostap
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

RSN: Stop connection attempt on apparent PMK mismatch

Browse source 
If WPA2-Enterprise connection with full EAP authentication (i.e., no
PMKSA caching used) results in a PMKID that does not match the one the
AP/Authenticator indicates in EAPOL-Key msg 1/4, there is not much point
in trying to trigger full EAP authentication by sending EAPOL-Start
since this sequence was immediately after such full authentication
attempt.

There are known examples of authentication servers with incorrect MSK
derivation when TLS v1.2 is used (e.g., FreeRADIUS 2.2.6 or 3.0.7 when
built with OpenSSL 1.0.2). Write a clear debug log entry and also send
it to control interface monitors when it looks likely that this case has
been hit. After doing that, stop the connection attempt by
disassociating instead of trying to send out EAPOL-Start to trigger new
EAP authentication round (such another try can be tried with a new
association).

Signed-off-by: Jouni Malinen <j@w1.fi>
This commit is contained in:
Jouni Malinen 2015-07-08 20:48:18 +03:00
parent 6c4b5da46d
commit bddc51e8e4
1 changed files with 11 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
src/rsn_supp/wpa.c
View file

@ -249,6 +249,17 @@ static int wpa_supplicant_get_pmk(struct wpa_sm *sm,
"RSN: the new PMK matches with the "
"PMKID");
abort_cached = 0;
} else if (sa && !sm->cur_pmksa && pmkid) {
/*
* It looks like the authentication server
* derived mismatching MSK. This should not
* really happen, but bugs happen.. There is not
* much we can do here without knowing what
* exactly caused the server to misbehave.
*/
wpa_dbg(sm->ctx->msg_ctx, MSG_INFO,
"RSN: PMKID mismatch - authentication server may have derived different MSK?!");
return -1;
}
if (!sm->cur_pmksa)