Subject: service ticket vs tgt lifetimes

From: "Joel N. Weber II" <[email-masked]>
Date: Thu, 19 Jun 2003 07:42:33 -0400

In the course of revising
draft-weber-krb-wg-kerberos-clock-synchronization-00.txt (which I have
realized grossly understates the importance of ticket expiration,
thanks to comments from Nicolas Williams), I've realized that adding
something like the following to the security considerations of
clarifications or its successor might be worthwhile (it doesn't feel
like it really fits into a discussion of clock sync):

   Tickets issued by the KDC remain valid until they expire, even when
   the long-term key of the principal is changed or disabled after the
   ticket is issued.  If, for example, a workstation is compromised,
   and both a long term key and a corresponding cache of tickets is
   stolen, followed by the user noticing and changing the long-term
   key, the stolen tickets remain valid until they expire.  This is
   particularily problematic in the case of tickets for application
   servers, which are useable until they expire without furthur
   verification by the KDC.  A KDC MAY issue tickets for application
   servers with significantly shorter lifetimes than the ticket
   granting ticket, so that the KDC can be used to more efficiently
   render stolen tickets useless.  A KDC MAY shorten the expiration
   time of a ticket granting ticket in response to the long-term key
   of the principal being changed or the principal being disabled.

I'm not really sure how to best handle the shortening of the lifetime
of a ticket granting ticket.  Ideally if I'm doing a routine password
change, that shouldn't destroy all of my tickets, but if I'm doing an
urgent change, it should, but that suggests that more complexity in
the password changing protocol may be needed, and I suspect that
additional complexity is not going to be met with enthusiasm.

On the other hand, if the case of a user being logged into multiple
machines is not terribly important, perhaps it is sufficient to always
shorten the lifetime, and have password changing programs always
request new credentials as soon as they change the password.

(And yes, I realize that this may be too late for clarifications, but
it seems worth sending here anyway.)

---

From: "Matt Crawford" <[email-masked]>
Date: Thu, 19 Jun 2003 09:20:26 -0500

>    A KDC MAY issue tickets for application
>    render stolen tickets useless.

The following comment might belong on krb-dev instead, but ... Unless
something has changed since the last time I tried, this doesn't work
well in practice, since when a library call finds an expired service
ticket in the cache, it doesn't try using an unexpired TGT to get a
new one.

>    A KDC MAY shorten the expiration

How does it do that?  The TGT is out there in the wild.  Are you
proposing that the KDC check the authtime against the principal's
last key change time?

> additional complexity is not going to be met with enthusiasm.

There could be a flag meaning "ticket with authtime before last key
change are now invalid." But existing tickets to non-KDC services
can't be invalidated this way.  Couple this flag with a slightly
smarter get-ticket-using-cache function and it might be worthwhile
for some environments.  (Environments where system compromise is
detected and acted upon faster than tickets expire.)

---

From: "Joel N. Weber II" <[email-masked]>
Date: Thu, 19 Jun 2003 11:23:22 -0400

> ticket in the cache, it doesn't try using an unexpired TGT to get a

That seems likely to be true, but also likely to be easy to change, if
you can ignore older clients which don't try using an unexpired TGT.
If the KDC allows the maximum service ticket lifetime to be
configurable and the documentation warns that limiting the service
ticket lifetime beyond the TGT lifetime will interact badly with older
clients, realms that care about older clients can be configured to
make service tickets last for the same duration as the TGT.

Alternatively, you could accomplish something similar by simply
requiring that all tickets be renewed much more frequently than the
normally are now, and having a more automated mechanism for requesting
renewed tickets.  (I believe MIT krb5 currently requires you to run
kinit explicitly in order to renew tickets.)

> proposing that the KDC check the authtime against the principal's

The KDC already allegedly should have some way of dealing with
invalidating renewable tickets rather than renewing them.  (I vaguely
recall clarifications talking about some kind of blacklist, but I have
no idea as a realm administrator how to actually use such a
blacklist.)  I don't see why the mechanism for invalidating a live TGT
would need to be significantly different.

> can't be invalidated this way.

Yes, which is why I proposed making non-KDC service tickets expire
much sooner, and having the client know to use the TGT to refresh them.

> Couple this flag with a slightly

If it takes a day to detect and act upon a compromised principal, and
then 10 hours for the ticket to expire, then it is not the case that
the detection and acting on is faster than the expiration, but I still
believe there may be benefit to making the ticket
expiration/revocation happen quickly once the compromise is detected.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 Jun 2003 11:20:37 -0400

>>>>> "Matt" == Matt Crawford <[email-masked]> writes:

    >> A KDC MAY issue tickets for application servers with
    >> significantly shorter lifetimes than the ticket granting
    >> ticket, so that the KDC can be used to more efficiently render
    >> stolen tickets useless.

    Matt> The following comment might belong on krb-dev instead, but
    Matt> ... Unless something has changed since the last time I
    Matt> tried, this doesn't work well in practice, since when a
    Matt> library call finds an expired service ticket in the cache,
    Matt> it doesn't try using an unexpired TGT to get a new one.

This bug is fixed in the MIT Kerberos 1.3 codebase which should be
released relatively soon.  I.E. there are a reasonably large number of
deployed clients out there that cannot deal with short service
tickets.

Also, short service tickets interact negatively with GSSAPI.

---

From: Ken Hornstein <[email-masked]>
Date: Thu, 19 Jun 2003 11:33:27 -0400

>would need to be significantly different.

It SHOULD have such a mechanism, but no implmenetation that I'm aware of
actually HAS such a mechanism.  So the mechanism for invalidating a live
TGT is _exactly_ like the mechanism for invalidating a renewable ticket:
it doesn't exist :-)

--Ken

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 19 Jun 2003 08:36:18 -0700

