linksys WRT54GX2 replay counter bug?
freebsdfan at hotmail.com
Thu Sep 7 02:35:33 EDT 2006
>On Wed, Sep 06, 2006 at 04:58:19PM -0700, Chuck T. wrote:
> > I now believe this is actually a problem with wpa_supplicant's handling
> > errors during the handshake.
>I don't agree with this.
> >x My initial analysis was wrong, I had assumed
> > that the packet that didn't show an increase in the reply_count was 1/2
> > the group handshake, infact it was a retransmission of the 2/4 of the 4
> > handshake message. Apparently the AP didn't get the reply from the STA
> > resent the 2/4 message with the same replay_count. The wpa_supplicant
> > didn't respond to the retransmitted message so the handshake failed.
>But this looks correct except that 2/4 should be 3/4 (i.e., it is the
>message 3 from AP that is being retransmitted). However, that AP is just
>plain broken. Replay counter must be incremented for each EAPOL-Key
>frame within the association, including retransmissions at this level
>(IEEE 802.11 MPDU re-transmissions are not modified, but those would be
>dropped at lower layer). Based on the the frame timestamps, these
>EAPOL-Key frames (msg 3/4) were retransmitted once a second, i.e., most
>likely at the authenticator state machine. However, the replay counter
>was not incremented.
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)
"NOTEThe 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."
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
There's also an interesting note on page 80:
"NOTEThe 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 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.
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
>wpa_supplicant drops, as required by IEEE Std 802.11i-2004, these frames
>as replay attacks. The same replay counter must not be re-used within
>the same association. In addition, the standard actually specifies that
>this replay counter is initialized to zero on association while the AP
>is clearly not doing this, but using a random (I would assume) value.
>This itself should not really cause issues, but it just looks like
>whoever implemented that authenticator did not really follow the
>standard very closely.
I agree. The Linksys AP does the same thing. If you look at the
reply_counter in hex you'll see the *lower* 32 bits have been cleared, but
not the upper 32 bits. Lazy programmer perhaps.
Thanks for the help understanding this stuff.
More information about the HostAP