Logging EAP-TLS certificate details

Roberto.Franceschetti at ocfl.net Roberto.Franceschetti at ocfl.net
Wed Mar 24 03:43:28 CET 2021


For the record,

> * Your site has (essentially) random vendors issuing random certs that you don't control.  This practice is insecure, and is contributing towards the problem you're seeing.
This is once more incorrect. We are the ones issuing certificates to vendors and users via our Certificate Authority, not vice-versa. We are in full control of that process, and certificates are issued manually by us.
What we (and nobody else) CANNOT control is the fact that these IoT devices with the certs can be physically stolen (thus exposing the certificate), or that an employee who was issued a certificate decides to perform unlawful acts and use that certificate for nefarious purposes.
There is absolutely nothing wrong with our practices, please do no make baseless accusations.

> * the User-Name field is taken from the EAP-Identity, which is in turn taken from the subjectAltName or Common name fields of the certificate.
You are simply wrong here. It would be up to the application to provide the "User-Name" and that is completely unrelated to the certificate details. You yourself here just said it can be the SubjAltName or the CN... so even for you there's no standard. And as I've said, some applications provide the CN, some the MAC address, some random usernames.. Neither you nor I control what these applications provide. We didn't program them - they are commercial applications and/or a function of the OS.

> * These fields are the same 99% of the time.  The server checks that User-Name matches EAP-Identity.  It is up to you to configure the server to check that User-Name matches the correct certificate field.  See the first point above.
Wrong. See above. In real life you can't perform matches on the EAP-TLS provided User-Name as there's NOTHING IN ANY RFC that says it must match the CN/SubjAltName. Just because you say it's best practices it doesn't mean that Microsoft/Apple/Netmotion or JoesGarage etc will listen to you. I keep repeating - WE are not specifying the User-Name - commercial products we use that authenticate via EAP-TLS are specifying the various flavors of "User-Name" EAP-TLS identities while authenticating using our *properly issued* certificates.

> *  Because your site is not following this common practice, you're seeing all kinds of issues.  Issues which most other people don't see.
I'm sorry, but WE are following best practices. What is not following best practice was freeradius not auditing/logging the identity (meaning the certificate details) that was used to authenticate via EAP-TLS. 
Imagine what would happen if Microsoft, instead of logging the username used to login, would instead log the "description" field in Active Directory for the account. Sure, you could scream all you want and say "but the users should have a real valid description in the description field". Do you actually think that would fly...? No.
This is what is happening with Freeradius. Instead of logging the certificate used to login, it's logging the "User-Name" field which in the case of EAP-TLS is a completely random user-defined field - a "description".

You are trying to blame us for something which is instead a big whole in freeradius - the lack of auditing of the certificates used to authenticate via EAP-TLS in the default configuration of freeradius. If auditing was in place, we would not be having these arguments. The solution is simple - all it takes is for the developers to understand that it is an actual issue and fix it instead of baselessly blaming us admins for not following best practices.

Luckily freeradius is the beauty that it is, and we were able to customize it to log what should be logged out-of-the-box.

And at this point, I will repeat - "For anyone who thinks this is an actual concern, here's how we did it - see previous posts."

Roberto


> On Mar 22, 2021, at 6:40 PM, Alan DeKok <aland at deployingradius.com> wrote:
> 
> On Mar 22, 2021, at 5:04 PM, <Roberto.Franceschetti at ocfl.net> <Roberto.Franceschetti at ocfl.net> wrote:
>> Let me clarify - we issue certificate to actual people and applications. Every certificate is accounted for, and the Common Name will either have the persons's name or the serial/MAC address of the IoT it was issued to.
> 
>  There's a lot of details which have come out over a series of messages.  Incomplete problem descriptions tend to cause confusion.
> 
>  The summary here is:
> 
> 
> * the default configuration doesn't log TLS client cert serial, because (a) most people don't use EAP-TLS, and (b) most people who do use it also check that the user names are valid
> 
> * the User-Name field is taken from the EAP-Identity, which is in turn taken from the subjectAltName or Common name fields of the certificate.
> 
> * These fields are the same 99% of the time.  The server checks that User-Name matches EAP-Identity.  It is up to you to configure the server to check that User-Name matches the correct certificate field.  See the first point above.
> 
> * We can't add in these checks by default, because there are variations in which fields are used
> 
> * Your site has (essentially) random vendors issuing random certs that you don't control.  This practice is insecure, and is contributing towards the problem you're seeing.
> 
> * Most people control their own client certificates.  This means that they can issue certs with fields that make sense, in a format that makes sense.
> 
> *  Because your site is not following this common practice, you're seeing all kinds of issues.  Issues which most other people don't see.
> 
> *  Access-Request packets contains NAS IP / port information.  You can log that, along with other information such as certificate serial numbers.
> 
> *  Accounting-Request packets also contain NAS IP / port information.   This is the same information as seen in the Access-Accept.
> 
> * You can correlate the two sets of information, in order to see (a) which port the user is on, and (b) what TLS cert they have.
> 
>  This minor change to the default configuration will address all of the issues you're seeing.
> 
>  The security issue here is that your site is not validating that the User-Name matches the cert, and is not validating that the User-Name is known.  While there are reasons for that, it's important to note that these reasons are local to your site.  
> 
>  Perhaps we need better documentation to say "don't do that, it's a problem".
> 
>  Alan DeKok.
> 
> 
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

PLEASE NOTE: Florida has a very broad public records law (F. S. 119).
All e-mails to and from County Officials are kept as a public record.
Your e-mail communications, including your e-mail address may be
disclosed to the public and media at any time.




More information about the Freeradius-Users mailing list