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)
> 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 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 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 > 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 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)
:) 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]] > 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)
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?
> From: Artur Hecker [mailto:[EMAIL PROTECTED]] > Sent: den 19 november 2002 20:27 > To: [EMAIL PROTECTED] > Subject: Re: eap_identity or username attribute? > i only wanted to say, that the certified identity could be e.g. > [EMAIL PROTECTED] so, the eap-id would carry [EMAIL PROTECTED] each AP > should basically put this value into User-Name, so it would be > [EMAIL PROTECTED] again. We could verify that for both > authentication and > authorization the three fields are the same, certificate = eap-id = > User-Name. Right. I don't think it is standardized how to check that the identity/user-name corresponds to the certificate, so one would probably just base the check on what Win XP does. > now the server receiving the request from the AP happens to be in > visited.com. so it has to proxy the request to the home.com radius > server. it could happen, that home.com (being some huge ISP) > demands a > stripped user-name, i.e. simply kevin. so the server at visited.com > would strip it, but in the User-Name only, since the > EAP-Message is not > considered when proxying. Now home.com, when running > freeradius, would > state that the three attributes mentioned before are *not* > the same and > would reject, right? or did i misget your point? I see your point, but I just don't think it makes sense to demand a stripped User-Name when using certificates for authentication. - 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
Re: eap_identity or username attribute?
to the original question: the two fields should be the same, that's now verified. to Lars: since the draft and the standard basically state the same, let's refer to the standard :) but that's not the point... i only wanted to say, that the certified identity could be e.g. [EMAIL PROTECTED] so, the eap-id would carry [EMAIL PROTECTED] each AP should basically put this value into User-Name, so it would be [EMAIL PROTECTED] again. We could verify that for both authentication and authorization the three fields are the same, certificate = eap-id = User-Name. now the server receiving the request from the AP happens to be in visited.com. so it has to proxy the request to the home.com radius server. it could happen, that home.com (being some huge ISP) demands a stripped user-name, i.e. simply kevin. so the server at visited.com would strip it, but in the User-Name only, since the EAP-Message is not considered when proxying. Now home.com, when running freeradius, would state that the three attributes mentioned before are *not* the same and would reject, right? or did i misget your point? well, i see, that there are work-arounds for it (do not use stripping :)). perhaps one could find better examples, i don't know. what i'm saying is that we should be sure about demanding this equality. as already said, otherwise, i would agree with everything you said, especially that there is no point in those three being completely different. the problem is only the realm part (is kevin = [EMAIL PROTECTED]?), perhaps. > I don't really think it makes sense to use EAP-TLS with Service-Type > = Call Check, so I'm not sure this is a problem. that i don't know, i'm not using that. if you are sure about this point, ok, let's forget this one. > I don't think there are any contradictions between Std 802.1X and the > congdon ID. one more point for the standard, right? :-) 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?
> From: Artur Hecker [mailto:[EMAIL PROTECTED]] > Sent: den 19 november 2002 18:49 > To: [EMAIL PROTECTED] > Subject: Re: eap_identity or username attribute? > > > Lars, > > in the IEEE Std 802.1X-2001 there is the following: > > > D.3.1 User-Name > In IEEE Std 802.1X-2001, the supplicant typically > provides its > identity via an EAP-Response/Identity message. Where > available, the > supplicant identity is included in the User-Name attribute > and included > in the RADIUS Access-Request and Access-Reply messages as > specified in > IETF RFC 2865. > Alternatively, where Service-Type = Call Check, the User-Name > attribute > contains the Calling-Station-ID value, which is set to the Supplicant > MAC address. This is basically the same text as in the congdon ID. > > I think the critical point is that the rlm_eap_tls module should > > verify that the User-Name, that is used for authorization, > corresponds > > to the client certificate used for authentication. It looks like it > > doesn't do this currently. > > spontaneously, i would agree with that but we should > definitely verify > it for the case of proxying. Notably the stripping of realms could > provoke enormous problems here, don't you think? (since the realms > syntax is completely free, this includes every modification > of User-Name > whatsoever). I'm not quite sure I understand what the problem is. I would say that the rlm_eap_tls module has to check that the User-Name/EAP-Identity corresponds to the client certificate (this is a SHOULD in RFC 2716). Otherwise there is little point in authorizing at all. > additionally, the "Alternatively" part of the citation > above could > be a problem, too. I don't really think it makes sense to use EAP-TLS with Service-Type = Call Check, so I'm not sure this is a problem. > nothing to do with the topic, but since everybody is talking > about this > draft: after all it's still a draft, and perhaps it will > never become an > RFC, what do you think? > > we have to follow the 802.1X norm. and also here i have some doubts > about the proxying. I don't think there are any contradictions between Std 802.1X and the congdon ID. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: eap_identity or username attribute?
Lars, in the IEEE Std 802.1X-2001 there is the following: D.3.1 User-Name In IEEE Std 802.1X-2001, the supplicant typically provides its identity via an EAP-Response/Identity message. Where available, the supplicant identity is included in the User-Name attribute and included in the RADIUS Access-Request and Access-Reply messages as specified in IETF RFC 2865. Alternatively, where Service-Type = Call Check, the User-Name attribute contains the Calling-Station-ID value, which is set to the Supplicant MAC address. I think the critical point is that the rlm_eap_tls module should verify that the User-Name, that is used for authorization, corresponds to the client certificate used for authentication. It looks like it doesn't do this currently. spontaneously, i would agree with that but we should definitely verify it for the case of proxying. Notably the stripping of realms could provoke enormous problems here, don't you think? (since the realms syntax is completely free, this includes every modification of User-Name whatsoever). additionally, the "Alternatively" part of the citation above could be a problem, too. The congdon ID specifies that the User-Name should be the EAP identity. It would perhaps make sense to have the rlm_eap module verify that the User-Name matches the EAP identity also, although this isn't critical unless the rlm_eap_tls module matches the identity, rather than the User-Name, against the certificate. nothing to do with the topic, but since everybody is talking about this draft: after all it's still a draft, and perhaps it will never become an RFC, what do you think? we have to follow the 802.1X norm. and also here i have some doubts about the proxying. 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?
> From: Artur Hecker [mailto:[EMAIL PROTECTED]] > Sent: den 19 november 2002 16:37 > To: [EMAIL PROTECTED] > Subject: Re: eap_identity or username attribute? > > > shouldn't those two be always set to the same? i can't > remember, but i think that i read something like this in the > "Usage of RADIUS with IEEE 802.1X" recommendations once... > > try to take a look. > > > James Xie wrote: > > HI, > > I am debuging EAP-TLS module. Who can tell me FreeRadius should use > > which value(eap_identity and username attribute of radius > packet) to > > authorize the supplicant? Now I am using rlm_sql module to > authorize > > the supplicant. Must I set username in database to eap_identity? If > > not, is there a safe hole? Thanks! I think the critical point is that the rlm_eap_tls module should verify that the User-Name, that is used for authorization, corresponds to the client certificate used for authentication. It looks like it doesn't do this currently. The congdon ID specifies that the User-Name should be the EAP identity. It would perhaps make sense to have the rlm_eap module verify that the User-Name matches the EAP identity also, although this isn't critical unless the rlm_eap_tls module matches the identity, rather than the User-Name, against the certificate. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: eap_identity or username attribute?
shouldn't those two be always set to the same? i can't remember, but i think that i read something like this in the "Usage of RADIUS with IEEE 802.1X" recommendations once... try to take a look. James Xie wrote: > HI, > I am debuging EAP-TLS module. Who can tell me FreeRadius should use which >value(eap_identity and username attribute of radius packet) to authorize the >supplicant? Now I am > using rlm_sql module to authorize the supplicant. Must I set username in database to >eap_identity? If not, is there a safe hole? Thanks! -- 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
eap_identity or username attribute?
HI, I am debuging EAP-TLS module. Who can tell me FreeRadius should use which value(eap_identity and username attribute of radius packet) to authorize the supplicant? Now I am using rlm_sql module to authorize the supplicant. Must I set username in database to eap_identity? If not, is there a safe hole? Thanks! â²Ø§~ì¹» ®&Þþéì¹» ®&ÞI硶Úÿ 0~·§bºÊ+ùb²ßî±êìÙ¥
