linksys WRT54GX2 replay counter bug? (Nope!)

[Chuck T.]

I hooked up another device and did an off the air Kismet trace of the 
handshake and found the problem.  Apparently the timing on the MIMO APs is 
different enough from "normal" APs that it's uncovered a race my WiFi 
driver.

What's happening is that message 4/4 is being sent from the STA to the AP 
with the pairwise encryption enabled, which is why the AP isn't receiving 
the message.  wpa.c clearly sends the packet before issuing the ioctl to 
install the key, but apparently the card's firmware or driver is applying 
the key before actually sending the packet.  I added a 1/2 second delay in 
wpa_supplicant_process_3_of_4 just before the call to 
wpa_supplicant_install_ptk that made the problem go away.  (Note I carefully 
didn't say "fixed the problem").

Thanks again for the help, I've certainly learned a *LOT* about 802.11i !

Chuck
>From: Jouni Malinen <jkmaline at cc.hut.fi>
>To: hostap at shmoo.com
>Subject: Re: linksys WRT54GX2 replay counter bug?
>Date: Sun, 10 Sep 2006 18:06:42 -0700
>
>On Wed, Sep 06, 2006 at 11:35:33PM -0700, Chuck T. wrote:
>
> > I don't really know enough about the protocol to agree or disagree.  
>When I
> > read the spec I see it's very specific about 1/2 needing to increment 
>the
> > reply_counter on retries, it would stand to reason the same applies to 
>1/4
> > and 3/4.  (page 94)
> >
> > "NOTE?The Authenticator must increment and use a new Key Replay Counter
> > field value on every Message 1 instance, even retries, because the 
>Message
> > 2 responding to an earlier Message 1 may have been lost."
>
>One thing to keep in mind about these "NOTE" comments is that they are
>considered informative and in case of conflict with normative text, the
>normative text prevails. Though, in this case, the NOTE here matches
>with my interpretation of the normative text.
>
>My interpretation of key replay counter is that it must be increment for
>every EAPOL-Key frame that authenticator transmits, even if it is a
>replay. The key replay counter is not incremented for lower layer
>retransmission (i.e., if the MPDU is not acknowledged), but in that case
>it is not the authenticator (but lower layer entity) doing the
>retransmission.
>
> > On the other hand the spec seems to imply that 1/4 is retransmitted with
> > the same reply_counter value (page 80)
>
> > "The local Key Replay Counter field should not be updated until the 
>after
> > EAPOL-Key MIC is checked and is valid. In other words, the Supplicant 
>never
> > updates the Key Replay Counter field for Message 1 in the 4-Way 
>Handshake,
> > as it includes no MIC. This implies the Supplicant must allow for
> > retransmission of Message 1 when checking for the key replay counter of
> > Message 3."
>
>This statement is somewhat confusing. I interpret it somewhat
>differently, though. For me, it just says that supplicant cannot enforce
>incrementing key replay counter between message 1 and 3 since message 1
>does not include MIC. It does not say that retries of message 1 should
>use the same key replay counter.
>
>The first sentence is fine, but the two following sentences would look
>more like informative notes.
>
> > There's also an interesting note on page 80:
> >
> > "NOTE?The key replay counter does not play any role beyond a performance
> > optimization in the 4-Way Handshake. In particular, replay protection is
> > provided by selecting a never-before-used nonce value to incorporate 
>into
> > the PTK."
> >
> > The spec goes on to say that 4/4 "serves no cryptographic purpose" so 
>one
> > could make the argument that responding to a 3/4 message with the same
> > replay_counter would do no harm.
>
>No harm to cryptographic purposes, but maybe harm to something else.. If
>nothing else, it adds extra traffic and latency to key handshake.
>
> > The only thing I know for sure is that two APs from two different
> > manufactures (Linksys WRT54GX2 and a Netgear WPNT834) with current 
>firmware
> > seem to have the same bug.  The single channel APs I have (Linksys 
>WRT54G,
> > Dlink Di-524 never seem to miss any of the replies so I don't know how 
>they
> > behave.
>
>For what it's worth, the WRT54G I have here resets the key replay
>counter to zero on association and increments it for every re-try of
>msg 1/4, 3/4, and 1/2.
>
>--
>Jouni Malinen                                            PGP id EFC895FA
>_______________________________________________
>HostAP mailing list
>HostAP at shmoo.com
>http://lists.shmoo.com/mailman/listinfo/hostap