Arnaud Ebalard wrote:
- they come with an unknow username in their request but I don't want to kick them at that point (that's what I meant by "authorize *unknown* people").
Are they using EAP? If so, you can either reject them, or perform full authentication. You CANNOT simply "let them in". EAP doesn't work like that.
Their username is unknown but they are not unknown if I have enough information in their certificate to act. The problem is that the certificate is not a radius attribute.
Perhaps you are not clear on how EAP-TLS works. The user has a client certificate. If it is signed by the appropriate issuer, then the user is known. It doesn't matter what their User-Name is.
At the moment, to have a complete chain of trust when using EAP-TLS with freeradius, one has to use check_cert_cn so that a known user (user name in EAP) matches in some way the content of its certificate's CN. Otherwise, if you have a valid certificate, you can simply pretend you are someone else by presenting another username and get associated attributes during authorization.
I think you are not clear on how EAP-TLS works. The RADIUS User-Name is almost irrelevant. All that matters is the certificate that they present. And they can only present the right certificate if they (a) have it, and (b) have the password used to decrypt the private keys. An attacker *can't* just copy the certificate and expect to get authenticated. The EAP-TLS designers know a little bit about what they're doing. If you want to do *additional* checks, on top of certificate validation, you can. But this is not turning "unknown users" into "known users", and it is not "authorizing unknown users".
Perhaps I am wrong, but this is why I try to have some kind of authorization happening after the authentication.
You are trying to do all sorts of additional work because you don't understand how EAP-TLS works, and you think that the designers of EAP-TLS didn't know what they were doing. Alan DeKok.