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)
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.

I also looked into securing open wireless, and I have been able to
make a solution based on EAP-TLS work in a lab environment that is RFC
compliant and requires no client authentication at all.

It turns out it is as simple as modifying the authentication server
not to request a client certificate. I know it's considered common
knowledge that EAP-TLS needs a client cert, but according to the
standard (RFC5216):
"The certificate_request message is included when the server desires
the peer to authenticate itself via public key. While the EAP server
SHOULD require peer authentication, this is not mandatory, since there
are circumstances in which peer authentication will not be needed
(e.g., emergency services, as described in [UNAUTH]), or where the
peer will authenticate via some other means."

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.

My biggest difficulty has been in getting the attention of vendors or
the WiFi Alliance - basically the folks who could do something to make
this a reality. All I'm really suggesting is that authenticators and
supplicants be RFC compliant in making the certificate_request
optional.

I have an article and paper up on this at
http://riosec.com/open-secure-wireless. Please let me know what you
think!

Thanks,

Christopher Byrd
twitter.com/@cbyrd01

On Tue, Nov 16, 2010 at 7:45 AM, Rob Fuller <jd.mubix (at) gmail (dot) com [email concealed]> wrote:
> Here's Mike's post on the subject:
> http://blog.kismetwireless.net/2010/11/psk-doesnt-mean-public-shared-key
.html
>
> Was the SOPHOS guy wrong about being able to decrypt other's traffic,
> sure, but his idea would still raise the bar back up to non-Grandma
> level. Sure, that's a bandaid, and that's what we in the industry are
> famous for, but ask Mike said, there really isn't a solution.
>
> And people will point the finger at the web app peeps who coded their
> cookie/sessions 'insecure', and they'll point at the transport layer,
> in this round robin of blame.
>
> Yes. The SOPHOS gent was wrong in his assumption that it was a
> solution, but it's a step forward, and that's better than we have to
> offer.
>
>
> --
> Rob Fuller | Mubix
> Certified Checkbox Unchecker
> Room362.com | Hak5.org
>
>
>
> On Mon, Nov 15, 2010 at 3:21 PM, Paul Asadoorian <paul (at) pauldotcom (dot) com [email concealed]> wrote:
>> I have to say, I am really digging this blog (I mean it is called "naked
>> security", which is really close to "hack naked", or is it?). I
>> referenced several articles from it on a few podcasts.  However, an
>> article was posted titled, "Dear Starbucks: The skinny on how you can be
>> a security hero", and well, should have had a few more eyes on it before
>> it went public:
>>
>> http://nakedsecurity.sophos.com/2010/11/09/dear-starbucks-the-skinny-on-
how-you-can-be-a-security-hero/
>>
>> They did come clean and present the real (?) facts, that in a WPA-PSK
>> network you can decrypt anyone's traffic that joins the network after
>> you (which I am assuming is correct, unless the experts on this list
>> present evidence to the contrary or I get off my lazy ass and look it up
>> myself).
>>
>> Enjoy the article for a good laugh while I go back and review some of
>> its earlier posts that I mentioned....
>>
>> Cheers,
>> Paul
>>
>> --
>> Paul Asadoorian
>> PaulDotCom Enterprises
>> Web: http://pauldotcom.com
>> Phone: 401.829.9552
>> Fax: 1.877.846.2187
>>
>

[ reply ]
Re: The Skinny On How Not To Write An Article About WPA-PSK Nov 18 2010 04:47PM
dragorn kismetwireless net
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