Using X.509 Cert. subject and issuer for authorization with EAP-TLS

[Arnaud Ebalard]

Hi,

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
>> 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+