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

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

Title: 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]
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.