Path: utzoo!attcan!uunet!cs.utexas.edu!sun-barr!apple!agate!shelby!ATHENA.MIT.EDU!chariot
From: chariot@ATHENA.MIT.EDU (Mark Lillibridge)
Newsgroups: comp.protocols.kerberos
Subject: Proposal for long-lived revocable tickets.
Message-ID: <8907211628.AA19301@VULCAN.MIT.EDU>
Date: 21 Jul 89 16:28:44 GMT
References: <8907051758.AA00754@LYCUS.MIT.EDU>
Sender: daemon@shelby.Stanford.EDU
Reply-To: chariot@athena.mit.edu
Organization: The Internet
Lines: 50


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.  (By 'successors', I mean the series of tickets which
resulted from renewing again and again the original ticket) This is
because if I know the session key for the old ticket & have watched its
successors being obtained, I can figure out the session key for all of
the old ticket's successors, including the one currently in use.  Thus,
even if I stole a renewable ticket more than the site's maximum lifetime
ago, I may still be able to use it.

	(2) I see no reason to keep unrenewable tickets at all.  Since
user's have no control over a site's maximum lifetime, they have no
choice but to always ask for renewable tickets if they want a minimum
(renewable) lifetime.  This would remove the need for a RENEWABLE flag &
simplify the code.

	(3) Limits on what kinds of tickets could be acquired were not
mentioned in the proposal but I would like to propose the following:

		- TGT's can be acquired with any from and till values
given only that from<till.  The actual lifetime of the TGT is the
minimum of the requested value and the site minimum.  Note that some
sites may want to have a smaller minimum lifetime for TGT's than normal
tickets.

		- Normal tickets can be requested using a TGT with from
time f and till time t only with from values >=f and till values <= t.
I.e., no ticket can be obtained from a TGT which gives authentication
beyond the authentication interval of the TGT.  Lifetime is treated as
for TGT although possibly with a different site lifetime minimum.

		- 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 would protect against someone getting a very long
lived ticket while you are momentarily away from your workstation and
using it to wreck havoc later on.

	(4) Note that if the hotlist is kept on only one KDC and the net
becomes partitioned, splitting a slave KDC off from the KDC with the
hotlist, that slave KDC is no longer able to renew tickets.  As this is
a major loss of functionality, esp. if all tickets are renewable, I
believe copies of the hotlist should be maintained on all KDC's.

						- Mark Lillibridge
						  MIT Project Athena