Re: Counter Mode: Proposed Way Forward

[Russ Housley <housley@vigilsec.com>]

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