Hmm, I shouldn't have replied to an old thread, maybe too many people sort their mail on threads (like I do) ;-)
I have not used FreeRadius for a while just because there is no support yet for EAP-TTLS and because of the earlier mentioned "security hole" in the TLS implementation.
Someone suggested in the past that there should be some option (in my opinion it really should be enabled by default) to verify if the identity in the EAP-Identity response is the same as the one used in the certificate that was signed. I don't know if this option is there already: I think it will make the TLS implementation better/safer (now you can fake an identity, even for accounting and so on). I hope this option made it to the code yet, but I haven't seen any comments on this issue after this mail (or I just missed it :-)) And I couldn't find it with a quick look at the CVS-code.
Is it available yet?
Regards, Paul
Artur Hecker wrote:
hi
this has been discussed on the list a long time ago. please take a look at the archives.
"Ian Pritchard" <[EMAIL PROTECTED]> wrote:
If I understand the implications correctly, then this means as long as
I'm
able to present *a* valid certificate I can authenticate with any name.
Not really. The RADIUS packet still contains a User-Name attribute,
which the server uses to perform it's authentication. If that
User-Name is for an unknown user, then the request SHOULD be rejected.
well, be carefull with that: there is no security in the content of the user-name attribute. it contains exactly the EAP-Response/Identity data (which is mapped into User-Name by the AP). however, there is NO authentication in the EAP-Response/Identity, so anybody can forge such a packet (malicious user, rogue AP, ...) so presenting a valid user-name is not difficult.
e.g. in Windows XP you can check the box "authenticate as another user" and choose both a different certificate AND the content of EAP-Response/Identity (which don't have to match in any way) i.e. Ian is completely correct with his assumption: *a* valid certificate is ok for eap_tls right now.
basically, as we discussed this a while ago, we've seen that there are three possible identifications which the server sees: - User-Name - EAP-Identity (available in the first EAP message) - certified name out of the presented certificate
EAP-Identity should be equal to User-Name (that's the task of the AP), however the only thing we can be sure about is the certified identity. so, eap_tls should prove that the certified name is equal to User-Name (the most functions of freeradius are based upon User-Name). however, perhaps we should be able to strip the realm part before matching, that depends on exact security requirements (consider e.g. user roaming: the certificate could certify user's real-life name only, without any realm part in it. however, proxying has to be done if the certificate can't be verified locally, which could be included in the EAP-Identity, i.e. User-Name - so User-Name and certified name wouldn't match thus resulting in a wrong Reject). briefly, he have to clarify how "equal" is defined in this context or allow to configure an equality function.
and: Alan is right, it only concerns rlm_eap_tls.
ciao artur
Right, but if for some reason the other user is known, but has been
temporarily suspended or is only allow to authenticate from certain
locations then the first user should be able to authenticate successfully.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
