wpa_supplicant/NM fallback to WPA?

[Jouni Malinen]

On Tue, May 06, 2008 at 09:24:41PM +0200, Johannes Berg wrote:

> > No, I don't think that would be a good idea. Security policy should be
> > to pick the best available (i.e., enabled at both ends) option and stick
> > to it.. If you have to live with such a broken AP, I would assume you
> > can configure wpa_supplicant to only allow WPA with it.. 
> 
> Right, of course I can, or I wouldn't be writing email right now. I'm
> more worried about regular users ;)

Yeah.. The problem here is that this AP is broken in a way that could
lead to compromised security since supplicant will not be able to verify
that the advertised RSN IE matches with the signed one.. In theory, one
could try to use WPA in this type of case, but I don't really like the
extra complexity that this would bring into AP selection.

I'm all for making wpa_supplicant work without user having to do
something extra, but that gets quite a bit more complex if doing that
involves reduced security by default..

> It's an "Arcor-Easy Box A 300 WLAN", no idea what's in that. I'll send
> you a log in private, it essentially goes:

Thanks! Someone should point the vendor to IEEE 802.11 clause 8.5.3.3
and ask them to fix the AP to include correct RSN IE in msg 3/4 (i.e.,
exact same IE that was included in Beacon). This AP seems to advertise
both TKIP and CCMP as allowed pairwise ciphers, but only includes the
negotiated pairwise cipher suite in msg 3/4. By doing so, it breaks the
protection against downgrade attacks..

WPA: IE in 3/4 msg does not match with IE in Beacon/ProbeResp
WPA: RSN IE in Beacon/ProbeResp - hexdump(len=26): 30 18 01 00 00 0f ac 02 02 00 00 0f ac 02 00 0f ac 04 01 00 00 0f ac 02 01 00
WPA: RSN IE in 3/4 msg - hexdump(len=22): 30 14 01 00 00 0f ac 02 01 00 00 0f ac 04 01 00 00 0f ac 02 01 00

Quick Google search for this AP seemed to bring lots of pages with
things like "funktioniert nicht" and "keine Verbindung", so maybe you
are not the only one seeing this problem.. The connection would likely
fail with any WPA2-enabled (and correctly implemented ;-) client..

My guess would be that this could work fine if the AP were configured to
use "Nur WPA2" in the Sicherheit | Verschl?sselungsmethode.. I would
assume WPA/WPA2 is the default, though, and that results in this problem
with RSN.

Would you happen to have any idea how common those APs are? If I
understood correctly, this is a telco/ISP-branded AP from a large ADSL
provider, so there may very well be quite a few of those APs around..

-- 
Jouni Malinen                                            PGP id EFC895FA