Multiple realms and network validation with WPA2 Enterprise

[Brian Candler]

On 24/12/2016 00:07, Henti Smith wrote:
> To put it another way. Users have been taught to look at browsers address
> bar, to ensure they are talking to the correct server and that there is a
> lock next to the https to indicate the SSL cert fo rthat host has been
> validated (admittedly byt a thir party, which you have already pointed out
> has it's own insecurities)
Basically you have to configure the client to require a certificate with 
a specific identity, otherwise they are wide open to man-in-the-middle 
credential gathering attacks.

I use a real certificate from Letsencrypt: you can set up a webserver 
called (say) "wireless.yourdomain.com" and get a certificate from 
letsencrypt for that; then you copy the private key and cert onto your 
radius servers.  This at least gives you a green tick in some clients 
(e.g. OSX).

But there is still no binding between SSID and certificate identity. 
When users connect who *haven't* pre-configured their client, they would 
still have to be trained to look for (a) a valid certificate, and (b) 
the identity is "wireless.yourdomain.com".  And you know how bad users 
are like for clicking through things.

So using something like the CAT tool to preconfigure their client is way 
better.

https://cat.eduroam.org/

> I need to show the business the same risk
> management before we can switch to WPA2 Enterprise away from a shared key,
> which again has it's own set of insecurities.

Yes, EAP-TTLS/PEAP has the problem you outlined, and like everything, 
it's a balance of risk.

Two other solutions you can look at:

* EAP-TLS.  You deploy certificates to all the clients to identify 
themselves, *and* they have to know which certificate identity to look 
for from the SSID to avoid MITM.  It's a pain unless you have central 
deployment of certificates to all clients.

* EAP-PWD. This offers strong mutual authentication using just a 
password for each user, and is secure against off-line dictionary 
attacks.  However: (1) you need the cleartext password available 
server-side, and (2) unfortunately many clients don't support it. (It 
might be workable if you are an all-Linux and all-Android shop)