Re: The usability of service ticket lifetimes

On Tue, 2012-08-21 at 13:21 -0400, Jeffrey Altman wrote:

> The purpose of the endtime being shorter than the renew_till time is to
> force the client to contact the Ticket Granting Service within the
> required "lifetime" to permit the TGS to block continued use of the
> tickets in case one of the principals has been deactivated.

No, that's not the only purpose.  It also gives operational control
over the maximum time before a policy change has fully gone into
effect.  Such policies may affect the issuing and/or renewing of both
TGTs and service tickets, and may not be as simple as a particular
client principal being enabled or not.  For example, I may need an
upper bound on when an enctype policy change has become fully
effective, or a policy change relating to authorization data included
in issued tickets.

As an operator, I'd be nervous about replacing a relatively simple,
easily-understood rule (a policy change is in effect by the time any
TGT issued prior to it has expired) with one involving complex
interactions between all of the services a user might have used.


> The fact that the client has to contact the TGS in order to obtain a
> service ticket provides the opportunity to validate the state of the
> principal's accounts.

Not when the principal is from another realm.


> Especially,
> when the TGT is renewable and the service ticket is renewable.

But these conditions do not always obtain, and a KDC processing a
service ticket renewal does not have the TGT to examine.  In fact, the
client may not have the TGT to renew.


> In that
> situation, the service ticket should be issued with the maximum
> permitted lifetime constrained as specified in 3.3.3 except that the
> TGT's overall lifetime should be used in place of the TGT's endtime.  In
> order words, if the TGT was granted with a 10 hour lifetime, then the
> service ticket should be granted with up to a 10 hour lifetime unless
> otherwise constrained.
 
I am very nervous about this from a security standpoint.  We've had
issues before with such sliding lifetimes, some of which have resulted
in a client being able to extend ticket life indefinitely.

Furthermore, this violates the expectations of _users_ who, when they
are aware of expiration at all, expect it to happen a fixed amount of
time after they log in or otherwise obtain tickets, rather than based on
when they first talked to a particular service on a particular day.





> Such an approach can be viewed as an implied TGT renewal since the TGT
> itself could have been renewed.

This presumes that the client has the TGT, that it is renewable, and
that renewal would have succeeded.  A KDC processing a service ticket
renewal is not in a position to know these things.


-- Jeff

_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg