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

["David A. Mcgrew" <mcgrew@cisco.com>]

Russ,

> -----Original Message-----
> From: Housley, Russ [mailto:rhousley@rsasecurity.com]
> Sent: Tuesday, August 06, 2002 12:02 PM
> To: David A. Mcgrew
> Cc: ipsec@lists.tislabs.com
> Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt
>
>
> 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.

Ah, I understand.  I didn't get this from my read of the draft, but you're
right.

David