Subject: [Ietf-krb-wg] The usability of service ticket lifetimes

From: Jeffrey Altman <[email-masked]>
Date: Tue, 21 Aug 2012 13:21:18 -0400

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-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 21 Aug 2012 14:49:01 -0400

> 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.

> 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
 
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.

> 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

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 21 Aug 2012 16:28:13 -0400

> client may not have the TGT to renew.

I'm going to break up the thread into sub-threads based on the issues
raised by Jeff Hutzelman's response.

What are the policy semantics of a service ticket that is marked as
RENEWABLE?

If the realm's policy is that obtaining a service ticket with a longer
lifetime must require the possession of the TGT, that is is really easy
to enforce:

  Remove the allow renewable property from the service principal's
  entry in the database.

But if the service principal does permit the issuance of RENEWABLE
service tickets, shouldn't that mean that those tickets can be renewed
without the TGT?  What else could it possibly mean?

RFC 4120 is very ambiguous in this area.

Jeffrey Altman

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 21 Aug 2012 16:33:23 -0400

> interactions between all of the services a user might have used.

The rule would become

  A policy is in effect by the time any ticket issued prior to it
  has expired.

Your rule assumes that policy changes are enforced upon TGT renewals and
my rule assumes that policy changes are enforced upon all ticket
renewals.  I hope that policy changes are enforced during the issuance
of all tickets and not just TGTs.

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 21 Aug 2012 16:40:08 -0400

> when they first talked to a particular service on a particular day.

Most ticket managers such as Network Identity Manager, the Microsoft
Windows LSA, and any site that is making use of k5start (or similar
tools) works very hard to ensure that _users_ are completely unaware of
expiration.  The goal is to make the acquisition and use of Kerberos
tickets invisible to the user.  The only time a user should be aware of
the inability to renew is when

 (a) the renew_till lifetime has expired (if the platform enforces that)

 (b) if a policy change prevents the further renewal of the TGT
     (or user account in the case of Windows)

The Kerberos community has years of experience with enforcement of
expiration times on application protocols such as those protected by
GSS-API and the conclusion has been that expiration enforcement on
connections is a bad idea because of the usability problems that are caused.

In my opinion a more secure solution is one that permits the ticket
lifetime to be shorter and the renewable lifetime to be longer providing
the realm administrator a shorter period of time between when policy or
account adjustments are made and when they take effect.

Jeffrey Altman

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 21 Aug 2012 13:49:03 -0700

> interactions between all of the services a user might have used.

+1 KISS

Otherwise you can't analyze the protocol and understand all the implications in all cases.  Let's not forget that some of the people who need to understand the rules and their implications are not Kerberos experts.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 21 Aug 2012 14:08:21 -0700

> of all tickets and not just TGTs.

Are there any currently deployed implementations which will directly renew service tickets?  I've always thought the concept of a renewable non-tgt was counter to the design.

Is this is aimed at the efficiency problems with Java not caching service tickets?  I thought I saw some traffic about fixing that.  Checking. . .

---

From: Tom Yu <[email-masked]>
Date: Tue, 21 Aug 2012 17:17:57 -0400

> Are there any currently deployed implementations which will directly renew service tickets?  I've always thought the concept of a renewable non-tgt was counter to the design.

RFC 1510 section 3.3.2 makes it clear that the KDC can renew a non-TGT
service ticket.  Whether that's a good idea is debatable, but it does
appear to be part of the original design.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Tue, 21 Aug 2012 16:57:09 -0500

> connections is a bad idea because of the usability problems that are caused.

I am and have been of two minds about this.

I'm not happy with apps that allow connections to stay up forever
without further efforts to handle revocation.  And we have no standard
revocation protocol.  Oof.

But at the same time expiring connections when the tickets used to
authenticate expire has been disastrous for usability.  All sorts of
things go wrong within clock skew of ticket expiration.  Two types of
problems arise:

 - bugs around clock skew of ticket expiration, of which there have
been too many, sadly

 - application protocols that can't re-authenticate without reconnecting.

Of the latter IMAP has been used as an example before.  But IMAP
clients can typically recover state quickly enough that reconnection
should just be a hiccup (as long as there are no transfers that
require so long that the connection always expires first).  The
filesystem protocols can handle re-authentication.  LDAP is pretty
much stateless (but don't expire a connection in the middle of a write
operation!).   ...

The former are all just depressing.  We had such a bug in the Solaris
NFS/RPC stack where every RPC resulted in a new security context when
within clock skew of ticket expiration due to a client-side bug.  I'm
quite sure there have been others.

What to do?

Some possibilities:

 - expire contexts sometime *after* ticket expiration -- unlikely to
