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

From: "Paul Leach" <[email-masked]>
Date: Tue, 19 Oct 2004 12:11:38 -0700

I'm confused about a bunch of stuff.

1. How will implementations know this (that it has no extra structure)
about H?
2. I thought that putting in seq numbers etc in the get_mic output for
replay detect etc was both common and a good way to do so -- what
replaces that.

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

 Sam Hartman wrote:
> that h had no extra bits or structure.

Agreed. This should be clarified as follows.

   H is selected by the client.  H MUST be cryptographically 
   strong (e.g. H(octet string)->octet string = get_mic(dummy-key)
   SHALL NOT have extra structures in the output), otherwise 
   the KDC MUST return error code KDC_ERR_PA_CHECKSUM_TOO_WEAK (77). 

Larry

---

From: Sam Hartman <[email-masked]>
Date: Tue, 19 Oct 2004 15:48:35 -0400

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

    Paul> I'm confused about a bunch of stuff.  1. How will
    Paul> implementations know this (that it has no extra structure)
    Paul> about H?  

pkinit implementation will have to know what unkeyed checksums they support.
This is not ideal.

    Paul> 2. I thought that putting in seq numbers etc in
    Paul> the get_mic output for replay detect etc was both common and
    Paul> a good way to do so -- what replaces that.

As Larry said, not provided by kcrypto.  Also note that while adding
randomness may be useful for certain types of keyed checksum, I cannot
see its benefit for unkeyed checksums.