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

[Jeffrey Hutzelman]

On Wed, 2012-10-31 at 22:59 -0400, Benjamin Kaduk wrote:
> On Mon, 29 Oct 2012, Jeffrey Hutzelman wrote:

> > combine-tokens operation is _not_ commutative; the order of the inputs
> 
> Hmm, I had not really internalized that, thanks for mentioning it 
> explicitly.  This is solely from the way in which we use KRB-FX-CF2 for 
> key combination, not in any of the rxgk-specific bits, right?

Yes and no.  It is (or was) a design property of rxgk that one could
combine tokens with different properties, including one where someone
else knows the keys, and get back a token you could trust belonged to
you alone.  So, using the CM example again because it's convenient...

A CM wanting to combine its token with a user's knows both keys, but the
key in the user's token is also known to the user.  We want the combined
token to have primarily the user's identity, so that filesystem accesses
are done as the user.  But we want the key to be one the user doesn't
know, so he cannot poison the cache.

Furthermore, we don't want the user to be able to unduly influence the
properties of the combined token, either through his knowledge of one of
the input keys or through his ability to influence or control some of
the properties of the input token.  For example, contrary to Simon's
comment, we don't want to take the lowest security level of all tokens,
because that would allow a client to force a weaker level than the CM is
willing to live with (this is not as bad as with rxkad, because rxgk's
weakest level is still fairly strong, but it's still worth considering).
The same applies to enctype selection.





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


> Actually, KRB-FX-CF2 for keys calls random-to-key() and pseudo-random(), 
> which depend on the enctype; random-to-key() would use the Kn enctype, and 
> pseudo-random() would use the K0 and K1 enctype as appropriate. I'm a 
> little uneasy using pseudo-random() from one enctype to produce the 
> appropriate number of random bits for random-to-key() of a different 
> enctype

You shouldn't be; that's a perfectly reasonable use.  The output of the
PRF operation is explicitly intended to be usable for generating key
material for arbitrary cryptographic use that may have nothing to do
with the enctype of the key it is keyed with.



>  (I don't have a good reason for unease, feel free to tell me I'm 
> wrong); can we get away with requiring that the enctypes must be the same? 

No, I don't think we can, and I see no reason to do so.  The construct
in question is well-formed and uses the primitives exactly as intended.


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

> > If that's too much of a change for people, then you could also simply
> > assert that the enctype used is that from a particular input token.  In
> > that case, it needs to be the token that, in the case of an AFS cache
> > manager combining tokens with a user, works out to be the token that
> > belongs to the CM (i.e. the one the user doesn't control).
> 
> Right, this.  Would you prefer to require the CM token or the stronger 
> enctype (insamuch as there is an ordering of strength)?

I'm fine with either, I think.


> Back to negotiation, a brainstorming thought: rather than have the server 
> send back a selected enctype (which would want to be protected under one 
> or the other of K0/K1), we could have the client send a nonce and the 
> server send it back encrypted in Kn.  The client would then build Kn for 
> each enctype in the list and see if the nonce decrypts properly, to tell 
> which enctype was used.  Still kind of ugly, huh.

Ugh, that sounds expensive.  I see no reason the server's enctype
indication needs to be protected -- either it will match the session key
type in the token or it won't, and if it doesn't, it's not going to
work.

-- Jeff