linksys WRT54GX2 replay counter bug? (Nope!)

Chuck T. freebsdfan
Mon Sep 18 13:03:52 PDT 2006 

>From: Dan Williams <dcbw at redhat.com>
>To: "Chuck T." <freebsdfan at hotmail.com>
>CC: jkmaline at cc.hut.fi, hostap at shmoo.com
>Subject: Re: linksys WRT54GX2 replay counter bug? (Nope!)
>Date: Mon, 18 Sep 2006 11:54:46 -0400
>
>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.

I don't know enough about Linux internals to answer with any authority, but 
the packet and the ioctl take a decidedly different path in reaching the 
driver.  Does Linux make any guarantee that a packet that's sent via the 
networking stack actual gets to the driver before the ioctl?  Is there any 
guarantee that packets queued for transmission aren't immediately affected 
by the ioctl that enables encryption?

Clearly the time delay isn't an ideal "fix".  I'd have a hard time arguing 
that a delay is the correct fix. On the other hand it bypassed my problem 
and it only occurs on initial connection to the network.

As for diagnosing the driver ... I just have a binary blob of the firmware, 
no source.  The driver has numerous other "issues" and I don't consider it 
to be of good quality.

(by the way I reduced the delay to 1/4 second and it still "fixed" the 
problem)

Chuck
>
>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
>

More information about the Hostap mailing list