Subject: RE: Deriving a symmetric key from the DH key

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 19 Oct 2004 11:16:56 -0700

Paul> No, I didn't agree with this. get_mic is not a hash.

 Get_mic() can be a hash, and this proposal only accepts those unkeyed
get_mic() operations that are hashes. See below.

    Paul> but the presence of other
    Paul> bits (such as sequence numbers, version numbers, etc)

 These are certainly not required by the kcrypto draft. I suspect you
confused GSS_GetMIC() with the kcrypto get_mic(), am I correct?

I modified my original proposal to require get_mic(dummy-key) be a
cryptographically strong hash, or the KDC will reject the client's
choice and negotiate a new one. For all practical purposes, H here is
SHA1.

I would prefer changing kcrypto suites, but that is impossible. If I
were able to change kcrypto, I would have added the key derivation
function which can use hashes underneath the cover, why do we need the
hash as a separate cryptosystem. 

Adding hash-IDs, and the like, is the class of changes that will
completely change the Kerberos protocol, I would prefer to do such
changes in the extensions.

Sam Hartman wrote:
> Agreed.  I'll point out that at the same time we should negotiate the
hash used to authenticate the initial 
> message.

What do we gain by doing that?

-- Larry

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Tuesday, October 19, 2004 11:07 AM
To: Paul Leach
Cc: Liqiang(Larry) Zhu; [email-masked]; [email-masked]
Subject: Re: Deriving a symmetric key from the DH key

>>>>> "Paul" == Paul Leach <[email-masked]> writes:

    Paul> No, I didn't agree with this. get_mic is not a hash. A hash
    Paul> may be embedded in its output, but the presence of other
    Paul> bits (such as sequence numbers, version numbers, etc) is
    Paul> allowed and I believe common, and if so makes it not
    Paul> suitable as a hash for creating keys.

Good catch.  *Oops.*

---

From: Sam Hartman <[email-masked]>
Date: Tue, 19 Oct 2004 14:22:32 -0400

>>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu <[email-masked]> writes:

    Liqiang(Larry)>  Get_mic() can be a hash, and this proposal only
    Liqiang(Larry)> accepts those unkeyed get_mic() operations that
    Liqiang(Larry)> are hashes. See below.

O, so you did.  I even looked at that change although I thought you
were more concerned with making sure that h was a cryptographically
strong hash than that h had no extra bits or structure.