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, July 30, 2002 5:56 AM
> To: David A. Mcgrew
> Cc: ipsec@lists.tislabs.com
> Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt
>
>
> David:
>
> I want to respond to one point that was raised by your exchange
> with Steve
> Kent.
>
> <SNIP>
>
> > > Apparently Cisco has
> > > chosen to offer only low assurance IPsec products, e.g,. FIPS level 2
> > > at most, so the security perimeter is very large and thus the
> > > sequence number can be maintained within that boundary. But, to
> > > impose this assurance-limiting architecture on vendors who might wish
> > > to offer higher security implementations is inappropriate.
> >
> >What ESP implementations don't maintain the sequence number within the
> >security perimeter?   I am not aware of any.  If you are, please let us
> >know.
>
> <SNIP>
>
> The consequences for reusing a sequence number are significantly
> different
> than the consequence of reusing a CTR mode key stream.

Agreed.

> Therefore, I think
> that it is worth a few extra bits of overhead to make sure that the
> per-packet value is managed inside the security boundary.
>
> Russ

But why not make the per-packet value that's managed within the security
boundary be the sequence number?  If an LFSR is used to generate explicit
IVs, then it will need to be generated and managed within the security
boundary.  An LFSR is no easier to manage than an integer, since both types
share the same properties w.r.t. the storage and movement of data.  If the
ESP sequence number is generated within the security boundary, it can be
used to provide secure anti-replay protection as well as secure per-packet
values for counter mode.

David