Subject: RE: static-static DH and pkinit

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 26 Jul 2004 13:58:43 -0700

Sam Hartman wrote:
>  k_i = prf(k_dh, n_c|i) xor prf(k_dh, n_k|i) Where | is  
> concatenation k = k_0|...|k_c

Try something CBC alike:

k_0 = prf(k_dh, n_c|i) xor prf(k_dh, n_k|i)
K_(i+1) = k_i = prf(k_i, n_c|(i+1)) xor prf(k_i, n_k|(i+1))

Can you also hash in the whole pkauthenticator value (before it is
signed), 
thus we can garanetee the session key is not reused. 

> 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?

Add a flags (bitstrings) field to pkAuthenticator and allocate a bit to 
indicate that the client will accept cached DH values. 

Can the client enforce it (by using a y-value-reply cache) that KDC
does not use a cached value? Or vice versa? I guess yes if you can 
hash the timestamps as I assugested above.

and we need to make the nonce large enough (the nonce in draft -20 
is too small) and the number of bits in the nonce field should be at 
least as large as the # of bits in the shared key.

Note that the nonce in AS_REQ is a UINT32 and may not be sufficient.

> what level of support is required?  Is this a clients MAY implement 
>cached DH, SHOULD implement or MUST  
>implement.  

How useful is this?

> (Well, if it's a MUSt, it should only apply to clients 
> that implement DH at all)

I think it is more useful if the client can make sure that the KDC 
MUST not use a cached Y when the client does not indicate it will 
accept cached DH. We should also recommend how long a cached Y can 
be re-used. 

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Monday, July 26, 2004 10:09 AM
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.
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: Sam Hartman <[email-masked]>
Date: Mon, 26 Jul 2004 17:10:17 -0400

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

    >> concatenation k = k_0|...|k_c

    Liqiang(Larry)> Try something CBC alike:

I don't know how to do security proofs for this; I know how to do
security proofs for what I proposed.  What advantage do you hope to
get out of something CBC-like?

    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.

Sure, that's fine too.

    >> 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?

    Liqiang(Larry)> Add a flags (bitstrings) field to pkAuthenticator
    Liqiang(Larry)> and allocate a bit to indicate that the client
    Liqiang(Larry)> will accept cached DH values.

    Liqiang(Larry)> Can the client enforce it (by using a
    Liqiang(Larry)> y-value-reply cache) that KDC does not use a
    Liqiang(Larry)> cached value? Or vice versa? I guess yes if you
    Liqiang(Larry)> can hash the timestamps as I assugested above.

    Liqiang(Larry)> and we need to make the nonce large enough (the
    Liqiang(Larry)> nonce in draft -20 is too small) and the number of
    Liqiang(Larry)> bits in the nonce field should be at least as
    Liqiang(Larry)> large as the # of bits in the shared key.

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

Do we want to use an octet-string for the nonce.?

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 26 Jul 2004 16:25:55 -0500

>     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
--