TTLS+PAP with Windows
Hello! I am running FreeRADIUS 2.2.5 on Debian 8.7 (Jessie). The RADIUS server is using TTLS+PAP. I am trying to find a good way to authenticate the server to Windows clients. With macOS, Linux, Android etc., I am using a custom self signed CA certificate. On these devices it is possible to specify that this certificate is only usable for a specific SSID. However, for Windows I have found no way to accomplish this. To make it work, I have to install the CA certificate in the "Trusted Root CA" store. This is rather inconvenient. If I (against all odds) lose the private key, the attacker could use it to issue certificates for web pages, and the Windows clients would accept them. One of the options I have considered is make FreeRADIUS present multiple certificates simultaneously: an LE certificate for Windows and the self signed CA certficiate for other clients. As Windows clients already trust LE, they should also accept the server certificate. 1) Is it possible to use LE certificates with FreeRADIUS? 2) Is it possible to make the server present multiple certificates? The reason for wanting multiple certificates, is that a complete switch to LE would require reconfiguring all the non-Windows clients that use the CA certificate. Naturally, all thoughts concerning EAP and Windows are also welcome. Thanks in advance! -- Herman Øie Kolden Trondheim, Norway
Am 14.03.2017 um 00:56 schrieb Herman Øie Kolden:
Hello!
I am running FreeRADIUS 2.2.5 on Debian 8.7 (Jessie). The RADIUS server is using TTLS+PAP.
Hi, you can stop here ... try FR3 and you'll have success. I had the same issue and everything fails, with FR3 it just worked. Michael
On Tue, Mar 14, 2017 at 06:23:41AM +0100, Muenz, Michael wrote:
I am running FreeRADIUS 2.2.5 on Debian 8.7 (Jessie). The RADIUS server is using TTLS+PAP.
you can stop here ... try FR3 and you'll have success. I had the same issue and everything fails, with FR3 it just worked.
Thank you for replying :) What just works? Presenting multiple certificates or using LE? -- Herman Øie Kolden Trondheim, Norway
Am 14.03.2017 um 10:07 schrieb Herman Øie Kolden:
On Tue, Mar 14, 2017 at 06:23:41AM +0100, Muenz, Michael wrote:
I am running FreeRADIUS 2.2.5 on Debian 8.7 (Jessie). The RADIUS server is using TTLS+PAP. you can stop here ... try FR3 and you'll have success. I had the same issue and everything fails, with FR3 it just worked. Thank you for replying :)
What just works? Presenting multiple certificates or using LE?
TTLS+PAP in any way doesn't work with the Debian package 2.2.5. Here's a way to implement LE: https://framebyframewifi.net/2017/01/29/use-lets-encrypt-certificates-with-f... Michael
On Tue, Mar 14, 2017 at 10:47:04AM +0100, Muenz, Michael wrote:
TTLS+PAP in any way doesn't work with the Debian package 2.2.5.
Actually, the TTLS+PAP part works, except that distributing the CA cert to Windows clients is problematic.
Here's a way to implement LE: https://framebyframewifi.net/2017/01/29/use-lets-encrypt-certificates-with-f...
Great, thanks! -- Herman Øie Kolden ITK, Samfundet
On Mar 14, 2017, at 5:47 AM, Muenz, Michael <m.muenz@spam-fetish.org> wrote:
TTLS+PAP in any way doesn't work with the Debian package 2.2.5.
There's no problem with it. Thousands of people are using it just fine.
Here's a way to implement LE: https://framebyframewifi.net/2017/01/29/use-lets-encrypt-certificates-with-f...
I don't recommend using public CAs for WiFi authentication. It's insecure. Alan DeKok.
Herman Øie Kolden <herman@samfundet.no> writes:
On Tue, Mar 14, 2017 at 07:12:28PM -0400, Alan DeKok wrote:
I don't recommend using public CAs for WiFi authentication. It's insecure.
Interesting. Would you mind explaining why?
/usr/share/doc/freeradius/examples/certs/README in the Debian package says In general, you should use self-signed certificates for 802.1x (EAP) authentication. When you list root CAs from other organizations in the "CA_file", you permit them to masquerade as you, to authenticate your users, and to issue client certificates for EAP-TLS. Bjørn
On Wed, Mar 15, 2017 at 09:53:39AM +0100, Bjørn Mork wrote:
In general, you should use self-signed certificates for 802.1x (EAP) authentication. When you list root CAs from other organizations in the "CA_file", you permit them to masquerade as you,
Why is this a concern for EAP, but not for regular web certificates?
to authenticate your users, and to issue client certificates for EAP-TLS.
Agreed, but as we don't use client certificates in our organization, this doesn't apply to us. -- Herman Øie Kolden Trondheim, Norway
On 15-03-17 11:00, Herman Øie Kolden wrote:
On Wed, Mar 15, 2017 at 09:53:39AM +0100, Bjørn Mork wrote:
In general, you should use self-signed certificates for 802.1x (EAP) authentication. When you list root CAs from other organizations in the "CA_file", you permit them to masquerade as you,
Why is this a concern for EAP, but not for regular web certificates?
Web certificates have a check to see if the dns name matches the certificate. You can do a hostname check with some radius supplicants, but 90% of the people don't use it. This means there is only one check remaining: is this certificate valid according to some certificate authority on this device. This means I can order a certificate for foo.com and use that on a rogue access point inside company Bar. -- Herwin Weststrate
Herwin Weststrate wrote:
On 15-03-17 11:00, Herman Øie Kolden wrote:
On Wed, Mar 15, 2017 at 09:53:39AM +0100, Bjørn Mork wrote:
In general, you should use self-signed certificates for 802.1x (EAP) authentication. When you list root CAs from other organizations in the "CA_file", you permit them to masquerade as you,
Why is this a concern for EAP, but not for regular web certificates?
Web certificates have a check to see if the dns name matches the certificate. You can do a hostname check with some radius supplicants, but 90% of the people don't use it.
Especially since AFAIK a TLS name-based server identity check like defined in RFC 6125 for various other protocols is not yet clearly defined for RADIUS with EAP. Ciao, Michael.
Herman Øie Kolden <herman@samfundet.no> writes:
On Wed, Mar 15, 2017 at 09:53:39AM +0100, Bjørn Mork wrote:
In general, you should use self-signed certificates for 802.1x (EAP) authentication. When you list root CAs from other organizations in the "CA_file", you permit them to masquerade as you,
Why is this a concern for EAP, but not for regular web certificates?
I would say it is a concern for web cerificates as well. You cannot trust them any more than you can trust the long list of public CAs. But that's another discussion :) At least you have a name you can match up against the DN or SNI for a web server. How can the end user verify your RADIUS server certificate? Answer: By verifying the issuer. The DN and SNI are irrelevant, since the user will not know what they are supposed to be (unless you pin the certificate, in which case it could just as well be self signed). If the issuer gives cerificates to anyone, like a public CA will do, then anyone can impersonate your RADIUS server, Bjørn
On Mar 15, 2017, at 6:13 AM, Bjørn Mork <bjorn@mork.no> wrote:
I would say it is a concern for web cerificates as well. You cannot trust them any more than you can trust the long list of public CAs. But that's another discussion :)
Pretty much. Was have been known to give out certificates to the wrong people, and to give out certificates for domains with misleading names.
At least you have a name you can match up against the DN or SNI for a web server. How can the end user verify your RADIUS server certificate? Answer: By verifying the issuer. The DN and SNI are irrelevant, since the user will not know what they are supposed to be (unless you pin the certificate, in which case it could just as well be self signed).
The CA is also pre-provisioned on the users machine.
If the issuer gives cerificates to anyone, like a public CA will do, then anyone can impersonate your RADIUS server,
Exactly. Alan DeKok.
On Mar 15, 2017, at 6:00 AM, Herman Øie Kolden <herman@samfundet.no> wrote:
On Wed, Mar 15, 2017 at 09:53:39AM +0100, Bjørn Mork wrote:
In general, you should use self-signed certificates for 802.1x (EAP) authentication. When you list root CAs from other organizations in the "CA_file", you permit them to masquerade as you,
Why is this a concern for EAP, but not for regular web certificates?
Because you don't own google.com. So you don't care (so much) if someone else masquerades as google.com. In fact, you have *no idea* who "google.com" really is. All you know is that there's a certificate from a CA, which says that this site is really "google.com". For most web browsing, that's good enough. The CA is pre-provisioned on your machine, which means you trust the CA, and then trust them to say who google really is. For EAP, you own the site, so you *do* care who else can masquerade as you. By using a self-signed CA and provisioning it on the users machines, you're sure that no one else can pretend to be you.
to authenticate your users, and to issue client certificates for EAP-TLS.
Agreed, but as we don't use client certificates in our organization, this doesn't apply to us.
That's not how the protocols work. If you allow EAP-TLS, you allow users to be authenticated with client certificates. *ANY* client certificate which has a chain of trust going back to the root CA. When you use a public CA, you let *anyone on the planet* issue client certificates which will be accepted as genuine by your RADIUS server. Because that's how the certificate chain of trust works. When you use a self-signed CA, the only person who can issue client certificates is you. And if you don't issue client certificates, you know that there are none which have been issued. Alan DeKok.
Le 15/03/2017 à 14:31, Alan DeKok a écrit :
On Mar 15, 2017, at 6:00 AM, Herman Øie Kolden <herman@samfundet.no> wrote:
On Wed, Mar 15, 2017 at 09:53:39AM +0100, Bjørn Mork wrote:
In general, you should use self-signed certificates for 802.1x (EAP) authentication. When you list root CAs from other organizations in the "CA_file", you permit them to masquerade as you, Why is this a concern for EAP, but not for regular web certificates? Because you don't own google.com. So you don't care (so much) if someone else masquerades as google.com. In fact, you have *no idea* who "google.com" really is. All you know is that there's a certificate from a CA, which says that this site is really "google.com".
For most web browsing, that's good enough. The CA is pre-provisioned on your machine, which means you trust the CA, and then trust them to say who google really is.
For EAP, you own the site, so you *do* care who else can masquerade as you. By using a self-signed CA and provisioning it on the users machines, you're sure that no one else can pretend to be you.
I Alan, I'm not really aware about these subjects so excuse my question if it's a newbie one Reading this, what do you propose if we don't have any access to client's machine (students or autonomous users) ? I can't provision anything on them, just announce a valid server certificate. Thanks Cedric
to authenticate your users, and to issue client certificates for EAP-TLS. Agreed, but as we don't use client certificates in our organization, this doesn't apply to us. That's not how the protocols work.
If you allow EAP-TLS, you allow users to be authenticated with client certificates. *ANY* client certificate which has a chain of trust going back to the root CA.
When you use a public CA, you let *anyone on the planet* issue client certificates which will be accepted as genuine by your RADIUS server. Because that's how the certificate chain of trust works.
When you use a self-signed CA, the only person who can issue client certificates is you. And if you don't issue client certificates, you know that there are none which have been issued.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Cédric Delaunay Direction des Systèmes d'Informations Equipe Réseau & Telephonie 263, Avenue du Général Leclerc Tel: 02 23 23 71 59 CS 74205 - 35042 Rennes Cedex Pour toute demande utiliser l'aide et assistance via l'ENT à l'adresse http://ent.univ-rennes1.fr
Hi,
Reading this, what do you propose if we don't have any access to client's machine (students or autonomous users) ? I can't provision anything on them, just announce a valid server certificate.
Provisioning is typically done with config files that devices consume. There are tools that generate such config files per-OS ("Apple Configurator" ...) but there are also web services that, once fed with the server details, generate such configs for many popular OSes. One example of such is https://802.1x-config.org Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Le 16/03/2017 à 11:18, Stefan Winter a écrit :
Hi,
Reading this, what do you propose if we don't have any access to client's machine (students or autonomous users) ? I can't provision anything on them, just announce a valid server certificate. Provisioning is typically done with config files that devices consume.
There are tools that generate such config files per-OS ("Apple Configurator" ...) but there are also web services that, once fed with the server details, generate such configs for many popular OSes. One example of such is
Greetings,
Stefan Winter
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Ok thanks Stefan
-- Cédric Delaunay Direction des Systèmes d'Informations Equipe Réseau & Telephonie 263, Avenue du Général Leclerc Tel: 02 23 23 71 59 CS 74205 - 35042 Rennes Cedex Pour toute demande utiliser l'aide et assistance via l'ENT à l'adresse http://ent.univ-rennes1.fr
Bjørn Mork wrote:
Herman Øie Kolden <herman@samfundet.no> writes:
On Tue, Mar 14, 2017 at 07:12:28PM -0400, Alan DeKok wrote:
I don't recommend using public CAs for WiFi authentication. It's insecure.
Interesting. Would you mind explaining why?
/usr/share/doc/freeradius/examples/certs/README in the Debian package says
In general, you should use self-signed certificates for 802.1x (EAP) authentication. When you list root CAs from other organizations in the "CA_file", you permit them to masquerade as you, to authenticate your users, and to issue client certificates for EAP-TLS.
Strictly speaking a self-signed certificate is a public-key certificate signed by the private key of the very same key pair (and not by another entity's private key). So while I fully agree with the statement above the term "self-signed certificate" is wrong. It should clearly say that you should run your own single-purpose EAP CA and distribute the EAP CA's public-key certificate in all your client configurations. Ciao, Michael.
Hi,
wrong. It should clearly say that you should run your own single-purpose EAP CA and distribute the EAP CA's public-key certificate in all your client configurations.
exactly. +1 - a CA that is only used for purpose of RADIUS authentication (EAP methods). not to be used for signing web certs or anything else. that would be defined in the CA policy. alan
Am 15.03.2017 um 00:12 schrieb Alan DeKok:
On Mar 14, 2017, at 5:47 AM, Muenz, Michael <m.muenz@spam-fetish.org> wrote:
TTLS+PAP in any way doesn't work with the Debian package 2.2.5. There's no problem with it. Thousands of people are using it just fine.
I was not able to connect with Windows (Linux, Andriod, iPhone worked) and with just a upgrade to FR3 everything was fine, so I was assuming there was a general problem with FR2, Debian package and Windows in combination. Probably it was only just my fault :)
Here's a way to implement LE: https://framebyframewifi.net/2017/01/29/use-lets-encrypt-certificates-with-f... I don't recommend using public CAs for WiFi authentication. It's insecure.
Yep, I'd also not do this. Michael
Hi,
I was not able to connect with Windows (Linux, Andriod, iPhone worked) and with just a upgrade to FR3 everything was fine, so I was assuming there was a general problem with FR2, Debian package and Windows in combination. Probably it was only just my fault :)
old versions (2.2.5 is old...very old) havent had any work done to them - newer versions have had all sorts added to them over the years - including basic stuff such as EAP processing, certificate generation scripts etc - to ensure that the server is generting certs that the modern OSes demand/require etc. the general answer now is 'does it work on latest release' - little/no effort will go into digging around old server versions and code - especially if the latest release works (and if it doesnt, only the latest release will get fixed) alan
On Tue, Mar 14, 2017 at 12:56:08AM +0100, Herman Øie Kolden wrote:
I am running FreeRADIUS 2.2.5 on Debian 8.7 (Jessie). The RADIUS server is using TTLS+PAP.
I am trying to find a good way to authenticate the server to Windows clients. With macOS, Linux, Android etc., I am using a custom self signed CA certificate. On these devices it is possible to specify that this certificate is only usable for a specific SSID. However, for Windows I have found no way to accomplish this. To make it work, I have to install the CA certificate in the "Trusted Root CA" store. This is rather inconvenient.
First of all, thanks to everyone for your responses. I have found a solution: Make two eap modules, eap-pub and eap-priv, using certificates signed by respectively LE and our private CA. Then, in outer-tunnel, I specify authorize { ... if ( "%{User-Name}" == "windows" ) { eap-pub { ok = return } } else { eap-priv { ok = return } } ... } I am not very acquainted with FreeRADIUS config, so I am probably doing this in an ugly way, but the main idea is as follows: for Windows clients, install a profile with Anonymous identity "windows". For non-Windows clients, have Anonymous identity be something else. With this, I accomplish the following: 1. Windows users install a profile that uses the LE Root CA to verify "radius.example.com" 2. Non-Windows users install a profile/config that uses our private CA to verify a non-specified server URL Some security concerns that have been mentioned: 1. Wouldn't this allow any server using an LE cert be able to impersonate my RADIUS server? * No. Non-Windows still use the private CA. Windows users specify server URL in the profile, so only an LE cert for radius.example.com works. 2. Wouldn't this allow any client with an LE cert to be authenticated? * No. Client authentication in my organization doesn't use client certificates. To be extra certain of this, I have removed the "CA_file" option entirely. I know this solution is kind of random, and possibly a misuse of Anonymous identity. However, we don't utilize this field anyways, and it works! Please enlighten me if this is an abomination, or if I have misunderstood anything :) -- Herman Øie Kolden Trondheim, Norway
participants (9)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Bjørn Mork -
cedric delaunay -
Herman Øie Kolden -
Herwin Weststrate -
Michael Ströder -
Muenz, Michael -
Stefan Winter