TKIP attack

Miles mileshwu
Wed Nov 12 07:55:56 PST 2008

Jouni, wpa_receive() is only for EAPOL-KEY message, not for encrypted data. isn't it? For MIC error happens in data packets, we will wait 2 times.
Please correct me if I'm wrong.

--- On Wed, 11/12/08, Jouni Malinen <j at> wrote:
From: Jouni Malinen <j at>
Subject: Re: TKIP attack
To: hostap at
Date: Wednesday, November 12, 2008, 7:00 AM

On Tue, Nov 11, 2008 at 07:50:02PM -0800, Miles wrote:
> Thank your reply, but I checked and found following(version 0.4.8):
> ??? if (now > hapd->michael_mic_failure + 60) {
> ??? ??? hapd->michael_mic_failures = 1;
> ??? } else {
> ??? ??? hapd->michael_mic_failures++;
> ??? ??? if (hapd->michael_mic_failures > 1)
> ??? ??? ??? ieee80211_tkip_countermeasures_start(hapd);
> ??? }
> It will wait until the second MIC error and then go to countermeasure.

Yes, but the PTK rekeying is handled in wpa_receive() and it is done for
every MIC error report.

> Even hostapd will go to countermeasure mode for every single MIC error, is
it too expensive to kick out all clients? How about we just  rekey or deauth the
client who cause it.

TKIP countermeasures are required if there are two MIC failures within
60 seconds and that is not going to change unless the standard and
certification tests are changed (i.e., unlikely to happen). Likewise, I
don't think I would be enabling countermeasures on a single MIC failure
or change the behavior to deauthenticate a client (it's not really the
client causing it here; it's the attacker..).

Rekeying of PTK is already done for each error report. I could consider
changing the code to rekey GTK, too, if the error report is for a group
key. I don't think that that part is handled in the current

Jouni Malinen                                            PGP id EFC895FA
HostAP mailing list
HostAP at

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Hostap mailing list