So I'm getting some pushback in my organization against using a self-signed CA for signing my RADIUS server certs. To make a long story short, I was asked to find out what other people were doing. For my own reasons, I'd like to know slightly more than that. If you AREN'T using a self-signed CA for your RADIUS server, what made you use another CA, and what CA did you use? And just to be clear, is the concensus still that a self-signed CA is the way to go, assuming that you have a decent way to distribute the CA cert (which we do) to the clients who need to trust it? I've read /etc/raddb/certs/README and I've done some Googling and everything I find pretty much assumes that you're using a self-signed CA. The README explains briefly why, but my management wants more assurance than that, so here I am. Looking forward to your responses, and thanks in advance. --J
Hi, On Thu, Jan 26, 2012 at 12:08:34AM +0000, McNutt, Justin M. wrote:
long story short, I was asked to find out what other people were doing.
Self-signed CA.
And just to be clear, is the concensus still that a self-signed CA is the way to go,
Self-signed CA - you have to distribute the CA cert to your clients. Nobody can set up a rogue network / AP with rogue RADIUS server without the client throwing up some sort of warning. Public CA - easier as you don't have to distribute the CA cert. You're open to spoofing attacks where someone can get another cert from the same CA and put it on a rogue RADIUS server. These days it seems anyone can get a public-CA certificate for any domain by just asking for it at the back door...
management wants more assurance than that, so here I am.
First is more secure, second is more convenient.
assuming that you have a decent way to distribute the CA cert (which we do) to the clients
If you can easily push the certs out, I'd go for the more secure self-singned certs, as the main objection to it seems to be pushing out the CA cert. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On 01/26/2012 01:43 AM, Matthew Newton wrote:
Public CA - easier as you don't have to distribute the CA cert.
You're open to spoofing attacks where someone can get another cert from the same CA and put it on a rogue RADIUS server. These days it seems anyone can get a public-CA certificate for any domain by just asking for it at the back door...
This depends on the CA. As I've said before, anyone going down this route should pony up and pay top dollar for a reliable cert from a (reasonably!) reliable CA, AND ENSURE that clients are validating the certificate CN. I'm no fan of X.509 or CAs (oh, EAP-EKE - how I wish we could have been together!) but not every CA is terrible!
McNutt, Justin M. wrote:
So I'm getting some pushback in my organization against using a self-signed CA for signing my RADIUS server certs. To make a long story short, I was asked to find out what other people were doing.
Self-signed CA. *Always*.
And just to be clear, is the concensus still that a self-signed CA is the way to go, assuming that you have a decent way to distribute the CA cert (which we do) to the clients who need to trust it?
Yes.
I've read /etc/raddb/certs/README and I've done some Googling and everything I find pretty much assumes that you're using a self-signed CA. The README explains briefly why, but my management wants more assurance than that, so here I am.
Well, I wrote that README. It's correct. Here's a question for management. Do they want anyone on the planet to be able to set up a copy of their WiFi SSID, and grab user information? If yes, use a public CA. If no, use a self-signed CA. With web surfing, your web browser verifies that the site at "facebook.com" is holding an SSL certificate which says "facebook.com". This prevents anyone else from using a "facebook.com" certificate, because no one else can control the "facebook.com" domain. For WiFi, there is no such control. If your company SSID is "example.com", *anyone* can duplicate that SSID. The EAP supplicant doesn't check if the SSID matches the certificate. It can't check, for a whole host of reasons. So the situations are different. The result is that the security methods are different, too. Alan DeKok.
Hi, that's a discussion / holy war admins are fighting over for *years* in the eduroam roaming consortium. I agree with all what was said in the thread, regarding security vs. convenience. Just to add one thing to the mix: if you allow "bring your own device" for your network, you'll have much less control over what hardware comes to visit you. For some supplicants it is very hard/impossible to add an own self-signed CA to the trust root. In these cases, being able to verify the issuing CA against the hard-wired trust store is arguably more secure than not being able to validate the cert at all with a self-signed CA. For Android <4.0 for example, pushing a new CA into the trust store is hard. Doing it in a non-interactive autoconfig way is to my knowledge impossible. So, BYOD is a factor to consider. Greetings, Stefan Winter
McNutt, Justin M. wrote:
So I'm getting some pushback in my organization against using a self-signed CA for signing my RADIUS server certs. To make a long story short, I was asked to find out what other people were doing.
Self-signed CA. *Always*.
And just to be clear, is the concensus still that a self-signed CA is the way to go, assuming that you have a decent way to distribute the CA cert (which we do) to the clients who need to trust it?
Yes.
I've read /etc/raddb/certs/README and I've done some Googling and everything I find pretty much assumes that you're using a self-signed CA. The README explains briefly why, but my management wants more assurance than that, so here I am.
Well, I wrote that README. It's correct.
Here's a question for management. Do they want anyone on the planet to be able to set up a copy of their WiFi SSID, and grab user information?
If yes, use a public CA. If no, use a self-signed CA.
With web surfing, your web browser verifies that the site at "facebook.com" is holding an SSL certificate which says "facebook.com". This prevents anyone else from using a "facebook.com" certificate, because no one else can control the "facebook.com" domain.
For WiFi, there is no such control. If your company SSID is "example.com", *anyone* can duplicate that SSID. The EAP supplicant doesn't check if the SSID matches the certificate. It can't check, for a whole host of reasons.
So the situations are different. The result is that the security methods are different, too.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
hi, self-signed CA. the authentication is a closed-loop system. the only people that need to trust your RADIUS server for authentication are your own users (unlike eg a public web server). you have full control of your own CA..and know its policies. With an external CA you are a slave to their reputation and policies...wouldnt it be nice to come in on a monday morning and find your CA had been removed by the OS as happened recently... The issue is with the distribution/installation of that CA - but you already say you have that covered..so great! :-) alan
I've attached android, windows 7, macosx, and ubuntu linux to an eap-tls network using wpa2-eap-tls, which requires client and CA certs. it's no issue once you know what you're doing. the hardest part is the nearly complete lack of documentation for any OS except linux. you're limited to what google provides from various blogs. On 1/26/2012 00:19, Stefan Winter wrote:
Hi,
that's a discussion / holy war admins are fighting over for *years* in the eduroam roaming consortium.
I agree with all what was said in the thread, regarding security vs. convenience.
Just to add one thing to the mix: if you allow "bring your own device" for your network, you'll have much less control over what hardware comes to visit you. For some supplicants it is very hard/impossible to add an own self-signed CA to the trust root.
In these cases, being able to verify the issuing CA against the hard-wired trust store is arguably more secure than not being able to validate the cert at all with a self-signed CA.
For Android<4.0 for example, pushing a new CA into the trust store is hard. Doing it in a non-interactive autoconfig way is to my knowledge impossible.
So, BYOD is a factor to consider.
Greetings,
Stefan Winter
McNutt, Justin M. wrote:
So I'm getting some pushback in my organization against using a self-signed CA for signing my RADIUS server certs. To make a long story short, I was asked to find out what other people were doing. Self-signed CA. *Always*.
And just to be clear, is the concensus still that a self-signed CA is the way to go, assuming that you have a decent way to distribute the CA cert (which we do) to the clients who need to trust it? Yes.
I've read /etc/raddb/certs/README and I've done some Googling and everything I find pretty much assumes that you're using a self-signed CA. The README explains briefly why, but my management wants more assurance than that, so here I am. Well, I wrote that README. It's correct.
Here's a question for management. Do they want anyone on the planet to be able to set up a copy of their WiFi SSID, and grab user information?
If yes, use a public CA. If no, use a self-signed CA.
With web surfing, your web browser verifies that the site at "facebook.com" is holding an SSL certificate which says "facebook.com". This prevents anyone else from using a "facebook.com" certificate, because no one else can control the "facebook.com" domain.
For WiFi, there is no such control. If your company SSID is "example.com", *anyone* can duplicate that SSID. The EAP supplicant doesn't check if the SSID matches the certificate. It can't check, for a whole host of reasons.
So the situations are different. The result is that the security methods are different, too.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 01/27/2012 12:29 AM, Christ Schlacta wrote:
I've attached android, windows 7, macosx, and ubuntu linux to an eap-tls network using wpa2-eap-tls, which requires client and CA certs. it's no issue once you know what you're doing. the hardest part is the nearly complete lack of documentation for any OS except linux. you're limited to what google provides from various blogs.
"Once you know what you're doing". When guests arrive at your site, they don't want to spend 20 minutes following intricate docs. Especially if their meeting is only 30 minutes. Sure *I* can get any of those systems online in under a minute. The concern is how fast a short-lived guest can get online. Our web-based "staff create a guest account" portal takes only seconds. Walking the user through cert installation takes a lot longer.
Thanks to all for the responses so far. I'm still reading through them. In my case, guests are given a WEP key (which just keeps the "Automatically Connect to Open Networks" devices away) and allowed to connect to a guest SSID which has a separate Internet drain, policies, limitations, etc. To get high speed access, you have to take the trouble to get an account and use the EAP-enabled network. Carrot and stick. But to be clear, I'm not making guests authenticate at all, so that's one nasty problem that is outside of the scope of this particular discussion. --J From: Phil Mayers <p.mayers@imperial.ac.uk<mailto:p.mayers@imperial.ac.uk>> Reply-To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org<mailto:freeradius-users@lists.freeradius.org>> Date: Fri, 27 Jan 2012 10:07:27 +0000 To: <freeradius-users@lists.freeradius.org<mailto:freeradius-users@lists.freeradius.org>> Subject: Re: self-signed root CA On 01/27/2012 12:29 AM, Christ Schlacta wrote: I've attached android, windows 7, macosx, and ubuntu linux to an eap-tls network using wpa2-eap-tls, which requires client and CA certs. it's no issue once you know what you're doing. the hardest part is the nearly complete lack of documentation for any OS except linux. you're limited to what google provides from various blogs. "Once you know what you're doing". When guests arrive at your site, they don't want to spend 20 minutes following intricate docs. Especially if their meeting is only 30 minutes. Sure *I* can get any of those systems online in under a minute. The concern is how fast a short-lived guest can get online. Our web-based "staff create a guest account" portal takes only seconds. Walking the user through cert installation takes a lot longer. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 01/26/2012 12:08 AM, McNutt, Justin M. wrote:
So I'm getting some pushback in my organization against using a self-signed CA for signing my RADIUS server certs. To make a long story short, I was asked to find out what other people were doing.
This has been discussed extensively on the list!
For my own reasons, I'd like to know slightly more than that. If you AREN'T using a self-signed CA for your RADIUS server, what made you use another CA, and what CA did you use?
We use a Verisign cert. We chose this because we decided the difficulty of deploying the certificate to unmanaged client desktop, laptop and mobile devices was excessive, given our client base. I should emphasise that this is a 5 year old decision; at the time, the various open-source cert deployment tools (e.g. su1x) were unavailable, and there was (indeed, still is) an unwillingness to pay for a solution such as CloudPath. I should also emphasise that, at the time, the client base included Windows Mobile 5 devices (on which it is practically impossible to install certs) as well as guest laptops (on which the hassle of installing a cert eats significantly into the time the guest is here). Therefore, we opted for a public cert. If we were starting from scratch, we'd probably use a private cert and su1x to deploy it. There is zero appetite to change certs (and reconfigure ~10,000 clients).
And just to be clear, is the concensus still that a self-signed CA is the way to go, assuming that you have a decent way to distribute the CA cert (which we do) to the clients who need to trust it?
Yes, very much so. Is is the safer and more secure default option.
Self-signed provides stronger security in most cases. I'm using self-signed here, and distributing a certificate to unmanaged user devices is as easy as placing a p12 file on a USB drive and requiring users to stop by ops before getting on wireless. If you're using a public CA to sign certs, and you're not using TLS authentication (I'm guessing you're not. getting that many certs would be expensive), then anyone can impersonate your network and intercept perceivably protected traffic. this is BAD. Insofar as I know, nearly everyone on this list using certs is using self-signed. On 1/25/2012 16:08, McNutt, Justin M. wrote:
So I'm getting some pushback in my organization against using a self-signed CA for signing my RADIUS server certs. To make a long story short, I was asked to find out what other people were doing.
For my own reasons, I'd like to know slightly more than that. If you AREN'T using a self-signed CA for your RADIUS server, what made you use another CA, and what CA did you use?
And just to be clear, is the concensus still that a self-signed CA is the way to go, assuming that you have a decent way to distribute the CA cert (which we do) to the clients who need to trust it?
I've read /etc/raddb/certs/README and I've done some Googling and everything I find pretty much assumes that you're using a self-signed CA. The README explains briefly why, but my management wants more assurance than that, so here I am.
Looking forward to your responses, and thanks in advance.
--J
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
This is basically what we've decided. Assuming there are no more issues with management, we're going to set up a separate CA for RADIUS that only signs the server certs for the RADIUS servers. Thanks to all for the replies. Very useful! --J From: Christ Schlacta <lists@aarcane.org<mailto:lists@aarcane.org>> Reply-To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org<mailto:freeradius-users@lists.freeradius.org>> Date: Thu, 26 Jan 2012 16:25:33 -0800 To: <freeradius-users@lists.freeradius.org<mailto:freeradius-users@lists.freeradius.org>> Subject: Re: self-signed root CA Self-signed provides stronger security in most cases. I'm using self-signed here, and distributing a certificate to unmanaged user devices is as easy as placing a p12 file on a USB drive and requiring users to stop by ops before getting on wireless. If you're using a public CA to sign certs, and you're not using TLS authentication (I'm guessing you're not. getting that many certs would be expensive), then anyone can impersonate your network and intercept perceivably protected traffic. this is BAD. Insofar as I know, nearly everyone on this list using certs is using self-signed. On 1/25/2012 16:08, McNutt, Justin M. wrote: So I'm getting some pushback in my organization against using a self-signed CA for signing my RADIUS server certs. To make a long story short, I was asked to find out what other people were doing. For my own reasons, I'd like to know slightly more than that. If you AREN'T using a self-signed CA for your RADIUS server, what made you use another CA, and what CA did you use? And just to be clear, is the concensus still that a self-signed CA is the way to go, assuming that you have a decent way to distribute the CA cert (which we do) to the clients who need to trust it? I've read /etc/raddb/certs/README and I've done some Googling and everything I find pretty much assumes that you're using a self-signed CA. The README explains briefly why, but my management wants more assurance than that, so here I am. Looking forward to your responses, and thanks in advance. --J - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (7)
-
Alan Buxey -
Alan DeKok -
Christ Schlacta -
Matthew Newton -
McNutt, Justin M. -
Phil Mayers -
Stefan Winter