Re: eap_identity or username attribute? (to Artur and lars)
hi 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. Yes. As we have discussed the important point is to verify that the User-Name used for authorization (and accounting) corresponds to the certificate used for authentication. The EAP identity shouldn't really matter if the User-Name is used directly for this verification. ok, so we would agree at: use some handler id_equality(..., ...) for the verification of the equality of User-Name and the certified identity. make this handler configurable in radius.conf. provide common radius variables and in particular the realm suffixes and the configured realms to the handler in some form. (the best would be to provide the standard handler in this form, so everybody could modify the actual metrics). something like that? 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 wrote: Hi, Can I say both of you premise that NAS(radius client) must set User-Name value to eap-id? I see in FreeRadius that the username to i can't speak for Lars, but i would say yes, that's what is dictated by the standard. the ap must set the User-Name to eap-id since it is the first instance to create a Radius packet. all packets before are NOT radius. used authorize is set to User-Name attibute value. If User-Name value is null then eap-id is set to it. Now if NAS sends a packet to FreeRadius whose User-Name attibute is not same as eap-id, then there will be a logic bug. So I beleive that it make sense to let rlm_eap module to check consistency between User-Name and eap-id. i believe it, too. i just have some doubts in the situation mentioned in my previous mail. i could be wrong, though :) but you still should prove 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 750746, 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)
From: Artur Hecker [mailto:[EMAIL PROTECTED]] James Xie wrote: Hi, Can I say both of you premise that NAS(radius client) must set User-Name value to eap-id? I see in FreeRadius that the username to i can't speak for Lars, but i would say yes, that's what is dictated by the standard. the ap must set the User-Name to eap-id since it is the first instance to create a Radius packet. all packets before are NOT radius. Promise that it must is a bit strong :-) However, I would say that a NAS that doesn't do this is broken. used authorize is set to User-Name attibute value. If User-Name value is null then eap-id is set to it. Now if NAS sends a packet to FreeRadius whose User-Name attibute is not same as eap-id, then there will be a logic bug. So I beleive that it make sense to let rlm_eap module to check consistency between User-Name and eap-id. i believe it, too. i just have some doubts in the situation mentioned in my previous mail. i could be wrong, though :) but you still should prove it. Yes, but note that just adding this check will not close the hole we discussed previously since the rlm_eap_tls module currently doesn't seem to check the EAP identity. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: eap_identity or username attribute? (to Artur and lars)
:) Lars Viklund wrote: Promise that it must is a bit strong :-) However, I would say that a NAS that doesn't do this is broken. so, you are stating the same :)) well, i would say, the first Radius client MUST do so, because otherwise what could it probably put inside of User-Name and why? i believe it, too. i just have some doubts in the situation mentioned in my previous mail. i could be wrong, though :) but you still should prove it. Yes, but note that just adding this check will not close the hole we discussed previously since the rlm_eap_tls module currently doesn't seem to check the EAP identity. so you want the rlm_eap_tls to check if eap_id = certified identity, right? sounds very reasonable for me, but in some weird way, Windows XP gives the possibility to use a certificate and explicitely type in some name which has to be put in eap_identity then. so we probably shouldn't verify that... 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)
From: Artur Hecker [mailto:[EMAIL PROTECTED]] Sent: den 20 november 2002 14:51 To: [EMAIL PROTECTED] Subject: Re: eap_identity or username attribute? (to Artur and lars) so you want the rlm_eap_tls to check if eap_id = certified identity, right? sounds very reasonable for me, but in some weird way, Windows XP gives the possibility to use a certificate and explicitely type in some name which has to be put in eap_identity then. What wierd way are you refering to? Is it the Use a different user name for the connection check box you are talking about or something else? so we probably shouldn't verify that... But if you don't verify that the User-Name (or EAP identity, if you have already verified that the User-Name and EAP identity is the same) corresponds to the certificate then any authorization or accounting is basically meaningless. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: eap_identity or username attribute? (to Artur and lars)
hi Lars What wierd way are you refering to? Is it the Use a different user name for the connection check box you are talking about or something else? yes, exactly. so we probably shouldn't verify that... But if you don't verify that the User-Name (or EAP identity, if you have already verified that the User-Name and EAP identity is the same) corresponds to the certificate then any authorization or accounting is basically meaningless. i agree with that too, but why does this box exist in Windows then? i personally tend to think (and so I used it in that way some times during the test phase), that it exists in order to add a realm to the name. 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. then, one day, you expand and your domain gets a second part, with a complete another architecture. so, you would like the radius server in the second part simply forward the request to the original domain, right? (you bet that re-certification is NOT wanted). so with the current approach, you simply type in windows XP: use another name for this connection: windows proposes artur, you add @old_site or something similiar and here we go, the radius server forwards to the old site and everything works (with the new server stripping the realm away, e.g. or having reconfigured the server at old_site). if you verify that, then you have a problem. it won't work. i would tend to think, that the certificate has to be seen as the authentication method and the only reliable information. now of course you are right that is has to be bound to the User-Name, since the authorization happens with that one later... perhaps we have to define rules for equality of User-Name and the certified identity. one reasonable way for equality would be to take into consideration the defined realms and suffixes in the radius.conf (proxy.conf). i.e., if e.g. in the radius.conf you've defined a suffix @, and a realm old_site1, then freeradius should consider the certified kevin and the User-Name kevin@old_site1 as being the same, except of course it knows kevin locally. just an idea, which probably has bugs. what do you think? 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)
From: Artur Hecker [mailto:[EMAIL PROTECTED]] Sent: den 20 november 2002 17:15 To: [EMAIL PROTECTED] Subject: Re: eap_identity or username attribute? (to Artur and lars) i agree with that too, but why does this box exist in Windows then? i personally tend to think (and so I used it in that way some times during the test phase), that it exists in order to add a realm to the name. 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. 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. 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 :-) then, one day, you expand and your domain gets a second part, with a complete another architecture. so, you would like the radius server in the second part simply forward the request to the original domain, right? (you bet that re-certification is NOT wanted). so with the current approach, you simply type in windows XP: use another name for this connection: windows proposes artur, you add @old_site or something similiar and here we go, the radius server forwards to the old site and everything works (with the new server stripping the realm away, e.g. or having reconfigured the server at old_site). if you verify that, then you have a problem. it won't work. 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? i would tend to think, that the certificate has to be seen as the authentication method and the only reliable information. now of course Yes. you are right that is has to be bound to the User-Name, since the authorization happens with that one later... Yes. perhaps we have to define rules for equality of User-Name and the certified identity. one reasonable way for equality would be to take into consideration the defined realms and suffixes in the radius.conf (proxy.conf). Maybe. i.e., if e.g. in the radius.conf you've defined a suffix @, and a realm old_site1, then freeradius should consider the certified kevin and the User-Name kevin@old_site1 as being the same, except of course it knows kevin locally. just an idea, which probably has bugs. what do you think? 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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: eap_identity or username attribute? (to Artur and lars)
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)
From: Artur Hecker [mailto:[EMAIL PROTECTED]] Sent: den 20 november 2002 19:16 To: [EMAIL PROTECTED] Subject: Re: eap_identity or username attribute? (to Artur and lars) 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. Yes. As we have discussed the important point is to verify that the User-Name used for authorization (and accounting) corresponds to the certificate used for authentication. The EAP identity shouldn't really matter if the User-Name is used directly for this verification. I think verifying that the User-Name matches the EAP identity is more of a sanity check that can be ignored, without affecting security, if that simplifies the scenarios you are thinking about. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: eap_identity or username attribute? (to Artur and lars)
Hi, Can I say both of you premise that NAS(radius client) must set User-Name value to eap-id? I see in FreeRadius that the username to used authorize is set to User-Name attibute value. If User-Name value is null then eap-id is set to it. Now if NAS sends a packet to FreeRadius whose User-Name attibute is not same as eap-id, then there will be a logic bug. So I beleive that it make sense to let rlm_eap module to check consistency between User-Name and eap-id. .+-wèþ˱Êâmïî˱Êâmäzm§ÿðÃëyêÚv+¬¢¸?+-þë ®Èm
