[2736] in Kerberos
Re: The renewable-tickets feature
daemon@ATHENA.MIT.EDU (Shyh-Wei Luan)
Tue Jun 29 14:51:41 1993
Date: Tue, 29 Jun 1993 14:28:46 -0400
From: Shyh-Wei Luan <luan@eng.umd.edu>
To: jtkohl@zk3.dec.com
Cc: bcn@ISI.EDU, kerberos@MIT.EDU, luan@eng.umd.edu
> From jtkohl@zk3.dec.com Tue Jun 29 08:42:29 1993
>
> > Date: Mon, 28 Jun 1993 16:27:35 -0400
> > From: Shyh-Wei Luan <luan@eng.umd.edu>
>
> [...]
> > Observations:
>
> > Assume ticket thefts are always reported and stolen tickets (their authtime
> > values and client-principal identities) are included in the TGS's hot-list.
>
> [...]
> > (2) If an application ticket is stolen, renewable tickets with a
> > shorter lifetime would further limit the damage caused by the theft. However
> > the same goal can be achieved simply by always requesting shorter-lived
> > application tickets, and get new ones when the old ones expire. The renewal
> > mechanism does not seem to be necessary for limiting the use of stolen
> > application tickets.
>
> ... unless you do not have a TGT. If I am going to use long-lived
> tickets in some variety of batch application, I would not entrust it
> with a TGT. I would only give it the application ticket, and let it
> renew that ticket.
>
> John Kohl
>
Thanks for the response. Yes, it seems to be a reasonable pre-caution
to hide TGT's from some applications, or to purge TGT's before leaving a
workstation with a batch application running. Probably Section 2.3 should
at least add this to explain that using short-lived non-renewable application
tickets is not an option in these cases.
A different, but related question: There seems to be a
problem/bug in the TGS's renew-period setting logic.
TGS logic:
Upon a new ticket request at TGS, if the requested lifetime (req.till)
of the new ticket exceeds the expiration time (tgt.endtime) of the TGT, the
new ticket's expiration time will be set to the same as the TGT's expiration
time. In addition, if the RENEWABLE flag is set in the TGT and the
RENEWABLE-OK option is set in the request, the RENEWABLE flag in the new
ticket will be set and the new ticket could be renewed till the end of the
renewable lifetime (tgt.renew-till) of the TGT.
Upon a request for a renewal at TGS, the renewed (new) ticket will have
the SAME lifetime as that of the old ticket. That is, the period of renewal
is fixed to the lifetime length of the original ticket.
The problem:
If a ticket request at TGS is made when the TGT is about to expire,
then the lifetime of the ticket generated will be very short. If the
new ticket is renewable and used by a long-running batch application, then
the ticket renewals could be too frequent and too many to be reasonable.
Solutions?
A quick, ad-hoc, but probably wrong solution: TGS sets
new_tkt.endtime = req.till (subjected to other limits, of course)
if tgt.renew_till >= req.till.
A more general solution appears to be adding a "renew-period" field in
TGS request and tickets, although it means message-format changes. A new
field, say, rperiod[?] (in seconds) would be an INTEGER OPTIONAL field in
KDC-REQ-BODY, and could be present when RENEWABLE-OK or RENEWABLE option is
set. With this new field, a client could specify the ticket-renewal period
when requesting for a new ticket, and the renewal period would not have to be
the same as the lifetime of the original ticket. This optional field would
also be in EncTicketPart. If the "rperiod" is set in a ticket that is being
renewed, the TGS sets the lifetime of a renewed ticket to be the "rperiod" value
(subjected to other limits).
Comments?
Shyh-Wei Luan
