Arnaud Ebalard wrote:
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).
Yes, I would use the User-Name for VLAN assignment. I would also use check_cert_cn to be sure that they didn't lie about the User-Name. If they lie, check_cert_cn rejects them. If they don't lie, they get put in the correct VLAN.
alice Auth-Type == EAP, EAP-Type == EAP-TLS Reply-Message = "Hello, Alice.",
You are mixing multiple policies. This is a bad idea. If you want to enforce that only EAP-TLS is being used, then do that. As a separate step, perform VLAN assignment.
DEFAULT Auth-Type := Reject
The server automatically rejects unknown users. You do NOT need this line.
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, ...).
As always, patches are welcome.
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.
The server lets you create policies on non-RADIUS elements, too. That's why it integrates with LDAP and SQL databases. If you need to check more than the CN of the cert, write a patch.
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.
You use check_cert_cn? That's why it exists...
Either you consider all users with a certificate (and associate key) equal (no attribute specific to that user),
If they all have the SAME certificate and key, then YES, they are identical. If they have seperate certs && keys, then the CN's are different.
or you MUST use check_cert_cn in relation with the RADIUS User-Name.
Which is why it's there. Honestly, I don't see why you're so shocked about it. You seem to be saying that check_cert_cn is a bad idea, because you have to *use* it to prevent people from lying. Well... the "User-Password" attribute has exactly the same properties. If you don't check it, people might lie, and get authenticated. Oh no! Alan DeKok.