Riccardo Veraldi wrote:

I think there is a cleaner way. I enabled only EAP-TTLS and disabled EAP-TLS just puttting this lin in /etc/radddb/users

DEFAULT EAP-Type == EAP-TLS, Auth-Type := Reject

It works, I think Alan gave me this hint 1 year ago, maybe it could be put in the FAQ since it is an interesting way to solve the problem. Don't you want

DEFAULT EAP-Type != EAP-TTLS, Auth-Type := Reject or in unlang if("%{EAP-Type}" != 'EAP-TTLS'){ reject }

Rick

Reimer Karlsen-Masur, DFN-CERT ha scritto:

...

Hi,

nikitha george wrote on 09.01.2008 10:04:

...

Hi, I want to enable only TTLS authentication and if the client is requesting any other types EAP-TLS or PEAP the authentication should be denied.

within the eap section you must configure the tls and the ttls section. Delete the peap section.

...

I am running freeradius-1.1.6, and if try to disable EAP-TLS module the server itself is not starting up. Please let me know if there are any ways to achieve this.

Then to disable the eap-tls functionality you must create an *empty* directory e.g. ${raddbdir}/certs/trustedCAsForRoamingClients/ and then within the tls section define

CA_path = ${raddbdir}/certs/trustedCAsForRoamingClients/

Also you must remove the definition of the parameter

CA_file =

This way you don't have any accepted CAs in your config that are trusted CAs for issued client certificates for eap-tls authentication

Make sure though that you put the radius server certificate and its CA chain including the root CA certificate in PEM format into the file specified with the

certificate_file

option in the tls section.

HTH

------------------------------------------------------------------------

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

-- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900

This is definitely more elegant than my suggestion but I found that many FreeRADIUS admins get confused by the CA_file CA_path options. They think that they need to place the CA chain from *their FreeRADIUS servers SSL certificate* in the file/directory specified in above options. But by doing so they most likely implicitly trust these CAs for client authentication via eap-tls, ie. they enabled EAP-TLS with some set of trusted CAs that were never intended to authenticate client certs for their organisation. Whereas the CA chain of *their FreeRADIUS servers SSL certificate* should be appended to the server certificate file specified with the certificate_file option. So since specifying an empty CA_file does not work (FreeRADIUS does not start) the only way for a really clean minimal config that is not allowing EAP-TLS is to have an empty CA_path directory. Defining the DEFAULT in the users file like below is a good additional step to rule all other EAP-Types out. my 2 cents Alan DeKok wrote on 09.01.2008 10:55:

nikitha george wrote:

...

Hi, I want to enable only TTLS authentication and if the client is requesting any other types EAP-TLS or PEAP the authentication should be denied. I am running freeradius-1.1.6, and if try to disable EAP-TLS module the server itself is not starting up. Please let me know if there are any ways to achieve this.

Put this at the top of the "users" file:

DEFAULT EAP-Type != EAP-TTLS, Auth-Type := Reject

-- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki 15 Jahre DFN-CERT + 15. DFN-Workshop "Sicherheit in vernetzten Systemen" am 13./14. Februar 2008 im CCH Hamburg - https://www.dfn-cert.de/ws2008/ -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Sachsenstr. 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski

Alan DeKok wrote on 10.01.2008 11:26:

Reimer Karlsen-Masur, DFN-CERT wrote:

...

This is definitely more elegant than my suggestion but I found that many FreeRADIUS admins get confused by the

CA_file CA_path

options. They think that they need to place the CA chain from *their FreeRADIUS servers SSL certificate* in the file/directory specified in above options.

I've added some comments in eap.cnf && raddb/certs/README explaining more about these issues.

...

But by doing so they most likely implicitly trust these CAs for client authentication via eap-tls, ie. they enabled EAP-TLS with some set of trusted CAs that were never intended to authenticate client certs for their organisation.

That's the whole purpose of CA_file, to be honest.

Agreed, but usually the CAs of the chain of the RADIUS servers SSL certificate are *not* the CAs that one wants to trust for organisational client authentication. Certs for client authN are mainly issued by organisational CAs. Whereas IMO the SSL cert of the RADIUS server should be issued by a CA which has its root CA certificate preinstalled in the standard certificate stores... Very good that you added some explanatory comments to these options. -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki 15 Jahre DFN-CERT + 15. DFN-Workshop "Sicherheit in vernetzten Systemen" am 13./14. Februar 2008 im CCH Hamburg - https://www.dfn-cert.de/ws2008/ -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Sachsenstr. 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski

No. You are saying that the supplicant should trust those root CA's for ALL authentication.

i.e. you have a certificate for "example.com", signed by Verisign. The supplicant is configured to trust the verisign-signed certificates, because that's what you have.

Now *anyone* who is issued a certificate from verisign can authenticate your users. If your users are using EAP-TTLS with PAP authentication, you've just convinced them to send their clear-text password to some random person on the Internet.

RADIUS certificates for EAP should ALMOST ALWAYS be self-signed. That means that no one else can successfully convince the users to send them the passwords.