make us happy in general, but at least this should steer clear of the
bugs I mentioned above

 - add a protocol for checking the status of a client principal (but
this won't work with asymmetric x-realm trusts)

 - add a revocation protocol (but how to scale to large networks?!)

 - ???

Of these I prefer the first, but I think we could/should add the
second (the service would talk to the client princ's realm using the
client's ticket as a second ticket for the TGS-REQ and get an answer
indicating whether the client is still live) (but there are privacy
issues involved).

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 21 Aug 2012 17:55:26 -0400

Tom Yu <[email-masked]> wrote:

>> Are there any currently deployed implementations which will directly
>renew service tickets?  I've always thought the concept of a renewable
>non-tgt was counter to the design.
>

Of course, a KDC my choose not to renew a ticket.  But, issuing a renewable ticket which one has no intention of ever renewing is in poor taste.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Tue, 21 Aug 2012 17:09:58 -0500

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

Note that some client libraries check that the KDC does not exceed the
limits you quoted.  That means that relaxing them will require a KDC
options flag in the request...  And it should only be used in KDC-REQs
where the body of the request is protected (e.g., TGS-REQs and AS-REQs
in a FAST tunnel).

Nico

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 21 Aug 2012 15:22:39 -0700

> where the body of the request is protected (e.g., TGS-REQs and AS-REQs

IMO it's inappropriate (as in: a *bug*) for a client to unconditionally enforce limits which are the KDCs responsibility to enforce.  If nothing else, it makes it hard to support edge cases which may violate some letters of the limits, but not the intent or the policy.  (I suppose I'm a bit twitchy due to a PKINIT issue I ran into recently.)

---

From: [email-masked] (Martin Rex)
Date: Wed, 22 Aug 2012 02:56:15 +0200 (CEST)

>  - application protocols that can't re-authenticate without reconnecting.

As there was a "mandatory" security context expiration in MIT Kerberos
when we added support for GSS-API to our application, I built support
for dealing with replacing an expired security context before it expires.

While it has been working OK in principle, we've found some application
states where the apps programmers didn't sufficiently plan ahead (to cope
with the resulting complexity).

I've also encountered interop problems resulting from incorrect
security context lifetime being determined when running on Microsoft
Windows under Citrix with the user-specific Citrix timezone hack.

Performing security context renegotiation for GSS-API requires to
address a number of interesting problems:

   - the new security context will typically have to be established
     in the exact same direction, so when the server/acceptor detects after
     a longer period of silence that a new security context is required
     it will have to ask the client/initiator to start a new security
     context establishment.

   - you may want to limit the security context "renegotiation" (attempts)
     to near the end of the security context lifetime

   - you may want to start security context "renegotiation" before the
     current security context expired, so that no protected data
     "expires in transit" (which would otherwise require application-level
     retransmission queues).  But really, the strict security context
     expiration in the original MIT Kerberos is a royal PITA about
     "protected data expiring in transit" when using other than simplistic
     request/response protocols where the processing of protected data
     in application-level request queues may get delayed for 10+ minutes.

   - you may want to limit the number/frequence of attempts for renegotiating
     a new security context so that there is no deadly embrace.

   - there is no point in trying to renegotiate a new security context if
     that will not be valid any longer than the current security context
     (when that lifetime is determined by the credentials, and the
      available credentials have not been updated/renewed since the
      original/previous security context establishment).

> quite sure there have been others.

Bugs like this often happen when testing is limited to black-box testing
(product / end-user testing) rather than module testing an white-box testing,
where developers watch the real behaviour of their code when they first
implement it and whenever they change it, and testing every "feature"
and non-trivial combination of features they implement, fully aware
of the boundary conditions within their own code.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Tue, 21 Aug 2012 20:07:04 -0500

> address a number of interesting problems:

Considering the GSI GSS mech that is TLS on the wire, and MSFT's API
to TLS which is basically SSPI, and how MSFT handles TLS re-nego in
that API, we could do the same in GSS.  BUT, it'd require app changes.

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 21 Aug 2012 21:35:32 -0400

On Tue, 2012-08-21 at 15:22 -0700, Henry B. Hotz wrote:
> IMO it's inappropriate (as in: a *bug*) for a client to unconditionally
>  enforce limits which are the KDCs responsibility to enforce.  If
>  nothing else, it makes it hard to support edge cases which may violate
>  some letters of the limits, but not the intent or the policy.  (I
>  suppose I'm a bit twitchy due to a PKINIT issue I ran into recently.)

Actually, no.  The protocol contains fields to allow a client to place
limits on the lifetime and renew lifetime of tickets it requests, and
the spec requires the KDC to obey those limits.  As a check that these
fields have not been modified in transit, it is reasonable for a client
to verify that the requested limits have not been exceeded.

There is a mechanism for a client to indicate the KDC should use the
maximum lifetime permitted by policy; when this is used, clients should
not expect any particular values back.

-- Jeff

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 21 Aug 2012 20:10:26 -0700

> to verify that the requested limits have not been exceeded.

Oh, yeah. . .  I remember a bug in that check.  Not really what I was talking about though.

Or, actually, it is.  In both cases the client was erroneously failing because it was not leaving checks/modifications to the discretion of the KDC when it should have.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 21 Aug 2012 20:13:41 -0700

> Is this is aimed at the efficiency problems with Java not caching service tickets?  I thought I saw some traffic about fixing that.  Checking. . .

I'm told that Java will now save service tickets within the program, but not to a ccache.  Have not actually experimented.