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