Your solution is not very useful in situations where the username must remain the same due to outside account status checking. Why should I force the user to change his username? What about situations where changing the username is *not* an option. For instance, say we check the CN against the username in an LDAP database to make sure the user has not been disable for some reason. And yes, I have actually patched my FR server to make sure the UserName attribute matches the CN in the cert. I can make this patch available to anyone who wants it, but I'd like to change how its done before submitting a full blown server patch. In this case though, changing the username would be the *harder* option, and impossible in many cases as our usernames are tied to a LOT of other information.
Certificate revokation *is* the real answer in this case. It allows me to keep the affected laptop from gaining access to the network while allowing the true user to regain access *with the same username*. As to which "online validity control" to use, RADIUS should (and does) make use of all available information to decide whether or not to allow a user, including whether or not a user is valid, is who he says he is, and the certificate he's attempting to use is valid or not. --Mike On Thu, 2003-10-16 at 08:54, Artur Hecker wrote: > i don't think so. well, the final answer depends on your configuration > and your PKI usage. but, if you are using your PKI basically only for > 802.1X access control, it would be a madness to deploy CRL control > because it will demand some kind of online-certificate control at the > connection time. > > why bother? you already have an online access control at the connection > time - this IS radius. so, don't bother, forget the certificate and > block the user in the radius configuration. this doesn't demand ANY > effort from your part: change the user configuration to be an explicit > REJECT and let him in your config file till his certificate expires. > > in terms of complexity it's a better solution. what's the difference > which protocol you use for the online validity control - that of the CRL > or radius? > > you should only be aware of one thing: for the moment there is a > security flaw in freeradius: it is possible to use an arbitrary UserName > along with _some_ valid certificate. however, it shouldn't be difficult > to add an additional check: the UserName should be equal to the CN in > the certificate. > > > ciao > artur > > > Michael Griego wrote: > > > What you SHOULD do is consider the private key compromised and revoke > > the certificate. A patch was added a while back to incorporate CRL > > checking in the EAP-TLS module. This is really more of a PKI issue. > > > > --Mike > > > > > > > > On Thu, 2003-10-16 at 08:54, arniel wrote: > > > >>hi guys, > >> > >>I am implementing Free Radius EAP-TLS on my network, all my wireless > >>clients are issued with a certificate. What I am trying to do is to block a > >>particular wireless client from accessing my network even if the certificate > >>is still valid or has not expired. This is in anticipation if the lap top > >>has been stolen. > >> > >>Is there something that I can do on my Free Radius Server in blocking the > >>wireless client w/o hampering other users who are using the wireless > >>network? > >> > >>I tried deleting the clients name at the raddb/users file, but to no avail. > >>I also tried deleting the clients certificate /etc/keys/client.p12 still to > >>no avail. > >> > >> > >>Thanks in advance... > >> > >> > >>arniel > >> > >> > >> > >> > >> > >> > >>- > >>List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- --Mike ----------------------------------- Michael Griego Wireless LAN Project Manager The University of Texas at Dallas - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
