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

[Benjamin Kaduk]

On Fri, 2 Nov 2012, Jeffrey Hutzelman wrote:

> On Fri, 2012-11-02 at 15:50 -0400, Benjamin Kaduk wrote:
>> [Attempting to combine Jeff's two latest mails into one reply]
>>
>> On Thu, 1 Nov 2012, Jeffrey Hutzelman wrote:
>>
>>> On Wed, 2012-10-31 at 22:59 -0400, Benjamin Kaduk wrote:
>>>> On Mon, 29 Oct 2012, Jeffrey Hutzelman wrote:
>>>
>
>
>
>> It also may present something of a future-proofing problem: currently, we
>> pass two tokens in and get a token out.  If we need to start passing more
>> information back, we might get into trouble if an application has
>> app-specific data into the token that also needs information passed back.
>> If we can keep the interface as tokens-in, tokens-out only, that situation
>> is much cleaner.
>> Though, if we're going to be defining app-specific RPCs anyway
>> (AFSCombineTokens), maybe this is not a huge concern.
>
> Well, note that when you get a token in the first place, you necessarily
> get some additional information along with it, such as the enctype and
> the key itself.  In this case, we don't need to transport the key
> because it is derived using the PRF; that's useful because the nature of
> the operation means that none of the existing keys can be fully trusted.

Right.

> However, that doesn't mean we can't pass other information required to
> make the token usable, and even use the new key to protect it (with
> appropriate key usage, of course).

True.  My concern is basically about whether we can pass that other 
information in a general-enough fashion to not paint ourselves into a 
corner.  Attempting to enumerate the "additional information" one gets 
along with a token makes me wonder if the enumeration is complete, or even 
can be complete given the possibility of application-specific data.

>
>>> The caller should be able to assert any identity ordering, presumably by
>>> the order in which the input tokens are provided.  That is, if Alice and
>>> Bob "combine forces", the caller gets to decide whether the identity
>>> expressed by the output token is [Alice,Bob] or [Bob,Alice], and the
>>> spec says how to do so.  Of course, the meaning of multiple identities
>>> in a token is up to the application, and in any case, might end up being
>>> considerably more complex than just a list.
>>>
>>
>> Do I need to go read brashear-afs3-pts-extended-names to have context for
>> this
>
> No.  As above, the point is that there is an ordering, and it can
> matter.  For example, in the cache manager case, the user's token might
> belong to alice@EXAMPLE.COM, and the CM's token might belong to
> host/your-workstation.example.com@EXAMPLE.COM.  You want the resulting
> token to confer all of the rights Alice has, and possibly also rights
> granted to users of your-workstation.example.com (the equivalent of an
> IP address ACL, but actually secure).  But you don't want to include
> rights granted to the workstation's host principal -- there's a
> difference between the y-w.example.com and "people accessing AFS from
> y-w.example.com".  Also, you want to use Alice's ID as the owner of new
> files and as the recorded author of changes.
>
> So, when I write [Alice,Bob], I just mean whatever potentially-complex
> identity and authorizations the application confers when the tokens are
> combined _in that order_.

Fair enough.
It's not clear what reading to apply to a "combined combined token", that 
is, a Tn where one of the source T0 or T1 was already the result of a 
CombineTokens() operation.

"list of identities is the union of those in the original tokens" would 
seem to imply that there is not a concept of nested list/pairs, just a 
flat space.  Actually, "union" would seem to imply a set-theoretic 
concept, *without* order.  So given your above interpretation, that would 
be a bug in the spec.

>
>>> Choice of enctype should be by selecting the strongest available
>>> enctype, where "available" means those enctypes both supported by the
>>> server and known to be supported by the client, and "strongest" is up to
>>> the server to determine. The list of enctypes could be taken from all of
>>> the provided tokens, but I think it would be better for the caller to
>>> provide an explicit list, as this allows upgrade to an enctype that is
>>> supported by the caller and server but may not have been supported by
>>> the original token issuers (or by the clients that got the tokens).
>>
>> I agree that there is sense in allowing an enctype other than the two
>> present in the provided tokens, but it's not imeediately/obviously clear
>> that it must always be the stronger one.
>
> Well, it needs to be the "most preferred" one.  That pretty much has to
> mean one of three things:
>
> 1) Whichever one the server picks from the client-provided list.
> 2) Whichever one comes first(*) in the client-provided list.
> 3) Whichever one comes first(*) on a standardized fixed list.
>

I'll accept that as a complete list.

> I certainly don't want (3), and I don't think anyone else does, either.
> Both of (1) or (2) are in common use, and either would be acceptable to
> me.  Note that in the case of (1), you can still say that the client
> list is sorted by preference, without requiring the server to agree.
>
> (*) without loss of generality

Okay.  I would pick (1) from that, and prefer that the client indicates 
its preferences.

>
> I'm going to defer the discussion of levels to another message, both
> because I want to get to dinner and because I need more time to think
> about it.

The above discussion of combined identities probably renders some of my 
analysis incorrect.  I look forward to your thoughts.

-Ben