Troubleshooting EAP-TLS with External Certificates

[Matthew West]

>> In my attempts to get FreeRADIUS configured to work with e-mail/auth
>> certificates (previously issued), I was given a new 'CA Cert' to use
>> with our e-mail certificates.  I am now successfully authenticating
>> with the new CA file I was given and my e-mail certificate.
>> Unfortunately, the 'User-Name' field was filled with 'User Name' with
>> a space and failed the username field check.  I removed the space
>> filter from /etc/raddb/policy.d and I can now authenticate.  (Output
>> below).
>
>  That's stupid.

I agree. Whomever set up our certificates used our name (with space)
instead of e-mail address for username.  It's what I'm asked to use,
though.  Since we are using EAP-TLS, the username is provided in the
certificate, not by a user typing in a name.  Not that it makes the
issue any better, security-wise.

>> *** 2nd Question: If my company uses an internal CA certificate that
>> was issued/signed by Verisign and is bundled with the public CA's
>> chain, are there security implications with using the bundle?  (Output
>> below)
>
>  You usually can't set the EAP supplicant (end user PC) to trust an intermediate CA.  Often it's only the top-level CA.  Which means that anyone *else* with a version certificate will be accepted by the EAP supplicant.
>
>  That's bad.

I see why this is an issue if the supplicant (my target supplicants
are Windows 7, Mac OS, and Linux) only looks at the top-level CA.  The
implication, then, is that anyone with a VeriSign issued certificate
would authenticate.  That is bad.

To this, my technical lead on the project said:
] Need to look at two things here –
] * CRL checks – so that revoked certs do not authenticate
] * Certificate Whitelist of sorts – So only our bunch of certs authenticate

It is apparent that he understands the implication of using the
VeriSign chain as our CA. Is it possible to achieve a cert whitelist,
say, filter on the e-mail address presented in the certificate?

Would that remediate any security concerns, or would that still leave
room for abuse?

Thank you all for you help and insight,

Matthew West

On Thu, Sep 8, 2016 at 3:37 PM, Alan DeKok <aland at deployingradius.com> wrote:
> On Sep 8, 2016, at 6:09 PM, Matthew West <matthew.t.west at gmail.com> wrote:
>> Thank you for your help and direction while figuring out configuration
>> of FreeRADIUS.  You've been very helpful.
>
>   It's what we do.
>
>> *** 1st Question: Are there any implications when removing the space
>> filter from policy.d?
>
>   Yes.  It means that users can log in as "bob" or "bob ".  Depending on the database and other factors, they might be treated as different users, when they should be the same user.
>
>   The main reason someone puts spaces into a user name is they're trying to cheat you.
>
>> In my attempts to get FreeRADIUS configured to work with e-mail/auth
>> certificates (previously issued), I was given a new 'CA Cert' to use
>> with our e-mail certificates.  I am now successfully authenticating
>> with the new CA file I was given and my e-mail certificate.
>> Unfortunately, the 'User-Name' field was filled with 'User Name' with
>> a space and failed the username field check.  I removed the space
>> filter from /etc/raddb/policy.d and I can now authenticate.  (Output
>> below).
>
>   That's stupid.
>
>>> If you use a public CA then anyone else can get a cert signed by that CA for small change, they can then do eg evil twin etc attacks and badly configured clients will auth against them. ..thus giving them the users password (or easily cloud cracked mschap challenge/response)... many clients have basic security...eg only trust the CA. So local CA is the one way to ensure lowest common denominator is secure.
>>
>> *** 2nd Question: If my company uses an internal CA certificate that
>> was issued/signed by Verisign and is bundled with the public CA's
>> chain, are there security implications with using the bundle?  (Output
>> below)
>
>   You usually can't set the EAP supplicant (end user PC) to trust an intermediate CA.  Often it's only the top-level CA.  Which means that anyone *else* with a version certificate will be accepted by the EAP supplicant.
>
>   That's bad.
>
>   Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html