I definitely second that. We keep telling our eduroam participants that well-known CAs are not only no plus, but instead MAY introduce insecurity (properly configured supplicants also check the CN in the certificate, which makes the risk go away; still, if a user forgets that, recognised CAs introduce a threat while self-signed ones don't). Either self-signed certs or at least dedicated CAs for the specific purpose of RADIUS Auth are the best practice. Some people which are in possession of a cert-store-present (read: browser-recognised) CA think it solves all problems whatsoever. They have a hard time laerning that it can actually be a hindrance, but it is a lesson everyone who is really concerned about security should learn at some point. Greetings, Stefan Winter -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu     Tel.:    +352 424409-1 http://www.restena.lu               Fax:      +352 422473

A.L.M.Buxey@lboro.ac.uk wrote on 10.01.2008 14:53:

Hi,

...

RADIUS certificates for EAP should ALMOST ALWAYS be self-signed. That means that no one else can successfully convince the users to send them the passwords.

seconded/thirded. as UK eduroam support I agree that such a closed-loop system provides a better protection. though more config and deployment pains, certainly ;-)

Actually we were talking about server side config. Looking at the supplicant, the user strongly should enter a fully qualified name of the radius server he is expecting his authN is checked against and he strongly should make sure that his supplicant is checking hard that this FQDN matches the CN of the RADIUS server cert. Usually there is some checkbox/option to enable that behavior. If the supplicant is not configured that strictly, at the end of the day it does not matter if you rolled your own self-signed RADIUS server cert or you have a cert with its root CA pre-installed. -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki 15 Jahre DFN-CERT + 15. DFN-Workshop "Sicherheit in vernetzten Systemen" am 13./14. Februar 2008 im CCH Hamburg - https://www.dfn-cert.de/ws2008/ -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Sachsenstr. 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski

Hi,

I don't recall seeing that, to be honest. wpa_supplicant doesn't have that, and Windows doesn't have it. They both have a "validate server certificate" checkbox, but that only checks the CA chain, NOT the CN.

Oh, it exists. It's called subject_match within a network { } stanza of wpa_supplicant, and all the Windows supplicants I've seen so far allow you set your expectations on the server name. It's turned off by default though. We use and advertise this extensively in eduroam. Greetings, Stefan -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu     Tel.:    +352 424409-1 http://www.restena.lu               Fax:      +352 422473

however, this puts the security on the client end...and they'll still get a connection with the proper server even if they've ommitted all the checks. this is bad generally - you need to have a way of the server checking that these client settings are enforced. oh well. I guess thats what locked-down desktops, corporate images, GPO pushed settings etc are all for. not handy for supporting the average user.

That road is painful. What we've come up so far with is supplying pre-configured supplicants (SecureW2) that bring the proper CA certificate along and set the expected CN automatically. It can even be preconfigured to auto-discard any other certificates, which doesn't give the user any opportunity to mess around. Of course, that is just pre-setting checkboxes in the supplicant. If a user *really* wants to sacrifice security for getting online cheap and easy on possible fraud networks, he can still toggle the settings manually later and shoot himself in the foot with it. For the built-in supplicant in XP/Vista: it generally sucks. There is the new "Wireless Native API" that is supposed to allow scripted auto-setups of 802.1X settings for an SSID, but we haven't tested if that's really practical. If you can find a student to code on that API, please go ahead :-) Stefan -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu     Tel.:    +352 424409-1 http://www.restena.lu               Fax:      +352 422473

Hi,

That road is painful. What we've come up so far with is supplying pre-configured supplicants (SecureW2) that bring the proper CA certificate along and set the expected CN automatically. It can even be preconfigured to auto-discard any other certificates, which doesn't give the user any opportunity to mess around. Of course, that is just pre-setting checkboxes in the supplicant. If a user *really* wants to sacrifice security for getting online cheap and easy on possible fraud networks, he can still toggle the settings manually later and shoot himself in the foot with it.

For the built-in supplicant in XP/Vista: it generally sucks. There is the new "Wireless Native API" that is supposed to allow scripted auto-setups of 802.1X settings for an SSID, but we haven't tested if that's really practical. If you can find a student to code on that API, please go ahead :-)

we have a similar method - preconfigured setup installer for OpenSEA (open1x.sf.net) and SecureW2 3.x - both have the required CN etc already set. handy for ensuring people have eduroam already configured too ;-) my main issue with securew2 is that it is really just a windows zero config supplicant plugin - ie it inherits all the windows supplicant issues. the cisco (pre meetinghouse) supplicant is one of the best (aironet desktop utility) - the meetinghouse client is interesting - users cannot simply configure the supplicant for EAP networks - an admin system needs to be used to push settings out. not handy for those users with EAP at home :-) alan

Stefan Winter wrote on 10.01.2008 15:51:

Hi,

...

If the supplicant is not configured that strictly, at the end of the day it does not matter if you rolled your own self-signed RADIUS server cert or you have a cert with its root CA pre-installed.

Actually, It's not quite the same: if the user at least managed to enable to CA checking, then

- for a commercial CA, thousands of untrusted hosts match his check - for a self-signed CA, only one server matches - for a dedicated RADIUS Auth CA, only servers within the administrative reach which are trusted to handle user authentications anyway match

This *is* a win in security vs. commercial CAs.

agreed when you turn off 2/3 of the possible checks, but if he is that unexperienced as many users are, it is easy to trick them into installing/trusting a new rogue CA or self-signed rogue RADIUS server certificate anyway. Don't forget: The user desperately wants his internet connection.... -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Sachsenstr. 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski

nikitha george wrote:

Alan, I tried with the configuration you had given below, but it does not work out. Still radius server is accepting TLS method.

And debug mode says.... ? Alan DeKok.