On 1 Nov 2012, at 02:59, Benjamin Kaduk wrote: See my other email for comments on enctype negotiation - I just wanted to comment specifically on this ...
> 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 can't see any reason for unease here. These are general purpose building blocks. psuedo-random is defined as providing access to a seeded PRNG. Providing that PRNG provides at least enough bits of entropy for the subsequent random-to-key operation, random-to-key must be safe, regardless of the encryption types in play. > (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. I'm not sure you understand the model in play here - perhaps we need more text explaining the purpose of CombineTokens. It isn't intended that CombineTokens be used for tokens acquired for two different servers. Instead, it's supposed to combine multiple user tokens (For example, if Alice and Bob join forces to access a particular system) into a single authentication entity. Secondly, the encryption types of the server principal (afs3-bos/myserver.example.org or afs3-rxgk/_afs.example.org) don't have any relevance here. Instead, what you care about is the encryption type that has been negotiated between the server and client as part of the earlier GSSNegotiate operation, which will be chosen from the intersection of the list of rxgk encryption types supported by the client and the server. Bear in mind that rxgk is designed to be used as part of a GSSAPI negotiation - there's no requirement that the underlying mechanism is Kerberos based. Things do get complicated when we look at AFS specifically where there is an extended AFSCombineTokens RPC. This servers a number of purposes. Firstly, it provides a mechanism by which a client can determine whether a particular fileserver supports, or does not support, rxgk. Secondly, it allows user key material to be combined with cache manager key material to avoid the cache poisoning attack. Thirdly, it allows for fileservers which don't share the cell wide rxgk token encryption key, by allowing the vlserver to re-encrypt the token with a key that's specific to a given server. Cheers, Simon _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
