4-way handshake eapol questions with WPA capable airo driver

[Dan Williams]

Hi,

Using patches matthieu castet and Fabrice Bellet to add WPA support to
the airo driver, I've run into an odd problem and I need some insight
into where the problem may lie and what the choreography of the EAPOL
exchanges is.  I suspect a driver problem since other cards work just
fine with my setup, but I don't know enough about the interactions to
figure out where to look.

I'm using a Cisco AIR-AP1131AG-A-K9 v03 with FreeRADIUS and TTLS, using
TKIP encryption, wpa_supplicant 0.5.7, and 2.6.23.1.

The WPA-capable airo driver MICs the WPA packets internally with michael
and compares the computed MIC with the packet pulled from the card,
which I believe the firmware computes.

So down to the problem.  Everything goes great until the 4-Way handshake
when wpa_supplicant installs the PTK to the driver:

WPA: RX EAPOL-Key - hexdump(len=125): 01 03 00 79 fe 01 c9 00 20 00 00 00 00 00 00 00 02 da b4 39 fa ec 7f 0e 4e 6c 7e ac 12 3d 8a 34 fb b8 01 66 e2 7a 2b c2 18 e7 71 fc 42 a6 06 6f 2b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 71 35 69 56 3a 0c 3e 3c be a3 48 69 2a 9d 27 8e 00 1a dd 18 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 01 28 00
State: 4WAY_HANDSHAKE -> 4WAY_HANDSHAKE
WPA: RX message 3 of 4-Way Handshake from 00:1a:a2:be:0d:70 (ver=1)
WPA: IE KeyData - hexdump(len=26): dd 18 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 01 28 00
WPA: Sending EAPOL-Key 4/4
WPA: TX EAPOL-Key - hexdump(len=99): 01 03 00 5f fe 01 09 00 20 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b8 cb 39 d9 29 a8 fc 8d 35 1b ca 8f ed 87 9e 6d 00 00
WPA: Installing PTK to the driver.
WPA: RSC - hexdump(len=6): 00 00 00 00 00 00
wpa_driver_wext_set_key: alg=2 key_idx=0 set_tx=1 seq_len=6 key_len=32
State: 4WAY_HANDSHAKE -> GROUP_HANDSHAKE
RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
Wireless event: cmd=0x8b15 len=24
Wireless event: new AP: 00:00:00:00:00:00

At that point, the driver receives a series of 3 EAPOL frames that fail
the internal driver MIC checking, but _don't_ fail decryption (otherwise
I assume they would not be passed up to the driver from the firmware and
would just be dropped).  This causes a disassociation (either in FW or
driver) and causes wpa_supplicant to fail the handshake:

airo(eth1): set wpa : alg = 0x2, key len = 32, index = 0, flags 0xA
airo(eth1): airo_set_encodeext_wpa: writing WPA RID
airo(eth1): Setting default tx key to 0
               ^^^^ These 3 lines are the PTK getting installed
mic KO:type=88 8e 
airo(eth1): Bad mic on RX
mic KO:type=88 8e 
airo(eth1): Bad mic on RX
mic KO:type=88 8e 
airo(eth1): Bad mic on RX
airo(eth1): status : 0x8117
airo(eth1): airo_interrupt_tasklet: sending BSSID event 00:00:00:00:00:00

However, if I ignore the MIC failure in the driver (consequently passing
the packet up to wpa_supplicant), only _one_ bad MIC is detected (and
ignored), everything goes great, and wpa_supplicant completes the
handshake, and communication can proceed as normal:

airo(eth1): set wpa : alg = 0x2, key len = 32, index = 0, flags 0xA
airo(eth1): airo_set_encodeext_wpa: writing WPA RID
airo(eth1): Setting default tx key to 0
             ^^^^ PTK getting installed
mic KO:type=88 8e 
airo(eth1): Bad mic on RX
airo(eth1): authType=c101 flags=402 alg=2
airo(eth1): set wpa : alg = 0x2, key len = 32, index = 1, flags 0x6
airo(eth1): airo_set_encodeext_wpa: writing WPA RID
             ^^^^ GTK getting installed

and from wpa_supplicant in the ignore-bad-MIC case:

State: 4WAY_HANDSHAKE -> GROUP_HANDSHAKE
RX EAPOL from 00:1a:a2:be:0d:70
RX EAPOL - hexdump(len=131): 01 03 00 7f fe 03 91 00 20 00 00 00 00 00 00 00 03 da b4 39 fa ec 7f 0e 4e 6c 7e ac 12 3d 8a 34 fb b8 01 66 e2 7a 2b c2 18 e7 71 fc 42 a6 06 6f 29 06 51 43 2a 85 00 d6 2a b7 d3 41 5c 78 2a a8 c3 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 dd 3a 9b 27 75 ff fb df d2 75 28 eb eb e0 2e 34 00 20 93 54 f8 a0 88 1a 63 0c 76 5e ff 5c 4b 54 b8 a8 c6 90 0c 4b b6 7d 55 bd 31 6b 0e c5 d2 4d 5c 5d
IEEE 802.1X RX: version=1 type=3 length=127
  EAPOL-Key type=254
  key_info 0x391 (ver=1 keyidx=1 rsvd=0 Group Ack MIC Secure)
  key_length=32 key_data_length=32
  replay_counter - hexdump(len=8): 00 00 00 00 00 00 00 03
  key_nonce - hexdump(len=32): da b4 39 fa ec 7f 0e 4e 6c 7e ac 12 3d 8a 34 fb b8 01 66 e2 7a 2b c2 18 e7 71 fc 42 a6 06 6f 29
  key_iv - hexdump(len=16): 06 51 43 2a 85 00 d6 2a b7 d3 41 5c 78 2a a8 c3
  key_rsc - hexdump(len=8): 0e 00 00 00 00 00 00 00
  key_id (reserved) - hexdump(len=8): 00 00 00 00 00 00 00 00
  key_mic - hexdump(len=16): dd 3a 9b 27 75 ff fb df d2 75 28 eb eb e0 2e 34
WPA: RX EAPOL-Key - hexdump(len=131): 01 03 00 7f fe 03 91 00 20 00 00 00 00 00 00 00 03 da b4 39 fa ec 7f 0e 4e 6c 7e ac 12 3d 8a 34 fb b8 01 66 e2 7a 2b c2 18 e7 71 fc 42 a6 06 6f 29 06 51 43 2a 85 00 d6 2a b7 d3 41 5c 78 2a a8 c3 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 dd 3a 9b 27 75 ff fb df d2 75 28 eb eb e0 2e 34 00 20 93 54 f8 a0 88 1a 63 0c 76 5e ff 5c 4b 54 b8 a8 c6 90 0c 4b b6 7d 55 bd 31 6b 0e c5 d2 4d 5c 5d
WPA: RX message 1 of Group Key Handshake from 00:1a:a2:be:0d:70 (ver=1)


So questions I've got:

a) don't EAPOL frames have MIC bits, and doesn't wpa_supplicant check
those itself?

b) at what point in the 4-way handshake are incoming 802.11 frames from
the AP expected to be encrypted with the PTK?

c) could some sequence numbering be causing the MIC failure?

d) Should the airo driver just ignore failed MICs for EAPOL frames
entirely?

Logs from successful (ie, ignore failed MICs) and unsuccessful runs at
http://people.redhat.com/dcbw/airo-wpa/ .

Any insight would be appreciated.

Thanks!
Dan