Hi Matthew,
The cert CN vs User-Name in EAP-TLS is a good example. If I hadn't seen that comment in check-eap-tls, I could have completely overlooked it and then anyone with a valid cert could just pretend to be someone else ...
EAP-TLS is based around one thing - if you can present a valid certificate then you are permitted to connect.
Well my use case is not that simple :) If you're issued a cert you can prove who you are. But then depending on who you proved you were, you're going to be granted / denied access to whatever you're requesting to access.
There's no such thing as "pretending to be someone else". Yes, you could steal someone elses certificate and key. You could also steal their username and password for a different authentication method...
Well I used the "pretending to be someone else" because by default everything (group membership / reply attrs / ...) is keyed off "User-Name". And the User-Name gets filled with the CN if not explicitly told to do something else in the client. But without an explicit check it can be anything.
check-eap-tls is for the slightly less usual situation where you want to do additional checks on the client certifiacte presented. It's not a "this is how you authenticate this person" - EAP-TLS authenticates everyone you've issued a certificate to by definition.
"authenticate" yes. "authorize" no.
The example case of check-eap-tls (which is the reason I wrote it)
Thanks for writing it :)
Usually you would just not issue certs to the PCs you didn't want to connect. That wasn't possible here, hence the possibility of an additional check to restrict what would normally be controlled elsewhere.
Same here.
This doesn't hold for other parts of FreeRADIUS. Users can log in because they're in the users file, or a database, etc.
Actually I think that's this kind of simplification that's not totally correct that surprised me at first. My understanding ATM is that they can login because they have a Cleartext-Password being set that allows one of the auth method to proceed. Sure, the usual way of setting this IS to use DB/file/... but if you have special config that sets it any other way, it'll work just as well and the presence of the user in DB/files is not actually strictly required. And for EAP-TLS that's kind of what happens, no need for that attr for it to succeed, so no need for it to be in the DB either. And yeah, NOW it looks obvious to me, just wasn't always the case :)
FreeRADIUS doesn't just let anyone connect when you've not permitted them to.
I never said it did. All I said was that my ignorance led to a first configuration that was allowing much more than what I thought it did. I didn't intend to place any blame for that on FreeRADIUS at all, sorry if it sounded that way. I perfectly understand why things work this way now. And that config never even went anywhere to production either, I was just illustrating that sometimes "Testing that something that shouldn't work does indeed _not_ work" is not a waste of time. Cheers, Sylvain