Using X.509 Cert. subject and issuer for authorization with EAP-TLS
arno at natisbad.org
Fri Apr 11 14:15:06 CEST 2008
Alan DeKok <aland at 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
> 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
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*
- 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
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
> 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
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
thanks again. Now, I stop bothering you and will come back with code or
More information about the Freeradius-Devel