[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: replay and insecure security implementations
> From: Steven Bellovin <smb@research.att.com>
> > The new
> > sequence number, though syntactically the same as the original swIPe
> > version, has a totally different purpose.
> >
> As much as it pains me, I have to disagree. Here is the text from
> the swIPe internet-draft in 1993:
>
> This doesn't at all contradict what I said. If you're doing any sort
> of replay prevention in a security context, it's to deter replay attacks.
>
Yes, then we agree -- swIPe had a sequence number and its purpose was
replay prevention. I thought that you were saying that it did not.
The purpose of the ESP Sequence Number is also for replay prevention.
I don't see how that is in any way different from swIPe?
> The question is what sort of attacks, and to what end. My statement
> was based on discussions with Blaze and Karn. No one mentioned
> the sorts of attacks I discussed in my papers.
>
Pardon? Why would we be concerned with "sorts of attacks"?
If someone developed a cipher, and made it resistant to differential
cryptanalysis, and 20 years later someone came out with linear
cryptanalysis, but the old cipher is also very resistant to linear using
the exact same mechanisms, would the original designer think the original
mechanisms were a failure? Or that the cipher suddenly had a whole
different purpose?
The purpose of the sequence number is to prevent replay, whether that
replay is from an outsider with no legitimate access to the keys, or an
insider with illegitimate access to the keys.
Maybe the reason nobody mentioned the sorts of attacks that you
mentioned in your paper is because they had already decided that any
"good" security implementation would not be subject to that attack?
We had already written that the keys must be segregated and that
sequence numbers be generated. There was a loud complaint against
segregating keys from certain vendors, and vigorous argument about
needing sequence numbers from others. But, that didn't make us any less
correct in the long run....
Do all possible attacks need to be known before any design can begin?
There is a certain IRTF group that took that approach, but IMnsHO that
isn't good engineering practice.
> User- or connection-oriented keying are excellent defenses against this
> attack. They're not always practical, especially if outboard (router-based
> or bump-in-the-cord) encryption is used.
>...
> Yes. So what? Segregating keys -- and my Danvers presentation was
> intended to justify precisely that policy -- is a defense. Sequence
> numbers are another defense that in some contexts work better.
At this point, I'd say we should take this off-list, as I cannot figure
out why we are disagreeing or even whether we _are_ disagreeing. Also,
I see no relevance of these semantic discussions to the protocol
specifications or implementations.
WSimpson@UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2