hi mike
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.
well, i suppose it's a question of a point of view. for me, the real identity is always the certified one. the user name is only a pseudo for it, since it doesn't have a proof.
if you rely so much on the username, you should not only block the certificate but also create a new user and block the old one everywhere: that user is very likely to store passwords and stuff on a stolen laptop. well, it depends.
however, this has nothing to do with CRLs and so on. the patch you are talking about: just change it to check if the CN is REJECTed and not the username, then you can use your username unchanged. still you won't need a CRL repository.
what i don't want are the problems around CRLs and CRL checking. and i don't see why radius shouldn't do what it was designed for: online user access control.
the people dealing with the CRLs spend monthes trying to resolve the problem with invalid identities, realize that they can't possible achieve anything without online checking and end up by producing a new online certificate check protocol... thanks, i can do that with radius since years, except that i don't need new software, i don't need to change every client and every server, i don't need a new always-up server and so on.
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*.
:-) well, for me certificate revocation is not an answer to anything, it's more a challenge. and, it is one of the reasons why PKIs still hardly exist. there are a LOT of unanswered problems in the CRL area, one of which is the online validation protocol: neither of those is standardized so far, so they basically don't exist. steady CRLs aren't a general option (i can explain you why, but it's out of scope for this list). as soon as we have a standardized protocol (if ever), we will be able to use it and in case of radius we will face the following: at the connection time the user will be verified by radius, then radius will verify the certificate, asking online the CRL server. so, you depend on at least two machines that have to be running all the time and you use two different protocols and you have two different user databases, one with the usernames, the other with certificates... CRL aware software hardly exists... pppffffffff... to be brief: you will keep two infrastructures up and running: AAA and PK.
in my proposition the AAA infrastructure is the only one to be up - but in this case it _is_ anyway (for 802.1X). the PK is basically reduced to (RA/VA and) CA and it doesn't have to be online.
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.
i don't think we understood each other here... i was trying to compare the online certificate check protocols with RADIUS: i know, it's a little bit far, but if you take an abstract look on what is happening - the idea is the same.
anyway mike, it's more a point of view than a discussion base, so... i would completely agree that it depends on the network and on its PKI usage (that's what i tried to mention in my previous mail).
regards artur
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
