Subject: RE: static-static DH and pkinit

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

Sam Hartman wrote:

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

Since everybody else does the pseduo-CBC-alike-with-feedback algorithms,
I guess why not here?

Let me send a email to Dan Simon to see what he thinks too. It might be
that the difference is marginal.

Also I had a typo in my earlier email and the algorithm should look
like:

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

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

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

We can actually reuse the nonce fields in the pkAuthenticator and
KDCDHKeyInfo, 
we just need to make them sufficiently large.

Making the nonce field of type OCETET string will be easier to
implement.

This is because after we added the paChecksum in pkAuthencatior (and
therefore broke backward wire-compatibility), the nonce in the normal
AS_REQ now cryptographically binds the AS-REP with AS-REQ, these two
PKINIT nonces are left in limbo and I do not know what the value it
provides now. 

I would suggest that the nonce in KDCDHKeyInfo is now NOT an echo of the
nonce in pkAuthenticator (but is randomly generated by the KDC), both of
these nonces should be OCTET strings with length >= the min key length
of the requested etypes.

What do you think?

Larry

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

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

    Liqiang(Larry)> 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

    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: Sam Hartman <[email-masked]>
Date: Mon, 26 Jul 2004 17:55:27 -0400

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

    >> 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)> Since everybody else does the
    Liqiang(Larry)> pseduo-CBC-alike-with-feedback algorithms, I guess
    Liqiang(Larry)> why not here?

    Liqiang(Larry)> Let me send a email to Dan Simon to see what he
    Liqiang(Larry)> thinks too. It might be that the difference is
    Liqiang(Larry)> marginal.

So, Nico points out that the security proof actually works either way.
I don't object to the CBC-based solution although I don't currently
see the point.