Subject: RE: static-static DH and pkinit

From: "Paul Leach" <[email-masked]>
Date: Mon, 26 Jul 2004 14:33:57 -0700

Comments inline...

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Monday, July 26, 2004 1:09 PM
To: [email-masked]
Cc: Paul Leach
Subject: static-static DH and pkinit

Before proposing text I'd like to make sure we are agreed on a
solution .  Also, there is one question I have.

First, remember that the crypto framework has a function prf(key,
string) that takes arbitrary length inputs and yields some fixed size
output.

Let n_c be a nonce contributed by the client.  Let n_k be the nonce
contributed by the kdc. Let c be the minimum number of PRF output blocks
required to get enough bits for input to the random to key function.

Let k_dh be a protocol key that we get from truncating the DH output and
running through random to key.

[pjl] is running the DH through rand2key necessary, when its just being
fed back into the prf?

k_i = prf(k_dh, n_c|i) xor prf(k_dh, n_k|i)

[pjl] Is this also provable: k_i = prf(k_dh, n_c|n_k|i)? It's a little
simpler, and a little faster (though that's not a major consideration).

Where | is  concatenation
k = k_0|...|k_c

We then truncate k to  the right number of bits and run through random
to key.

I believe this solution is provably secure given reasonable
assumptions for prf and given reasonable assumptions about the
security of kcrypto.

Question: how do we choose n_c and n_k?

[pjl] The output of a crypto-strength pseudo-random-number-generator.

Do we want to add some field in the pkinit values for these to be
transmitted?
[pjl] Yes.

ALso, how do we want to indicate we are using cached DH values?

[pjl] By the presence of the above fields? If fresh DH parameters are
chosen each time, then the nonces aren't necessary.

Finally: what level of support is required?  Is this a clients MAY
implement cached DH, SHOULD implement or MUST implement.  (Well, if
it's a MUSt, it should only apply to clients that implement DH at all)

[pjl] I'd be happy with SHOULD. 

Thanks,

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Mon, 26 Jul 2004 18:00:25 -0400

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

     > Comments inline...  -----Original Message----- From: Sam
     > Hartman [mailto:[email-masked]] Sent: Monday, July 26, 2004
     > 1:09 PM To: [email-masked] Cc: Paul Leach Subject:
     > static-static DH and pkinit

     > First, remember that the crypto framework has a function
     > prf(key, string) that takes arbitrary length inputs and yields
     > some fixed size output.

     > Let n_c be a nonce contributed by the client.  Let n_k be the
     > nonce contributed by the kdc. Let c be the minimum number of
     > PRF output blocks required to get enough bits for input to the
     > random to key function.

     > Let k_dh be a protocol key that we get from truncating the DH
     > output and running through random to key.

     > [pjl] is running the DH through rand2key necessary, when its
     > just being fed back into the prf?

Yes, although note that rand2key is mostly a type cast operation; the
AES draft simply copies the random bitstring to the output key.

     > [pjl] Is this also provable: k_i = prf(k_dh, n_c|n_k|i)? It's a
     > little simpler, and a little faster (though that's not a major
     > consideration).

Yes, I believe this is fine.

     > pseudo-random-number-generator.

Sounds good to me.

     > Do we want to add some field in the pkinit values for these to
     > be transmitted?  [pjl] Yes.

     > [pjl] By the presence of the above fields? If fresh DH
     > parameters are chosen each time, then the nonces aren't
     > necessary.

If that works for people that sounds good to me.  I was concerned
someone might object to adding two fields.

     > Finally: what level of support is required?  Is this a clients
     > MAY implement cached DH, SHOULD implement or MUST implement.
     > (Well, if it's a MUSt, it should only apply to clients that
     > implement DH at all)