On Fri, 9 Nov 2012, Benjamin Kaduk wrote:
I see valid arguments both pro- and anti- a generic CombinedTokens, and haven't had much time to think about it this week since I'm at the IETF meeting. It does seem, though, that the app-defined behavior is restricted to the server, since the client treats tokens as opaque and just passes them from server to server. It is probably possible to have an application client that knows it wants to combine identities but does not need to care about the details of how the identities are combined.
My ponderings seem to have decided that since there is some meaningful way in which one client implementation can talk to a different implementation's server and do the CombineTokens operation, it is worth keeping.
I have new commits up at https://github.com/kaduk/openafs/commits/prot (HEAD is 67b21de). Channel-binding is gone, I further tweaked the token expiry language, and a big change for the new CombineTokens prototype and the associated fallout. I seeded the errorcode values with a few things that came to mind; maybe there should be more.
I also added jhutz's desired text that explicitly says tokens SHOULD NOT expire later than the GSSAPI credential, and a first crack at security considerations for that issue.
Since I had thought about it while reviewing through for CombineTokens changes, there's also a bit about allowing the key version number to be the full 32 bits (still only 16 on the wire) if the endpoints can track it.
I think is is probably about time for a new I-D, if Simon is up for doing that.
-Ben _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
