RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt

["Housley, Russ" <rhousley@rsasecurity.com>]

Paul:

>  >> The draft asks that IKE detect and correct collisions in truncated
>  >> SPI values.  To comply with this request, IKE implementations
>  >> would need to change their behavior.  I strongly suspect that it
>  >> would be best to avoid any need to change IKE!
>
>  Housley,> I do not believe that this is correct.  It is my
>  Housley,> understanding that IKE establishes a separate key for
>  Housley,> encryption and decryption on the SA.  This whole discussion
>  Housley,> applies only when the same key is used for encryption and
>  Housley,> decryption.
>
>You should doublecheck this because my memory is getting rather rusty
>here, but as I recall IKE will produce the same key for both
>directions IF you use the same SPI.  That's because the key is
>produced from a hash that takes as inputs the phase 1 result (D-H and
>all that) along with the chosen phase 2 SPI number.  If both sides
>allow the same number to be used then the same key results.
>
>The reason I remember this is that I ran into it when implementing
>IPsec a few years ago, decided this was NOT a Good Thing, and took
>steps to enforce different SPI values for the two directions.

Good catch.

I have changed the security considerations to reflect this situation.  Here 
is the new text:

    Therefore, stream ciphers, including AES-CTR, should not be used with
    statically configured keys.  It is inappropriate to use AES-CTR with
    statically configured keys.  Extraordinary measures would be needed
    to prevent reuse of a counter block value with the static key across
    power cycles.  To be safe, implementations MUST use fresh keys with
    AES-CTR.  The Internet Key Exchange (IKE) protocol [IKE] can be used
    to establish fresh keys.

    When IKE is used to establish fresh keys between two peer entities,
    separate keys are established for the two traffic flows when each
    participant provides a different SPI values.  However, if each
    participant provides the same SPI value, then the same key will be
    used for encrypting outbound traffic and decrypting incoming traffic,
    resulting in a high probability that the participants will select the
    same IV values for some packets.  Therefore, when IKE is used with
    AES-CTR, the two participants MUST select different SPI values.

    When a mechanism other than IKE is used to establish fresh keys, and
    that mechanism establishes only a single key to encrypt packets, then
    there is a high probability that the peers will select the same IV
    values for some packets.  Thus, to avoid counter block collisions,
    ESP implementations that permit use of the same key for encrypting
    outbound traffic and decrypting incoming traffic with the same peer
    MUST ensure that the two peers assign different SPI values to the
    security association (SA).  Further, since the counter block only
    contains the least significant 24 bits of the SPI value, such
    implementations MUST ensure that the two SPI values differ in the
    least significant bits.

Russ