linksys WRT54GX2 replay counter bug?

[Jouni Malinen]

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