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@deployingradius.com> wrote:
On Sep 8, 2016, at 6:09 PM, Matthew West <matthew.t.west@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