hi
right, the EAP/Identity and User-Name must be the same, that's the job of the client, and we could thus verify only one, completely ignoring the other. however, the rlm_eap_tls currently authentifies the _certified_ name, which does not have to match either of the both... the bug i mentioned refers to the missing comparison of one of the both (from here on i will use the term "User-Name") to the certified name (CN in the certificate). as i already explained twice on this list, the problem is that the both do not HAVE to be strictly string-equal: e.g. in the case of proxying the User-Name is likely to have a suffix which the CN of the certificate is very unlikely to have in practice. thus, as i proposed before, there should be a definable equivalence (e.g. in the tls-module options) or even better a regular expression (or an external handler) which specifies exactly when the both can be considered equal. ciao artur Alan DeKok wrote: > > Artur Hecker <[EMAIL PROTECTED]> wrote: > > that's right, you don't. eap module will authentify independently. it > > can be seen as a bug, since the authentication is not very consistent. > > everything else in the server - e.g. the accounting - is based on the > > user-name... > > Further, the RFC's say that if an EAP client has a user name, it > MUST include that in the EAP-Identity, and also in the User-Name of a > RADIUS packet. > > The latest CVS snapshot is a little more forgiving, in that it > allows *SOME* EAP authentication types without a User-Name. > > Alan DeKok. > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Artur Hecker artur[at]hecker.info - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
