[19364] in Kerberos
Re: k[dc]destroy; Was: Apps aquiring tickets
daemon@ATHENA.MIT.EDU (Sam Hartman)
Wed Jun 4 01:46:35 2003
To: Buck Huppmann <buckh@pobox.com>
From: Sam Hartman <hartmans@MIT.EDU>
Date: Wed, 04 Jun 2003 01:43:11 -0400
In-Reply-To: <20030604045126.GB16447@dsl092-163-146.wdc1.dsl.speakeasy.net>
(Buck Huppmann's message of "Wed, 4 Jun 2003 00:51:26 -0400")
Message-ID: <87znkyl7o0.fsf@luminous.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
cc: kerberos@mit.edu
Errors-To: kerberos-bounces@mit.edu
>>>>> "Buck" == Buck Huppmann <buckh@pobox.com> writes:
Buck> 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.
Buck> this raises a question in my mind, which may be something i
Buck> should be able to figure out as an aspiring Competent
Buck> Kerberos User but which i can't: why isn't there (aside from
Buck> the obvious pain of im- plementation) a TGS-REQ to destroy
Buck> tickets (something like a reg- ular TGS req, but with maybe
Buck> the TGT being replaced by the ticket you want ``destroyed''
Buck> [unless it *is* the TGT] and the authentica- tor generated
Buck> using the session key from the ticket)? then the KDC would
Buck> refuse to issue tickets based on a ``destroyed'' TGT or to
Buck> renew ``destroyed'' tickets. (i.e., they'd be hotlisted.)
Buck> and may- be any other tickets that were issued on the basis
Buck> (TGT or renew- al[1]) of any such ``destroyed'' tickets
I believe that features like this are needed and simply have not been
implemented.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
