[AFS3-std] Re: rxgk token expiry

[Troy Benjegerdes]

> > The authentication data therefore needs to be discarded by any downstream
> > consumer of Kerberos tickets.  Not doing this significantly undermines the
> > Kerberos security model.  The lack of revocation support in Kerberos is
> > made possible by limited-lifespan tickets, and ignoring that expiration
> > means introducing new security vulnerabilities.
> >
> > It's particularly important in security systems to not discard bounds and
> > restrictions when translating their results into another protocol.  By
> > doing so, you discard invariants that you may be relying on for other
> > security guarantees, some of which can be quite subtle and tricky.
> 
> The battle was lost a long time ago.   Heimdal, MIT and Microsoft all
> disregard Kerberos ticket lifetimes for GSS security contexts derived 
> from
> Kerberos authentications.   The rxgk token is a derived form of GSS
> security context.  Forcing termination of application specific 
> connections
> because the authentication context has expired is impractical and has 
> been
> demonstrated to result in data loss.


I'd agree with you on the data loss... I regularly lose data when my 
kerberos tickets (and corresponding AFS tokens) expire. But in my case,
this is a *design feature* of my security policy and posture.

I don't want mozilla bookmarks, openoffice document changes, and other
random crap to get saved after my kerberos tickets expire, I want to 
have the screensaver and aklog work *right*, and only renew my filesystem
access after I have successfully re-authenticated, and have the data
get saved *after* I have re-authenticated.

I think this also makes it quite clear the need for an Rxk5 standard,
in addition to rxgk that explicitly directly uses Kerberos 5 tickets
*as* tokens, and continues to provide the robust 'you lose access
when your tickets expire' behavior that users, and administrators
expect.

There are also cases where we're going to need rxgk tokens that exist
longer than kerberos authorization. But I don't even want to begin to 
think about all the edge cases that would exist on rxgk token revocation.