TTLS+PAP with Windows
Alan DeKok
aland at deployingradius.com
Wed Mar 15 14:31:00 CET 2017
On Mar 15, 2017, at 6:00 AM, Herman Øie Kolden <herman at 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.
More information about the Freeradius-Users
mailing list