linksys WRT54GX2 replay counter bug?

[Chuck T.]

>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 
>of
> > 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 
>of
> > the group handshake, infact it was a retransmission of the 2/4 of the 4 
>way
> > handshake message.  Apparently the AP didn't get the reply from the STA 
>and
> > 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

Right, 3/4.

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

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

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

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.

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.

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

Chuck