Troubleshooting EAP-TLS with External Certificates

[Matthew West]

Hi FR Users,

I've gotten to the point where both our *.acme.com server cert and CA
cert are working correctly.  Since we are using public CA-signed
e-mail certificates, I am looking to do some further checks before
sending the Access-Accept from EAP.
/etc/raddb/sites-available/check-eap-tls appears to be the correct
virtual server to do the check.

The information I am looking to check against is in the value-pair:
TLS-Client-Cert-Subject.  When checking the debug, I found the
information I'm looking for at chain-depth=0 in the chain (the first
two certs are the primary CA and intermediate CA).  Will check-eap-tls
use the information at chain-depth=0?

The information I get from TLS-Client-Cert-Subject has a lot of
information, and I only want to check the domain of the emailAddress
portion of what is sent to the server:

(18)  eap_tls : <<< TLS 1.0 Handshake [length 11fa], Certificate
(18)  eap_tls : chain-depth=2,
(18)  eap_tls : error=0
(18)  eap_tls : --> User-Name = Matthew West
(18)  eap_tls : --> BUF-Name = VeriSign Class 2 Public Primary
Certification Authority - G3
(18)  eap_tls : --> subject = /C=US/O=VeriSign, Inc./OU=VeriSign Trust
Network/OU=(c) 1999 VeriSign, Inc. - For authorized use
only/CN=VeriSign Class 2 Public Primary Certification Authority - G3
(18)  eap_tls : --> issuer  = /C=US/O=VeriSign, Inc./OU=VeriSign Trust
Network/OU=(c) 1999 VeriSign, Inc. - For authorized use
only/CN=VeriSign Class 2 Public Primary Certification Authority - G3
(18)  eap_tls : --> verify return:1
(18)  eap_tls : chain-depth=1,
(18)  eap_tls : error=0
(18)  eap_tls : --> User-Name = Matthew West
(18)  eap_tls : --> BUF-Name = Symantec Class 2 Shared Intermediate
Certificate Authority
(18)  eap_tls : --> subject = /C=US/O=Symantec Corporation/OU=Symantec
Trust Network/OU=Class 2 Managed PKI Individual Subscriber
CA/CN=Symantec Class 2 Shared Intermediate Certificate Authority
(18)  eap_tls : --> issuer  = /C=US/O=VeriSign, Inc./OU=VeriSign Trust
Network/OU=(c) 1999 VeriSign, Inc. - For authorized use
only/CN=VeriSign Class 2 Public Primary Certification Authority - G3
(18)  eap_tls : --> verify return:1
(18)  eap_tls : chain-depth=0,
(18)  eap_tls : error=0
(18)  eap_tls : --> User-Name = Matthew West
(18)  eap_tls : --> BUF-Name = Matthew West
(18)  eap_tls : --> subject = /CN=Matthew West/OU=S/MIME/O=ACME,
LLC/emailAddress=matthew.west at acme.com
(18)  eap_tls : --> issuer  = /C=US/O=Symantec Corporation/OU=Symantec
Trust Network/OU=Class 2 Managed PKI Individual Subscriber
CA/CN=Symantec Class 2 Shared Intermediate Certificate Authority

I would like to check the subject only for the inclusion of our
domain, acmetech.com, but am new to string manipulation using unlang.
I would like the function to work as following, but don't have the
syntax correct.

   if ("%{TLS-Client-Cert-Subject}" == (* + "acme.com") {
               update config {
                       Auth-Type := Accept
               }
       }
       else {
               update config {
                       Auth-Type := Reject
               }
               update reply {
                       Reply-Message := "Your certificate is not valid."
               }
       }

Your input is appreciated.

Thank You,

Matthew West



On Fri, Sep 9, 2016 at 3:53 PM, Matthew West <matthew.t.west at gmail.com> wrote:
>> > Would that remediate any security concerns, or would that still leave
>> > room for abuse?
>>
>> You can start with a known good secure situation where you have
>> control over all the variables, and do a little bit more work to
>> really tighten it down. Or you could start from a know less secure
>> situation where other people have control over your infrastructure,
>> and try and patch it up to stop people getting in who shouldn't.
>>
>> Your choice... but I know which one I'd go for to make sure access
>> to my network was secure.
>
> Thanks for your input everyone.  I was assured the CA certificate we
> are using is not a globally known CA and our e-mail/auth certificates
> were issued with it.
>
> The only issue I'm dealing with now is the space being present in the
> User-Name .  I'm hoping with the right regular expression I can grab
> only what we are to be expecting in the User-Name field (i.e 'User
> Name'), although I see a few e-mail certificates that break this rule.
>
>> On FreeRADIUS, look at OCSP in mods-available/eap, and
>> sites-available/check-eap-tls (also in mods-available/eap).
>
> OK, great.  That has everything I'm looking for.  Our PKI manager will
> either issue me a CRL or I'll set up with OCSP.  Thank you all for
> your help.  I'll let you know how everything turns out.
>
> Enjoy your weekend!
>
> Matthew West
>
>
>
> On Fri, Sep 9, 2016 at 12:36 PM, Matthew Newton <mcn4 at leicester.ac.uk> wrote:
>> On Fri, Sep 09, 2016 at 09:41:17AM -0700, Matthew West wrote:
>>> 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?
>>
>> On FreeRADIUS, look at OCSP in mods-available/eap, and
>> sites-available/check-eap-tls (also in mods-available/eap).
>>
>>> Would that remediate any security concerns, or would that still leave
>>> room for abuse?
>>
>> You can start with a known good secure situation where you have
>> control over all the variables, and do a little bit more work to
>> really tighten it down. Or you could start from a know less secure
>> situation where other people have control over your infrastructure,
>> and try and patch it up to stop people getting in who shouldn't.
>>
>> Your choice... but I know which one I'd go for to make sure access
>> to my network was secure.
>>
>> Matthew
>>
>>
>> --
>> Matthew Newton, Ph.D. <mcn4 at leicester.ac.uk>
>>
>> Systems Specialist, Infrastructure Services,
>> I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
>>
>> For IT help contact helpdesk extn. 2253, <ithelp at le.ac.uk>
>> -
>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html