Logging EAP-TLS certificate details

[Roberto.Franceschetti at ocfl.net]

Freeradius allows EAP-TLS authentication with certificates. Freeradius is however not logging which certificate was used to authenticate. Thus if a certificate is stolen/compromised, admins will be unable to determined which certificate needs to be revoked in order to stop the abuser.

A system that performs authentication must log the credential used to login. With EAP-TLS, the "credential" is the certificate used to authenticate. Freeradius needs to log at a minimum the certificate's issuer, and the serial or CN so that the certificate used to login can be identified.

This is not happening out-f-the-box. There's no option in the configs to enable the logging of that information. We had to (1) spend several days trying to figure out how to resolve this, and (2) make changes to the database and to a couple of config files to make it happen.

All I've pointed out from the beginning is that this EAP-TLS logging capability should be included as option (enabled by default) in freeradius, as right now when it comes to EAP-TLS, freeradius is an application that performs authentication without logging the credential (certificate) used to authenticate.

Roberto



> On Mar 24, 2021, at 6:09 PM, Alan DeKok <aland at deployingradius.com> wrote:
> 
> On Mar 24, 2021, at 4:59 PM, Martin Pauly <pauly at hrz.uni-marburg.de> wrote:
>> Watching discussions on this list is often a good way
>> to see what problems might lie ahead when, e.g. using
>> a feature you have not used before. So I would really like to
>> understand things, but it seems sort of hard to match the two points of view.
> 
>  The two points of view are this:
> 
> Roberto:  FR is broken because it doesn't do what I want out of the box
> 
> Alan: FR does the right thing most of the time, for most people.  If your situation is unusual or more complex, you need to edit the configuration.
> 
>  This is the same position taken by Matthew.
> 
>  The disagreement here is that Roberto is strenuously trying to convince me that bad actors can do bad things.  And implying that I don't already know that.  I do know that already.  I've said so repeatedly.
> 
>  The disagreement is that Roberto wants us to update the default configuration to match his environment.  I've explained why that request is wrong.  Instead of addressing my reasons, he's just repeated his arguments, and implied I don't know what I'm talking about.
> 
>  Matthew has already explained that in some situations, the server won't even log session information for users.  Because NAS vendors don't follow the standards, and don't put session information into the standard attributes which FreeRADIUS expects.
> 
>  The issues that Roberto is seeing are a tiny piece of the raging dumpster fire which is RADIUS.  There is literally NOTHING we can do to the default configuration which will make it perfectly secure in all situations.  So we are drawing a line.  Roberto disagrees with where that line is drawn, which is fine.  He can have opinions.
> 
>  What is inappropriate here is the implication that I'm stupid, that I don't understand how things work, and that I don't care about security.
> 
>> Roberto: We DO need to log bulletproof cert details like serial number.
>> Alan: Go set up your clients in a sane way, then you get your correlation for free.
>> Roberto: We already try, but vendors won't play along.
> 
>  You control the certificates, but not what goes into the EAP-Identity.  But a nonsense EAP identity is one of a very few weird things that a vendor can do.  There are still other fields you can use to cross-correlate information.
> 
>  But you have to write those correlation rules manually, for your local system.  We can't do this in the default configuration.  I've explained this.  These rules are created by reading the debug output, and then writing rules based on what you see.
> 
>  The response to that recommendation was a comment implying that I didn't know that the debug output didn't go into the database.
> 
> Just.... enough.  I have no idea why it's so important for Roberto to imply that I'm an idiot.  It's unproductive, and insulting.  I won't put up with that kind of nonsense.
> 
>> Alan: Then we are far from standards, and the default config cannot cover every weird situation that might arise.
>> But there's always a way to fix it through the config.
>> Roberto: But the default config/FR's processing MUST cover this, otherwise it a crap, security-wise.
> 
>  And that's where we disagree.  The default configuration does NOT cover every possible weird situation, and WILL NOT cover ever possible weird situation.  It is wrong and naive to ask that it does.
> 
>> Roberto, you've really dived deeply into your specific kind of problem.
>> Why not submit patches that try to improve the default config, if it is this clear
>> what is missing? I would really be interested to see what exactly should change.
> 
>  "Log TLS cert serial number on Access-Accept".
> 
>  Except, of course, that isn't enough.  Maybe the NAS vendors are broken, as Matthew has pointed out.  Then what?  You've logged a TLS cert serial number, but you have no idea what device it's for, or where that device is located on the network.
> 
>  This is why my recommendation (as always) is for people to understand their local network, and configure it to their local needs.
> 
>> What I haven't understood so far: Given Roberto's situation, _can_ you tweak
>> the config to log the data he wants, or would you need to change the processing
>> at some point (e.g. changing openssl lib calls to extract more information)?
> 
>  Yes.  Update the schemas to include TLS cert serial.  Update the SQL queries to log the TLS cert serial.
> 
>  But, and this is a huge BUT.  There are *still* situations where that won't work.  So even if we add that to the default configuration, someone *else* will jump in and say "I bought equipment from vendor X, which doesn't put session information into the standard attributes, so FR doesn't log it. OMG, FR is broken!"
> 
>  Such comments will be dealt with politely at first, and then with repeated slaps upside the head if they continue.
> 
> 
>  Here's the official recommendations for EAP-TLS:
> 
> * use your own CA, so you control which certificates are issued.
> 
> * use ONE client certificate per device.  Issuing the same certificate to multiple devices is broken and wrong
> 
> * include as much information as possible in the client certificate.  Names, MAC addresses, etc.
> 
> * when a user authenticates, check the information in RADIUS (User-Name, Calling-Station-ID) against the fields in the client cert.  If they disagree, then someone is likely doing something bad, and you can reject the user
> 
> * if the vendor equipment does stupid things, then most of the time you can work around it by following the previous guideline
> 
> * don't buy equipment from broken vendors who do stupid things.  It makes your life harder.
> 
> * read the debug logs to see what kind of things are sent by the NAS.  Then, write rules to store what you need in the DB.  Maybe update the DB schema.
> 
> * don't write scripts to scan / update the DB.  This is almost always unnecessary.  Instead, write SQL queries to update the *relevant* fields.  Use information taken from the packets, certificates, etc.  Read the debug output to see what information is available
> 
> * don't tell the FR developers that they're idiots.  It won't end well.
> 
> * don't ask that the default configuration be updated to match your particular use-case.  It won't end well.
> 
>  I'm currently writing an RFC which says this (not the last 2 points).  So that when people argue, I can point to the doc and say "this is how it's done".  And also so that when vendors do stupid things, people can point to the doc and say "here's how to do it correctly".
> 
>  People are free to review the doc and comment.  But they need to do so based on understanding how things work, and not by implying that the author is an idiot.
> 
>  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.