preserve original starttime on renewed TGTs

[Nicolas Williams]

On Fri, Nov 19, 2010 at 01:21:34PM -0800, Frank Cusack wrote:
> This change would violate RFC 4120 par 3.3.3:
> 
>   If the new ticket is to be a renewal, then the endtime above is
>   replaced by ... the starttime for the new ticket plus the life
>   (endtime-starttime) of the old ticket.
> 
> That is, the endtime would no longer be the starttime of the new
> ticket plus the life of the old ticket.
> 
> But I don't see how it'd be a problem in practice.  Note that the new
> ticket would still have the correct lifetime.

Clients could be checking that the KDC is doing what the RFC says, so, I
don't think that'd be OK.  However, the KDC could lie in the
EncKDCRepPart and put the original starttime in the actual Ticket.  I
might not mind that, but:

> Further renewals (ie, of the renewed ticket) would again violate this
> section in that the KDC would not know the original ticket's lifetime
> (it's no longer preserved in the renewed TGT presented to the KDC), so
> it'd have to choose the lifetime based on the configured maximum
> ticket lifetime.  For most uses, where people/applications don't request
> renewable tickets with shorter than maximum lifetimes, I submit that
> this is not a problem.

This could be a problem.  I'm not sure yet.  I suppose the KDC can
always include a KDC-ISSUED authorization-data element documenting the
original ticket lifetime.

But...  what's the motivation?  Slow clocks on servers?

Nico
--