Path: utzoo!attcan!uunet!lll-winken!ames!apple!agate!shelby!ATHENA.MIT.EDU!wesommer
From: wesommer@ATHENA.MIT.EDU (Bill Sommerfeld)
Newsgroups: comp.protocols.kerberos
Subject: Re: Proposal for long-lived revocable tickets.
Message-ID: <8907211652.AA09171@RA.MIT.EDU>
Date: 21 Jul 89 16:52:26 GMT
References: <8907211628.AA19301@VULCAN.MIT.EDU>
Sender: daemon@shelby.Stanford.EDU
Organization: The Internet
Lines: 35


   Date: Fri, 21 Jul 89 12:28:44 -0400
   From: Mark Lillibridge <chariot@ATHENA.MIT.EDU>
   Reply-To: chariot@ATHENA.MIT.EDU
   Address: EC Bemis 515, 3 Ames Street, Cambridge, MA 02139
   Phone: (617) 225-6554

   Comments on John's proposal:

	   (1) Note that under the proposed system, old renewable tickets
   which have expired but have a 'successor' which has not expired must be
   kept secret.  

Wrong; the ticket itself never has to be kept secret, and it is sent
over the wire "in the clear"; only the associated session key must be kept secret.

		   - I would recommend that whenever a TGT with a lifetime
   greater than say 7 days is requested, a mail notice be sent to the
   principal of the ticket if it is a user telling that a TGT has been
   requested for X time on host X and giving explicit instructions on how
   to revoke it.  

This is an implementation issue, and assumes that there is a sensible
mapping from  kerberos names to mail names.

When renewing a ticket, or using a ticket-granting-ticket, if the
client identity is from the local realm, does the KDC have to check
that the user in question still exists in the realm's database?

If so, then some forms of revocation short of a hotlist are possible;
however, if the kerberos database is replicated, but not strongly
consistent, I can imagine a number of unusual failure modes going on
for users which have just been added to the database.

					- Bill