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

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

David:

> > >In Section 6 the draft says:
> > >
> > >    "Thus, to avoid counter block collisions, ESP implementations that
> > >    permit use of the same key for encrypting and decrypting packets
> > >    with the same peer MUST ensure that the two peers assign different
> > >    SPI values to the security association (SA)."
> > >
> > >Is it actually kosher for two SAs to share the same keys?  SAs are
> > >simplex per RFC 2401, though they could in principle share a single
> > >key.  However, I'd expect that if the architecture allowed such
> > >key-sharing that it would require that the SAs be in the same SA
> > >bundle so that when one SA reaches it usage limit its twin gets
> > >deleted as well.  I'm not aware of any such language, which makes me
> > >suspicious about using the same keys twice.
> >
> > I tried to point out that IKE would not generate such an SA.  However,
> > there are serious security concerns if the same key streams are used for
> > encryption and decryption.  I just wanted to make sure that no
> > one did such
> > a thing!
>
>Using the same counter mode key across multiple SAs is potentially
>dangerous, and the draft needs to be explicit on this.  It's my impression
>that using the same key across multiple SAs is a false economy; I know many
>that agree with this statement, and a few that disagree with it.  I don't
>care much either way, but we certainly need to make it clear to future
>implementers what they cannot do.
>
>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!

I do not believe that this is correct.  It is my understanding that IKE 
establishes a separate key for encryption and decryption on the SA.  This 
whole discussion applies only when the same key is used for encryption and 
decryption.

Again, this paragraph was included to warn people who are using key 
management other than IKE.

Russ