RSN: Stop connection attempt on apparent PMK mismatch

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>

src/rsn_supp/wpa.c

@@ -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)