linksys WRT54GX2 replay counter bug? (Nope!)
dcbw at redhat.com
Mon Sep 18 11:54:46 EDT 2006
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
> 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.
> Thanks again for the help, I've certainly learned a *LOT* about 802.11i !
> >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
> > > reply_counter on retries, it would stand to reason the same applies to
> > > 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
> > > 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
> > > 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
> > > EAPOL-Key MIC is checked and is valid. In other words, the Supplicant
> > > updates the Key Replay Counter field for Message 1 in the 4-Way
> > > 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
> > > the PTK."
> > >
> > > The spec goes on to say that 4/4 "serves no cryptographic purpose" so
> > > 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
> > > seem to have the same bug. The single channel APs I have (Linksys
> > > Dlink Di-524 never seem to miss any of the replies so I don't know how
> > > 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
> HostAP mailing list
> HostAP at shmoo.com
More information about the HostAP