[AFS3-std] Re: rxgk token expiry

[Russ Allbery]

Troy Benjegerdes <hozer@hozed.org> writes:

> 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

rxgk is a protocol that uses GSS-API.  The authentication mechanism
details that you are describing are properties of the underlying mechanism
negotiated by GSS-API.

> 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.

> 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.

This is yet another reason why you want to use rxgk and not rxk5.  The
GSS-API is considerably cleaner than the Kerberos API.  The general
consensus in the Kerberos community is that GSS-API should be used in
preference to the Kerberos API for all new applications whenever possible.
There is even work on extending the GSS-API for initial ticket acquisition
so that one doesn't have to fall back on Kerberos for that.

> Are there any good discussions of the rxk5 callback problem somewhere?

There were substantial security evaluations posted to the OpenAFS mailing
list back when it was being considered for inclusion in the tree.

> Is this something that could be fixed, or is it somehow inherent in the
> approach?

It's inherent in the complexity tradeoff that rxk5 made.  I believe the
authors agreed that it was a less comprehensive solution; the intent was
that it would be easier to implement and wouldn't require inventing as
much new protocol as rxgk, which was the point of that tradeoff.  One of
the things one loses is that it continues to be vulnerable to some issues
that rxkad has, but which rxgk fixes.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>