Russ Housley <housley@xxxxxxxxxxxx> wrote:
> Your proposal obviously works too, but it exceeds the requirements.
>
> Do others agree with the conclusion from the discussions in Atlanta? Or,
> do others like the suggestion made by Paul?
>
> Since both obviously meet the requirements, the structure of existing
> implementations should probably guide us. The people that I talked to in
> Atlanta saw no problem with the use of IKE nonces.
From an "elegance" perspective, I prefer Paul's proposal (getting the
counter mode parameter from the keying material), and I see no practical
downside. But I also don't think it matters, so if you have a working
consensus, go for it!
Two nits:
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.
Nonces are bit strings rather than integers, so I believe the more correct
wording is the "final 32 bits" of the nonce rather than the least
significant. If the counter block is an integer, some endian-ness may need
to be specified in the translation.