<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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.<br>
<br>
On 1/26/2012 00:19, Stefan Winter wrote:
<blockquote cite="mid:4F210C88.40404@restena.lu" type="cite">
<pre wrap="">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
</pre>
<blockquote type="cite">
<pre wrap="">McNutt, Justin M. wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
Self-signed CA. *Always*.
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">
Yes.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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 <a class="moz-txt-link-freetext" href="http://www.freeradius.org/list/users.html">http://www.freeradius.org/list/users.html</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">-
List info/subscribe/unsubscribe? See <a class="moz-txt-link-freetext" href="http://www.freeradius.org/list/users.html">http://www.freeradius.org/list/users.html</a>
</pre>
</blockquote>
</body>
</html>