preserve original starttime on renewed TGTs
Nicolas.Williams at oracle.com
Fri Nov 19 17:13:32 EST 2010
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?
More information about the krbdev