[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wss] KERBEROS - Derriving session keys from master secret
As you mentioned, the reuse of keys for message protection in kerberos communication sessions is probably not a big security issue. However, if I remember some old discussions well, the key derivation from kerberos session keys is also useful for multi-treaded exchanges where the security context is shared among different threads that independently exchange messages without apparent order, protected through the same context (="master-session-key"). Again this magical WS-S* may be able to cater for this... -Frank. Hallam-Baker, Phillip wrote: > In an earlier discussion I had with Chris Kaler we discussed this issue wrt > the implications for the draft. > > I think we need to put a warning in here to state that the keys established > through the simple exchange MUST NOT be used without an additional source of > per-message key freshness. This may be provided by either: > > 1) The use of an encryption algorithm that uses an IV > 2) A key exchange algorithm (e.g. those to be discussed in WS-S*) > > Since WS-S* is currently out of scope for the group and cannot be referenced > normatively we should not use it in the examples. We can however cite it in > non-normative ways. > > I suggest that we use AES-CBC as the encryption alg in the examples and put > a warning in the security considerations section. > > Any objections? > > > -----Original Message----- > From: Hallam-Baker, Phillip > Sent: Tuesday, May 04, 2004 3:42 PM > To: 'Hal Lockhart'; Tim Alsop; Hallam-Baker, Phillip; > wss@lists.oasis-open.org > Subject: RE: [wss] KERBEROS - Derriving session keys from master secret > > > By 'master secret' I meant that the secret stored in the ticket is the same > for the life of the ticket and was attempting to draw an analogy with SSL. > The lifetime of an SSL master secret is equivalent in duration to a Kerb > ticket, measured in hours to days, but reused for several transactions, each > of which requires a sub-key to be split. > > Tim is correct in pointing out that we have an even longer term secret here. > OK so forget the term 'master' if it is confusing. > > Kerb was designed for use with a particular set of encryption algs, all of > which use IVs and are in any case safe for repeated encryption of different > data sets. So in that context the re-use of a kerb key does not bother me, > the security comes in from the fact that there is built in key freshening > when the key is used. My concern is that in the context of WS-Security we do > not have that guarantee. > > > IE we have two transactions: > > T1: Kerk ticket is k, secret is S, Plaintext is P1 > T2: Kerk ticket is k, secret is S, Plaintext is P2 > > Now if we use AES with a sensible mode like CBC we would end up with > > E1 = AES (P1, S, IV1) > E2 = AES (P2, S, IV2) > > So even if P1=P2 we guarantee E1 <> E2 provided Iv1, Iv2 are 'random', and > moreover there is no hint of any related plaintext attacks. > > But say we used RC4 instead: > > > E1 = RC4 (P1, S) > E2 = RC4 (P2, S) > > Here we have two ciphertexts encrypted under the same stream, so E1 XOR E2 = > P1 XOR P2. That is one of the big weaknesses in the original WEP scheme, you > can easily cryptanalyze to arrive at P1, P2 in this case. > > I don't use stream ciphers, but I do use MAC functions: > > I1 = HMAC (P1, S) > I2 = JMAC (P2, S) > > So if I1 = I2 the attacker can deduce that P1 = P2, a very significant > result in many protocols. > > As I said earlier, these are not an issue in the context of Kerb which uses > other controls, but we have to guarantee that we provide the same controls, > particularly given the nature of the audience. > > > > -----Original Message----- > From: Hal Lockhart [mailto:hlockhar@bea.com] > Sent: Tuesday, May 04, 2004 9:55 AM > To: Tim Alsop; Hallam-Baker, Phillip; wss@lists.oasis-open.org > Subject: RE: [wss] KERBEROS - Derriving session keys from master secret > > > Tim is correct. The service ticket is ENCYPTED UNDER a long term secret, but > does not contain it. Presumably the KDC uses a strong algorithm for creating > session keys. > > Hal > > -----Original Message----- > From: Tim Alsop [mailto:Tim.Alsop@CyberSafe.Ltd.UK] > Sent: Friday, April 23, 2004 4:54 AM > To: Hallam-Baker, Phillip; wss@lists.oasis-open.org > Subject: RE: [wss] KERBEROS - Derriving session keys from master secret > > > > I am sorry to join this discussion at a late stage, but I am not clear what > you mean by "master secret" ? You seem to be implying that a Kerberos > service ticket contains a master, long term secret and cannot, or should not > be used for authentication and encryption ? If so, then I disagree with > this. > > Thanks, Tim. > > -----Original Message----- > From: Hallam-Baker, Phillip [ mailto:pbaker@verisign.com > <mailto:pbaker@verisign.com> ] > Sent: 22 April 2004 17:34 > To: wss@lists.oasis-open.org > Subject: [wss] KERBEROS - Derriving session keys from master secret > > We need to specify how to use a secret bound in a kerb ticket for encryption > > and authentication. > > This has two parts, first nit picky issues like byte ordering, second > sub-key derrivation. > > The secret contained in a kerb ticket is a master secret, it should never be > > used to encrypt or authenticate data directly, it should only be used in a > secure fashion to create the session keys used for actual processing. > > > In the case of encryption SOME algorithms have an IV, others do not. If some > > looser were to encrypt two pieces of data with the same key under RC4 there > is a simple cryptanalytic attack for recovering the message data: > > [C1 = M1 XOR S, C2 = M2 XOR S => C1 XOR C2 = M1 XOR M2 XOR S XOR S = > > M1 XOR M2 > where S = E(k), the stream cipher cipher stream] > > In the case of MAC algorithms the message encryption layers do not specify > any key freshening scheme. > > > As I see it the question is to what extent we want to protect loosers from > loosing by making the scheme foolproof. > > A simple key derrivation scheme would be the sender specifies a random XOR > mask to be used to freshen the master secret. This is secure but only if the > > XOR mask is strong. A stronger scheme is to use some form of cryptographic > primitive such as a hash so we guarantee the derrived key is secure. > > > To unsubscribe from this mailing list (and be removed from the roster of the > OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php > <http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.ph > p> . > > -- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]