xsupplicant requires an "id" for authenticating to radius. This ID ends up as the User-Name in the radius request(s). I guess other 802.1x supplicant implementations do this similar. (Is this true?)
absolutely. you can type in an arbitrary identity.
The problem is that there is no connection between the certificate and the id / User-Name:
* The User-Name can be freely chosen by the supplicant. This username is then used for authorization (NOT authentication)
* The certificate gets used for authentication (NOT authorization)
Trouble is: There is no connection between the two. Assume the following situation:
yes. the issue is known though: it has been discussed several times on the list so far (please, search the archives). i think, raghu was the first to mention it but i could be wrong...
the trouble with this is that people have different understandings of what should be in the User-Name. Windows XP e.g. automatically puts the CN in it (but as you said before, you can override it). however, the mail address would be a reasonable alternative to CN. the problem is even worth when you are using proxying, since the CN typically will not contain the realm but the User-Name should do so if you want proxying to happen, so typically you can not just strcmp the strings but need some handler for that. briefly, it depends on what you certify and what you do with it.
so, it's still unresolved because the requirements vary a lot.
Is this possible with current sources? Anybody working on it? Would this be simple to add? It seems the current EAP-TLS implementation in
yes, in the EAP-TLS module you can add a line to check whether the EAP-Identity (which is always equal to the User-Name if you trust your NASes) equals whatever you have in the certificates, e.g. the CN.
you can also write an external authorization script which would do that checking. the certified content is not encrypted, so you can freely read it.
i think there are more solutions in the list-archive, search it.
On a side note: The very same issue seems to make it impossible to do any Simultanous-Use restrictions based on certificates. A user could just install the very same certificate on several machines and configure a different (allowed) User-Name for 802.1x. This would allow a single certificate to be used on more than one machine simultanously, blocking legitimate users and creating a DoS problem.
all issues you talk about are true: accounting without any changes is a problem. as explained above, due to the quite different requirements there is imho no such thing as a general solution.
ciao artur
-- Artur Hecker artur[at]hecker.info
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
