[AFS3-std] Re: rxgk token expiry

[Jeffrey Hutzelman]

On Wed, 2012-10-31 at 19:53 -0700, Russ Allbery wrote:
> Troy Benjegerdes <hozer@hozed.org> writes:

> This raises an interesting point.  rxgk is an application protocol that
> uses GSS-API.  It may be that this discussion is to some extent pointless
> because GSS-API doesn't provide enough information to do the proper
> thing.  Does GSS-API expose to the calling application either the
> expiration time of credentials or a revocation method?  Or are both
> supposed to be handled internal to the GSS-API mechanism implementation?

GSS-API exposes the lifetime of credentials via an output parameter from
GSS_Inquire_cred (RFC2743 section 2.1.3), and of contexts via an output
parameter from GSS_Inquire_context (section 2.2.6).  It also provides
the error codes GSS_S_CREDENTIAL_EXPIRED and GSS_S_CONTEXT_EXPIRED,
which can be used to signal credential expiration at context
establishment time, and context expiration when per-message operations
are used.  While the descriptions of these things refer to "expiration"
as if it happened at a fixed time, I see no reason why it would not be
possible to have a mechanism whose credentials are of indeterminate life
(for example, because they are revocable).


> Obviously, rxgk shouldn't be required to break the GSS-API abstraction and
> embed mechanism-specific state or knowledge.

This, in particular, means that regardless of the argument about whether
rxgk tokens should expire when the predecessor credentials do, their
expiration should certainly _not_ be based on the renewable lifetime of
a Kerberos ticket.  The renew-till time is not the lifetime of the
ticket, and does not indicate that the ticket is _or ever will be_ valid
that long.  It is merely an upper bound on when the holder of the ticket
may request a _new, different ticket_ from the TGS without making use of
the client's long-term credentials.  The TGS is always free to deny such
a request, and that is a critical security property of Kerberos.

-- Jeff