[AFS3-std] rxgk CombineTokens and enctypes

[Jeffrey Hutzelman]

On Wed, 2012-11-07 at 16:22 +0000, Simon Wilkinson wrote:
> On 7 Nov 2012, at 16:03, Andrew Deason wrote:
> 
> > On Tue, 6 Nov 2012 19:49:26 -0600
> > Andrew Deason <adeason@sinenomine.net> wrote:
> > 
> > After writing this, this morning I'm a little unclear now on why
> > CombineTokens is even in the rxgk draft. From a practical perspective,
> > we're not going to ever use that RPC, right? And from a theory
> > perspective, every single thing about it is application-specific.
> 
> I included it in this document, because I thought it was useful to
> define a building-block that could then be used as a foundation for the
> application specific RPCs. There are elements of CombineTokens that are
> not application specific - the way we generate the combined key, the
> limits on lifetime, bytelife and expiration time. I think what happens
> with encryption types and levels can probably be defined in a
> non-specific manner too.

In fact, really the only application-specific behavior is the combining
of identities.



> But yes, I think this discussion could be helped by looking at the
> specific case of AFSCombineTokens, clearly specifying that, and then
> working out what it is useful to generalise into CombineTokens. If we
> decide nothing, then we can just remove CombineTokens from this
> document.

AFS is a very unusual case, because it provides an operation which
conflates CombineTokens, a directory query ("does this server support
rxgk?"), and what is essentially the equivalent of a ticket-granting
service, all in one RPC.  That's convenient, but not essential -- one
_could_ first check with the vlserver to see whether a fileserver
supports rxgk, then use the generic CombineTokens, and finally contact
an AFS-specific TGS-like service to turn your generic "AFS" token into
one for use with the specific fileserver you're interested in.


I'd rather not see the generic operation go away just because one
component of one application chooses for convenience to do the same
thing in an RPC that also does two other things.  More generally, while
AFS is certainly a driving force for Rx, as someone who has written a
number of other Rx-based applications, I think there is great value in
maintaining the notion that Rx is its own protocol with AFS as one
application, rather than just some of the common bits of the various AFS
protocols with no concept of layering or abstraction.

-- Jeff