Re: Counter Mode: Proposed Way Forward

[Charlie_Kaufman@xxxxxxxxxxxxxxxx]

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.

More substantially, if the IKE SA and the ESP SA both negotiate CTR mode,
they will end up with the same nonces (though with different keys). Is that
a problem? (In practice no; what about in theory?)

          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).