linksys WRT54GX2 replay counter bug?
freebsdfan at hotmail.com
Tue Sep 12 11:07:19 EDT 2006
>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.
> > 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.
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
> > 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.
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!
More information about the HostAP