Re: Counter Mode: Proposed Way Forward

[Russ Housley <housley@xxxxxxxxxxxx>]

I updated the AES Counter Mode draft.  It should be posted as soon as the 
repository administrator returns from the holiday break.  The document 
describes the use of a nonce as previously discussed on the list.  And, a 
new section describes the way that IKE can provide the nonce.  This is the 
only part that has not already been discussed on the list, so I am posting 
it here to foster discussion.

5. IKE Conventions

   As described in section 2.1, implementations MUST use fresh keys with
   AES-CTR.  The Internet Key Exchange (IKE) [IKE] protocol can be used
   to establish fresh keys.  IKE can also provide the nonce value.  This
   section describes the conventions for obtaining the unpredictable
   nonce from IKE.

   The IKE_SA_init and the IKE_SA_init_response each contain a nonce.
   These nonces are used as inputs to cryptographic functions.  The
   CREATE_CHILD_SA request and the CREATE_CHILD_SA response also contain
   nonces.  These nonces are used to add freshness to keys for child
   security associations.  In both cases, these nonces are
   unpredictable, they are longer than 32 bits, and IKE transfers the
   nonce value to the peer.

   Each party will use the nonce that it generated for encryption, and
   the nonce that the other party generated for decryption.  The 32
   least significant bits of the nonce used to establish the security
   association will be used in the AES-CTR counter block.  For the first
   security association, the nonces come from the IKE_SA_init and
   IKE_SA_init_response.  For subsequent security associations, the
   nonces come from the CREATE_CHILD_SA request and CREATE_CHILD_SA
   response.

Enjoy,
  Russ