[763] in Kerberos
Proposal for long-lived revocable tickets.
daemon@TELECOM.MIT.EDU (Clifford Neuman)
Fri Jul 21 14:26:58 1989
From: bcn@JUNE.CS.WASHINGTON.EDU (Clifford Neuman)
To: jtkohl@ATHENA.MIT.EDU, Kerberos@ATHENA.MIT.EDU,
In-Reply-To: Mark Lillibridge's message of Fri, 21 Jul 89 12:28:44 -0400 <8907211628.AA19301@VULCAN.MIT.EDU>
Note that the message describing long-lived revocable tickets was
dated 5 July. For some reason it got stuck in a mail queue until just
a few days ago. The proposal has been revised since then. The
present plan is as follows:
We can support the features described in the original message by
simply adding a new field renew_till which only appears in renewable
tickets. A ticket can be renewed before its expiration by requesting
renewal from the KDC. The new lifetime (which is really the endtime -
the starttime) will be the minimum of the old lifetime, the requested
lifetime, and the time remaining till the renew_till field expires.
The hot list can be implemented in the same manner described in the
original message.
Here are the meanings of the variables used to describe the necessary
logic that would be implemented at the KDC.
current = time read from system clock when we started
processing this request
starttime = start time
endtime = end time
renew_till = renew_till field
authtime = time of initial authentication
life = a temporary variable
req_life = requested life from the request
(new) is the renewal, (old) is the ticket presented to the TGS
And here is the logic for generating the new values:
renew_till(new) = renew_till(old);
authtime(new) = authtime(old);
life = endtime(old) - starttime(old);
starttime(new) = current_time;
endtime(new) = MIN(starttime(new) + life, starttime(new)
+ req_life, renew_till)
The authtime would also be checked against the hot list.
Now to answer some of the questions raised in responses to the original
proposal:
We had already decided to add an authtime field. Since it is the
authtime that gets added to the hot list, all derivative tickets
(i.e. the successors that Mark describes) become invalid as well.
Just as a site can impose a maximum ticket lifetime, it can also
impose a maximum renewal lifetime. Typically, this limit would be
greater. Given this, I don't understand Mark's premise for making all
tickets renewable. As to whether we need both renewable and
non-renewable tickets, Mark has a point in that a non-renewable ticket
can be thought of as being renewable, but with a renew_till equal to
it's endtime. The majority of tickets, however, will not be renewable
(one argument is that most are for service besides the TGS). I think
explicitly making the distinction is appropriate.
As to limits on the life that may be requested, and where the checks
occur, this has already been discussed on the krb-protocol list. I
think the solution was that the KDC can set limits on the tickets it
issues, but that the end service can set more restrictive limits as
well. Additionally, the limits checked at the end service may be
based on authtime, and not just the starttime for the ticket. Thus,
an end service can refuse to accept tickets based on a renewed tgt if
the original authentication took place too long ago.
~ Cliff
