[AFS3-std] Re: rxgk CombineTokens and enctypes

[Benjamin Kaduk]

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