Logging EAP-TLS certificate details

Wed Mar 24 20:26:17 CET 2021

Alan,

I've been doing this for 20+ years as well. You focus on developing software and creating RFCs, 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. 

>  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. 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. 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'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. 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? 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. All I would have is a client IP which would tell me in our around which building the attacker is. Not what certificate they stole. And don't tell me about the RFCs you named as we deal with the real world, and in the real world there are multiple cases of large companies using EAP-TLS authentication where there is simply no standard for the User-Name. We cannot enforce any specific format or we'd have to stop using EAP-TLS altogether as nobody would be able to authenticate.

>  User-Name is crap?  Check that the MAC address in the certificate matches the MAC address in Calling-Station-Id.

..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? What if we want to assign the same certificate to the 5 fire trucks in Fire Station 1, another certificate to the 4 ambulances in Fire station 2, and so forth? We are actually assigning individual certificates for each vehicle, but what it we didn't want to as we were satisfied in knowing that each Fire station had its own certificate for their devices? 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? 

Roberto

> On Mar 24, 2021, at 8:30 AM, Alan DeKok <aland at deployingradius.com> wrote:
> 
> On Mar 23, 2021, at 10:43 PM, <Roberto.Franceschetti at ocfl.net> <Roberto.Franceschetti at ocfl.net> wrote:
>> 
>>> * 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.
> 
>  Given the amount of confusion in the messages, that wasn't clear.
> 
>> There is absolutely nothing wrong with our practices, please do no make baseless accusations.
> 
>  Go read Matthews' reply.  I'd also ask you to look in the mirror, and see hypocrisy.
> 
>  You've claimed that the default configuration of FreeRADIUS is insecure, which is stating outright that *our* practices are wrong.  We pointed out that no, we can't anticipate everything.  And that it's up to you to understand your system.  And that you've created an insecure system.
> 
>  At which point you get offended. This comes across like "*I* can say that you guys are wrong.  How DARE you tell me that my practices are wrong!".
> 
>  To be frank, I've been doing this for 20 years.  I've written many of the standards in the space.  I've implemented many of the standards.  I've deployed EAP at many sites.  I've done deep dives into TLS standards, implementations, and practices.  I'm in the middle of writing a new RFC on EAP best practices, including TLS.
> 
>  I'm saying your practices are wrong, and you're saying I don't understand the problem space.  Who is likely to be correct here?  Think hard.
> 
>  RFC 3580 says that the User-Name MUST be taken from the EAP-Identity.  RFC 5216 says that the EAP-Identity is taken from (some) fields of the certificate.  Those are the facts.  If you disagree with those facts, you have to explain why the words in the RFCs do not mean what they say.
> 
>  The RADIUS packets contain things like User-Name, NAS IP/port, MAC address, TLS cert fields, etc.  These fields are not always to be trusted, as vendors can (and do) insane things with the protocols. That is an entirely different issue.
> 
>  It is YOUR responsibility as an administrator to catch broken equipment, and work around it.  I've said that repeatedly, and you don't seem to take that seriously.  It's easier to just blame FreeRADIUS (and us).
> 
>  If you control the certificates, then you can cross-correlate the fields.  It's simply a matter of reading the debug output.
> 
>  MAC addresses in weird format (Calling-Station-Id)?  Normalize them.
> 
>  User-Name is crap?  Check that the MAC address in the certificate matches the MAC address in Calling-Station-Id.  And log the MAC and User-Name, along with the NAS IP, port, etc.  Unless things are completely insane, you have enough information to do this.
> 
>  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.
> 
>   If the certificate is compromised, you have all the information you need.  You can tell which certificate has been compromised, and can (a) revoke the cert, and (b) kick the user offline.
> 
>  Again, WE CANNOT CHECK TLS FIELDS IN THE DEFAULT CONFIGURATION.  I've explained why in great detail.  You've ignored this.
> 
>  Instead, you've referred to 'best practices" which you seem to have invented.  You've made false analogies.  You've claimed I'm wrong for stating how cert fields go to EAP-Identity and User-Name, despite me pointing to the RFCs which say this is how it works.  You've gotten offended when we say your practices are wrong.  But it's perfectly fine for you to say that our practices are wrong.  And to imply that we don't care about security.
> 
>  We simply cannot update the default configuration to work everywhere, in all possible configurations, always, no matter what.  This *is* what you're asking us to do.
> 
>  We've explained why that's true.  We've explained what you should do in order to take responsibility for your local configuration.  Instead of learning, you're getting offended that we're telling you you're wrong.  And you're implying that we don't care about security.
> 
>   If you want to piss off the FreeRADIUS developers, you're doing a great job.  If you want to learn how to make your system better (and come up with a simpler solution), you're failing miserably.
> 
> 
>  For anyone who's reading this, don't implement Roberto's solution.  It's heavyweight, complex, and unnecessary.
> 
>  Instead, issue certificates which contain as much information as possible about the device, mainly MAC addresses.
> 
>  Instead, check users who are authenticating, and ensure that only known users are authenticating.  Reject users who aren't known, etc.
> 
>  Instead, if the NASes send you crap, figure out what extra information you DO need to log, and add that to the logs.  
> 
>  And don't get upset that FreeRADIUS is missing a magic button which says "do what I want".  Those buttons don't exist in the real world.
> 
>  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.