> 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

Reply via email to