wpa_supplicant/NM fallback to WPA?

[Jouni Malinen]

On Wed, May 07, 2008 at 10:41:47AM +0200, Johannes Berg wrote:

> This is the part I'm still not sure about. If I analysed things
> correctly this doesn't look like a downgrade attack at all since we
> selected CCMP (the highest) and then got CCMP too. The only reason why
> this is similar to a downgrade attack is that the IE was modified, but
> not actually in a way that would constitute an attack.

The client saw the AP (i.e., possible the attacker) to advertise TKIP as
an allowed pairwise cipher in the Beacon/ProbeResp frames (i.e.,
unauthenticated frames that an attacker could replace) while TKIP was
not listed as an allowed pairwise cipher in 4-way handshake (msg 3/4
from the authenticator, i.e., a signed message that the attacker could
not have changed without knowing the key). This is the exact sign of
possible downgrade attack in process during the AP discovery phase. This
is why supplicant is required to verify that the RSN IE in the msg 3/4
matching exactly with the one used in Beacon/ProbeRsp (i.e., during
cipher suite selection).

Sure, in this particular case the client picked the most secure option,
but in general, any change in the IE is a sign of an attempted downgrade
attack (or faulty AP/Authenticator implementation as seems to be the
case here). If the IEs differ, the client simply cannot trust that the
RSN IE received prior to association was valid. For example, the real
RSN IE from the AP could have advertised management frame protection and
client would not have known about this if the attacker managed to send a
Beacon/ProbeResp with that part from the RSN IE removed. If the
AP/Authenticator were to function correctly, the flag indicating
management frame protection would show up in EAPOL-Key msg 3/4 and the
client would at that point notice that something fishy is happening.

-- 
Jouni Malinen                                            PGP id EFC895FA