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

[Benjamin Kaduk]

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

> Yeah, I'm not sure what "minimum" means here.  However, note that the

The RFC 3961 enctype registry has des-cbc-crc as enctype 1, which is 
probably not a good choice...

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

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

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 (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? 
This could result in headaches if there were two server principals that 
had different best enctypes in their key lists.  rxkad requires 
administrators to explicitly get DES keys, so maybe requiring coordination 
on a single strong enctype would not be too bad, but it still feels ugly.

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.

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



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.

-Ben