On Wed, 2012-10-31 at 19:53 -0700, Russ Allbery wrote: > Troy Benjegerdes <[email protected]> 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 _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
