Subject: Consensus Call: static-static DH

From: [email-masked] (Sam Hartman)
Date: Wed, 28 Jul 2004 11:23:44 -0400 (EDT)

One more question pops up: where does the KDC want to send back its
nonce for the static-static DH.  Note that PA-PK-AS_REP is a choice,
and in the DH case there is nothing outside the signedData.  Do we
need to add a new arm to the choice containing a sequence of
signedData and the nonce?  This is the only solution I see.

I'd like to make sure we have agreement on the open issues for
static-static DH before I work on text.  If you disagree with any of
the following please let us know:

* We'll use Paul's proposed key combination function.  That is, the
  KDC and client nonces are combined and we use a counter without CBC
  mode.  I like this better because there's no guarantee that the
  output of the PRF is the same length as the key, so I don't think
  Larry's construction is guaranteed to actually work..  (k_dh would
  not be the same length as k_i).  Larry talked to some crypto folks
  at Microsoft and they didn't believe that CBC was necessary, or at
  least that's how I read the response.

* In addition to the client nonce, kdc nonce and counter, we concat in
  the  the encoding of the pkAUthenticator.

* We add a field to PA-PK-AS-REQ for the client static DH nonce.  If
  this field is included the client wants to use cached parameters and
  supports the feature.

* We recommend that the nonces be the output of a cryptographically
  strong PRNG.

* We say clients that support DH should support cached DH parameters.

* We say KDCs MAY support cached DH parameters.

* Cached DH parameters should not live longer than 10 hours.  This
  number is arbitrary but should be long enough to avoid performance
  problems of DH.