[19363] in Kerberos
k[dc]destroy; Was: Apps aquiring tickets
daemon@ATHENA.MIT.EDU (Buck Huppmann)
Wed Jun 4 00:52:25 2003
Date: Wed, 4 Jun 2003 00:51:26 -0400
From: Buck Huppmann <buckh@pobox.com>
To: Sam Hartman <hartmans@mit.edu>
Message-ID: <20030604045126.GB16447@dsl092-163-146.wdc1.dsl.speakeasy.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <tslr87a900y.fsf@mit.edu>
cc: kerberos@mit.edu
Errors-To: kerberos-bounces@mit.edu
On Wed, May 07, 2003 at 12:47:25PM -0400, Sam Hartman wrote:
> >>>>> "Greg" == Greg Wettstein <greg@wind.enjellic.com> writes:
>
> Greg> Of course that begs the security question of why time
> Greg> limited credentials are even implemented.
>
> So that you have a single point at which to hotlist credentials.
this raises a question in my mind, which may be something i should
be able to figure out as an aspiring Competent Kerberos User but
which i can't: why isn't there (aside from the obvious pain of im-
plementation) a TGS-REQ to destroy tickets (something like a reg-
ular TGS req, but with maybe the TGT being replaced by the ticket
you want ``destroyed'' [unless it *is* the TGT] and the authentica-
tor generated using the session key from the ticket)? then the KDC
would refuse to issue tickets based on a ``destroyed'' TGT or to
renew ``destroyed'' tickets. (i.e., they'd be hotlisted.) and may-
be any other tickets that were issued on the basis (TGT or renew-
al[1]) of any such ``destroyed'' tickets would then be blacklisted
also. (sorry about all the quotes, but although ``invalidated''
would have been a more natural term and ``voided'' etc. would be
next best alternatives, ``destroyed'' is strongly suggested by
``kdestroy'', being a salient method whereby destruction/voiding
would occur)
again, i haven't really done my homework here so maybe there's
something truly obvious i'm missing, but the objections i imagine
are (besides it being a lot of trouble and requiring more resources
of the KDC) that (a) the hotlist mechanism should take care of any
tickets that are stolen, which assumes that people will figure out
that their tickets have been stolen, and that (b) people don't de-
stroy their tickets reliably enough for it to be useful, which ne-
glects stuff like PAM session service modules and stuff, and that
(c) tickets don't get stolen, which, with everybody from Microsoft
to Sun and beyond getting integrally into the Kerberos act, assumes
the last few decades, security-wise, hadn't happened and that the
stakes aren't getting higher
but, again, maybe i'm just spouting off; apologies, and please clue
me in if so
--buck
[1] whether forwarded or proxied tickets would be renewable or usa-
ble is a sticky wicket
>
> There are other benefits as well, but this is a significant one.
>
> ________________________________________________
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
