linksys WRT54GX2 replay counter bug? (Nope!)

[Dan Williams]

On Thu, 2006-09-14 at 16:02 -0700, Chuck T. wrote:
> 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").

Hmm, any way to diagnose why the driver is doing this?  I'd rather not
add latency in wpa_supplicant for broken drivers/firmware if it can be
helped.  Maybe the specific driver needs some fixing here.

dan

> 
> 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
> 
> 
> _______________________________________________
> HostAP mailing list
> HostAP at shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap