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
- Re: eap_identity or username attribute? (to Artur and lars) James Xie
- Re: eap_identity or username attribute? (to Artur and la... Artur Hecker
- RE: eap_identity or username attribute? (to Artur and la... Lars Viklund
- RE: eap_identity or username attribute? (to Artur and la... Lars Viklund
- RE: eap_identity or username attribute? (to Artur and la... Lars Viklund
- RE: eap_identity or username attribute? (to Artur and la... Lars Viklund