Path: utzoo!attcan!uunet!ginosko!ctrsol!cica!tut.cis.ohio-state.edu!ucbvax!agate!shelby!ATHENA.MIT.EDU!jtkohl
From: jtkohl@ATHENA.MIT.EDU (John T Kohl)
Newsgroups: comp.protocols.kerberos
Subject: Proposal for long-lived revocable tickets.
Message-ID: <8907051758.AA00754@LYCUS.MIT.EDU>
Date: 5 Jul 89 17:58:42 GMT
Sender: daemon@shelby.Stanford.EDU
Organization: The Internet
Lines: 113

Following is a proposal which I'd like to get comments on before
inclusion in the draft Kerberos V5 protocol specification.
The basic idea here was first proposed by Ted Anderson (CMU ITC).

The problem:  long-lived tickets are sometimes desired (e.g. to allow a
long-running computation to utilize Kerberos-mediated services), but the
exposure to stolen credentials (ticket + session key) is greatly
increased by increasing the lifetime of a ticket.

What we think people want is a way to allow long-lived tickets with a
(limited) form of revocability [Current tickets are not revocable,
they just expire].

Here's a way to achieve that which adds only a little state to the KDC
(in the form of a hot-list, described below).

Each ticket will include 4 timestamps:
"auth" time at which the initial password/key based authentication occurred
"from" time after which it can be valid
"till" time after which it can never be valid
"life" delta (a 'local' lifetime), where "life" < "till" - "from"

t(now) means the current time.

If (t(now) > "from") and (t(now) < "from" + "life"), then the ticket may be
valid, subject to the other normal restrictions (i.e. it hasn't expired).

Presenting a valid, renewable ticket (i.e. a RENEWABLE flag is set in
the ticket) to the KDC along with a request to extend the life results
in the server issuing a replacement with "from" (and possibly "life")
adjusted such that the ticket is valid for the minimum of "till"-"from"
and "life" time units from t(now), UNLESS the "auth" time of the ticket
is rejected by the "hot list" (see below).

How this is used for long-life tickets:

1) The client needing a long life ticket requests a renewable long-life
ticket.  The KDC returns a ticket with "from" & "till" set as requested,
but "life" set to some site-configured value (e.g. 8 hours).

2) The client remembers the "life" value.

3) The client presents this ticket to the server.

4) If the server is of the sort which refuses continued access after the
expiration of a ticket, then the client needs to present the ticket to
the KDC and request a lifetime extension before "life" expires.
The returned ticket is used to replace the old ticket; the new ticket is
presented to the server, and the Kerberos-mediated service transaction
continues on its merry way.

If the server doesn't want to expire access granted by use of a
now-expired ticket, nothing more need be done. (e.g. current MIT
implementations of TCP-based Kerberos mediated services)

The "hot list":

The "hot list" is maintained on one (or more) of a realm's KDC.  It
contains a short list of information which can be used to revoke a
renewable long-lived ticket.

The hot list needs to correlate "auth" times with tickets which are to
be revoked.  [The user whose tickets have been stolen may need to contact an
administrator to put his stolen tickets on this list].

When the KDC receives a lifetime-extension request, it verifies
that the ticket presented is not on the hot list.  If the ticket is on
the hot list, it logs the attempt, and rejects the request.

Notes:
1) an entry in the hot list need only be maintained in that list until
the maximum site "life" has passed.  After this point, any hot-listed
ticket will no longer be valid for obtaining a replacement, as it will
have expired.

2) The hot list should be short and easy to maintain.  Some possible
ways to store info:
	a) put all tickets from user.inst@realm for service svc.inst
		(perhaps from a given host?) issued before some specified
		time on the list.
		e.g. all tickets for testuser@FOO.EDU to use rcmd.atalanta
		issued before 01-Jan-2001 are revoked.
	   -This has the disadvantage of rendering invalid any other valid
	   tickets for that service currently held by the user (but the
	   user can reauthenticate manually).
	   -It needs the fields <principal,service,time,[host]>
	   -If an entire ticket cache were stolen, this could lead to a
	   large number of entries per theft.  An alternative would be
	   to allow wildcards for the service name (e.g. invalidate all
	   tickets from that user, rather than just the named tickets)

	b) put tickets from user.inst@realm authenticated at a specified time
		on the list.
		e.g. all tickets for testuser@FOO.EDU to use rcmd.atalanta
		issued at 08:30:43 01-Jan-2001 are revoked.
	   -This renders invalid only the stolen ticket, but the
	   user may still want to use it [tough luck].
	   -The hot list needs to store <principal,svc,time>
	   -The user may not be able to determine the correct value for <time>
           if the ticket cache were removed upon theft.  [An
	   administrator could intervene and check ticket issue logs, though.]

Possible problems:

Depending on the site-chosen value for the standard 'life', the KDC
could start fielding many more requests that currently required
(assuming that a site might wish to make this lifetime short, and by
policy issue all tickets with the renewal requirement, to reduce the
exposure to things like rebooted machines having readily available
credentials).

The hot-list probably needs duplication, and since it can change often,
this may be opening a database can of worms.