On 1 Nov 2012, at 03:17, Benjamin Kaduk wrote: > On Wed, 31 Oct 2012, Benjamin Kaduk wrote: > >> On Mon, 29 Oct 2012, Jeffrey Hutzelman wrote: >> >>> On Mon, 2012-10-29 at 16:57 -0500, Andrew Deason wrote: >> >> (This is 0309471e70d "Clarify CombineTokens' least-permissiveness", not >> 13a2d01b as might have appeared from the trimmed quoted text.) >> >>>> Also, should the combined token enctype really be set to the minimum of >>>> the input tokens? Does the order of enctypes based on integer value >>>> really mean anything? (should this maybe be "most preferable" enctype >>>> based on the input enctypes, or something?) >> >> A good question! :) >> >> The old text applied simple logic to "all numerical fields", and one of the >> notes I dug up was to specify which fields those are. Pulling from >> RXGK_ClientInfo, enctype is represented as 'int', which ... is hard to claim >> is non-numerical. (RXGK_Level is an enum type, and I also listed it as >> "numerical". Separate mail on that forthcoming.)
> > Since we give explicit values for the enum RXGK_Level, it would seem to fall > under a naive reading of "numerical type", and was included in the list in my > commit 0309471e70db7a. However, it seems like the "minimum of the values" > may not be the right choice here, either. The right choice itself, however, > is not immediately obvious to me. A CM could certainly have one token per > level and always combine with a user token using the same level ... but this > requires knowing what level a particular token uses, and the token is > supposed to be opaque. The CM knows what level a token has, otherwise it can't protect the first packet to the server at the appropriate level. So, that's red herring. It's also worth nothing that this a generic CombineTokens operation. AFS has its own specific CombineTokens operation which is defined in the other document - so even considering cache managers here is a bit of a diversion. From a level perspective, I think a combined token should have the lower level of security of the two tokens (where clear < auth < encrypt). We probably don't won't to express this as a numerical minimum. From an encryption type perspective, the intent was that the server should pick the enctype which appears highest within its preference list. I think any discussion on negotiation should wait until we consider the AFSCombineTokens operation, as that opens an entire other can of worms. Cheeers, Simon_______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
