4-way handshake eapol questions with WPA capable airo driver

[Jouni Malinen]

On Fri, Nov 02, 2007 at 11:46:01AM -0400, Dan Williams wrote:

> 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:

Those 3 EAPOL-Key frames would the first encrypted frame (EAPOL-Key for
group handshake and couple of retries). If the supplicant does not reply
to this, the AP/authenticator disassociates it.

> mic KO:type=88 8e 
> airo(eth1): Bad mic on RX

> 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:

Since this case allows the EAPOL-Key frame to be processed, there is no
timeout in the AP that would cause the client to be disassociated and
consequently, no need to retry group key messages.

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

EAPOL-Key frames have MIC and that is indeed verified in the supplicant.
However, all encrypted TKIP frames have a separate MIC (Michael MIC) and
that is usually verified in hardware/firmware/driver.

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

Immediately after the 4-way handshake, i.e., in case of WPA, in the
group key handshake (WPA2 does not have a separate group key handshake
during initial association, so the first data frame following the 4-way
handshake would be the first encrypted frame).

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

No, Michael MIC does not use sequence numbers.

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

No, it should drop all frames with invalid Michael MIC (and send an
event to user space notifying that this happened).

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

I'm not familiar with this driver, but my first guess would be that the
Michael MIC keys are configured incorrectly (maybe TX/RX keys swapped or
somehow the same key set for both). TKIP key has three components,
128-bit key used to derive per-packet RC4 keys, 64-bit Michael MIC key
for RX, 64-bit Michael MIC key for TX. If the TX and RX Michael MIC keys
are swapped, the frames will be decrypted correctly (which is the case
here), but Michael MIC validation will fail. Since TX/RX keys are
configured differently for AP and client modes (they need to be swapped
to get TX/RX matching at each end), it is quite common to see drivers
setting the keys in different order.

If I understood correctly, the AP here accepted the encrypted frame from
the client if the client when the client was made to ignore Michael MIC
errors. This is somewhat surprising, but it could either indicate that
the client has configured the same Michael MIC key for both TX and RX
and this key happens to work for TX, but not RX; or that the AP is not
actually verifying Michael MIC in the group key message..

I would suggest going through the TKIP key configuration code and test
swapping TX and RX Michael MIC keys (swap bytes 16..23 and 24..31 in
the 32-octet TKIP key). If that does not fix the issue, take a look at
whether the same 64-bit key could end up being used for both TX and RX.

-- 
Jouni Malinen                                            PGP id EFC895FA