Logging EAP-TLS certificate details

[Alan DeKok]

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.