WEP-Open Key Auth - detection of Decryption Failures???

[Jouni Malinen]

On Tue, Feb 21, 2006 at 12:08:30PM -0500, Tony Espy wrote:

> Hmmmm...  never thought of that approach.  Linksys APs have a WEP auth 
> setting of Auto or Shared.  So, when set to Auto, a client can use 
> either auth method.  I wonder what would happen if the AP was set for 
> Open and a client tried to associate using Shared Key?   Guess it'd time 
> out?  I wonder if the driver would see an authentication failed from the 
> firmware?

If AP is configured to only accept Open System authentication and client
is to only use Shared Key, 802.11 authentication would fail and the
station would not even try to associate. The AP would report this with a
error code in authenticate frame.

> Unfortunately, I can't use this trick as it looks like there's no 
> notification of an authentication failure via a wireless event and/or 
> return code from a WE or HostAP ioctl.  Instead, the association ends up 
> timing out which could indicate a whole range of possible failure cases...

In case of Prism2/2.5/3 cards, client mode management frames are
implemented in firmware and the driver does not have much control over
that.

> Also, knowing that WEP in any form is easy to crack these days, it's 
> probably not worth debating which form of WEP authentication is easier 
> to crack.

Yeah.. And one "funny" part of Shared Key authentication algorithm is
that it will provide a known plaintext/ciphertext pair for an attacker
to use for sending anything they want in first 128 (or so) bytes of a
frame due stream cipher being used without proper replay protection..
I.e., all it takes is to receive frames from one successful Shared Key
authentication and you get 128 bytes of known pseudo random stream for
encrypting your frames.. Decryption would require more since most
clients use different IVs for the frames. Anyway, this is indeed kind of
pointless detail nowadays due to other identified issues with WEP.

>  > System besides not being able to decrypt frames from the AP.  In SK at
>  > least, you must prove you know the correct key before you are
>  > authenticated/associated, but there's no such thing in Open System.

Well, prove.. Not quite, see above.. With that 128-byte part of pseudo
random stream you can easily encrypt the challenge response without
having any idea about the correct key..

> Hmmmmm, the bad rx decrypt count definately seems to increase in this 
> case... once associated with an AP, are there management packets that 
> it'll send that are encrypted with the WEP key?

If the AP is transmitting data frames with a key that does not match
with the decryption key in the client, this frames will show up as
decryption error.

> I agree it's an 'optimization' not a solution, but if it makes the user 
> experience better 50% or more of the time, that's still a win in my 
> book.  If we can't detect decryption failures, there are timeouts for 
> both association and IP address assignment that generate messages to the 
> user.

If the AP is known not use multiple broadcast domains (e.g., with
multiple SSIDs and different encryption key for each VLAN/domain) and
most received frames are dropped due to failed decryption, it is likely
that the WEP key is incorrect. However, there is no guaranteed
mechanisms for doing this in general way and this could flag some APs as
using mismatching keys even if they are not.

-- 
Jouni Malinen                                            PGP id EFC895FA