[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
A comment from the co-chair
All,
The misrepresentations in the notes below are unproductive and
unwarranted. The ongoing personal attacks on the chairs and other members
of the WG from Bill Simpson are not acceptable behavior in this or any
other IETF WG. In future, notes that contain personal attacks will be
ignored in toto by the chairs. If Bill keeps up his current behavior, we
suggest putting all incoming mail from Bill into /dev/null using a kill
file or other similar mechanism. We suggest that others on the list ignore
the entire contents of all notes containing personal attacks and simply
don't respond to them or their author.
It is entirely unproductive to focus on perceptions of history. Instead
the discussions should focus on the technical issues before us so that
forward progress can be made. Discussions about history, who said what
when to whom and so on cannot be objectively confirmed and only cause
confusion, contention and divisiveness. They are not productive.
As to what Ran has said or what Ran believes, Bill's assertions are quite
false. Ran is fairly confused as to how Bill came to his misperception of
the facts. Ran's comments quoted below about the inappropriateness of
Bill's draft to alter the AH specification clearly indicates that it is a
problem of scoping. AH/ESP specification changes MUST NOT be attempted by
any key management proposal. Rather, the key management proposals MUST
conform to the AH/ESP specs. If the WG later decides to modify the AH/ESP
specs at some time, then the key management specs can be correspondingly
modified at that future time.
The WG chairs understand from the LA IETF meeting that keyed integrity on
the protected data of the ESP header is part of the mandatory ESP
transform. Similarly, it is our understanding that implementation of
support for replay protection as part of ESP is mandatory. Finally,
understanding that WG consensus is that the RFC-1829 transform should be
obsoleted on the standards track by a new ESP transform. The new transform
will have a new transform identifier so as to avoid confusion with
RFC-1829. The WG chairs have assigned the Document Editor position for
that new ESP transform to Jim Hughes. The new transform will correct these
deficiencies in RFC-1829. Once that new transform moves to Proposed
Standard, RFC-1829 will move to HISTORIC status and leave the standards
track.
RFC-1825 through RFC-1828 are not yet able to be considered for
advancement to Draft Standard under IETF rules because of the cross
dependencies among each other and with the ESP transform. They can be
considered for advancement once the new ESP transform has been at Proposed
Standard for 6 months and has at least 2 interoperable implementations.
As none of the current Key Management proposals currently meet WG
requirements (though all could be modified to meet WG requirements), none
can proceed to Last Call or onto the Standards Track at this time.
It is the prerogative of Working Group Chairs to decide who may edit
documents for their working group.
Bill Simpson's behavior is incompatible with the requirements of Document
Editor for documents to be considered by the IPSEC Working Group for the
IETF Standards Track. Documents edited by Bill will not be considered by
the Chairs for consideration in the IPSEC Working Group. This does not
preclude others from listing Bill as co-author on documents in which he has
made significant technical contributions.
Randall Atkinson
rja@inet.org
Co-Chair, IP Security WG
PS: Any complaints about this note should be directed at the Security AD,
Jeff Schiller <jis@mit.edu>.
[Quoted notes follow]
----------------------------------------------------------------------
From: wsimpson@greendragon.com (William Allen Simpson)
To: ipsec@TIS.COM
Subject: AH and ESP Orthogonality
Message-ID: <5041.wsimpson@greendragon.com>
Date: 11 Mar 96 22:07:45 GMT
For the past several years, this WG (and others such as SIP, SIPP, and
IPng, and other protocol designers such as SSL) strongly supported
orthogonality between the Authentication and Encapsulation (both privacy
and compression) facilities.
Recently, the WG chairs (without any stimulating WG comments) have tried
to move the WG toward a non-orthogonal all-in-one approach for ESP.
Last week, Ran Atkinson stood at the microphone, and stated (without
elaboration) that his previous support for an orthogonal approach was "a
serious mistake".
I ask, what was the mistake?
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
----------------------------------------------------------------------
From: wsimpson@greendragon.com (William Allen Simpson)
To: ipsec@TIS.COM
Subject: Re: Alternative transform encapsulation scheme
Message-ID: <5040.wsimpson@greendragon.com>
Date: 11 Mar 96 21:42:41 GMT
Lines: 43
> From: smb@research.att.com
> Date: Sat, 09 Mar 96 14:48:32 EST
>
> There's a lot that needs to be rethought. I could quite easily be
> persuaded that we shouldn't -- we've got to get this stuff
> deployed ASAP.
I'm with Bellovin on this. I don't think we need a non-orthogonal
transform (even though I've written a draft).
The deployed AH-MD5 + ESP-DES is adequate.
> that we should simply decree that ESP
> must be used only in conjunction with AH
We already did, when the ESP transform doesn't provide integrity!!!
In addition to the numerous references in RFC-1825, -1826, and -1827,
RFC-1829 (ESP-DES) clearly states:
The usual (ICMP, TCP, UDP) transport checksum can detect
this attack, but on its own is not considered cryptographically
strong. In this situation, user or connection oriented integrity
checking is needed [RFC-1826].
And you promised to write up a more thorough analysis of your attack....
> One small change -- the addition of replay protection --
> does seem to be needed, though.
>
Why? Doesn't the underlying transport _already_ protect against replay?
That is, TCP and ICMP already protect themselves against replay.
So, you are recommending that the next version of -1826 provide a replay
prevention mechanism? We've discussed this before, but Atkinson was
opposed.
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
----------------------------------------------------------------------
From: wsimpson@greendragon.com (William Allen Simpson)
To: ipsec@TIS.COM
Subject: Re: AH and ESP Orthogonality
Message-ID: <5044.wsimpson@greendragon.com>
Date: 12 Mar 96 00:26:58 GMT
Lines: 33
> From: smb@research.att.com
> We therefore have a situation where ESP must be used in conjunction with
> AH, and no document saying so.
Hmmm, perhaps I am mistaken, but as I have already quoted the "documents
saying so" in a previous message, do I need to quote them again?
Why do you think that the documents don't say so? Is there a suggestion
you could make to improve the text?
> Worse yet, we're paying the overhead
> price for a new header twice.
>
True. That was the tradeoff for orthogonality. It was 8 bytes for AH.
But, if we also require AH for message origin authentication, while ESP
provides integrity, we haven't saved anything. As noted by Bob Baldwin
last week, we have a bigger hit for processing costs, too.
So, which do you prefer? 33% slower processing???
Look folks, we discussed this all last year. We knew about the cut and
paste attack before we wrote the documents. We referenced the Bellovin
presentation in the documents.
The "mistake" that Atkinson made MUST be something else that we didn't
already know about.
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
----------------------------------------------------------------------
From: wsimpson@greendragon.com (William Allen Simpson)
To: ipsec@TIS.COM
Newsgroups: cisco.external.ietf.ipsec
Subject: Re: AH and ESP Orthogonality
Message-ID: <5048.wsimpson@greendragon.com>
Date: 12 Mar 96 13:25:54 GMT
Lines: 45
> From: "Perry E. Metzger" <perry@piermont.com>
> William Allen Simpson writes:
> > Look folks, we discussed this all last year. We knew about the cut and
> > paste attack before we wrote the documents.
>
> Actually, we didn't during the initial drafts,
Ah, Perry, but I beg to differ. We knew about general cut and paste
against CBC _long_ before we wrote the drafts. It is a "feature" of
CBC itself.
Atkinson always had words in his drafts about the need for integrity.
There was always a strong consensus for providing integrity.
Bellovin merely described a specific scenario last April where cut and
paste was a problem, and integrity was required. We added words to that
effect to our documents.
> and we were discussing
> combined transforms as long ago as Toronto, though we didn't envision
> making them mandatory at the time.
>
Yes, we were! And we _decided_ as a WG _not_ to use them, that
orthogonality was better!
> Anyway, lets just consider the situation on its current technical
> merits, and not try to figure out who said what when...
>
My point is that we are rehashing old arguments, and undermining the
good work and deployment that this WG generated.
There has been no demonstrated need to eliminate orthogonality, and
worse, it has been shown to be computationally problematic.
What is the NEW attack, that we had not previously considered, that
would require a removal of orthogonality?
What was Atkinson's "serious mistake"?
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
----------------------------------------------------------------------
From: wsimpson@greendragon.com (William Allen Simpson)
To: ipsec@TIS.COM
Newsgroups: cisco.external.ietf.ipsec
Subject: Re: AH and ESP Orthogonality
Message-ID: <5053.wsimpson@greendragon.com>
Date: 12 Mar 96 18:15:56 GMT
Lines: 67
> From: Stephen Kent <kent@bbn.com>
> Having orthogonal transformations was not necessarily a bad idea,
> but there are benefits to having a better division of responsibility
> between AH and ESP.
I agree.
> For example, the current definition of AH is messy
> because either AH covers the entirity of an IP datagram (minus mutuable IP
> header fields) or it covers just upper layer protocols. The distinction is
> a function of where AH appears relative to ESP. Several of us would prefer
> a verison of AH that applied to the whole datagram (as described above),
> period.
>
I understand. You raised this last year. But, other analysts prefered
the AH "inside" ESP approach. So, there was no agreement. Instead,
a flexible mechanism was defined, and the orthogonality allowed both
approaches.
Indeed, the chairs dictated to Jim Hughes in his DES+MD5 draft that the
MD5 apply to the "inside" plaintext, rather than the "outside"
ciphertext. There were objections raised from the WG, such as Karn.
Outside allows detection of modification sooner, rather than after DES.
As you may remember, I'm an "outy" myself.
> It might be preferable if ESP defined
> optional, variable length fields for carrying the necessary data to support
> confidentiality and authentication and integrity. The specific fields used
> for a given SA would be defined at SA establishment, nailing this down for
> efficient per-packet processing. The result would be to make transform
> definition documents more modular.
>
The result would be to make the transform documents much more difficult
to understand and implement. The WG rejected the variable fields
approach yet _again_ last week.
Instead, we nail down the specific _transforms_ at SA establishment.
Same result, easier to implement, easier to verify.
> Several folks, including yours truly, have expressed a desire to
> add an anti-replay feature into the IPSEC suite. This could be useful in
> either AH or ESP, or both.
I'm included in that "several folks". We discussed this last year, and
again in January of this year. It's in our latest ESP revision, and in
Photuris Extensions. But, as you may remember Atkinson's message:
Date: Thu, 22 Feb 1996 12:29:13 -0800
Message-Id: <199602222029.MAA00276@puli.cisco.com>
5) Section 2.11 of draft-ietf-ipsec-photuris-ext-01.txt MUST be deleted.
It is WAY outside the scope of Bill's draft to modify any standards
track protocol and the attempt to do so is more than sufficient grounds
to bar publication as ANY kind of RFC until that section is deleted.
So, the chairs are rather vehemently against adding replay protection,
even as a negotiated option.
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
----------------------------------------------------------------------