[AFS3-std] Re: rxgk token expiry

[Troy Benjegerdes]

> > I can't imagine how this would result in anything other than two code
> > paths, and if there's rxgk compiled in, it's going to need to support
> > getting some sort of a token that may not have a time limit, and then
> > it'd be up to the client/server/whatever policy to time it out. I'd
> > rather have the kerberos server be authoritative on if something is too
> > old than depend on the fileservers.
> 
> 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?
> 
> Obviously, rxgk shouldn't be required to break the GSS-API abstraction and
> embed mechanism-specific state or knowledge.


So, it seems for this to work properly, GSS-API *MUST* provide a clean api
to call to find out if an authorization context/token/whatever has either
expired or has been revoked.

It seems that for efficiency, we could allow some (short) time window in
which we don't check if the context is still valid, but really must have
an API to ask gssapi if everything is still okay.

Would being able to set this window to something like 2 hours resolve the
kinds of problems jaltman mentioned with Windows?

If we don't have an API like this, it seems like options are:

a) negotiate a new extension to GSS-API
b) break the abstraction
c) use rxk5 until a) is resolved, or live with b)

Seems like we have a choice of long, worse, or ugly.  :-/