how to "ban" clients?

[greg@enjellic.com]

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,  <ghudson at mit.edu> 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: greg at enjellic.com
------------------------------------------------------------------------------
"If you care, you just get disappointed all the time. If you don't care
 nothing matters so you are never upset."
                                -- Calvin