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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
