Logging EAP-TLS certificate details

[Alan DeKok]

On Mar 24, 2021, at 3:26 PM, Roberto.Franceschetti at ocfl.net wrote:
> I've been doing this for 20+ years as well. You focus on developing software and creating RFCs,

  As I've said, I've also spent much of that time building actual real-world systems.  Please don't minimize that.

> I focus on security and ensuring applications are secure and also develop software myself. I insist that unless you log the EAP-TLS certificate data, freeradius is lacking security as you CANNOT find out what certificate is compromised when using data logged and audited by freeradius in its default configuration. You need to log the client cert's serial number and issuer. If you don't, there is NO WAY to to find out what cert is compromised. 

  You're strenuously arguing a point we've already agreed to.  I already know what the default configuration logs, and why.

  Matthew and I have explained WHY the default configuration does what it does, and what YOUR responsibility is.   Why not  address the reasons we gave why the default configuration is the way it is?  Show that you understand our position, and then try to refute it.

  You're just not doing that right now.  Which makes it clear that you don't understand my position.  Which means that your counter-arguments are largely irrelevant.

>> If you control the certificates, then you can cross-correlate the fields.  It's simply a matter of reading the debug output.
> You think we run freeradius in debug mode and log the output...? It's irrelevant what shows in freeradius -X in a production environment. What matters in case someone hacked in is what's in the logs/database. They don't contain the debug output.

  That's just missing the point.  The debug output is where you START your local customizations.

  Don't pretend that I'm an idiot who's asking you to always run the server in debug mode.  Don't pretend I'm an idiot who doesn't understand that the debug output doesn't go into the database.

  That implication is rude, ignorant, and uncalled for.  It shows that your counter-argument is based on ad hominems and false assumptions.

> The only thing the debug output is useful for is to use its data to see what's available and make use of it thru customizations. Which is exactly what we did. We customized freeradius using the info we saw in the debug output, and that required changing the database schema and the logging schema to capture cert information.

  Which is what we told you to do.  And what *everyone* has to do.  The default configuration works *mostly* in *most* situations.  But it has to be customized.

> I'm simply telling you that would you need to make those changes in the default freeradius configuration as well, because right now you're not logging the identity used to authenticate with EAP-TLS, and that's a big security issue.

  I'm simply telling YOU why you're wrong.  instead of addressing my points, you just repeat yourself.  It shows that your counter argument can't, in fact, address my points.

>> I'll note that the default configuration logs User-Name *and* Calling-Station-Id, which means that you have the name *and* the MAC of the device.  The default configuration also logs Called-Station-Id, along with NAS IP, port, etc.  Which means that you know where the device is on the network.
> You are 100% incorrect here, again.

  Bullshit.  You can believe that I don't understand RADIUS / EAP / TLS, or you can believe that you don't understand my points.  I know which one is easier for you, but that doesn't change what's going on here.

> Did actually realize that I can configure a Parallels/VMware guest with a completely bogus MAC address, and authenticate via WiFi and EAP-TLS with a stolen certificate by specifying a completely fake User-Name?

  OMFG, REALLY?  HOLY SHIT!!!!

  I mean, it's not like I *admitted* that in a prior email.  But it's hard to address my comments.  It's easier to have counter-arguments which assume I'm a freaking idiot.

> Will you tell me how in the world I'm supposed to find the compromised certificate if BOTH the MAC and the User-Name are fake? I CANNOT.

  I've explained.  Since you haven't learned from that explanation, there isn't more I can do.

> ..and you come up with all sorts of "you should do this" like this one. Why in the world should we be limited to assigning one specific certificate to one single IoT?

  Because using the same certificate in multiple devices is insecure and wrong.  It costs you NOTHING to create more certificates.  It costs you enormous amounts of insecurity to have the same cert on multiple devices.

  The fact that you don't see this as a problem is a huge red flag: You should not be recommending "best practices".

>  There are too many scenarios, and again, NONE OF THIS IS AN ISSUE IF YOU LOG THE SERIAL NUMBER AND ISSUER of the cert used to authenticate. If you log that information, then you're logging the method used to authenticate. How can you even argue that it's not needed? 

  Because I didn't argue that. So your counter-arguments are based on lying about what I said.

  Your position is based on lies, misunderstanding and/or ignoring my position, simple repetition, and implying that I'm an idiot.

  Why do you feel that this is the best approach?

  Alan DeKok.