[AFS3-std] Re: rxgk token expiry

[Troy Benjegerdes]

On Wed, Oct 31, 2012 at 07:11:51PM -0700, Russ Allbery wrote:
> Troy Benjegerdes <hozer@hozed.org> writes:
> 
> > 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.
> 
> It really doesn't.  rxgk is superior to rxk5, including in fixing some
> security vulnerabilities that rxk5 would still have around protection of
> callback data.  You don't get anything from rxk5 that you don't also get
> from rxgk.
> 
> > There are also cases where we're going to need rxgk tokens that exist
> > longer than kerberos authorization.
> 
> Why?  I don't see why this is any more necessary than having rxkad tokens
> exist longer than the underlying Kerberos ticket would be.

Well, if I'm understanding this right, rxgk is an abstraction onto two things:

1) Kerberos (or others) with explicit time-limited authorization/authentication

2) authorization/authentication with no time limits, but may have revocations

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.


In my opinion, less code is more secure code, and if I can eliminate a bunch
of complexity by using the well-tested and audited Kerberos implementations
to tell me if something is expired, so much the better.


Are there any good discussions of the rxk5 callback problem somewhere? Is
this something that could be fixed, or is it somehow inherent in the approach?