Re: [wss] KERBEROS - Derriving session keys from master secret

[Frank Siebenlist <franks@mcs.anl.gov>]

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