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

[Tim Alsop <Tim.Alsop@CyberSafe.Ltd.UK>]

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

Yes, a KDC will use a random function to generate a unique session key at time of authentication. So, there is no need to be concerned about long term secrets because they are not relavent to this use of Kerberos. It is perfectly acceptable to store service tickets in side XML and use session keys for message protection.

 

Tim.

---

From: Hal Lockhart [mailto:hlockhar@bea.com]
Sent: 04 May 2004 14:55
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.