Bug in madwifi communication

[Jouni Malinen]

On Thu, Feb 24, 2005 at 10:58:33AM +0100, Jens Stavnstrup wrote:

> I am told we are using something called Ringmaster version 2.1.2.0

OK. This is the first authentication server that I've seen doing this:

> RX EAPOL from 00:0b:0e:02:32:40
> RX EAPOL - hexdump(len=48): 01 00 00 26 01 0a 00 26 19 00 17 03 01 00 1b 5c 7a 0b 1f 26 9d cc 10 e3 05 c9 61 61 83 57 d2 84 1c 06 30 11 98 1a b8 e7 82 ef ed 92 9b 1a 18 f9
> EAPOL: Received EAP-Packet frame
> EAPOL: SUPP_BE entering state REQUEST
> EAPOL: getSuppRsp
> EAP: EAP entering state RECEIVED
> EAP: Received EAP-Request method=25 id=10

This is the protected success notification in EAP-TLV. EAP Id=10.

The following message is EAP-Success:

> RX EAPOL from 00:0b:0e:02:32:40
> RX EAPOL - hexdump(len=48): 01 00 00 04 03 0c 00 04 19 00 17 03 01 00 1b 5c 7a 0b 1f 26 9d cc 10 e3 05 c9 61 61 83 57 d2 84 1c 06 30 11 98 1a b8 e7 82 ef ed 92 9b 1a 18 f9

EAP Id=12. However, EAP RFC requires that EAP-Success uses the same Id
that was used in previous EAP-Request, i.e., 10 in this case.. This
makes wpa_supplicant ignore the frame:

> EAPOL: Received EAP-Packet frame
> EAPOL: SUPP_BE entering state REQUEST
> EAPOL: getSuppRsp
> EAP: EAP entering state RECEIVED
> EAP: Received EAP-Success
> EAP: EAP entering state DISCARD

There is already a workaround for lastId+1 in EAP-Success, but not for
lastId+2. Could you please try whether the attached patch removes this
issue in your network? You can apply it with 'patch -p0 <
eap_success_workaround.patch' in the wpa_supplicant directory.

-- 
Jouni Malinen                                            PGP id EFC895FA
-------------- next part --------------
Index: eap.c
===================================================================
RCS file: /home/jm/cvsroot/hostap/wpa_supplicant/eap.c,v
retrieving revision 1.62
diff -u -p -u -p -r1.62 eap.c
--- eap.c	22 Jan 2005 19:28:26 -0000	1.62
+++ eap.c	24 Feb 2005 14:38:04 -0000
@@ -458,19 +458,27 @@ SM_STATE(EAP, FAILURE)
 
 static int eap_success_workaround(struct eap_sm *sm, int reqId, int lastId)
 {
-	/* At least Microsoft IAS and Meetinghouse Aegis seem to be sending
+	/*
+	 * At least Microsoft IAS and Meetinghouse Aegis seem to be sending
 	 * EAP-Success/Failure with lastId + 1 even though RFC 3748 and
 	 * draft-ietf-eap-statemachine-05.pdf require that reqId == lastId.
+	 * In addition, it looks like Ringmaster v2.1.2.0 would be using
+	 * lastId + 2 in EAP-Success.
+	 *
 	 * Accept this kind of Id if EAP workarounds are enabled. These are
 	 * unauthenticated plaintext messages, so this should have minimal
-	 * security implications (bit easier to fake EAP-Success/Failure). */
-	if (sm->workaround && reqId == ((lastId + 1) & 0xff)) {
+	 * security implications (bit easier to fake EAP-Success/Failure).
+	 */
+	if (sm->workaround && (reqId == ((lastId + 1) & 0xff) ||
+			       reqId == ((lastId + 2) & 0xff))) {
 		wpa_printf(MSG_DEBUG, "EAP: Workaround for unexpected "
 			   "identifier field in EAP Success: "
 			   "reqId=%d lastId=%d (these are supposed to be "
 			   "same)", reqId, lastId);
 		return 1;
 	}
+	wpa_printf(MSG_DEBUG, "EAP: EAP-Success Id mismatch - reqId=%d "
+		   "lastId=%d", reqId, lastId);
 	return 0;
 }