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