Wireless Security
The Skinny On How Not To Write An Article About WPA-PSK Nov 15 2010 08:21PM
Paul Asadoorian (paul pauldotcom com) (4 replies)
Re: The Skinny On How Not To Write An Article About WPA-PSK Nov 16 2010 01:45PM
Rob Fuller (jd mubix gmail com) (1 replies)
Re: The Skinny On How Not To Write An Article About WPA-PSK Nov 17 2010 02:06PM
Christopher Byrd (chris riosec com) (1 replies)
Re: The Skinny On How Not To Write An Article About WPA-PSK Nov 18 2010 04:47PM
dragorn kismetwireless net
On Wed, Nov 17, 2010 at 08:06:33AM -0600, Christopher Byrd wrote:
> There have been two workable approaches proposed to solve this issue
> with public / guest wireless. The first was George Ou's proposal that
> we use a well known (or even blank) username/password combination for
> EAP-PEAPv0/MSCHAPv2. He originally proposed this back in 2007 at
> http://www.zdnet.com/blog/ou/a-secure-wireless-lan-hotspot-for-anonymous
-users/587
> but has also expanded on it since. His solution works because the TLS
> session established protects the PMK.

Assuming you somehow pre-provisioned the SSL cert and can trust users
not to click "OK" to any prompt about accepting one. This moves the
problem to a different level, but it doesn't solve it for non-savvy
users (and that's who we're concerned about here, because any of us
could tunnel it over SSH and be done)

I believe George was advocating for cooperation between companies and
hotspot operators so that the laptops would be provisioned by the
company with a CA used by the hotspot vendor, solving this trust problem
in that regard, but not for anyone who wasn't part of the trusted
company arrangement.

> It only requires a very simple code change for authentication servers,
> and no changes to access points or other infrastructure. Most
> importantly, it works with all existing wireless clients I have tested
> (more information on testing is included in the paper, but basically
> they all needed a client cert configured, but it didn't have to be
> valid and they never used it). Supplicant vendors would need a few UI
> changes, including removing the if..then that checks for a client cert
> before connecting, to improve usability for it to be a contender to
> replace open wireless in public hotspots.

How do you handle the trust model where the user knows they can trust
this AP? If they have to accept a cert, while technically sound, I fear
it's not much better for actually protecting the users, because they'll
just click OK anyhow. If it's signed w/ a public ca, I can just get my
own and spoof the AP and get all the non-https traffic anyhow.

I realize this argument mixes "is it cryptographically secure" and
"layer 8" problems, but if we don't solve both, we haven't actually
protected the users any.

-m

--
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAkzlWJ8ACgkQ17KIInOLvbGfIwCfc2mBENoBurjhSjzsV38oLp2s
87cAoJU6p5wog12DEPuTS446iGh0RxmV
=YvEm
-----END PGP SIGNATURE-----

[ reply ]
Re: The Skinny On How Not To Write An Article About WPA-PSK Nov 16 2010 02:28AM
Richard Farina (sidhayn gmail com)
Re: The Skinny On How Not To Write An Article About WPA-PSK Nov 16 2010 01:57AM
Grant Moerschel (gm wavegard com)
Re: The Skinny On How Not To Write An Article About WPA-PSK Nov 16 2010 01:00AM
Kenneth Voort (listbounce-01 voort ca) (1 replies)
Re: The Skinny On How Not To Write An Article About WPA-PSK Nov 17 2010 06:24AM
Cedric Blancher (blancher cartel-securite fr)


 

Privacy Statement
Copyright 2010, SecurityFocus