[590] in Kerberos
Re: extended ticket lifetimes
daemon@TELECOM.MIT.EDU (Jennifer Steiner)
Tue Jan 10 17:51:51 1989
To: John T Kohl <jtkohl@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Your message of Tue, 10 Jan 89 16:29:16 -0500.
From: Jennifer Steiner <steiner@ATHENA.MIT.EDU>
> Is it an acceptable option to allow each site to decide whether to
> support the proposed extended ticket lifetimes?
Not unless the lifetime-interpretation can be determined
by looking at the ticket.
Allowing different interpretations of the ticket lifetime
in different realms basically means there is no inter-realm
operability. The ticket lifetime must mean the same thing
in interoperating realms because it is computed based on
lifetimes spanning two realms: the client's and the server's.
If they aren't compatible, the ticket lifetime is meaningless.
The ticket lifetime is based on the minimum of 1) the lifetime
requested by the client 2) the maximum ticket lifetime allowed
for the client and 3) the maximum ticket lifetime allowed for
the server. If the request is through a ticket-granting server,
then the expiration time of the ticket-granting ticket is an additional
upper bound. If the client is in Realm A and its maximum lifetime
is in different units than the server's maximum lifetime, which
is in Realm B, then there's no way to compute the ticket lifetime
sensibly.
A solution would be to indicate what lifetime-scheme
was being used, which might not be a bad idea since several
different lifetime-interpretation schemes have been
proposed*, which implies there will be more.
Another approach would be to have a {start-valid-time,
end-valid-time} pair, in place of the current {start-valid-time,
lifetime} pair. It allows expression of all the requirements for
ticket lifetime I have heard so far. (But it's not as extensible
as a scheme indicating what lifetime-interpretation is being used.
For example, what if I want a ticket that's valid every third
Tuesday of the month from 2-3 am? )
Jennifer
* 1. The current scheme: an issue date and a lifetime of 1-255
units of 5 minutes each.
2. Same as (1) only with a larger lifetime range (2**16 instead
of 2**8).
3. Ted's scheme.
4. Postdated tickets, e.g. a {start-valid-time, end-valid-time}
pair.
