linksys WRT54GX2 replay counter bug?

[Chuck T.]

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

True, but extra traffic is probably preferable to a failed negotiation.  On 
the other hand sending it did no good either. As a test I disabled the 
replay_counter checking code, but it *DID NOT HELP*.  There's something 
going on that is preventing the AP from receiving or liking the 4/4 message. 
   It works about 10% of the time, but in the other 90% of the cases the 
negotiation fails even with retries.

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

The WRT54GX2 is a completely different animal than the WRT54G, I also have a 
WRT54G and it works solidly with the supplicant.  I've never seen any 
failures or retries with it.  The WRT54GX2 is a "MIMO" draft 802.11n AP, the 
WRT54G is a plain Jane 802.11g AP.

Since there is GPL'ed code tarballs for both the Netgear and Linksys I 
downloaded them.  Turns out they both use the same authenticator code 
apparently from Airgo.  Unfortunately the source for the authenticator 
(ani8021x_aa) in not in the tarball, only the executable.

Thanks again for the help!

Chuck