On Jul 27, 12:19pm, Nico Williams wrote: } Subject: Re: how to "ban" clients?
Hi, hope the week is going well for everyone. > On Tue, Jul 26, 2011 at 6:59 AM, <[email protected]> wrote: > > It's a reasonable desire to want to flip a switch and make a > > particular user instantly unable to affect your environment. That's > > the kind of thing you should get from a centrally managed > > authentication system, right? Â Unfortunately, there are three holes > > big enough to drive a truck through: > > > > 1. The user can keep requesting service tickets until the user's TGT > > expires. > > Right, this one can be fixed in the KDC (TGS), and should be. The > other two holes are not an excuse to not fix this one because if one > wishes to go fix all three holes one might want to start with the easy > one first. > > > 2. The user can keep using service tickets until they expire. > > Right. Nothing much can be done about this other than: a) set max > service ticket lifetimes short enough that this hole can be tolerated, > or b) implement a revocation protocol. (b) would be nice, but hard. > > > 3. The user can keep using active sessions until the session is > > invalidated somehow (interrupted connection, restarted client or > > server). > > This is the hardest problem of all. Short ticket lifetimes don't help > because expiring sessions with their tickets means re-keying or > re-connecting often and that's a pain (particularly in protocols that > don't have re-keying), and then there's local access where tickets are > completely irrelevant. > > Plugging this hole requires a revocation protocol. I don't mean > OCSP-like -- the TGS effectively is Kerberos' OCSP equivalent (or, > more correctly, OCSP is PKIX's Kerberos equivalent :). I mean a > protocol by which services participating in a realm can get notified > of principal revocation so they can act accordingly (whatever that > might be). Cross-realm relationships make a revocation protocol... > interesting. > > It'd be nice to have a standard revocation protocol for Kerberos... We have one, its called authorization.... :-) Unfortunately as an industry/community we were never able to agree on a 'standardized' way of doing this with respect to Kerberos. Actually more correctly stated we ceded the entire industry segment to Microsoft... :-)( If anyone wants to Google around a bit for the slides of a paper I presented at the AFS/KRB5 meeting at UMich a few years ago you can see what our strategy was with respect to this. The service ticket ended carried a 256 bit number in the authorization payload which represented the 'identity' of the user's service. The role of the service ticket was to transport and authenticate that service identity to the application. At that point the application has a token to use against an LDAP directory server to determine if the service should continue to be vended to the user. So in addition to the time limitation imposed by the service ticket there is the opportunity to implement much higher granularity revocation based on the 'service identity'. The whole strategy implemented inheritance rather nicely since the user's specific service identity was constructed from a compression of a bitstream consisting of the user's identity and the identity of the service. So by 'disabling' the master service identity all instances of the service would be turned off with the alternative of only disabling a particular user instance of a service. We actually treated Kerberos authentication as a service as well which was surprising with respect to how it confused people. It seemed difficult for a lot of people to understand that authentication is a service and as such should be subject to authorization constraints. Which as can be seen in the context of this thread is something which Chris as an application developer was definitely interested in accomplishing. > Nico Best wishes for a productive week. Greg }-- End of excerpt from Nico Williams As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102 development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: [email protected] ------------------------------------------------------------------------------ "If you care, you just get disappointed all the time. If you don't care nothing matters so you are never upset." -- Calvin
________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
