TKIP attack

[Jouni Malinen]

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
implementation.

-- 
Jouni Malinen                                            PGP id EFC895FA