Hi, Alan DeKok <aland@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+