The usability of service ticket lifetimes

RFC 4120 Section 3.3.3
<https://tools.ietf.org/html/rfc4120#section-3.3.3> "Generation of the
KRB_TGS_REP Message" specifies that the "expiration time" (aka
"endtime") as follows:

   If the request specifies an endtime, then the endtime of the new
   ticket is set to the minimum of (a) that request, (b) the endtime
   from the TGT, and (c) the starttime of the TGT plus the minimum of
   the maximum life for the application server and the maximum life for
   the local realm (the maximum life for the requesting principal was
   already applied when the TGT was issued).  If the new ticket is to be
   a renewal, then the endtime above is replaced by the minimum of (a)
   the value of the renew_till field of the ticket and (b) the starttime
   for the new ticket plus the life (endtime-starttime) of the old
   ticket.

In other words, the endtime of the issued service ticket MUST be
constrained to a lifetime that is no longer than that of the initial
TGT.  In practice, I find this constraint to be overly restrictive when
the KDC policy permits the issuance of a renewable service ticket with a
renew_till time greater than the endtime.

If the policy of the KDC permits a 10 hour lifetime for the service
ticket and a 1 week renew-lifetime but the renewable TGT has 5 minutes
before its endtime is reached, the endtime of the service ticket will
have 5 minutes remaining and a renew_till time matching that of the TGT.

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.

The issuance of service tickets with very short lifetimes can present
significant challenges to end users and processes that must maintain an
up to date service ticket for authentication.  Especially when the
application protocol constrains the lifetime of the authenticated
connection to the lifetime of the service ticket.

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.  As such the lifetime of the issued service ticket
should not be constrained to that of the TGT's endtime.  Especially,
when the TGT is renewable and the service ticket is renewable.  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.

Such an approach can be viewed as an implied TGT renewal since the TGT
itself could have been renewed.  I do not want to see client
applications put in the position where they need to regularly renew the
TGT in order to obtain a service ticket with a maximum lifetime. In
theory, upon receiving a renewable service ticket with a less than
maximum lifetime, the client could issue a TGS RENEW request on that
service ticket.  Since that would be permitted by RFC 4120 there is no
reason to not issue the longer lifetime in the first place.

As part of any revision to RFC 4120, I would like to see this section
modified.

Jeffrey Altman

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJQM8OQAAoJENxm1CNJffh49QYH/0DhRnLbVAi8GYkKKIJ1U7A2
UhRUIAkGYuHWbXXCUiF/C4uWmED/jiA8v9gL540BDunZjRMedJym42ZgqOPjaPlo
FhSEao1BR6znQfTWLATQAY0uKlbmeErBoNJH/iOO6AGs8Nr5jEPkcTgumDQP511w
FcEp5Q8TOri4FZrkIAalE39abBh+vWn7kSZh6GpaposK69AedUz4dh4Qzqrh+Ojd
DzLXCKPkaZ+e27bRKOH6XyN9SSFsoqGohNJVDBIHpbr6i56xrxe8xEcgVlesY+or
K4Ksd3KWj5sgP0WYWOSMzpZ04a6V2hF4qsvGYYqle5EmphkdTBIwjUCdKiNW9hM=
=qe5p
-----END PGP SIGNATURE-----