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