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

[Arnaud Ebalard]

Hi,

Alan DeKok <aland at deployingradius.com> writes:

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

I do not mean to be rude or arrogant, but I am perfectly clear on how
EAP-TLS. I just fail to explain my point.

Just consider for 2 seconds that you have alice and bob who both have
their own certificate and keys (valid and different) and see how you
will handle the following with freeradius (using for instance rlm_files
for authorization): 

Put alice in VLAN 23 and bob in VLAN 24 (by having the associated set
of attributes returned to the NAS) after a successful authentication
using EAP-TLS, *and* be sure that alice will NOT be able to be put in
bob's VLAN. 

I am very curious to see how/if you would use the Radius User-Name to do
that, and how you would provide a strong association between attributes
and real identity (i.e. certificate and ability to use associated
private key).

A simple example is provided below. Don't hesitate to comment if this is
the wrong way to do it, if there is a better way, or if you see errors:

users file:
-----------

....

alice   Auth-Type == EAP, EAP-Type == EAP-TLS
        Reply-Message = "Hello, Alice.",
        Tunnel-Medium-Type = "IEEE-802",
        Tunnel-private-group-id = 23,
        Tunnel-Type = VLAN,
        Fall-Through = No

bob     Auth-Type == EAP, EAP-Type == EAP-TLS
        Reply-Message = "Hello, Bob.",
        Tunnel-Medium-Type = "IEEE-802",
        Tunnel-private-group-id = 24,
        Tunnel-Type = VLAN,
        Fall-Through = No


DEFAULT  Auth-Type := Reject
         Reply-Message = "You're not allowed to enter!",
         Fall-Through = Yes



eap.conf file:
--------------

        ....
        eap {
                default_eap_type = tls
                tls {
                        ....
                        check_cert_cn = %{User-Name}
                        ....
                }
             }
        ....

radiusd.conf file:
------------------

....

authorize {
        preprocess
        auth_log
        eap
        files
}

authenticate {
        eap
}

....



The trick presented in previous example could be avoided if the
authorization and setting of RADIUS attributes could be made based on
the content of the certificate (CN, OU, ...).


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

I am clear on how it works.


> The RADIUS User-Name is almost irrelevant. 

Yes, that's the point. So, how can user specific attributes be set in
the Access-Accept? RADIUS User-Name is the only *RADIUS* element that
gives a clue about the user.


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

I know that perfectly. Just consider my previous example and show me a
simple way to be sure that alice will not be able to be put in bob's
VLAN. 


>   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".

Either you consider all users with a certificate (and associate key)
equal (no attribute specific to that user), or you MUST use
check_cert_cn in relation with the RADIUS User-Name.


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

Sorry if my replies make you feel that way but this is really not the
case, i.e. I am not that arrogant ;-)

Cheers,

a+