[AFS3-std] Re: rxgk token expiry

[Matt W. Benjamin]

Hi Troy,

There is no special rxk5 callback problem, it's the same as with rxkad, for traditional AFS-3.  But with new RPCs as we did later with extended callback information, the callback channel must be protected, to get an equivalent level of security.  We did some work towards adding an anonymous, secure backchannel using the rxk5 framework, but there has been no interest from the community in rxk5 essentially, and we stopped work on it.

Matt

----- "Troy Benjegerdes" <hozer@hozed.org> wrote:

> 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?
> _______________________________________________
> AFS3-standardization mailing list
> AFS3-standardization@openafs.org
> http://lists.openafs.org/mailman/listinfo/afs3-standardization

-- 
Matt Benjamin
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309