Hi, Alan DeKok <aland@deployingradius.com> writes:
Arnaud Ebalard wrote:
I might be missing something but the certificates get available during the TLS exchange, i.e. long after the decision from the authorization modules.
Please read what I read. There are MULTIPLE packet exchanges. The certificate is available during ONE of those packet exchanges.
[...]
Yes. So? Do you understand that multiple packets go back and forth?
Yes, perfectly. Sorry if my response was imprecise or misleading. I clarify things below.
This rcode is conditioned by the issue of the authentication (if authentication fails, the Accept will change to a Reject). In my case, the idea is to authorize *unknown* people to authenticate with EAP-TLS
That's not the way EAP-TLS works. They need a client certificate in order to be authenticated.
Yes, perfectly. To be more precise: - 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"). - they provide a valid certificate during authentication with enough information to act (an OU, a CN, ...)
and decide later what to do with them (i.e. been someone from my PKI should not automatically imply an Accept).
You can turn an Accept into a Reject. You can't turn a Reject into an Accept.
Good. That's all I need.
Obviously, I would like to be able to kick people or return specific attributes based on the content of their certificate (where more information is available than simply its username) even if they have been authorized to authenticate. It seems to require actions *after* authentication has happened (i.e. after the certificate gets available).
As I said. This is possible.
But... only for known users. If you're trying to authenticate unknown people with EAP-TLS, then it won't work. Stop trying to do the impossible.
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. 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. Perhaps I am wrong, but this is why I try to have some kind of authorization happening after the authentication.
$ man unlang
ack. thanks again. Now, I stop bothering you and will come back with code or definitive conclusions. a+