Subject: static-static DH and pkinit

From: [email-masked] (Sam Hartman)
Date: Mon, 26 Jul 2004 13:08:56 -0400 (EDT)

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.
k_i = prf(k_dh, n_c|i) xor prf(k_dh, n_k|i)
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?  Do we want to add some field
in the pkinit values for these to be transmitted?  ALso, how do we
want to indicate we are using cached DH values?

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)

Thanks,

--Sam

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 26 Jul 2004 14:41:53 -0700

Nicolas Williams wrote:
> I would say: pattern this after the IKEv2 key derivation algorithm.

This sounds good to me. If we reuse existing stuffs within the framework
of IETF: the IP issue has been dealt with at least once.

Larry

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Monday, July 26, 2004 2:26 PM
To: Sam Hartman
Cc: Liqiang(Larry) Zhu; [email-masked]; Paul Leach
Subject: Re: static-static DH and pkinit

On Mon, Jul 26, 2004 at 05:10:17PM -0400, Sam Hartman wrote:
> >>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu
<[email-masked]> writes:
>     Liqiang(Larry)> Can you also hash in the whole pkauthenticator
>     Liqiang(Larry)> value (before it is signed), thus we can garanetee
>     Liqiang(Larry)> the session key is not reused.
> 
Sam> Sure, that's fine too.

I would say: pattern this after the IKEv2 key derivation algorithm.

Quotes from the OKEv2 I-D:

"
   ...
   prf+ (K,S) = T1 | T2 | T3 | T4 | ...

   where:
   T1 = prf (K, S | 0x01)
   T2 = prf (K, T1 | S | 0x02)
   T3 = prf (K, T2 | S | 0x03)
   T4 = prf (K, T3 | S | 0x04)

   continuing as needed to compute all required keys. The keys are taken
   from the output string without regard to boundaries (e.g., if the
   required keys are a 256 bit AES key and a 160 bit HMAC key, and the
   prf function generates 160 bits, the AES key will come from T1 and
   the beginning of T2, while the HMAC key will come from the rest of T2
   and the beginning of T3).

   The constant concatenated to the end of each string feeding the prf
   is a single octet. prf+ in this document is not defined beyond 255
   times the size of the prf output.

   ...

       SKEYSEED = prf(Ni | Nr, g^ir)

       {SK_d | SK_ai | SK_ar | SK_ei | SK_er}
                 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )

   ...
"

Note the chaining.

Sam> You only alude to an answer to my question of where do we get n_c 
Sam> and n_k.  You seem to be indicating that the nonce from the draft 
Sam> is not what we want to use.  So, do we add additional fields?  If 
Sam> so, these fields need to be outside the signed structures.
Sam> 
Sam> Do we want to use an octet-string for the nonce.?

OCTET STRING, methinks.

Nico
--