Multiple realms and network validation with WPA2 Enterprise
Good morning all. I've searched a bit and while I found some information about how the client validates the SSID using certificates, it's not entirely clear how to make sure a fake SSID cannot steal user/pass from clients. As per previous mails, we're running EAP method TTLS with PAP 2nd phase against a Kerberos oracle. We're using CA signed wildcard cert for our internal network. Do we need to use a username@domain username structure to validate the realm (I assume using the domain_realm config in /etc/krb5.conf) use SSL to validate the radius server it's communicating with ? Does that also mean we can have multiple domains pointing to multiple realms using seperate realms and domain_realm configurations ? Regards Henti -- --
validates the SSID using certificates, it's not entirely clear how to make sure a fake SSID cannot steal user/pass from clients.
Since you use EAP-TTLS, use a self-signed CA, which signs your server and client certificates, then put the CA certificate onto the client devices. There's a lovely tool called eduroam CAT that does something like that, and Alan B on here has written about the iPhone configurator tool that provides the .mobileconfig for Apple devices (which makes that painless).
Does that also mean we can have multiple domains pointing to multiple realms using seperate realms and domain_realm configurations ?
I don't use Kerberos, so I can't comment on that, but in AD environments you can tweak the mschap module's command to either hard-code the domain or take what's provided in the NAI (i.e. DOMAIN\username or username@DOMAIN). Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
On 23 December 2016 at 11:30, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote:
validates the SSID using certificates, it's not entirely clear how to make sure a fake SSID cannot steal user/pass from clients.
Since you use EAP-TTLS, use a self-signed CA, which signs your server and client certificates, then put the CA certificate onto the client devices. There's a lovely tool called eduroam CAT that does something like that, and Alan B on here has written about the iPhone configurator tool that provides the .mobileconfig for Apple devices (which makes that painless).
How would that be different from using a proper CA signed cert which we already have ?
Does that also mean we can have multiple domains pointing to multiple realms using seperate realms and domain_realm configurations ?
I don't use Kerberos, so I can't comment on that, but in AD environments you can tweak the mschap module's command to either hard-code the domain or take what's provided in the NAI (i.e. DOMAIN\username or username@DOMAIN).
Thats what I've seen as well, was hoping to get confirmation before going down that path. Will explore. Thanks for answering. Regards Henti -- --
How would that be different from using a proper CA signed cert which we already have ?
The difference is that *you* control the CA, not some third party. You want to ensure that your clients only trust *your* CA infrastructure. :-) With a third-party CA, you're beholden to their security requirements (or failures for that matter - look online about the Diginotar incident, you'll get the drift). With Regards Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
On 23 December 2016 at 21:46, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote:
How would that be different from using a proper CA signed cert which we already have ?
The difference is that *you* control the CA, not some third party. You want to ensure that your clients only trust *your* CA infrastructure. :-)
With a third-party CA, you're beholden to their security requirements (or failures for that matter - look online about the Diginotar incident, you'll get the drift).
Hi Stefan, What you are saying of course makes sense, but I'm trying to understand the security mechanisms between and client and radius using SSL and how to ensure my users user/pass don't get stolen by a rogue AP/SSID impersonating ours. How does one ensure that when a user connects to SSID "MyCompany" they are actually sending user/pass to "MyCompany" using the correct SSL and Server validation ? 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) 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. So in a nutshell, how do I prove that Ivan the Hacker cannot just bring up his own AP with the same SSID and steal user credentials to get into our network to steal our data. Regards Henti -- --
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)
On Dec 23, 2016, at 7:07 PM, Henti Smith <henti@geekware.co.za> wrote:
What you are saying of course makes sense, but I'm trying to understand the security mechanisms between and client and radius using SSL and how to ensure my users user/pass don't get stolen by a rogue AP/SSID impersonating ours. How does one ensure that when a user connects to SSID "MyCompany" they are actually sending user/pass to "MyCompany" using the correct SSL and Server validation ?
Because the users machine has the SSID configured to use a particular root CA. See the WiFi / 802.1X configuration for any modern operating system. The users machine will trust *any* certificate signed by that root CA. Which is why everyone recommends using a "self signed" CA for WiFI. Because then you know that only your RADIUS server has a certificate signed by that CA.
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) 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.
<sigh> A shared WiFi key is always less secure than using actual security.
So in a nutshell, how do I prove that Ivan the Hacker cannot just bring up his own AP with the same SSID and steal user credentials to get into our network to steal our data.
The short answer is that the people who designed WiFi security aren't stupid. If your managers aren't security experts, they should stop playing games with security. Instead, they should trust the experts. They should follow the best practices recommended by the experts. Alan DeKok.
So in a nutshell, how do I prove that Ivan the Hacker cannot just bring up his own AP with the same SSID and steal user credentials to get into our network to steal our data.
Short answer, in a BYOD environment, where the devices aren't pre-configured with wireless profiles - you can't. Supplicant security negotiation is horrifically bad. Using PSKs doesn't make it any better as the attacker can configure a WPA2-Enterprise secured version of the SSID. Where you pre-deploy profiles, the user should not be involved in any security decisions. The supplicant will not send credentials if it cannot validate the server certificate. Ideally if you control the device, the user should be prevented from modifying the 802.1X configuration at all, and unrecognised 802.1X authenticated networks should be blocked. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Thank you all for the information. H On 27 December 2016 at 00:41, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
So in a nutshell, how do I prove that Ivan the Hacker cannot just bring up his own AP with the same SSID and steal user credentials to get into our network to steal our data.
Short answer, in a BYOD environment, where the devices aren't pre-configured with wireless profiles - you can't. Supplicant security negotiation is horrifically bad. Using PSKs doesn't make it any better as the attacker can configure a WPA2-Enterprise secured version of the SSID.
Where you pre-deploy profiles, the user should not be involved in any security decisions. The supplicant will not send credentials if it cannot validate the server certificate. Ideally if you control the device, the user should be prevented from modifying the 802.1X configuration at all, and unrecognised 802.1X authenticated networks should be blocked.
-Arran
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
-- --
Hi,
How would that be different from using a proper CA signed cert which we already have ?
because anyone can get a server cert signed by that CA - and most clients are dumb so cannot be set to trust the commonname ...so such clients are ripe to be MITM attacked trivially. very big issue if using EAP-TTLS PAP... and almost just as big for MSCHAPv2 inner which just takes a little more effort to recover the password. dont use public CA for secure 802.1X alan
participants (6)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Brian Candler -
Henti Smith -
Stefan Paetow