> proposing that the KDC check the authtime against the principal's

By refusing to issue service tickets to a client whose TGT is unexpired
but otherwise no longer valid in the eyes of the KDC.

I think the idea is to issue long-lived TGTs and short-lived service
tickets so as to compensate for the lack of a ticket revocation
facility.

For example, if you disable a principal in the KDB any outstanding
TGTs may remain unexpired, but the KDC may (should) refuse to issue
service tickets to that principal, and, because that principals service
tickets have shorter lifetimes that principal's tickets become useless
very soon after the principal is disabled.

Long TGT expiration times help avoid frequent AS exchanges, whereas
short service ticket lifetimes compensate for the additional risk
involved in issueing long-lived TGTs.

Of course, short-lived TGTs with long renewable lifetimes + short-lived
service tickets nets the same effect, with the minor problem that
holders of such TGTs must take care to renew them often to avoid
unnecessary AS exchanges.

> detected and acted upon faster than tickets expire.)

I'm more interested in invalidating TGTs because the client principal
has been disabled than because the client principal changed its long
term key.

Cheers,

Nico
--

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 19 Jun 2003 11:07:27 -0500

> very soon after the principal is disabled.

There is a more serious problem with cross realm. With in the local realm,
the principal or TGT can/should be able to to cancelled/blacklisted. But after
a cross realm ticket is issued, the other realm does not know this,
and may continue to issue additional service tickets. 

This might be an argument for shorter or renewable cross realm TGTs.

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 19 Jun 2003 09:30:14 -0700

> This might be an argument for shorter or renewable cross realm TGTs.

For the purposes of my example above x-realm TGTs should be considered
as plain service tickets.

Perhaps I should have said "initial TGTs" because that's what users want
to be long-lived (to avoid AS exchanges and typing in passwords and what
not); short-live non-initial tickets, on the other hand, are ok because
the TGS exchanges needed to refresh (note: not renew) non-initial
tickets should be transparent to users.

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Mon, 23 Jun 2003 12:06:09 +0200 (MET DST)

> Also, short service tickets interact negatively with GSSAPI.

My experiences with GSS-API based on MIT Kerberos 5 beta6 (in 1996/7)
were the opposite, and I wouldn't expect that this was changed.

When using GSS-API the initiator of a security context can specify
a desired security context lifetime, although portable applications
will probably use GSS_C_INDEFINITE.

When a specific (short) lifetime was requested from MIT Kerberos 5 beta 6
then the following would happen:
 1) if there was no service ticket available for the requested target
    a new service ticket would be acquired with a lifetime derived from
    the desired security context lifetime if that was shorter than the
    remaining lifetime of the TGT
 2) if there was a service ticket for the requested target present in
    the ticket cache and its remaining lifetime was shorter than
    the desired lifetime (but shorter than that of the TGT) a new
    service ticket was requested as in (1).
 3) if there was a service ticket for the requested target present in
    the ticket cache and its remaining lifetime was longer than
    the desired lifetime, then this service ticket was used
    (resulting in a security context lifetime longer than the
     desired lifetime, but that is OK with gssapi).

This behaviour was quite useful when I was testing how my automatic
security context refresh logic at the application level was working
(attempting to refresh the security context several minutes before
 it expired so that no protected messages would expire while in transit,
 and checking that the refresh logic wouldn't go into a tight loop when
 the TGT was also close to expiration resulting in extremely short-lived
 security contexts).

-Martin

---

From: "Joel N. Weber II" <[email-masked]>
Date: Tue, 24 Jun 2003 09:46:27 -0400

Here is some revised text based on the discussion; I think I am
proposing that it should go into the security considerations section
of extensions.  It may be better to revise it furthur and split it
into text for the body of the document and text for security
considerations, and if the author/editor wants me to do so, I am
certainly willing.

I think the one thing I don't really address is Sam's ``Also, short
service tickets interact negatively with GSSAPI.'', because I don't
understand how short service tickets interact negatively with GSSAPI.

   Tickets issued by the KDC remain valid until they expire, even when
   the long-term key of the principal is changed or disabled after the
   ticket is issued.  A KDC MAY provide a mechanism by which an
   unexpired TGT can be blacklisted to prevent tickets from being
   issued when it is presented.  A KDC MAY also provide an option to
   check that the principal is not disabled before honoring a TGT
   request, and MAY provide a way to invalidate all of a principal's
   outstanding TGTs when its long term key is changed.

   For example, if a workstation is compromised, and both a long term
   key and a corresponding cache of tickets is stolen, followed by the
   user noticing and changing the long-term key, the stolen tickets
   remain valid until they expire.  This is particularily problematic
   in the case of tickets for application servers, which are useable
   until they expire without furthur verification by the KDC.

   A KDC MAY issue tickets for application servers with significantly
   shorter lifetimes than the TGT, known as short service tickets, so
   that the KDC can be used to more efficiently render stolen tickets
   useless.  A KDC MAY shorten the lives of a cross-realm TGT in a
   similar fashion.

   It should be noted that older clients may assume that service
   ticket lifetimes will be equal to TGT lifetimes, and older clients
   may notice that the service ticket expired without checking to see
   if the TGT is unexpired.  Until a realm administrator knows that
   all clients have been upgraded to deal with short service tickets,
   the KDC MUST NOT be configured to issue short service tickets.

   A KDC MAY allow the livetime of a service ticket to vary by
   service, so that services that don't deal well with short service
   tickets can get tickets which are valid for the entire time the TGT
   is valid.

---

From: Matt Crawford <[email-masked]>
Date: Tue, 24 Jun 2003 09:11:08 -0700

On Tuesday, Jun 24, 2003, at 06:46 US/Pacific, Joel N. Weber II wrote:
>    ticket is issued.

  ... of the CLIENT principal ...