hi Lars


> I think the primary purpose is to allow the user to select a
> certificate other than the one associated with the currently logged
> in windows user. This makes perfect sense.

no, i'm sorry it doesn't :) i can take a certificate of "lars" and use the name "artur", windows has no problem with it whichsoever. additionally, one user can have a plenty of certificates which are all usable under the same login as long as he knows the private key password. under windows you can indeed choose the certificate, too, but in some other place...


> The option to specify an EAP identity other than the one that
> corresponds to the certificate only seems to makes sense in some
> environments, for instance if you assume that all clients with valid
> certificates are implicitly authorized.

usually, since you know the private key, you are good or at least you can be supposed to be the owner of that certificate.

basically, Lars, of course you are right :) we have to be aware that the proven identity is the certified identity. so, the proving server is the only one which can map this to whichever User-Name in a secure way. i.e. all the clients on the way UP should blindly copy and the proving server only can modify on the DOWNlink, if it thinks that it's ok.

the only point are the realms and all this stuff.

e.g. in my environment here, i use a common PKI between two universities. so basically, i can let verify my cert both at the local radius server and at the remote radius server. when i use an identity from the remote university, i can use the local server too. but, i can add @remote_univ in the windows XP window and the request will be proxied. that's a nice feature to have... we currently use "normal" certificates, i.e. we certify the Full Names and include the mail addresses, too. in that way, the domain name is included but Windows uses the Name part, not the email part (for what i've seen till now).


>> an example: when you are certifying users in your closed domain,
>> you could have certified users like "lars", "artur", etc., why not,
>> it's your domain, so you don't care.

> Using such names in the certificates is obviously a bad idea :-)

s. above. it's true, that's a big problem in the certification anyway or more generally in the security: which is the concerned identity? i bet that the user@realm isn't the best for the most applications. that's the problem. and nobody can afford three parallel PKIs today (the most people can't afford a stand-alone one...)


> If the realm is stripped away, wouldn't this work just fine as long
> as you just verify the User-Name against the certificate and ignore
> the EAP identity?

e.g., but then you propose to not verify the equality of all THREE fields.


> I guess that would work at least for the scenario you described
> above. An alternative would be to by default require that the
> User-Name matches exactly, but allow the server configuration to
> instead specify an external program/script to do the comparison. That
> way you can handle all kind of weird cases but it is up to the server
> administrator to specify the exact rules for equality.

ouch, no external scripts :) but that's a nice idea to let the admin specify the equality rule and the included attributes (if he takes in consideration User-Name, eap-id and the cert or just two of those, etc.). I can perfectly live with it.


ciao

artur



--
Artur Hecker Groupe Accès et Mobilité
hecker[at]enst[dot]fr Département Informatique et Réseaux
+33 1 45 81 7507 46, rue Barrault 75634 Paris cedex 13
http://www.infres.enst.fr ENST Paris


- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Reply via email to