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

[Jeffrey Hutzelman]

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:
> >


> >>> matters.  Since we will be generating a new key anyway, the right answer
> >>> is probably to have the client send a list of supported enctypes and
> >>> have the server issuing the combined token select a suitable one.
> >>
> >> It is tempting, as GSSNegotiate() already does so.  However, we need to
> >> come up with the same enctype on both client and server, and communicating
> >> the result back from the server to the client could get complicated.
> >
> > Huh?  Why?  The server already has to communicate the new token back to
> > the client; why can't it also communicate the enctype used?
> 
> It changes the RPC signature, which is by no means a blocking objection 
> (but might, say, hurt interoperability with already-deployed 
> implementations).

I don't think there are any, and to some extent, that's what you get for
deploying a work-in-progress before it's done.  I know YFS has an
implementation, or at least most of one.  However, I suspect they're
running it on an alternate Rx service ID (allocated by the registrar for
that purpose) to avoid conflicts with whatever eventually comes out of
this process.  I don't know if they've shipped or deployed anything.



> 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.
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).


> >> If we can't get away with requiring identical enctypes, I think I'd rather
> >> just say "take the enctype of K0" than try a negotiation.  With some text
> >> like "the client SHOULD ensure that if K0 and K1 have different enctypes,
> >> the stronger enctype is presented as K0", that would probably be okay.
> >
> > Not if you also have rules about where the client identity in the
> > combined token comes from.
> 
> What form would/could such rules take? afs3-rxgk-afs does mention 
> ordering, but I did not see anything about how to combine identities.

It doesn't matter.  The point is that the input tokens are an ordered
list, not a set, and order may matter when the application is deciding
what authorizations to grant to the holder of the resulting token.  


> I suppose it would not be too great a DoS risk to drop something if the 
> indicated enctype does not match the token (which does not match the key 
> generated by the client).  We would not be able to check the parenthetical 
> until we try to use the token, though, but we already have similar 
> behavior.

Sure.  An attacker could modify the token in flight, after all.



> > 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_.



> > 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 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


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.

-- Jeff