Troy Benjegerdes <[email protected]> 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 ([email protected]) <http://www.eyrie.org/~eagle/> _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
