>>>>> "Russ" == Russ Housley <housley@xxxxxxxxxxxx> writes:
Russ> I updated the AES Counter Mode draft. It should be posted as Russ> soon as the repository administrator returns from the holiday Russ> break. The document describes the use of a nonce as previously Russ> discussed on the list. And, a new section describes the way Russ> that IKE can provide the nonce. This is the only part that has Russ> not already been discussed on the list, so I am posting it here Russ> to foster discussion.
Russ> 5. IKE Conventions
Russ> As described in section 2.1, implementations MUST use fresh Russ> keys with AES-CTR. The Internet Key Exchange (IKE) [IKE] Russ> protocol can be used to establish fresh keys. IKE can also Russ> provide the nonce value. This section describes the Russ> conventions for obtaining the unpredictable nonce from IKE.
Russ> The IKE_SA_init and the IKE_SA_init_response each contain a Russ> nonce. These nonces are used as inputs to cryptographic Russ> functions. The CREATE_CHILD_SA request and the CREATE_CHILD_SA Russ> response also contain nonces. These nonces are used to add Russ> freshness to keys for child security associations. In both Russ> cases, these nonces are unpredictable, they are longer than 32 Russ> bits, and IKE transfers the nonce value to the peer.
Russ> Each party will use the nonce that it generated for encryption, Russ> and the nonce that the other party generated for decryption. Russ> The 32 least significant bits of the nonce used to establish Russ> the security association will be used in the AES-CTR counter Russ> block. For the first security association, the nonces come Russ> from the IKE_SA_init and IKE_SA_init_response. For subsequent Russ> security associations, the nonces come from the CREATE_CHILD_SA Russ> request and CREATE_CHILD_SA response.
Why not simply use some more of the generated key material for the nonce? That seems a lot cleaner than reaching into the internals of IKE for the bits you need.
paul