rxgk CombineTokens and security level (was Re: [AFS3-std] Re: afs3-rxgk-updates for 03)

[Benjamin Kaduk]

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.  Or, perhaps a user wishes 
to combine two tokens, not necessarily of the same level.

It seems that the key question here is whether the combined token 
represents access to the intersection or the union of the two identities. 
(Or whether ACLs should be configurable in either fashion, I suppose.)
That would lean towards a "most restrictive" or "least restrictive" 
policy, though is not a conclusive argument in either case.
I don't remember seeing much about this in the email archives; was it 
discussed in in-person meetups?

While "use the value from the first one of the two" seems reasonable for 
choosing an enctype, I can't convince myself that such a procedure would 
be reasonable for the security level.  It seems like the client may have 
reason to prefer a stronger or weaker security level, and the server may 
have policy reasons to disallow either type of request.  This would lean 
to a negotiation scenario, and my brainstorming is not coming up with 
other plausible options.

But, if we are negotiating security levels, we might as well negotiate 
enctypes at the same time.

I would love some more input here...

-Ben