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

[Simon Wilkinson]

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

Cheers,

Simon