[769] in Kerberos
Proposal for long-lived revocable tickets.
daemon@TELECOM.MIT.EDU (Mark Lillibridge)
Mon Jul 24 14:11:06 1989
From: Mark Lillibridge <chariot@ATHENA.MIT.EDU>
To: bcn@june.cs.washington.edu
Cc: Kerberos@ATHENA.MIT.EDU, krb-protocol@ATHENA.MIT.EDU
In-Reply-To: Clifford Neuman's message of Fri, 21 Jul 89 11:21:58 PDT <8907211821.AA20578@june.cs.washington.edu>
Reply-To: chariot@ATHENA.MIT.EDU
> Date: Fri, 21 Jul 89 11:21:58 PDT
> From: bcn@june.cs.washington.edu (Clifford Neuman)
>
> ...
>
> 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.
>
> ...
>
> 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.
This proposal is almost identical to the previous one. To see
this, make the following substitutions:
renew_till -> till
starttime -> from
endtime - starttime -> life
authtime -> auth
I.e., instead of storing the lifetime of the ticket, we are storing
from+life. This is not a very major change.
The logic to calculate the new lifetime is different though.
The inclusion of starttime(new)+life in the MIN function in the
assignment to endtime(new) causes all successor tickets to have a
lifetime at most that of their precessor tickets. This is a good
feature because it means that when I get a long ticket I can ensure that
I can revoke it in a chosen amount of time. Note that I would add the
site_maximum lifetime (if any) to that MIN function.
> 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.
The reasoning for making all tickets renewable is as follows.
Suppose I wish to request a 10 hour ticket. Now, if I ask for a
non-renewable ticket I may get one good for only 8 hours. (Due to the
site maximum lifetime...) Thus, in order to be guarenteed one for 10
hours, I must ask for a renewable ticket. (this is assuming I don't
want to waste an extra trip trying for a non-renewable ticket)
Given this, why would I ever ask for a non-renewable ticket?
(i.e., what is a non-renewable ticket better at than a renewable
ticket?) Likewise, since all applications must be able to deal both
with renewable & non-renewable tickets, there is no cost for asking just
for renewable tickets. (They must deal with both because I the user
may obtain a long lived ticket for them then destroy my TGT) Thus, by
this reasoning, non-renewable tickets are useless & should be discarded.
Note that non-TGT tickets are exactly the ones most in need of
renewal. This is because they are the ones needed by a batch job.
(I have no intention of leaving a TGT around for a batch job to use...)
> 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.
The operative word here is "can". If you can request arbitary
from and renew_till fields, we have lost a lot of security. Consider
for instance if I temporily get a copy of your 8 hour TGT. I now
request 8 hour tickets forward dated for 8 hours of each day for the
next year. Now, I can act as you for the entire next year. No longer
is the effects of stealing a ticket limited to the lifetime of that
ticket. Similar examples exist with infinite lifetimes from finite
lifetime TGT's.
In order to prevent serious problems like these, we need a
minimum set of restrictions on possible from, till, lifetime fields. My
proposal was a first cut at these. I have noticed at least one problem
with it so far. This is the fact that we can not premit arbitary from
fields. This is due to the need to change kerberos master keys every so
often. This also implies that all sites must have a maximum lifetime if
they ever intend to change their kerberos master key.
- Mark Lillibridge
MIT Project Athena
