[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
reserved SAID values
Perry, will you please shut up on this issue. If this fellow is such an
asshole that he can't read "for future use", and such an incompetent
that he can't write a draft on how to use one, then he deserves to sink
in his own shit. He's just trying to piggyback on our work.
You, Ran, Jeff, Ted, Deering and I have all said "write a draft".
You are just dragging out the debate, by giving him a prompt to reply.
Just leave it alone. Ignore him until he has a draft. That's how we
work.
> From: Danny.Nessett@eng.sun.com (Dan Nessett)
> the value of this field shall be 0x00000000. The set of SAID values
> in the range 0x00000001 through 0x000000FF are reserved for future
> use.
>
> There is similar language in the ESP I-D. I read this to mean that the
> reserved values are "reserved," i.e., not to be used, since they may
> be used for some unspecified purpose in the future. If the security documents
> are modified to indicate an SAID value that is to mean, "using in-band
> keying," then what you say would be true. However, at present it is not.
>
Bill.Simpson@um.cc.umich.edu
Received: from relay.tis.com by neptune.TIS.COM id aa12011; 28 Feb 96 2:47 EST
Received: by relay.tis.com; id CAA25341; Wed, 28 Feb 1996 02:48:34 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma025338; Wed, 28 Feb 96 02:48:05 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA13608; Wed, 28 Feb 96 02:47:00 EST
Received: by relay.tis.com; id CAA25335; Wed, 28 Feb 1996 02:48:04 -0500
Received: from unknown(194.30.193.159) by relay.tis.com via smap (V3.1)
id xma025333; Wed, 28 Feb 96 02:47:27 -0500
Received: from del.tla.org (root@ppp52.hol.gr [194.30.192.168]) by prometheus.hol.gr (8.6.12/8.6.12) with ESMTP id JAA29040 for <ipsec@tis.com>; Wed, 28 Feb 1996 09:44:19 -0200
Received: from del.tla.org (ji@localhost.tla.org [127.0.0.1]) by del.tla.org (8.7.2/8.6.9) with ESMTP id JAA01763 for <ipsec@tis.com>; Wed, 28 Feb 1996 09:45:19 +0200 (EET)
Message-Id: <199602280745.JAA01763@del.tla.org>
X-Mailer: exmh version 1.6.2 7/18/95
To: ipsec@TIS.COM
Subject: Re: Censure of Mr. Simpson
In-Reply-To: Dan Nesset's message of "Tue, 27 Feb 1996 08:13:53 PST."
<199602271613.IAA18839@elrond.Eng.Sun.COM>
Reply-To: ji@hol.gr
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 28 Feb 1996 09:45:13 +0200
From: John Ioannidis <ji@hol.gr>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
I find this entire debate to be a *personal* attack on Bill Simpson, and not
an attack on his work based on its technical merits. This is simply
unacceptable. I urge everybody involved to calm down and re-evaluate their
positions.
I have stayed silent so far, but I think it is time I spoke up. Remember that
we are primarily a *technical* group (and one in a very important area), and
we cannot allow technical work to be hindered by personal animosity.
Furthermore, whatever Mr. Simpson's failings may be (and I am not necessarily
implying there are any), the behavior of a segment of this working group has
far exceeded what would be considered acceptable, polite, and civilized.
Name-calling and ad hominem attacks have no place here, and some people seem
to have fogotten that.
Besides, summarily rejecting someone's work because of that someone's alleged
personality traits is, to say the least, detrimental to the progress of the
group as a whole.
Mr. Nessett's mail is what prompted my involvement in this thread, so let me
comment on a few points:
> [ Dan Nesset's message of "Tue, 27 Feb 1996 08:13:53 PST." <199602271613.IAA18839@elrond.Eng.Sun.COM> ]
> To the members of the IPSEC working group,
>
> I am no longer active in this group, having moved on to other duties. However,
> based on prior interactions with Mr. Simpson, I fully support the move by
> Paul Lambert to attempt to bring order into the working group proceedings.
So you are admitting that you do not know the particulars of this case, and
that your reasons for wanting Mr. Simpson silenced are personal, not based on
the technical merits of his work. Wonderful!
> As evidence I hereby make public a post Mr. Simpson sent to me in regards
> to in-band keying. I have retained a record of the prior email on this
Maybe my mailer ate it, but there is no date on that message. How recent is
it? If it upset you so much, why didn't you bring it to the immediate
attention of the group? Elementary good manners dictate that you do not make
public a private piece of email without the author's consent. Is *your* proper
behavior a function of other people's behavior? And in any case, I don't see a
PGP (or other) signature. For all we know, you fabricated this.
> topic, which I believe shows Mr. Simpson had no reason to adopt an insulting
> and scurrilous writing style.
I read the piece of mail. I cannot tell from it whether Mr. Simpson had a
reason to adopt what you are calling "insulting and scurrilous." What I see is
that you are making public a private piece of e-mail, an act which I (and many
others, for that matter) consider unethical.
> It is interesting that Mr. Simpson's defender
> in this controversy is Mr. Metzger.
Your point being? You seem to be implying that there is something wrong about
being defended by Mr. Metzger. Whatever your personal animosity towards Mr.
Metzger may be, the fact that he is defending Mr. Simpson does not ipso facto
imply that the defense should be considered invalid.
>
> Dan Nessett
>
/ji
Received: from relay.tis.com by neptune.TIS.COM id aa17280; 28 Feb 96 7:43 EST
Received: by relay.tis.com; id HAA27208; Wed, 28 Feb 1996 07:45:02 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma027203; Wed, 28 Feb 96 07:44:34 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA17291; Wed, 28 Feb 96 07:43:29 EST
Received: by relay.tis.com; id HAA27196; Wed, 28 Feb 1996 07:44:32 -0500
Received: from charrua.bellcore.com(192.4.6.118) by relay.tis.com via smap (V3.1)
id xma027190; Wed, 28 Feb 96 07:44:26 -0500
Received: (from afa@localhost) by charrua.bellcore.com (8.6.9/8.6.10) id HAA00714; Wed, 28 Feb 1996 07:44:58 -0500
Date: Wed, 28 Feb 1996 07:44:58 -0500 (EST)
From: Antonio Fernandez <afa@bellcore.com>
X-Sender: afa@charrua
To: John Ioannidis <ji@hol.gr>
Cc: ipsec@TIS.COM
Subject: Re: Censure of Mr. Simpson
In-Reply-To: <199602280745.JAA01763@del.tla.org>
Message-Id: <Pine.SUN.3.91.960228074355.650D-100000@charrua>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
On Wed, 28 Feb 1996, John Ioannidis wrote:
> I find this entire debate to be a *personal* attack on Bill Simpson, and not
> an attack on his work based on its technical merits. This is simply
> unacceptable. I urge everybody involved to calm down and re-evaluate their
> positions.
>
Right on target JI, and I fully agree with you
Antonio
Received: from relay.tis.com by neptune.TIS.COM id aa20553; 28 Feb 96 10:16 EST
Received: by relay.tis.com; id KAA00131; Wed, 28 Feb 1996 10:18:35 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma000126; Wed, 28 Feb 96 10:18:08 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA25565; Wed, 28 Feb 96 10:17:03 EST
Received: by relay.tis.com; id KAA29999; Wed, 28 Feb 1996 10:18:06 -0500
Received: from labs-n.bbn.com(128.89.0.100) by relay.tis.com via smap (V3.1)
id xma029989; Wed, 28 Feb 96 10:17:48 -0500
Received: from ARA20.BBN.COM by LABS-N.BBN.COM id aa21094; 28 Feb 96 10:15 EST
X-Sender: kent@eudora.bbn.com (Unverified)
Message-Id: <v02130503ad5a1bdca271@[128.89.30.29]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 28 Feb 1996 10:17:48 -0500
To: ji@hol.gr
From: Stephen Kent <kent@bbn.com>
Subject: Re: Censure of Mr. Simpson
Cc: ipsec@TIS.COM
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
John,
Let me add my support to Paul's censure of Bill, from the
perspective of someone who has been involved with the IPSEC WG from the
beginning, who has attended a number (though not all) of the Wg meetings,
and who reads most of the mail list traffic. I dislike censuring in this
context, but I have to admit that Bill's actions in this WG have created a
situation that merits such action.
Bill's interaction with people via email is almost always very rude
and intimidating. I have been the target of some of Bill's tirades in
various contexts and have watched him "flame" many others on this and other
mailing lists. This behavior has had a chilling effect on some people,
causing them to contribute less than they might otherwise. The result is
detrimental to the advancement of work in any area and I think we have seen
the effects of that in this WG. Several individuals have approached me
over the last couple of years and noted that they were deterred from
participating in mailing list exchanges becaue of the likelihood of rousing
Bill's ire.
In another vein, Bill's work as a document editor has been a mixed
blessing. The IETF relies on voulenteers to do the real work of standards
production and Bill's offer to write a document contributing to that work
is laudable. However, the work of this group has suffered from very poor
documents in general and several members have cited Bill's documentation of
Photuris as an example of specification that does not facilitate
independent interoperable implementation. Your individual experience to
the contrary, this complaint about Bill's writing still stands. Moreover,
Bill's reluctance to make changes to documents based on direction from the
WG chairs raises serious questions as to his suitability as an editor for a
document of this sort.
You suggest that personal animosity has no place in a technical
group such as this one, yet it is precisely Bill's personal attacks on
individuals that have caused the animosity and resulted in his censure.
Any standards activity is a social activity involving individuals with
differing technical and personal agendas. A successful WG must integrate
these agendas to produce a documents that represent appropriate tradeoffs
arrived at via a technical and social process. Bill's behavior has skewed
this process and this response from the WG chair is a response to this
behavior.
Steve
Received: from relay.tis.com by neptune.TIS.COM id aa22155; 28 Feb 96 11:06 EST
Received: by relay.tis.com; id LAA01703; Wed, 28 Feb 1996 11:08:00 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma001699; Wed, 28 Feb 96 11:07:32 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA29293; Wed, 28 Feb 96 11:06:26 EST
Received: by relay.tis.com; id LAA01696; Wed, 28 Feb 1996 11:07:30 -0500
Received: from mercury.sun.com(192.9.25.1) by relay.tis.com via smap (V3.1)
id xma001685; Wed, 28 Feb 96 11:07:03 -0500
Received: by mercury.Sun.COM (Sun.COM)
id IAA29669; Wed, 28 Feb 1996 08:06:59 -0800
Received: from sabretooth.Eng.Sun.COM (sabretooth-23.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
id AA24361; Wed, 28 Feb 1996 08:06:39 -0800
Received: from elrond.Eng.Sun.COM by sabretooth.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
id IAA10004; Wed, 28 Feb 1996 08:06:34 -0800
Received: by elrond.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
id IAA20108; Wed, 28 Feb 1996 08:05:32 -0800
Date: Wed, 28 Feb 1996 08:05:32 -0800
From: Dan Nessett <nessett@sabretooth.eng.sun.com>
Message-Id: <199602281605.IAA20108@elrond.Eng.Sun.COM>
To: ipsec@TIS.COM, ji@hol.gr
Subject: Re: Censure of Mr. Simpson
X-Sun-Charset: US-ASCII
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
>
> So you are admitting that you do not know the particulars of this case, and
> that your reasons for wanting Mr. Simpson silenced are personal, not based on
> the technical merits of his work. Wonderful!
I believe my post was significant evidence that I do know the particulars of
this case. The censure of Mr. Simpson has nothing to do with the technical
merits of his work. It addresses his unacceptible behavior in the conduct
of IETF work.
> > As evidence I hereby make public a post Mr. Simpson sent to me in regards
> > to in-band keying. I have retained a record of the prior email on this
>
> Maybe my mailer ate it, but there is no date on that message. How recent is
> it? If it upset you so much, why didn't you bring it to the immediate
> attention of the group? Elementary good manners dictate that you do not make
> public a private piece of email without the author's consent. Is *your* proper
> behavior a function of other people's behavior? And in any case, I don't see a
> PGP (or other) signature. For all we know, you fabricated this.
Let me address your points in order. There was a date on the message, it was
Wed Mar 15 06:25:01 1995. I brought it to the attention of the IESG at the
time. If someone writes me a letter threating my life or the well being of my
family, I have no obligation to keep it private. In the same vein, if
someone is employing terrorist tactics to ensure his point of view prevails,
I have no obligation to keep these tactics private. For all you know the
complete record of this working group email list is fabricated. You don't
even know if Dan Nessett sent this message.
> > topic, which I believe shows Mr. Simpson had no reason to adopt an insulting
> > and scurrilous writing style.
>
> I read the piece of mail. I cannot tell from it whether Mr. Simpson had a
> reason to adopt what you are calling "insulting and scurrilous." What I see is
> that you are making public a private piece of e-mail, an act which I (and many
> others, for that matter) consider unethical.
In regards to the ethics of divulging mail sent to me privately, see above.
If you believe there are any circumstances in which the writing style of
the message in question is excusable, then we have no basis for a continued
exploration of this topic.
>
> > It is interesting that Mr. Simpson's defender
> > in this controversy is Mr. Metzger.
>
> Your point being? You seem to be implying that there is something wrong about
> being defended by Mr. Metzger. Whatever your personal animosity towards Mr.
> Metzger may be, the fact that he is defending Mr. Simpson does not ipso facto
> imply that the defense should be considered invalid.
>
The point is that Mr. Metzger's defense of Mr. Simpson may be biased. The
evidence for this is the statement by Mr. Simpson that "He's just trying to
piggyback on our work."
Dan Nessett
Received: from relay.tis.com by neptune.TIS.COM id aa25575; 28 Feb 96 13:30 EST
Received: by relay.tis.com; id NAA05249; Wed, 28 Feb 1996 13:32:06 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma005239; Wed, 28 Feb 96 13:31:38 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA07796; Wed, 28 Feb 96 13:30:33 EST
Received: by relay.tis.com; id NAA05232; Wed, 28 Feb 1996 13:31:36 -0500
Received: from info.forthnet.gr(139.91.1.17) by relay.tis.com via smap (V3.1)
id xma005214; Wed, 28 Feb 96 13:31:06 -0500
Received: from info.forthnet.gr by info.forthnet.gr via FORTHnet with SMTP;
id UAA09233 (8.6.12/FORTHNET-2.0); Wed, 28 Feb 1996 20:28:25 +0200 (EET DST)
Message-Id: <199602281828.UAA09233@info.forthnet.gr>
Organization:
To: Dan Nessett <nessett@sabretooth.eng.sun.com>
Cc: ipsec@TIS.COM, ji@hol.gr
Subject: Re: Censure of Mr. Simpson
In-Reply-To: Your message of "Wed, 28 Feb 1996 08:05:32 PST."
<199602281605.IAA20108@elrond.Eng.Sun.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <9199.825532088.1@forthnet.gr>
Date: Wed, 28 Feb 1996 20:28:09 +0200
From: "Angelos D. Keromytis" <kermit@forthnet.gr>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
In message <199602281605.IAA20108@elrond.Eng.Sun.COM>, Dan Nessett writes:
>
>I believe my post was significant evidence that I do know the particulars of
>this case. The censure of Mr. Simpson has nothing to do with the technical
>merits of his work. It addresses his unacceptible behavior in the conduct
>of IETF work.
>
Speaking for myself, the exerpt you sent didn't prove anything about your
knowledge of the case.
>Let me address your points in order. There was a date on the message, it was
>Wed Mar 15 06:25:01 1995. I brought it to the attention of the IESG at the
>time. If someone writes me a letter threating my life or the well being of my
>family, I have no obligation to keep it private. In the same vein, if
>someone is employing terrorist tactics to ensure his point of view prevails,
>I have no obligation to keep these tactics private. For all you know the
>complete record of this working group email list is fabricated. You don't
>even know if Dan Nessett sent this message.
>
Sending in public private communications without asking permission first sounds
like "terrorist" tactics to me.
>In regards to the ethics of divulging mail sent to me privately, see above.
>If you believe there are any circumstances in which the writing style of
>the message in question is excusable, then we have no basis for a continued
>exploration of this topic.
>
A lot can be said on this, but let's not open a can of worms.
>The point is that Mr. Metzger's defense of Mr. Simpson may be biased. The
>evidence for this is the statement by Mr. Simpson that "He's just trying to
>piggyback on our work."
>
Biased ? I guess cooperating with Mr. Simpson might make someone object to
another's views that it's impossible to work with him.
Again, this seems more like a personal attack than a well thought
action of a WG chair.
-Angelos
Received: from relay.tis.com by neptune.TIS.COM id aa29315; 28 Feb 96 15:52 EST
Received: by relay.tis.com; id PAA07551; Wed, 28 Feb 1996 15:54:29 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma007542; Wed, 28 Feb 96 15:54:06 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA15732; Wed, 28 Feb 96 15:53:01 EST
Received: by relay.tis.com; id PAA07529; Wed, 28 Feb 1996 15:54:03 -0500
Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1)
id xma007512; Wed, 28 Feb 96 15:53:35 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id PAA16286; Wed, 28 Feb 1996 15:54:16 -0500 (EST)
Message-Id: <199602282054.PAA16286@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: Stephen Kent <kent@bbn.com>
Cc: ji@hol.gr, ipsec@TIS.COM
Subject: Re: Censure of Mr. Simpson
In-Reply-To: Your message of "Wed, 28 Feb 1996 10:17:48 EST."
<v02130503ad5a1bdca271@[128.89.30.29]>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Wed, 28 Feb 1996 15:54:08 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Stephen Kent writes:
> The IETF relies on voulenteers to do the real work of standards
> production and Bill's offer to write a document contributing to that work
> is laudable. However, the work of this group has suffered from very poor
> documents in general and several members have cited Bill's documentation of
> Photuris as an example of specification that does not facilitate
> independent interoperable implementation. Your individual experience to
> the contrary, this complaint about Bill's writing still stands.
Are we angry with Bill for being rude, or are we angry with him
because he is a poor writer? I would hate to think that one could be
censured for being a poor writer. I will add, however, that in my
opinion Bill is a very good writer from an implementors perspective.
Perry
Received: from relay.tis.com by neptune.TIS.COM id aa01213; 28 Feb 96 17:06 EST
Received: by relay.tis.com; id RAA08912; Wed, 28 Feb 1996 17:08:30 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma008896; Wed, 28 Feb 96 17:08:02 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA20220; Wed, 28 Feb 96 17:06:56 EST
Received: by relay.tis.com; id RAA08883; Wed, 28 Feb 1996 17:08:00 -0500
Received: from info.forthnet.gr(139.91.1.17) by relay.tis.com via smap (V3.1)
id xma008875; Wed, 28 Feb 96 17:07:53 -0500
Received: from vicky.forthnet.gr by info.forthnet.gr via FORTHnet with SMTP;
id XAA25536 (8.6.12/FORTHNET-2.0); Wed, 28 Feb 1996 23:58:38 +0200 (EET DST)
Message-Id: <199602282158.XAA25536@info.forthnet.gr>
Organization:
To: perry@piermont.com
Cc: Stephen Kent <kent@bbn.com>, ji@hol.gr, ipsec@TIS.COM
Subject: Re: Censure of Mr. Simpson
In-Reply-To: Your message of "Wed, 28 Feb 1996 15:54:08 EST."
<199602282054.PAA16286@jekyll.piermont.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <28513.825544722.1@forthnet.gr>
Date: Wed, 28 Feb 1996 23:58:42 +0200
From: "Angelos D. Keromytis" <kermit@forthnet.gr>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
In message <199602282054.PAA16286@jekyll.piermont.com>, "Perry E. Metzger" writ
es:
>
>Are we angry with Bill for being rude, or are we angry with him
>because he is a poor writer? I would hate to think that one could be
>censured for being a poor writer. I will add, however, that in my
>opinion Bill is a very good writer from an implementors perspective.
>
I might add here that Bill has asked me a few (hundred) times if this part
of the Photuris draft is clear enough, or if that part needs refining. He
sent me a copy of the last 2 (or 3?) drafts a few days before they were
publically available, to check for errors - and i wasn't the only one.
-Angelos
Received: from relay.tis.com by neptune.TIS.COM id aa08321; 28 Feb 96 23:38 EST
Received: by relay.tis.com; id XAA13550; Wed, 28 Feb 1996 23:40:07 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma013547; Wed, 28 Feb 96 23:39:38 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA28385; Wed, 28 Feb 96 23:38:33 EST
Received: by relay.tis.com; id XAA13544; Wed, 28 Feb 1996 23:39:37 -0500
Received: from uucp2.netcom.com(163.179.3.2) by relay.tis.com via smap (V3.1)
id xma013542; Wed, 28 Feb 96 23:39:36 -0500
Received: by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1)
id UAA22459; Wed, 28 Feb 1996 20:32:19 -0800
Received: from cc:Mail by spysouth.spyrus.com
id AA825567603 Wed, 28 Feb 96 20:20:03
Date: Wed, 28 Feb 96 20:20:03
From: "Housley, Russ" <housley@spyrus.com>
Encoding: 223 Text
Message-Id: <9601288255.AA825567603@spysouth.spyrus.com>
To: ipsec@TIS.COM
Subject: Re: Sensitivity Labels
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
smb@research.att.com writes:
> Count me as a supporter of sensitivity labels.
Me too. Sensitivity labels must be an attribute of a security association.
IEEE 802.10c already supports sensitivity labels. ;)
Russ
Received: from relay.tis.com by neptune.TIS.COM id aa24587; 29 Feb 96 14:25 EST
Received: by relay.tis.com; id OAA24226; Thu, 29 Feb 1996 14:27:24 -0500
From: hugo@watson.ibm.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma024216; Thu, 29 Feb 96 14:26:55 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA27947; Thu, 29 Feb 96 14:25:51 EST
Received: by relay.tis.com; id OAA24213; Thu, 29 Feb 1996 14:26:54 -0500
Message-Id: <199602291926.OAA24213@relay.tis.com>
Received: from watson.ibm.com(129.34.139.4) by relay.tis.com via smap (V3.1)
id xma024211; Thu, 29 Feb 96 14:26:43 -0500
Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2789;
Thu, 29 Feb 96 14:26:02 EST
Date: Thu, 29 Feb 96 13:49:30 EST
To: ipsec@TIS.COM
Cc: rja@cisco.com, PALAMBER@us.oracle.com
Subject: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Ref: Your note of Mon, 26 Feb 96 20:34:35 GMT (attached)
I suggest NOT moving forward RFC1828.
Let's replace that transform by the keyed-MD5 transform
of Bellare, Canetti and Krawczyk,
as described in draft-krawczyk-keyed-md5-01.txt.
(This function is now named HMAC).
This new transform has a strong cryptographic analysis supporting it.
The paper showing that (see below) has been presented in several
public forums (including RSA conference and MIT's crypto seminar),
and has been widely circulated to cryptographers and security experts in
the last two months. The feedback has been overwhelming positive
(no one objection to its security or analysis).
The proposal was warmly welcome in general when I presented it in Dallas'
IETF (only the authors of RFC1828 objected). It was in the meantime adopted
into a few other protocols. I know of two independent implementations for
use with IPSEC/AH.
I believe it has all the merits and formal requirements to become an RFC
and the DEFAULT transform for AH.
I would like this WG to make a decision in that regard.
Sincereley and unpolitically (;-)
Hugo
PS: for those who still didn't read the paper :-)
Bellare, M., Canetti, R., and Krawczyk, H., "Keyed Hash Functions and
Message Authentication".
http://www.research.ibm.com/security/keyed-md5.html
Clarification: the name HMAC as used in the paper does not appear
in the internet draft draft-krawczyk-keyed-md5-01.txt. However, the described
function is the same.
Received: from relay.tis.com by neptune.TIS.COM id aa26732; 29 Feb 96 16:07 EST
Received: by relay.tis.com; id QAA26012; Thu, 29 Feb 1996 16:08:56 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma026003; Thu, 29 Feb 96 16:08:26 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA07451; Thu, 29 Feb 96 16:07:22 EST
Received: by relay.tis.com; id QAA25998; Thu, 29 Feb 1996 16:08:25 -0500
Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1)
id xma025994; Thu, 29 Feb 96 16:08:20 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id QAA18882; Thu, 29 Feb 1996 16:09:21 -0500 (EST)
Message-Id: <199602292109.QAA18882@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: hugo@watson.ibm.com
Cc: ipsec@TIS.COM, rja@cisco.com, PALAMBER@us.oracle.com
Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward
In-Reply-To: Your message of "Thu, 29 Feb 1996 13:49:30 EST."
<199602291926.OAA24213@relay.tis.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Thu, 29 Feb 1996 16:09:19 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
hugo@watson.ibm.com writes:
> Ref: Your note of Mon, 26 Feb 96 20:34:35 GMT (attached)
>
> I suggest NOT moving forward RFC1828.
>
> Let's replace that transform by the keyed-MD5 transform
> of Bellare, Canetti and Krawczyk,
> as described in draft-krawczyk-keyed-md5-01.txt.
> (This function is now named HMAC).
I have no problem with the idea of ultimately advancing the HMAC
transform to standard, especially after it has been out for a good
while and there has been additional opportunity for cryptographers to
attack it, but I disagree with the words "replace". As Paul's survey
reveals, many implementations currently implement 1828. Let us instead
speak of requiring this new superior transform rather than of
"replacing" the old one, which would imply, for example, that
identifiers for 1828 in key management protocols would have to point
at HMAC instead, which would result in interoperability problems.
Perry
Received: from relay.tis.com by neptune.TIS.COM id aa27319; 29 Feb 96 16:32 EST
Received: by relay.tis.com; id QAA26675; Thu, 29 Feb 1996 16:34:26 -0500
From: hugo@watson.ibm.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma026657; Thu, 29 Feb 96 16:33:56 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA09414; Thu, 29 Feb 96 16:32:52 EST
Received: by relay.tis.com; id QAA26653; Thu, 29 Feb 1996 16:33:54 -0500
Message-Id: <199602292133.QAA26653@relay.tis.com>
Received: from watson.ibm.com(129.34.139.4) by relay.tis.com via smap (V3.1)
id xma026644; Thu, 29 Feb 96 16:33:31 -0500
Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 5303;
Thu, 29 Feb 96 16:34:02 EST
Date: Thu, 29 Feb 96 16:22:35 EST
To: perry@piermont.com
Cc: ipsec@TIS.COM
Subject: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Ref: Your note of Thu, 29 Feb 1996 16:09:19 -0500 (attached)
Perry,
>
> I have no problem with the idea of ultimately advancing the HMAC
> transform to standard, especially after it has been out for a good
> while and there has been additional opportunity for cryptographers to
> attack it, but I disagree with the words "replace". As Paul's survey
> reveals, many implementations currently implement 1828. Let us instead
> speak of requiring this new superior transform rather than of
> "replacing" the old one, which would imply, for example, that
> identifiers for 1828 in key management protocols would have to point
> at HMAC instead, which would result in interoperability problems.
What I want is that implementations *do* move to this new function.
We are doing a lot of implementation work regarding IPSEC, and we talk
to many other implementation people involved with IPSEC.
The message is very clear: no one has any real problem to implement the
new transform, however they will not do that as long as there is another
one that is *officially* required by the IPSEC standard.
We need to find a way to break this loop. I don't care about the word
"replace" just about making clear that IPSEC-AH REQUIRES HMAC
(as the default implementation).
As a general note: if we can't modify the standards during the
standarization process why do we have that process in place.
Implementors need to know (and we know!) that changes will occur.
This particular one is easy to implement and upgrade.
If the decision is that it is too late to change the default algorithm
I would recommend this group to be even more careful on any decision about
moving any document to standards track.
Hugo
Received: from relay.tis.com by neptune.TIS.COM id aa27621; 29 Feb 96 16:50 EST
Received: by relay.tis.com; id QAA27094; Thu, 29 Feb 1996 16:51:59 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma027082; Thu, 29 Feb 96 16:51:30 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA10525; Thu, 29 Feb 96 16:50:26 EST
Received: by relay.tis.com; id QAA27079; Thu, 29 Feb 1996 16:51:29 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma027072; Thu, 29 Feb 96 16:51:14 -0500
Received: from inet-smtp-gw-1.us.oracle.com by interlock.ans.net with SMTP id AA29358
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Thu, 29 Feb 1996 16:52:12 -0500
Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7)
id NAA09891; Thu, 29 Feb 1996 13:52:19 -0800
Received: by mailsun2.us.oracle.com (8.7.1/37.8)
id NAA18059; Thu, 29 Feb 1996 13:54:11 -0800 (PST)
Message-Id: <199602292154.NAA18059@mailsun2.us.oracle.com>
Date: 29 Feb 96 13:36:29 -0800
From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>
To: perry@piermont.com
Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward
Cc: ipsec@ans.net
X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:perry@piermont.com's message of 29-Feb-96 16:09
Mime-Version: 1.0
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
>but I disagree with the words "replace". As Paul's survey
>reveals, many implementations currently implement 1828.
There has been very strong support for the use of HMAC as the "standard"
transform for AH. A "change" of this mechanism sooner, rather than later,
would limit the impact on implementors.
Paul
--------------------------------------------------------------
Paul Lambert Director of Security Products
Oracle Corporation Phone: (415) 506-0370
500 Oracle Parkway, Box 659410 Fax: (415) 413-2963
Redwood Shores, CA 94065 palamber@us.oracle.com
--------------------------------------------------------------
Received: from relay.tis.com by neptune.TIS.COM id aa27736; 29 Feb 96 16:52 EST
Received: by relay.tis.com; id QAA27133; Thu, 29 Feb 1996 16:54:29 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma027130; Thu, 29 Feb 96 16:54:00 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA10645; Thu, 29 Feb 96 16:52:56 EST
Received: by relay.tis.com; id QAA27124; Thu, 29 Feb 1996 16:53:59 -0500
Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1)
id xma027119; Thu, 29 Feb 96 16:53:54 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id QAA18966; Thu, 29 Feb 1996 16:54:56 -0500 (EST)
Message-Id: <199602292154.QAA18966@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: hugo@watson.ibm.com
Cc: ipsec@TIS.COM
Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward
In-Reply-To: Your message of "Thu, 29 Feb 1996 16:22:35 EST."
<199602292135.QAA26356@linet02.li.net>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Thu, 29 Feb 1996 16:54:52 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
hugo@watson.ibm.com writes:
> We need to find a way to break this loop. I don't care about the word
> "replace" just about making clear that IPSEC-AH REQUIRES HMAC
> (as the default implementation).
Thats fine, so long as we don't speak of "replacing", and so long as
we take some time to allow people to examine the transform. I would
want to see some considerable time taken between the time that an HMAC
based RFC is issued and the time it is advanced. No personal slight
intended, Hugo, but I've learned at this point that the only way to
get certainty out of cryptographers is to wait a year or two for the
dust to settle thoroughly. I fully believe your statements that no one
who has seen your work has had any trouble with it, but recall that
similar statements were made the last time around -- it would be
better if we gave it some time. This isn't to say we should advance
something else in its place, you understand. It is just to say we
should be more carefull.
> As a general note: if we can't modify the standards during the
> standarization process why do we have that process in place.
We can alter what is standard. However, it is often bad to alter what
already exists. When SMTP got revised, an extensions mechanism was
created -- existing SMTPs weren't broken. Sometime soon it will be
required that SMTP implementations support ESMTP, but it will
doubtless be a long while before ESMTP is totally universal, if
ever.
Perry
Received: from relay.tis.com by neptune.TIS.COM id aa29546; 29 Feb 96 18:15 EST
Received: by relay.tis.com; id SAA29041; Thu, 29 Feb 1996 18:17:09 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma029034; Thu, 29 Feb 96 18:16:40 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA14540; Thu, 29 Feb 96 18:15:36 EST
Received: by relay.tis.com; id SAA29024; Thu, 29 Feb 1996 18:16:38 -0500
Received: from unknown(198.82.204.99) by relay.tis.com via smap (V3.1)
id xma029013; Thu, 29 Feb 96 18:16:17 -0500
Received: from inner.net ([192.168.1.1]) by inner.net (8.7.4/42) with ESMTP id OAA02007; Thu, 29 Feb 1996 14:19:55 -0500
Message-Id: <199602291919.OAA02007@inner.net>
X-Mailer: exmh version 1.6.5 12/11/95
To: hugo@watson.ibm.com
Cc: ipsec@TIS.COM
Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward
In-Reply-To: Your message of "Thu, 29 Feb 1996 16:22:35 EST."
<199602292133.QAA26653@relay.tis.com>
X-Reposting-Policy: With explicit permission only
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 29 Feb 1996 18:16:57 -0500
From: Craig Metz <cmetz@inner.net>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
In message <199602292133.QAA26653@relay.tis.com>, you write:
>What I want is that implementations *do* move to this new function.
>We are doing a lot of implementation work regarding IPSEC, and we talk
>to many other implementation people involved with IPSEC.
>The message is very clear: no one has any real problem to implement the
>new transform, however they will not do that as long as there is another
>one that is *officially* required by the IPSEC standard.
What is the patent status of this MAC function?
(I don't think anyone would want to have an "oh, by the way" patent
problem)
-Craig
Received: from relay.tis.com by neptune.TIS.COM id aa29765; 29 Feb 96 18:27 EST
Received: by relay.tis.com; id SAA29204; Thu, 29 Feb 1996 18:29:07 -0500
From: hugo@watson.ibm.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma029200; Thu, 29 Feb 96 18:28:39 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA14934; Thu, 29 Feb 96 18:27:35 EST
Received: by relay.tis.com; id SAA29197; Thu, 29 Feb 1996 18:28:38 -0500
Message-Id: <199602292328.SAA29197@relay.tis.com>
Received: from watson.ibm.com(129.34.139.4) by relay.tis.com via smap (V3.1)
id xma029194; Thu, 29 Feb 96 18:28:25 -0500
Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 7425;
Thu, 29 Feb 96 18:29:04 EST
Date: Thu, 29 Feb 96 18:22:30 EST
To: cmetz@inner.net
Cc: ipsec@TIS.COM
Subject: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Ref: Your note of Thu, 29 Feb 1996 18:16:57 -0500 (attached)
> From: Craig Metz <cmetz@inner.net>
>
> In message <199602292133.QAA26653@relay.tis.com>, you write:
> >What I want is that implementations *do* move to this new function.
> >We are doing a lot of implementation work regarding IPSEC, and we talk
> >to many other implementation people involved with IPSEC.
> >The message is very clear: no one has any real problem to implement the
> >new transform, however they will not do that as long as there is another
> >one that is *officially* required by the IPSEC standard.
>
> What is the patent status of this MAC function?
>
> (I don't think anyone would want to have an "oh, by the way" patent
> problem)
>
> -Craig
Thanks for asking. This construction has NOT been patented.
(I made this statement clear during the Dallas' IETF).
It is as free as any other keyed hash function (we heard in Dallas IETF
-- see minutes -- that Novel may have a patent on keyed hash functions
in general. I do not know any details or what the status of that is).
Hugo
Received: from relay.tis.com by neptune.TIS.COM id aa00207; 29 Feb 96 18:47 EST
Received: by relay.tis.com; id SAA29407; Thu, 29 Feb 1996 18:49:37 -0500
From: hugo@watson.ibm.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma029404; Thu, 29 Feb 96 18:49:09 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA15508; Thu, 29 Feb 96 18:48:05 EST
Received: by relay.tis.com; id SAA29401; Thu, 29 Feb 1996 18:49:07 -0500
Message-Id: <199602292349.SAA29401@relay.tis.com>
Received: from watson.ibm.com(129.34.139.4) by relay.tis.com via smap (V3.1)
id xma029399; Thu, 29 Feb 96 18:49:00 -0500
Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 7675;
Thu, 29 Feb 96 18:49:43 EST
Date: Thu, 29 Feb 96 18:31:34 EST
To: perry@piermont.com
Cc: ipsec@TIS.COM
Subject: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Ref: Your note of Thu, 29 Feb 1996 16:54:52 -0500 (attached)
There is so much traffic in this list these days and I hate contributing
more but this may interest other people in addition to Perry.
Perry writes:
> hugo@watson.ibm.com writes:
> > We need to find a way to break this loop. I don't care about the word
> > "replace" just about making clear that IPSEC-AH REQUIRES HMAC
> > (as the default implementation).
>
> Thats fine, so long as we don't speak of "replacing", and so long as
> we take some time to allow people to examine the transform. I would
> want to see some considerable time taken between the time that an HMAC
> based RFC is issued and the time it is advanced. No personal slight
> intended, Hugo, but I've learned at this point that the only way to
> get certainty out of cryptographers is to wait a year or two for the
> dust to settle thoroughly. I fully believe your statements that no one
Waiting 1-2 years is unrealistic for IETF proposals.
However, I wish there was a more orderly scrutiny of security designs
for IETF protocols by cryptographers.
Photuris is a good example. It took me 6 drafts (from 03 to 09)
to convince Simpson to derive *independent* key bits for keyed-MD5 and DES.
Photuris still directly signs secret information which is a clearly wrong
cryptographic practice. Photuris confuses between MAC keys and data.
It does not handle key refreshment in a satisfactory way. It uses
unconstrained strings like SPI's as nonces, and incurs in some other
cryptographic sins. I didn't see where is the cryptographic community
that is inspecting this design.
It is actually very hard for cryptographers that are not directly involved
with this work to analyze these protocols in the implementation-oriented way
that they are written. They should be accompanied by a clear protocol
describing the basic flows and cryptographic rationale. But they are not.
What we did with HMAC is far more sound cryptographicaly as well as
for analysis, for presentation, and for exposure to cryptographers.
Moreover, notice that we have very clear proofs of security. That means that
there are no heuristics involved in the MAC construction except the minimal
and unavoidable assumptions that you need from MD5 (or your favorite
hash function). I wish I could always come with such strong arguments
for other cryptographic construction that I propose or use.
> > As a general note: if we can't modify the standards during the
> > standarization process why do we have that process in place.
>
> We can alter what is standard. However, it is often bad to alter what
> already exists. When SMTP got revised, an extensions mechanism was
> created -- existing SMTPs weren't broken. Sometime soon it will be
> required that SMTP implementations support ESMTP, but it will
> doubtless be a long while before ESMTP is totally universal, if
> ever.
I repeat this very clearly. In my opinion (and I hope people will agree
and even say it ;-) NOW is the time to move to the new transform,
and, if possible, forget about the previous one.
Having two around will only create confusion and interoperability problems.
Hugo
Received: from relay.tis.com by neptune.TIS.COM id aa00453; 29 Feb 96 19:01 EST
Received: by relay.tis.com; id TAA29722; Thu, 29 Feb 1996 19:03:28 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma029712; Thu, 29 Feb 96 19:03:04 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA15773; Thu, 29 Feb 96 19:01:59 EST
Received: by relay.tis.com; id TAA29706; Thu, 29 Feb 1996 19:03:01 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma029701; Thu, 29 Feb 96 19:02:49 -0500
Received: from puli.cisco.com by interlock.ans.net with SMTP id AA02736
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Thu, 29 Feb 1996 19:03:49 -0500
Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id QAA23756; Thu, 29 Feb 1996 16:03:47 -0800
Message-Id: <199603010003.QAA23756@puli.cisco.com>
To: ipsec@ans.net, perry@piermont.com, bill.simpson@cc.umich.edu
Subject: technical clarification request to RFC-1828.
Date: Thu, 29 Feb 1996 16:03:47 -0800
From: Paul Traina <pst@cisco.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
The last thing I feel like doing is stepping into the war over 1828, however I
do have a technical concern with regard to the specification of a compliant
implementation. I apologise for missing the last call on this document, at
the time I was not involved in this area of standards. This is purely a
technical clarification, I make no judgements about the appropriateness of the
protocol.
My issue is entirely based upon what I consider to be an inadequate
specification of the padding of the initial key. To my "trained" implementors
eye, it's not at all clear from the RFC, and in fact, I had to speak to
someone who implemented it correctly at the bake-off who received additional
information from Bill. (read: I looked at the NRL code)
The RFC does not mis-specify the method of padding, merely it specifies it
inadequately. Given that with the additional information, the compliant
implementation became obvious, I would request the that the working group
insure the clarity of future revisions of 1828.
I think some simple pseudo-code would be enough, as long as the "revision" to
the RFC1323 MD5Final routine was *strongly* noted.
Given that the group seems to be in a war about 1828 and other recently
released drafts, now is as good a time as any to nail down some technical
details.
Sigh,
Paul
-----------------------------------------------------------------------------
Details:
My inadequate interpretation of 1828 caused the following code to be written
(the MD5 routines are the canonical ones from 1323):
/*
* md5_rfc1828
*
* User-friendly way to compute keyed MD5 authentication information for
* a chunk of data.
*
* Call it like this:
*
* char hash[MD5_LEN];
* md5_rfc1828(message, msglength, key, strlen(key), hash, sizeof(hash));
*/
#define FILL_LEN 64 /* 512 bit boundaries for fill */
#define MOD_LEN 56 /* pad key to bit 448 modulo 512 */
boolean
md5_rfc1828 (void *data, int datalen,
char *key, int keylen,
uchar *digest, int digestlen)
{
static uchar padding[FILL_LEN] = { 0x80, 0 };
MD5_CTX context;
int padlen;
if (digestlen < MD5_LEN)
return FALSE;
padlen = keylen % FILL_LEN;
padlen = padlen < MOD_LEN ? MOD_LEN - padlen
: (FILL_LEN+MOD_LEN) - padlen;
MD5Init(&context);
MD5Update(&context, key, keylen);
MD5Update(&context, padding, padlen);
MD5Update(&context, data, datalen);
MD5Update(&context, key, keylen);
MD5Final(digest, &context);
return TRUE;
}
whereas the correct implementation would be:
boolean
md5_rfc1828 (void *data, int datalen,
char *key, int keylen,
uchar *digest, int digestlen)
{
MD5_CTX context;
if (digestlen < MD5_LEN)
return FALSE;
MD5Init(&context);
MD5Update(&context, key, keylen);
RFC_1828_MD5Final(NULL, &context); /* do padding according to 1828 */
MD5Update(&context, data, datalen);
MD5Update(&context, key, keylen);
MD5Final(digest, &context);
return TRUE;
}
void
RFC_1828_MD5Final (unsigned char *digest, /* message digest */
MD5_CTX *context) /* context */
{
unsigned char bits[8];
unsigned int index, padLen;
/* Save number of bits */
Encode(bits, context->count, 8);
/*
* Pad out to 56 mod 64.
*/
index = (unsigned int) ((context->count[0] >> 3) & 0x3f);
padLen = (index < 56) ? (56 - index) : (120 - index);
MD5Update(context, PADDING, padLen);
/* Append length (before padding) */
MD5Update(context, bits, 8);
| if (digest) { /* change to allow RFC1828 padding */
| /* Store state in digest */
| Encode(digest, context->state, 16);
|
| /*
| * Zeroize sensitive information.
| */
| MD5_memset((POINTER) context, 0, sizeof(*context));
| }
}
Received: from relay.tis.com by neptune.TIS.COM id aa01856; 29 Feb 96 20:52 EST
Received: by relay.tis.com; id UAA00539; Thu, 29 Feb 1996 20:54:28 -0500
From: smb@research.att.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma000535; Thu, 29 Feb 96 20:54:03 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA17601; Thu, 29 Feb 96 20:52:56 EST
Received: by relay.tis.com; id UAA00532; Thu, 29 Feb 1996 20:53:58 -0500
Message-Id: <199603010153.UAA00532@relay.tis.com>
Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1)
id xma000529; Thu, 29 Feb 96 20:53:28 -0500
Received: from research.att.com by ns; Thu Feb 29 20:51:50 EST 1996
Received: from gryphon by research; Thu Feb 29 20:48:54 EST 1996
Received: by gryphon; Thu Feb 29 20:48:50 EST 1996
To: perry@piermont.com
Cc: hugo@watson.ibm.com, ipsec@TIS.COM
Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward
Date: Thu, 29 Feb 96 20:48:49 EST
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
hugo@watson.ibm.com writes:
> We need to find a way to break this loop. I don't care about the wor
d
> "replace" just about making clear that IPSEC-AH REQUIRES HMAC
> (as the default implementation).
Thats fine, so long as we don't speak of "replacing", and so long as
we take some time to allow people to examine the transform. I would
want to see some considerable time taken between the time that an HMAC
based RFC is issued and the time it is advanced. No personal slight
intended, Hugo, but I've learned at this point that the only way to
get certainty out of cryptographers is to wait a year or two for the
dust to settle thoroughly. I fully believe your statements that no one
who has seen your work has had any trouble with it, but recall that
similar statements were made the last time around -- it would be
better if we gave it some time. This isn't to say we should advance
something else in its place, you understand. It is just to say we
should be more carefull.
Of course, all along the unanimous opinion of the cryptographic theoreticians
has been that keyed hash functions were an unknown -- they weren't designed
to do that, and it wasn't clear that they were secure in this mode. But
we went ahead anyway.
> As a general note: if we can't modify the standards during the
> standarization process why do we have that process in place.
We can alter what is standard. However, it is often bad to alter what
already exists. When SMTP got revised, an extensions mechanism was
created -- existing SMTPs weren't broken. Sometime soon it will be
required that SMTP implementations support ESMTP, but it will
doubtless be a long while before ESMTP is totally universal, if
ever.
Right. And if ESMTP had been proposed way back when, before RFC821 was
officially blessed, it would have been a different matter. If we're going
to change it, now is the time. We should certainly use a different transform
number for HMAC, to make the transition easier, but we should have only
one full standard.
RFC1828 is a ``Proposed Standard''. Let me quote from RFC1880, the current
instantiation of STD 1:
4.1.3. Proposed Standard Protocol
These are protocol proposals that may be considered by the IESG
for standardization in the future. Implementation and testing by
several groups is desirable. Revision of the protocol
specification is likely.
Note carefully: revision is *likely*. If we're going to change it, now is
the time -- after it goes to Draft, it's too late for fixes of this nature
(absent, say, the discovery of a feasible attack).
Received: from relay.tis.com by neptune.TIS.COM id aa01962; 29 Feb 96 20:57 EST
Received: by relay.tis.com; id UAA00607; Thu, 29 Feb 1996 20:59:28 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma000603; Thu, 29 Feb 96 20:59:01 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA17705; Thu, 29 Feb 96 20:57:56 EST
Received: by relay.tis.com; id UAA00593; Thu, 29 Feb 1996 20:58:58 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma000585; Thu, 29 Feb 96 20:58:45 -0500
Received: from jekyll.piermont.com by interlock.ans.net with SMTP id AA04418
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Thu, 29 Feb 1996 20:59:47 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id UAA19307; Thu, 29 Feb 1996 20:58:25 -0500 (EST)
Message-Id: <199603010158.UAA19307@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>
Cc: ipsec@ans.net
Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward
In-Reply-To: Your message of "29 Feb 1996 13:36:29 PST."
<199602292154.NAA18059@mailsun2.us.oracle.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Thu, 29 Feb 1996 20:58:20 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
"PALAMBER.US.ORACLE.COM" writes:
> >but I disagree with the words "replace". As Paul's survey
> >reveals, many implementations currently implement 1828.
>
> There has been very strong support for the use of HMAC as the "standard"
> transform for AH. A "change" of this mechanism sooner, rather than later,
> would limit the impact on implementors.
Fine, but that doesn't necessarily mean "replace".
Perry
Received: from simon.cs.cornell.edu by neptune.TIS.COM id aa02255;
29 Feb 96 21:13 EST
Received: from cloyd.cs.cornell.edu (CLOYD.CS.CORNELL.EDU [128.84.227.15]) by simon.cs.cornell.edu (8.6.10/R1.4) with ESMTP id VAA14615 for <ipsec@neptune.tis.com>; Thu, 29 Feb 1996 21:15:56 -0500
Received: from gilling.cs.cornell.edu (GILLING.CS.CORNELL.EDU [128.84.254.180]) by cloyd.cs.cornell.edu (8.6.10/M1.8) with ESMTP id VAA18815; Thu, 29 Feb 1996 21:15:53 -0500
From: Lewis McCarthy <lew@cs.cornell.edu>
Received: (lew@localhost) by gilling.cs.cornell.edu (8.6.10/C1.3) id VAA10324; Thu, 29 Feb 1996 21:15:43 -0500
Message-Id: <199603010215.VAA10324@gilling.cs.cornell.edu>
Subject: Re: technical clarification request to RFC-1828.
To: ipsec@neptune.tis.com
Date: Thu, 29 Feb 1996 21:15:42 -5300 (EST)
In-Reply-To: <199603010003.QAA23756@puli.cisco.com>
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2281
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Paul Traina <pst@cisco.com> writes:
> My issue is entirely based upon what I consider to be an inadequate
> specification of the padding of the initial key.
[...]
> The RFC does not mis-specify the method of padding, merely it specifies it
> inadequately.
[..]
> I think some simple pseudo-code would be enough, as long as the "revision"
> to the RFC1323 MD5Final routine was *strongly* noted.
(I went digging through a stack of papers before I realized you meant 1321 :)
OK, so essentially you seem to be suggesting a clarification (in the RFC) of
the following phrasing in Section 2 of 1828:
"First, the variable length secret authentication key is filled
to the next 512-bit boundary, using the same pad with length
technique defined for MD5."
How about rephrasing it as:
"...512-bit boundary, using the padding technique defined in
subsections 3.1 and 3.2 of the MD5 specification [RFC-1321]."
I think that makes the method clear, since the relevant parts of MD5Final
are conveniently separately numbered in 1321. Would pseudo-code still be
preferable in addition to (or instead of) rephrasing like this ?
Just to add fuel to the fire, I think the discussion of key length in 1828,
subsection 1.1, could stand slight revision. In particular, I think the
last sentence
"Longer keys are encouraged."
is ambiguous. Certainly, longer keys up to 128 bits in length should be
encouraged versus shorter keys. But as I understand things, the security of
this envelope construction is not increased by using a key with more than
128 bits of entropy, since MD5 only generates a 128-bit hash. (This is
already reflected to some extent in the 1828 Security Considerations section,
where the van Oorschot/Wiener MD5 supercollider is discussed.) If the key is
only pseudorandom, however, then length(key) > 128 may be desirable to ensure
at least 128 bits of entropy are present.
The Security Considerations section already notes that the specification's
security depends on the strength of MD5 and "the strength of the key". I am
proposing a more explicit acknowledgement that keys longer than 128 bits are
only helpful under certain assumptions about their non-randomness, as a
result of the other two considerations.
-Lewis <lew@cs.cornell.edu> (until mid-May)
Received: from relay.tis.com by neptune.TIS.COM id aa08263; 1 Mar 96 6:18 EST
Received: by relay.tis.com; id GAA04870; Fri, 1 Mar 1996 06:20:09 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma004865; Fri, 1 Mar 96 06:19:41 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA26980; Fri, 1 Mar 96 06:18:37 EST
Received: by relay.tis.com; id GAA04862; Fri, 1 Mar 1996 06:19:39 -0500
Received: from info.forthnet.gr(139.91.1.17) by relay.tis.com via smap (V3.1)
id xma004857; Fri, 1 Mar 96 06:19:16 -0500
Received: from vicky.forthnet.gr by info.forthnet.gr via FORTHnet with SMTP;
id NAA09205 (8.6.12/FORTHNET-2.0); Fri, 1 Mar 1996 13:14:40 +0200 (EET DST)
Message-Id: <199603011114.NAA09205@info.forthnet.gr>
Organization:
To: hugo@watson.ibm.com
Cc: ipsec@TIS.COM, rja@cisco.com, PALAMBER@us.oracle.com
Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward
In-Reply-To: Your message of "Thu, 29 Feb 1996 13:49:30 EST."
<199602291926.OAA24213@relay.tis.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <26518.825678872.1@forthnet.gr>
Date: Fri, 01 Mar 1996 13:14:32 +0200
From: "Angelos D. Keromytis" <kermit@forthnet.gr>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
In message <199602291926.OAA24213@relay.tis.com>, hugo@watson.ibm.com writes:
>I suggest NOT moving forward RFC1828.
>
>Let's replace that transform by the keyed-MD5 transform
>of Bellare, Canetti and Krawczyk,
>as described in draft-krawczyk-keyed-md5-01.txt.
>(This function is now named HMAC).
I, for one, agree; this transform seems better than the one we
currently have.
-Angelos
Received: from relay.tis.com by neptune.TIS.COM id aa08620; 1 Mar 96 6:52 EST
Received: by relay.tis.com; id GAA05153; Fri, 1 Mar 1996 06:54:40 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma005145; Fri, 1 Mar 96 06:54:16 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA27670; Fri, 1 Mar 96 06:53:07 EST
Received: by relay.tis.com; id GAA05138; Fri, 1 Mar 1996 06:54:10 -0500
Received: from ktik0.ethz.ch(129.132.66.42) by relay.tis.com via smap (V3.1)
id xma005134; Fri, 1 Mar 96 06:54:05 -0500
Received: from komsys-pc-gc.ethz.ch (komsys-pc-gc.ethz.ch [129.132.66.22]) by ktik0 (8.6.8.1/8.6.6) with SMTP id MAA11063 for <ipsec@tis.com>; Fri, 1 Mar 1996 12:54:58 +0100
Message-Id: <2.2.32.19960301120435.006b4810@ktik0.ethz.ch>
X-Sender: caronni@ktik0.ethz.ch
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 01 Mar 1996 13:04:35 +0100
To: ipsec@TIS.COM
From: Germano Caronni <caronni@tik.ee.ethz.ch>
Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
At 13:36 29.2.96 -0800, you wrote:
>There has been very strong support for the use of HMAC as the "standard"
>transform for AH. A "change" of this mechanism sooner, rather than later,
>would limit the impact on implementors.
>From an implementors standpoint, I fully agree. Now is the easiest time to
change the algorithm employed. Later will be harder, as implementations will
tend to proliferate. So this forum 'simply' needs to make up its mind if
it's appropriate to change from 'keyed MD5' to a new transform.
HMAC certainly is not weaker than keyed MD5, and strong indications exist
that it is indeed stronger, so I for one would prefer to have HMAC in the RFC.
Germano
Received: from relay.tis.com by neptune.TIS.COM id aa09923; 1 Mar 96 8:27 EST
Received: by relay.tis.com; id IAA06158; Fri, 1 Mar 1996 08:29:39 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma006153; Fri, 1 Mar 96 08:29:11 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA01930; Fri, 1 Mar 96 08:28:07 EST
Received: by relay.tis.com; id IAA06150; Fri, 1 Mar 1996 08:29:09 -0500
Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1)
id xma006146; Fri, 1 Mar 96 08:28:57 -0500
Received: from hawpub.watson.ibm.com ([9.2.90.19]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id IAA23896; Fri, 1 Mar 1996 08:30:07 -0500
Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/2/16/96)
id AA37794; Fri, 1 Mar 1996 08:30:00 -0500
Message-Id: <9603011330.AA37794@hawpub.watson.ibm.com>
Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward
To: perry@piermont.com
Date: Fri, 1 Mar 1996 08:29:59 -0500 (EST)
From: Uri Blumenthal <uri@watson.ibm.com>
Cc: ipsec@TIS.COM
In-Reply-To: <199603010158.UAA19307@jekyll.piermont.com> from "Perry E. Metzger" at Feb 29, 96 08:58:20 pm
X-External-Networks: yes
Reply-To: uri@watson.ibm.com
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Perry E. Metzger writes:
> > There has been very strong support for the use of HMAC as the "standard"
> > transform for AH. A "change" of this mechanism sooner, rather than later,
> > would limit the impact on implementors.
>
> Fine, but that doesn't necessarily mean "replace".
In light of what has already been said, I *strongly suggest* that
HMAC should *replace* the current MAC, with, as Steve proposes, a
different transform number. And it has to be done NOW.
--
Regards,
Uri uri@watson.ibm.com
-=-=-=-=-=-=-
<Disclaimer>
Received: from relay.tis.com by neptune.TIS.COM id aa11515; 1 Mar 96 10:02 EST
Received: by relay.tis.com; id KAA08495; Fri, 1 Mar 1996 10:04:40 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma008491; Fri, 1 Mar 96 10:04:11 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA08778; Fri, 1 Mar 96 10:03:07 EST
Received: by relay.tis.com; id KAA08488; Fri, 1 Mar 1996 10:04:10 -0500
Received: from unknown(206.1.51.15) by relay.tis.com via smap (V3.1)
id xma008481; Fri, 1 Mar 96 10:03:49 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id KAA21009; Fri, 1 Mar 1996 10:04:47 -0500 (EST)
Message-Id: <199603011504.KAA21009@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: hugo@watson.ibm.com
Cc: ipsec@TIS.COM
Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward
In-Reply-To: Your message of "Thu, 29 Feb 1996 18:31:34 EST."
<199602292350.SAA17634@linet02.li.net>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Fri, 01 Mar 1996 10:04:39 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
hugo@watson.ibm.com writes:
> Waiting 1-2 years is unrealistic for IETF proposals.
Its not unrealistic to wait that long to advance to a high level
provided that the proposal is made into an RFC and a proposed standard
first so that people know it is standards track.
> However, I wish there was a more orderly scrutiny of security designs
> for IETF protocols by cryptographers.
The process is sometimes chaotic. However, it does, in the end,
usually work.
Perry
Received: from relay.tis.com by neptune.TIS.COM id aa11663; 1 Mar 96 10:08 EST
Received: by relay.tis.com; id KAA08660; Fri, 1 Mar 1996 10:10:10 -0500
From: hugo@watson.ibm.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma008656; Fri, 1 Mar 96 10:09:42 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA09116; Fri, 1 Mar 96 10:08:38 EST
Received: by relay.tis.com; id KAA08647; Fri, 1 Mar 1996 10:09:40 -0500
Message-Id: <199603011509.KAA08647@relay.tis.com>
Received: from watson.ibm.com(129.34.139.4) by relay.tis.com via smap (V3.1)
id xma008636; Fri, 1 Mar 96 10:09:18 -0500
Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 6285;
Fri, 01 Mar 96 10:10:01 EST
Date: Fri, 1 Mar 96 10:10:01 EST
To: perry@piermont.com
Cc: ipsec@TIS.COM
Subject: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Ref: Your note of Fri, 01 Mar 1996 10:04:39 -0500 (attached)
>
> > However, I wish there was a more orderly scrutiny of security designs
> > for IETF protocols by cryptographers.
>
> The process is sometimes chaotic. However, it does, in the end,
> usually work.
Right. It works in 95% of the cases.
Security is exactly about the remaining 5%.
Hugo
>
> Perry
Received: from relay.tis.com by neptune.TIS.COM id aa13244; 1 Mar 96 11:30 EST
Received: by relay.tis.com; id LAA10309; Fri, 1 Mar 1996 11:32:52 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma010307; Fri, 1 Mar 96 11:32:25 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA15264; Fri, 1 Mar 96 11:31:20 EST
Received: by relay.tis.com; id LAA10300; Fri, 1 Mar 1996 11:32:23 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma010293; Fri, 1 Mar 96 11:32:18 -0500
Received: from jekyll.piermont.com by interlock.ans.net with SMTP id AA17697
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Fri, 1 Mar 1996 11:33:19 -0500
Received: (from perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) id LAA21154; Fri, 1 Mar 1996 11:33:11 -0500 (EST)
Date: Fri, 1 Mar 1996 11:33:11 -0500 (EST)
Message-Id: <199603011633.LAA21154@jekyll.piermont.com>
From: "Perry E. Metzger" <perry@piermont.com>
To: ipsec@ans.net
Subject: what I am proposing re HMAC
Reply-To: perry@piermont.com
X-Reposting-Policy: please ask before redistributing
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Just to be clear, what I am proposing on HMAC is this:
1) We leave 1828 alone. We do not advance it further but we do not
"replace" it, meaning new RFCs do NOT "supersede" it in the way a
replacement would.
2) We publish an RFC as a proposed standard for HMAC.
3) We think of the HMAC transform not as a replacement for the
existing transforms but as a new transform. Any key negotiation
protocols that exist do not replace the meaning of "use the 1828
transform" with using HMAC -- they think of HMAC as a new
transform. I do not want the new RFC to "supersede" 1828 as a
replacement RFC would. One of the reasons I'm strongly opinioned on
this is that I expect this situation will occur over and over in
the next decade -- we will discover something and want to replace
what people are using. Right now we can fail to advance 1828 as
part of this process, but in general what we are doing is creating
NEW transforms, not REPLACING old ones. The new transforms are then
encouraged to be "must implement".
4) We leave the HMAC RFC at proposed standard long enough for the crypto
community to really get its teeth in. Being at proposed should be
sufficient to encourage vendors to implement. I know Hugo would
probably like it to advance to draft standard more quickly, but my
gut instinct says "wait". Proofs are good, I fully believe Hugo is
a good crypto guy and that his proofs are excellent, but this is
engineering at this point, not math. Proposed standard should be
sufficient for a while.
5) If we desire, we may issue a document clarifying 1828 for
historical reasons, but we do this as an informational RFC.
Perry
Received: from relay.tis.com by neptune.TIS.COM id aa14075; 1 Mar 96 12:20 EST
Received: by relay.tis.com; id MAA11229; Fri, 1 Mar 1996 12:22:22 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma011225; Fri, 1 Mar 96 12:21:56 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA18204; Fri, 1 Mar 96 12:20:51 EST
Received: by relay.tis.com; id MAA11216; Fri, 1 Mar 1996 12:21:53 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma011207; Fri, 1 Mar 96 12:21:29 -0500
Received: from relay.hp.com by interlock.ans.net with SMTP id AA19071
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Fri, 1 Mar 1996 12:22:22 -0500
Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP
(1.37.109.16/15.5+ECS 3.3) id AA021590938; Fri, 1 Mar 1996 09:22:18 -0800
Message-Id: <199603011722.AA021590938@relay.hp.com>
Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com
id AA243181129; Fri, 1 Mar 1996 12:25:29 -0500
X-Mailer: exmh version 1.6.2 7/18/95
To: perry@piermont.com
Cc: ipsec@ans.net
Subject: Re: what I am proposing re HMAC
In-Reply-To: perry's message of Fri, 01 Mar 1996 11:33:11 -0500.
<199603011633.LAA21154@jekyll.piermont.com>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Fri, 01 Mar 1996 12:22:16 -0500
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
content-type: text/plain; charset=us-ascii
Just to be clear, what I am proposing on HMAC is this:
1) We leave 1828 alone. We do not advance it further but we do not
"replace" it, meaning new RFCs do NOT "supersede" it in the way a
replacement would.
Agreed, but see the comments to #5
3) We think of the HMAC transform not as a replacement for the
existing transforms but as a new transform. Any key negotiation
protocols that exist do not replace the meaning of "use the 1828
transform" with using HMAC -- they think of HMAC as a new
transform. I do not want the new RFC to "supersede" 1828 as a
replacement RFC would.
This points out a weakness in the current IPSEC document structure.
Each key management method (ISAKMP, Photuris, SKIP, manual) has to
solve the exact same problem of "how do I name the transforms".
The author of a new transform needs to allocate separate transform
id's for each different key management protocol.
If there was a common algorithm-id spec defined by the transform-level
architecture, the work needed to define new transforms and hook them
into the key management infrastructure would be somewhat simplified.
[I'd suggest starting with SKIP's algorithm id's because early
versions of SKIP have actually been deployed, but it looks to me that
the way SKIP handles algorithm id's makes handling combined
encryption/MAC/... transforms messy.]
One of the reasons I'm strongly opinioned on
this is that I expect this situation will occur over and over in
the next decade -- we will discover something and want to replace
what people are using. Right now we can fail to advance 1828 as
part of this process, but in general what we are doing is creating
NEW transforms, not REPLACING old ones. The new transforms are then
encouraged to be "must implement".
I'm in violent agreement with this..
4) We leave the HMAC RFC at proposed standard long enough for the crypto
community to really get its teeth in. Being at proposed should be
sufficient to encourage vendors to implement. I know Hugo would
probably like it to advance to draft standard more quickly, but my
gut instinct says "wait". Proofs are good, I fully believe Hugo is
a good crypto guy and that his proofs are excellent, but this is
engineering at this point, not math. Proposed standard should be
sufficient for a while.
5) If we desire, we may issue a document clarifying 1828 for
historical reasons, but we do this as an informational RFC.
Instead, why not:
(a) in the HMAC draft suggest that implementors implement
HMAC-MD5 (or whatever it's called) in addition to 1828
(b) have the IESG relabel 1828 as "historic" when HMAC goes to
PS or DS...
- Bill
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMTcyQVpj/0M1dMJ/AQEdfgP+K8VcZziZ6NUYyGy6GaL3/KtLvOV/Q7zV
WvzHPX77weOh6G2qvaQRmmDU15mih+U1mwEl7FZ/c5ZR2n+XFxL6t4tXiDRugX3G
U/PEXtoswpEZUshZ4L7cg6TVqox4U+xV+W3nmJLsBBoL+OZu5Tlt0K49iWE2pmm0
1dhBmEnacIY=
=Npz1
-----END PGP SIGNATURE-----
Received: from relay.tis.com by neptune.TIS.COM id aa14284; 1 Mar 96 12:29 EST
Received: by relay.tis.com; id MAA11484; Fri, 1 Mar 1996 12:31:53 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma011479; Fri, 1 Mar 96 12:31:25 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA18642; Fri, 1 Mar 96 12:30:20 EST
Received: by relay.tis.com; id MAA11473; Fri, 1 Mar 1996 12:31:23 -0500
Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1)
id xma011467; Fri, 1 Mar 96 12:31:12 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id MAA21282; Fri, 1 Mar 1996 12:32:14 -0500 (EST)
Message-Id: <199603011732.MAA21282@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: hugo@watson.ibm.com
Cc: ipsec@TIS.COM
Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward
In-Reply-To: Your message of "Fri, 01 Mar 1996 10:10:01 EST."
<199603011510.KAA09472@linet02.li.net>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Fri, 01 Mar 1996 12:32:13 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
hugo@watson.ibm.com writes:
> > > However, I wish there was a more orderly scrutiny of security designs
> > > for IETF protocols by cryptographers.
> >
> > The process is sometimes chaotic. However, it does, in the end,
> > usually work.
>
> Right. It works in 95% of the cases.
> Security is exactly about the remaining 5%.
I realize the process may seem like a problem to those who normally
work alone on a problem and then proceed to give a document to a set
of reviewers for orderly review, but it really isn't. Perhaps we need
to use some better tools (a trouble ticket system? I'm not joking) to
give people better confidence that edits aren't being dropped on the
floor, but the process *does* work in the end, even now.
Perry
Received: from relay.tis.com by neptune.TIS.COM id aa14829; 1 Mar 96 13:02 EST
Received: by relay.tis.com; id NAA12488; Fri, 1 Mar 1996 13:04:19 -0500
From: smb@research.att.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma012484; Fri, 1 Mar 96 13:03:51 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA20729; Fri, 1 Mar 96 13:02:47 EST
Received: by relay.tis.com; id NAA12478; Fri, 1 Mar 1996 13:03:49 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma012472; Fri, 1 Mar 96 13:03:33 -0500
Received: from research.att.com (ns.research.att.com) by interlock.ans.net with SMTP id AA20470
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Fri, 1 Mar 1996 13:04:33 -0500
Message-Id: <199603011804.AA20470@interlock.ans.net>
Received: from research.att.com by ns; Fri Mar 1 13:01:55 EST 1996
Received: from gryphon by research; Fri Mar 1 12:58:48 EST 1996
Received: by gryphon; Fri Mar 1 12:58:43 EST 1996
To: perry@piermont.com
Cc: ipsec@ans.net
Subject: Re: what I am proposing re HMAC
Date: Fri, 01 Mar 96 12:58:42 EST
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Just to be clear, what I am proposing on HMAC is this:
1) We leave 1828 alone. We do not advance it further but we do not
"replace" it, meaning new RFCs do NOT "supersede" it in the way a
replacement would.
2) We publish an RFC as a proposed standard for HMAC.
3) We think of the HMAC transform not as a replacement for the
existing transforms but as a new transform. Any key negotiation
protocols that exist do not replace the meaning of "use the 1828
transform" with using HMAC -- they think of HMAC as a new
transform. I do not want the new RFC to "supersede" 1828 as a
replacement RFC would. One of the reasons I'm strongly opinioned on
this is that I expect this situation will occur over and over in
the next decade -- we will discover something and want to replace
what people are using. Right now we can fail to advance 1828 as
part of this process, but in general what we are doing is creating
NEW transforms, not REPLACING old ones. The new transforms are then
encouraged to be "must implement".
4) We leave the HMAC RFC at proposed standard long enough for the cryp
to
community to really get its teeth in. Being at proposed should be
sufficient to encourage vendors to implement. I know Hugo would
probably like it to advance to draft standard more quickly, but my
gut instinct says "wait". Proofs are good, I fully believe Hugo is
a good crypto guy and that his proofs are excellent, but this is
engineering at this point, not math. Proposed standard should be
sufficient for a while.
5) If we desire, we may issue a document clarifying 1828 for
historical reasons, but we do this as an informational RFC.
There's no problem with any of this. But we need point 6 -- the status
of 1828 and HMAC as mandatory/recommended/elective etc. What do we
tell people they MUST implement? My own view is to make HMAC mandatory
and 1828 recommended -- and recommended only because there's already
a lot out there.
Received: from relay.tis.com by neptune.TIS.COM id aa15248; 1 Mar 96 13:21 EST
Received: by relay.tis.com; id NAA12888; Fri, 1 Mar 1996 13:22:49 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma012875; Fri, 1 Mar 96 13:22:20 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA21861; Fri, 1 Mar 96 13:21:16 EST
Received: by relay.tis.com; id NAA12872; Fri, 1 Mar 1996 13:22:19 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma012869; Fri, 1 Mar 96 13:22:08 -0500
Received: from jekyll.piermont.com by interlock.ans.net with SMTP id AA21033
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Fri, 1 Mar 1996 13:23:09 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id NAA21418; Fri, 1 Mar 1996 13:23:06 -0500 (EST)
Message-Id: <199603011823.NAA21418@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: smb@research.att.com
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
Cc: ipsec@ans.net
Subject: Re: what I am proposing re HMAC
In-Reply-To: Your message of "Fri, 01 Mar 1996 12:58:42 EST."
<199603011804.NAA29924@linet02.li.net>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Fri, 01 Mar 1996 13:23:01 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
smb@research.att.com writes, re my proposal:
> There's no problem with any of this. But we need point 6 -- the status
> of 1828 and HMAC as mandatory/recommended/elective etc. What do we
> tell people they MUST implement? My own view is to make HMAC mandatory
> and 1828 recommended -- and recommended only because there's already
> a lot out there.
I agree fully with your amendment. This seems like "the right thing".
Perry
Received: from relay.tis.com by neptune.TIS.COM id aa15803; 1 Mar 96 13:42 EST
Received: by relay.tis.com; id NAA13447; Fri, 1 Mar 1996 13:44:49 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma013444; Fri, 1 Mar 96 13:44:20 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA23337; Fri, 1 Mar 96 13:43:16 EST
Received: by relay.tis.com; id NAA13441; Fri, 1 Mar 1996 13:44:19 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma013436; Fri, 1 Mar 96 13:43:58 -0500
Received: from igw2.watson.ibm.com by interlock.ans.net with SMTP id AA21688
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Fri, 1 Mar 1996 13:44:58 -0500
Received: from hawpub.watson.ibm.com ([9.2.90.19]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id NAA22500 for <ipsec@ans.net>; Fri, 1 Mar 1996 13:44:59 -0500
Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/2/16/96)
id AA42869; Fri, 1 Mar 1996 13:44:52 -0500
Message-Id: <9603011844.AA42869@hawpub.watson.ibm.com>
Subject: Re: what I am proposing re HMAC
To: ipsec@ans.net
Date: Fri, 1 Mar 1996 13:44:52 -0500 (EST)
From: Uri Blumenthal <uri@watson.ibm.com>
In-Reply-To: <199603011633.LAA21154@jekyll.piermont.com> from "Perry E. Metzger" at Mar 1, 96 11:33:11 am
X-External-Networks: yes
Reply-To: uri@watson.ibm.com
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Perry E. Metzger writes:
> Just to be clear, what I am proposing on HMAC is this:
> 1) We leave 1828 alone. We do not advance it further but we do not
> "replace" it, meaning new RFCs do NOT "supersede" it in the way a
> replacement would.
I'm against. There are no reasons NOT to "supersede" 1828.
> 2) We publish an RFC as a proposed standard for HMAC.
> 3) We think of the HMAC transform not as a replacement for the
> existing transforms but as a new transform.
Yes, certainly.
> Any key negotiation
> protocols that exist do not replace the meaning of "use the 1828
> transform" with using HMAC -- they think of HMAC as a new
> transform. I do not want the new RFC to "supersede" 1828 as a
> replacement RFC would.
It is a question of what transform will be mandatory and what won't.
HMAC should be the mandatory one, for several good reasons.
> ...........Right now we can fail to advance 1828 as
> part of this process, but in general what we are doing is creating
> NEW transforms, not REPLACING old ones. The new transforms are then
> encouraged to be "must implement".
We are [or should be] making the new transform "must implement" and
the old one - "optional". In my eyes it's either a "replace", or
very close to it. (:-)
--
Regards,
Uri uri@watson.ibm.com
-=-=-=-=-=-=-
<Disclaimer>
Received: from relay.tis.com by neptune.TIS.COM id aa16503; 1 Mar 96 14:17 EST
Received: by relay.tis.com; id OAA14110; Fri, 1 Mar 1996 14:19:21 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma014084; Fri, 1 Mar 96 14:18:50 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA25640; Fri, 1 Mar 96 14:17:46 EST
Received: by relay.tis.com; id OAA14081; Fri, 1 Mar 1996 14:18:49 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma014076; Fri, 1 Mar 96 14:18:32 -0500
Received: from pilot.firewall.is.chrysler.com (pilot.is.chrysler.com) by interlock.ans.net with SMTP id AA22638
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Fri, 1 Mar 1996 14:19:32 -0500
Received: by pilot.firewall.is.chrysler.com; id OAA19020; Fri, 1 Mar 1996 14:43:52 -0500
Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilot.is.chrysler.com via smap (g3.0.1)
id sma019016; Fri, 1 Mar 96 14:43:50 -0500
Received: from rgm3 ([172.16.8.13]) by clhubgw1.is.chrysler.com (5.x/SMI-4.1)
id AA25736; Fri, 1 Mar 1996 14:21:14 -0500
Message-Id: <2.2.32.19960301191824.00381014@pop3hub.is.chrysler.com>
X-Sender: t3125rm@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 01 Mar 1996 14:18:24 -0500
To: ipsec@ans.net
From: Robert Moskowitz <rgm3@is.chrysler.com>
Subject: IETF meetings :(
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
I will not be arriving until Tuesday midnight. I HAVE to be home with the
family until after Purim.
ERGO I will miss both sessions, sorry.
I have been a bit overworked here to get my notes together on what I want
for the auto industry (yes I now have a much louder "voice" than in the
past), but I can convey that information on wednesday....
See you all then.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from relay.tis.com by neptune.TIS.COM id aa18104; 1 Mar 96 15:36 EST
Received: by relay.tis.com; id PAA16999; Fri, 1 Mar 1996 15:38:43 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma016986; Fri, 1 Mar 96 15:38:21 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA00642; Fri, 1 Mar 96 15:37:15 EST
Received: by relay.tis.com; id PAA16974; Fri, 1 Mar 1996 15:38:16 -0500
Received: from unknown(194.100.1.134) by relay.tis.com via smap (V3.1)
id xma016945; Fri, 1 Mar 96 15:37:41 -0500
Received: (from ylo@localhost) by trance.olari.clinet.fi (8.6.12/8.6.12) id WAA12732; Fri, 1 Mar 1996 22:41:14 +0200
Date: Fri, 1 Mar 1996 22:41:14 +0200
Message-Id: <199603012041.WAA12732@trance.olari.clinet.fi>
From: Tatu Ylonen <ylo@cs.hut.fi>
To: perry@piermont.com
Cc: hugo@watson.ibm.com, ipsec@TIS.COM
Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward
In-Reply-To: <199602292154.QAA18966@jekyll.piermont.com>
References: <199602292135.QAA26356@linet02.li.net>
<199602292154.QAA18966@jekyll.piermont.com>
Organization: Helsinki University of Technology, Finland
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
> > As a general note: if we can't modify the standards during the
> > standarization process why do we have that process in place.
>
> We can alter what is standard. However, it is often bad to alter what
> already exists. When SMTP got revised, an extensions mechanism was
> created -- existing SMTPs weren't broken. Sometime soon it will be
> required that SMTP implementations support ESMTP, but it will
> doubtless be a long while before ESMTP is totally universal, if
> ever.
But, in my understanding IPSEC does not "exist" yet in the same sense
as SMTP did. It does not yet have a wide user base, just a few small
groups using various implementations. I think it is probably early
enough to simply change the spec if it is otherwise justified.
(It may not be a bad idea to change the protocol number though if
confusion is likely.)
Tatu
Received: from relay.tis.com by neptune.TIS.COM id aa18172; 1 Mar 96 15:39 EST
Received: by relay.tis.com; id PAA17073; Fri, 1 Mar 1996 15:41:13 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma017063; Fri, 1 Mar 96 15:40:43 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA00768; Fri, 1 Mar 96 15:39:39 EST
Received: by relay.tis.com; id PAA17060; Fri, 1 Mar 1996 15:40:42 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma017053; Fri, 1 Mar 96 15:40:27 -0500
Received: from inner.net (avarice.inner.net) by interlock.ans.net with SMTP id AA24838
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Fri, 1 Mar 1996 15:41:24 -0500
Received: from inner.net ([192.168.1.1]) by inner.net (8.7.4/42) with ESMTP id LAA02374; Fri, 1 Mar 1996 11:43:36 -0500
Message-Id: <199603011643.LAA02374@inner.net>
X-Mailer: exmh version 1.6.5 12/11/95
To: uri@watson.ibm.com
Cc: ipsec@ans.net
Subject: Re: what I am proposing re HMAC
In-Reply-To: Your message of "Fri, 01 Mar 1996 13:44:52 EST."
<9603011844.AA42869@hawpub.watson.ibm.com>
X-Reposting-Policy: With explicit permission only
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 01 Mar 1996 15:41:02 -0500
From: Craig Metz <cmetz@inner.net>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
In message <9603011844.AA42869@hawpub.watson.ibm.com>, you write:
>> Any key negotiation
>> protocols that exist do not replace the meaning of "use the 1828
>> transform" with using HMAC -- they think of HMAC as a new
>> transform. I do not want the new RFC to "supersede" 1828 as a
>> replacement RFC would.
>
>It is a question of what transform will be mandatory and what won't.
>HMAC should be the mandatory one, for several good reasons.
I guess I may be missing something. People are talking as if RFC-1828
is totally worthless and HMAC is the holy grail, yet I'm not seeing any real
data that justifies this conclusion.
We know of no *feasable* attacks on RFC-1828, right? And how long have
cryptographers been playing with envelope MACs? Now, we have this new MAC. It
is probably better. It looks better to us. But it is still new enough that
we don't really know.
Why the mad rush to replace RFC-1828 with HMAC as the mandatory
minimum? First, this obseletes all current implementations. Sure, it's not that
difficult to update this, but that doesn't mean you still don't have to do
the work and then go through testing cycles again. Second, we're moving from a
known to an unknown. How many people have implemented and tested HMAC-based AH?
I don't know of any, though the IBM people probably have.
At the very least, it doesn't seem like a very good idea to change
RFC-1828's status until more people have *implemented* HMAC AH.
-Craig
Received: from relay.tis.com by neptune.TIS.COM id aa20614; 1 Mar 96 17:30 EST
Received: by relay.tis.com; id RAA19700; Fri, 1 Mar 1996 17:32:42 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma019694; Fri, 1 Mar 96 17:32:15 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA06709; Fri, 1 Mar 96 17:31:10 EST
Received: by relay.tis.com; id RAA19687; Fri, 1 Mar 1996 17:32:12 -0500
Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1)
id xma019681; Fri, 1 Mar 96 17:32:05 -0500
Received: from Bill.Simpson.DialUp.Mich.Net (pm001-02.dialip.mich.net [35.1.48.51]) by merit.edu (8.7.3/merit-2.0) with SMTP id RAA03597 for <ipsec@TIS.COM>; Fri, 1 Mar 1996 17:32:56 -0500 (EST)
Date: Fri, 1 Mar 96 21:35:44 GMT
From: William Allen Simpson <wsimpson@greendragon.com>
Message-Id: <5033.wsimpson@greendragon.com>
To: ipsec@TIS.COM
Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
I'm on the road, and don't have a lot of time to reply here:
> From: smb@research.att.com
> Of course, all along the unanimous opinion of the cryptographic theoreticians
> has been that keyed hash functions were an unknown -- they weren't designed
> to do that, and it wasn't clear that they were secure in this mode. But
> we went ahead anyway.
>
Yes. And we then learned that the "theoreticians" got it wrong.
Randall Atkinson (and Perry and myself and others) originally proposed
keying in the most simple and obvious way -- H[key,length,data].
After analysis, we now know that the originally proposed construct is
more secure than what the "theoreticians" repeatedly told us we needed
to change. As demonstrated within 6 months by other more capable
theoreticians.
We made a mistake. We made changes without 2 or 3 years of review.
We should never have given in to the pressure.
I remind you who prompted that change:
Date: Tue, 24 Jan 95 18:40:52 EST
From: hugo@watson.ibm.com
To: bsimpson@MorningStar.Com, IPSEC@ans.net
Cc: jis@mit.edu
Subject: AH-MD5
Just to break the *quiet* consenus: I personally would prefer to
see a prepend+append MD5 for IP authentication.
The reasons are a more robust security design, less plausible to
suffer yet unknown vulnerabilities or implementation errors, at
a very low cost compared to prepend only (notice that MD5, by definition,
APPends the length of the information and I didn't see any claims
that this causes any significant degradation in performance).
Think about his claims in the light of new evidence.
> Note carefully: revision is *likely*. If we're going to change it, now is
> the time -- after it goes to Draft, it's too late for fixes of this nature
> (absent, say, the discovery of a feasible attack).
>
In retrospect, let me apply the wisdom posted to this list, that
prompted Perry and I to make the change to H[key,data,key] rather than
Kaliski's proposal:
Date: Tue, 14 Mar 95 15:28:27
From: "Housley, Russ" <housley@spyrus.com>
To: Hilarie Orman <ho@cs.arizona.edu>
Cc: ipsec@ans.net
Subject: Re[2]: End of WG Last Call for AH+MD5 and ESP+DES+3DES
Hilarie said:
I think that MD5(key, text, key) may be more secure than the double
hash. My understanding is that Kaliski's suggestion was based on the
idea that MD5(text) might be a useful subfunction. However, I'm
uneasy at the idea of a possible cryptanalysis of MD5(foo,key); not a
question I've seen examined before.
MD5(key,data,key) is one of the few things we had concensus about. Burt
did not say that this was weak, rather he said that the other had more
study behind it.
I think that we should keep MD5(key,data,key) because it an be computed
with one function invocation when implemented in hardware.
MD5(MD5(data),key) will require two function invocations in hardware
implementations.
We now know a very formal analysis shows an IMPRACTICAL attack on
H[key,data,key]. But, between the 2 choices, practicality was a
principle consideration.
That is one of the reasons that DES was chosen over 3DES as required to
implement. Yes, we know it's weaker than we'd like. But we _know_ the
weaknesses. And it's strong enough for practical purposes.
Now, if we wait long enough, we might find even better choices. We have
something that works. There is no hurry!
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
Received: from relay.tis.com by neptune.TIS.COM id aa20615; 1 Mar 96 17:30 EST
Received: by relay.tis.com; id RAA19699; Fri, 1 Mar 1996 17:32:42 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma019693; Fri, 1 Mar 96 17:32:15 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA06708; Fri, 1 Mar 96 17:31:10 EST
Received: by relay.tis.com; id RAA19688; Fri, 1 Mar 1996 17:32:12 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma019683; Fri, 1 Mar 96 17:32:06 -0500
Received: from merit.edu by interlock.ans.net with SMTP id AA27321
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Fri, 1 Mar 1996 17:33:02 -0500
Received: from Bill.Simpson.DialUp.Mich.Net (pm001-02.dialip.mich.net [35.1.48.51]) by merit.edu (8.7.3/merit-2.0) with SMTP id RAA03601 for <ipsec@ans.net>; Fri, 1 Mar 1996 17:32:59 -0500 (EST)
Date: Fri, 1 Mar 96 22:03:36 GMT
From: William Allen Simpson <wsimpson@greendragon.com>
Message-Id: <5034.wsimpson@greendragon.com>
To: ipsec@ans.net
Subject: NMAC not HMAC, SHA not MD5
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
> From: "Perry E. Metzger" <perry@piermont.com>
> Subject: what I am proposing re HMAC
> 1) We leave 1828 alone. We do not advance it further but we do not
> "replace" it, meaning new RFCs do NOT "supersede" it in the way a
> replacement would.
Disagree. We should advance to Draft Standard. We have met the
requirements for Draft Standard.
> 2) We publish an RFC as a proposed standard for HMAC.
Disagree. We should publish a proposed standard for NMAC, which has
supporting analysis from multiple researchers.
Oh, and I've already written the draft....
HMAC is merely conjectural, and is less efficient to implement than NMAC.
And HMAC derives its security from NMAC. If anything, HMAC has a few
very specious assumptions.
> 3) We think of the HMAC transform not as a replacement for the
> existing transforms but as a new transform. Any key negotiation
> protocols that exist do not replace the meaning of "use the 1828
> transform" with using HMAC -- they think of HMAC as a new
> transform. I do not want the new RFC to "supersede" 1828 as a
> replacement RFC would. One of the reasons I'm strongly opinioned on
> this is that I expect this situation will occur over and over in
> the next decade -- we will discover something and want to replace
> what people are using. Right now we can fail to advance 1828 as
> part of this process, but in general what we are doing is creating
> NEW transforms, not REPLACING old ones.
>
Agreed! Particularly with the latter.
> 4) We leave the HMAC RFC at proposed standard long enough for the crypto
> community to really get its teeth in. Being at proposed should be
> sufficient to encourage vendors to implement. I know Hugo would
> probably like it to advance to draft standard more quickly, but my
> gut instinct says "wait".
Agreed.
> 5) If we desire, we may issue a document clarifying 1828 for
> historical reasons, but we do this as an informational RFC.
>
This is called an "applicability statement" and it is already provided
for in our standards process. I have already begun writing it.
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
Received: from relay.tis.com by neptune.TIS.COM id aa21422; 1 Mar 96 18:09 EST
Received: by relay.tis.com; id SAA20154; Fri, 1 Mar 1996 18:11:16 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma020152; Fri, 1 Mar 96 18:10:47 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA07764; Fri, 1 Mar 96 18:09:43 EST
Received: by relay.tis.com; id SAA20149; Fri, 1 Mar 1996 18:10:46 -0500
Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1)
id xma020147; Fri, 1 Mar 96 18:10:21 -0500
Received: from Bill.Simpson.DialUp.Mich.Net (pm001-00.dialip.mich.net [35.1.48.49]) by merit.edu (8.7.3/merit-2.0) with SMTP id SAA04611 for <ipsec@TIS.COM>; Fri, 1 Mar 1996 18:11:22 -0500 (EST)
Date: Fri, 1 Mar 96 22:37:07 GMT
From: William Allen Simpson <wsimpson@greendragon.com>
Message-Id: <5036.wsimpson@greendragon.com>
To: ipsec@TIS.COM
Subject: Hugo tutors (Was: (IMPORTANT) ...)
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
> Date: Thu, 29 Feb 96 18:31:34 EST
> From: hugo@watson.ibm.com
> There is so much traffic in this list these days and I hate contributing
> more but this may interest other people in addition to Perry.
>
> Waiting 1-2 years is unrealistic for IETF proposals.
> However, I wish there was a more orderly scrutiny of security designs
> for IETF protocols by cryptographers.
>
> Photuris is a good example. It took me 6 drafts (from 03 to 09)
> to convince Simpson to derive *independent* key bits for keyed-MD5 and DES.
This is a patently false and misleading statement.
Since, until draft -09, AH and ESP always had different SPIs, they also
always had independently derived keys.
With the advent of the WG request this winter for the _complication_ of
having AH and ESP _share_ the same SPI, then the key schedule of ESP-DES
in Photuris was required to change.
A more _complicated_ design engendered a more _complicated_ keying
schedule. No surprise there; these requests seem to avalanche.
I find it personally insulting that Hugo claims to have to teach us
simple and practical cryptographic features.
I will leave it to the rest of you to decide whether he is on track
about other "cryptographic sins".
> cryptographic sins. I didn't see where is the cryptographic community
> that is inspecting this design.
I have in hand a quote from another cryptographic analyst:
"I am impressed with the thoroughness of the Photuris spec."
Thanks anyway....
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
Received: from relay.tis.com by neptune.TIS.COM id aa22688; 1 Mar 96 19:37 EST
Received: by relay.tis.com; id TAA21286; Fri, 1 Mar 1996 19:39:47 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma021280; Fri, 1 Mar 96 19:39:18 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA09469; Fri, 1 Mar 96 19:38:14 EST
Received: by relay.tis.com; id TAA21274; Fri, 1 Mar 1996 19:39:17 -0500
Received: from orodruin.cs.berkeley.edu(128.32.38.24) by relay.tis.com via smap (V3.1)
id xma021270; Fri, 1 Mar 96 19:39:15 -0500
Received: from espresso.CS.Berkeley.EDU.mammoth (espresso.CS.Berkeley.EDU [128.32.33.40]) by orodruin.CS.Berkeley.EDU (8.7.Gamma.0/8.7.Gamma.0) with SMTP id QAA25358; Fri, 1 Mar 1996 16:40:17 -0800 (PST)
Received: by espresso.CS.Berkeley.EDU.mammoth (5.x/SMI-SVR4)
id AA20983; Fri, 1 Mar 1996 16:40:01 -0800
From: David A Wagner <daw@orodruin.cs.berkeley.edu>
Message-Id: <9603020040.AA20983@espresso.CS.Berkeley.EDU.mammoth>
Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward
To: William Allen Simpson <wsimpson@greendragon.com>
Date: Fri, 1 Mar 1996 16:40:00 -0800 (PST)
Cc: ipsec@TIS.COM
In-Reply-To: <5033.wsimpson@greendragon.com> from "William Allen Simpson" at Mar 1, 96 09:35:44 pm
Reply-To: daw@cs.berkeley.edu
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
> Randall Atkinson (and Perry and myself and others) originally proposed
> keying in the most simple and obvious way -- H[key,length,data].
>
> After analysis, we now know that the originally proposed construct is
> more secure than what the "theoreticians" repeatedly told us we needed
> to change. As demonstrated within 6 months by other more capable
> theoreticians.
Technical nitpick:
I assume you are claiming that recent attacks on the envelope method
show that it's less secure than H[key,length,data] ?? If so, you're
mistaken. (Is this really important, anyhow?)
The collision-based attacks of Preneel & van Oorschot which apply to
the envelope method also apply to H[key,length,data] in exactly the
same way. Furthermore, the comments of Kaliski & Robshaw apply to the
H[key,length,data] construction (which notably has no padding after
the key): short messages might be vulnerable to certain techniques,
such as linear cryptanalysis. The envelope method in RFC1828 is
strengthened against the short-message concern.
We're seeing incremental improvements in hash-based MAC technology due
to research by the cryptographers-- that much is apparent, I think.
Apolitically yours,
-- Dave Wagner
Received: from relay.tis.com by neptune.TIS.COM id aa24641; 1 Mar 96 22:17 EST
Received: by relay.tis.com; id WAA23549; Fri, 1 Mar 1996 22:19:16 -0500
From: smb@research.att.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma023546; Fri, 1 Mar 96 22:18:55 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA11993; Fri, 1 Mar 96 22:17:44 EST
Received: by relay.tis.com; id WAA23543; Fri, 1 Mar 1996 22:18:46 -0500
Message-Id: <199603020318.WAA23543@relay.tis.com>
Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1)
id xma023540; Fri, 1 Mar 96 22:18:31 -0500
Received: from research.att.com by ns; Fri Mar 1 22:16:37 EST 1996
Received: from gryphon by research; Fri Mar 1 22:13:40 EST 1996
Received: by gryphon; Fri Mar 1 22:13:35 EST 1996
To: ipsec@TIS.COM
Subject: bump-in-the-stack encryptor paper
Date: Fri, 01 Mar 96 22:13:34 EST
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Folks on this list might want to take a look at a paper by David Wagner
and myself: ftp://ftp.research.att.com/dist/smb/bisconf.ps. It describes
an IPSEC implementation for MS-DOS. Perhaps of more interest than the
paper itself are two subtle attacks on IPSEC modules, a fragmentation
attack and a routing attack.
--Steve Bellovin
Received: from relay.tis.com by neptune.TIS.COM id aa29681; 2 Mar 96 7:10 EST
Received: by relay.tis.com; id HAA27038; Sat, 2 Mar 1996 07:12:46 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma027035; Sat, 2 Mar 96 07:12:17 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA19126; Sat, 2 Mar 96 07:11:13 EST
Received: by relay.tis.com; id HAA27029; Sat, 2 Mar 1996 07:12:16 -0500
Received: from unknown(35.1.1.42) by relay.tis.com via smap (V3.1)
id xma027025; Sat, 2 Mar 96 07:12:05 -0500
Received: from Bill.Simpson.DialUp.Mich.Net (pm002-20.dialip.mich.net [141.211.7.156]) by merit.edu (8.7.3/merit-2.0) with SMTP id HAA19052 for <ipsec@TIS.COM>; Sat, 2 Mar 1996 07:12:57 -0500 (EST)
Date: Sat, 2 Mar 96 11:23:26 GMT
From: William Allen Simpson <wsimpson@greendragon.com>
Message-Id: <5037.wsimpson@greendragon.com>
To: ipsec@TIS.COM
Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
> From: David A Wagner <daw@orodruin.cs.berkeley.edu>
> I assume you are claiming that recent attacks on the envelope method
> show that it's less secure than H[key,length,data] ?? If so, you're
> mistaken. (Is this really important, anyhow?)
>
Hmmm, we can put our heads together and compare at LA, but looking at
"MDx-MAC" proposition 4 (page 6), finding internal collisions, but no
key recovery (yet):
/
/ 2/(s+1) * 2 ** 64 for H[key,length,data]
\/
versus "Two MAC" proposition 2 (page 5), with key recovery:
/
/ 2 * 2 ** 64 for H[key,data,key]
\/
Seems much weaker to me....
> Furthermore, the comments of Kaliski & Robshaw apply to the
> H[key,length,data] construction (which notably has no padding after
> the key): short messages might be vulnerable to certain techniques,
> such as linear cryptanalysis.
Actually, Atkinson's initial key was always padded (since 1993).
Although we argued about whether it should be to 128-bits or 512-bits.
The consideration was always for efficiency, however; promoted block
alignment for IPng and allowed precomputation.
And as you may remember, Metzger and I were whipsawed back and forth on
the key padding issue by the crypto-theoreticians for several months!
I can refer you to messages from Colin Plumb, Eric Rains, Burt Kaliski,
Russ Housley, Hilary Orman, Rich Schroeppel, and of course the
ubiquitous IBM trio of Amir, Hugo and Uri.
> The envelope method in RFC1828 is
> strengthened against the short-message concern.
>
Yes. And I thank you for the contribution. But the reason that it was
so easily accepted was it fit with precomputation, and was easy to code!
> We're seeing incremental improvements in hash-based MAC technology due
> to research by the cryptographers-- that much is apparent, I think.
>
Yes. I don't see any reason to leap off to yet another transform
without considerable validation by multiple analysts.
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
Received: from relay.tis.com by neptune.TIS.COM id aa00504; 2 Mar 96 8:22 EST
Received: by relay.tis.com; id IAA27246; Sat, 2 Mar 1996 08:24:16 -0500
From: smb@research.att.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma027244; Sat, 2 Mar 96 08:23:47 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA19962; Sat, 2 Mar 96 08:22:43 EST
Received: by relay.tis.com; id IAA27241; Sat, 2 Mar 1996 08:23:46 -0500
Message-Id: <199603021323.IAA27241@relay.tis.com>
Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1)
id xma027239; Sat, 2 Mar 96 08:23:27 -0500
Received: from research.att.com by ns; Sat Mar 2 08:21:37 EST 1996
Received: from gryphon by research; Sat Mar 2 08:17:25 EST 1996
Received: by gryphon; Sat Mar 2 08:17:22 EST 1996
To: ipsec@TIS.COM
Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward
Date: Sat, 02 Mar 96 08:17:22 EST
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Who else, besides Bill, thinks that we should go with the current transforms
instead of HMAC?
Received: from relay.tis.com by neptune.TIS.COM id aa10210; 3 Mar 96 0:01 EST
Received: by relay.tis.com; id AAA01291; Sun, 3 Mar 1996 00:03:16 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma001287; Sun, 3 Mar 96 00:02:47 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA02216; Sun, 3 Mar 96 00:01:43 EST
Received: by relay.tis.com; id AAA01284; Sun, 3 Mar 1996 00:02:46 -0500
Received: from theory.lcs.mit.edu(18.52.0.92) by relay.tis.com via smap (V3.1)
id xma001282; Sun, 3 Mar 96 00:02:44 -0500
Received: from cuckoo.lcs.mit.edu by theory.lcs.mit.edu (5.65c/TOC-1.2S)
id AA23248; Sun, 03 Mar 96 00:03:45 EST
From: Ran Canetti <canetti@theory.lcs.mit.edu>
Received: by cuckoo.lcs.mit.edu (5.65c/TOC-1.2C)
id AA02132; Sun, 03 Mar 96 00:04:09 EST
Date: Sun, 03 Mar 96 00:04:09 EST
Message-Id: <199603030504.AA02132@cuckoo.lcs.mit.edu>
To: ipsec@TIS.COM
Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
The following telegraphic presentation attempts at summing up our relevant
knowledge, accumulated during the past year or two, on the use of keyed hash
functions as MACs. I hope it will help in clarifying the current discussion.
I will consider the following schemes:
* The "prepend key and length" scheme, PKL(msg) = Hash(key,length,msg)
* The "envelope" scheme, ENV(msg) = Hash(key,pad,msg,key)
* The HMAC scheme, HMAC(msg) = Hash(key,pad1, Hash(key,pad2,msg))
* The NMAC scheme, NMAC(msg) = Hash_key1 (Hash_key2(msg))
(This last scheme is similar to HMAC, with the exceptions that
it uses two keys instead of one, and puts the keys in the IV of
the hash function instead of in the first part of the input.)
I) No feasible attack is currently known against any of these schemes.
If this is satisfactory then any of the above schemes will do.
However, one may want to have a better assurance than that for a standard.
Thus, attempts have been made to gain further assurance in the security
of schemes by proving statements of the sort: "If the underlying hash
function enjoys property X then scheme Y is a good MAC".
The weaker property X is, the more assurance we have in the security of
scheme Y. I am not aware of any other method for gaining assurance
in the security of a MAC scheme based on cryptographic hash functions.
II) The only claim I know, of the sort described above, regarding PKL and ENV
is: "If the compression function of the underlying hash function
is pseudorandom then PKL and ENV are good MACs".
This was the first statement of this sort that was proven, regarding any scheme;
thus at the time ENV and PKL gave the best assurance. However,
Pseudorandomness is quite a strong assumption.
III) On the more recently proposed NMAC scheme one can show that
"If the hash function is collision-free (in a very weak sense)
and the compression function is a good MAC on 512-bit messages then NMAC
is a good MAC".
Here the required properties of the hash function are much weaker
than pesudorandomness. In fact, they are quite minimal in the sense that
if they are not satisfied by some hash function then it is hard to imagine
that this hash function can be used to genrate MACs in any way at all.
In particular, this is the best security guarantee known for a hash-based MAC.
However, NMAC has the drawbacks that it uses two keys rather than one
and that it requires a small change in the code of the hash function
(i.e., putting the keys in the IV). Thus HMAC was proposed as a compromise.
HMAC uses only one key and requires no change in the code of the hash
function. However, an additional "mixing" property of the compression
function is assumed. Still, the combined assumptions on the hash function
are near-minimal and in particular much weaker than those of (II).
In short, out of the schemes that use a single 128-bit key and do not
change the code of the underlying hash function, HMAC provides
the strongest assurance in its security.
I must say that, given that all these schemes are of comparable efficiency,
I find it hard to imagine why the forum would want to adopt a scheme
that provides weaker assurance than HMAC.
Ran Canetti
Received: from relay.tis.com by neptune.TIS.COM id aa19250; 3 Mar 96 15:13 EST
Received: by relay.tis.com; id PAA04293; Sun, 3 Mar 1996 15:15:51 -0500
From: braden@isi.edu
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma004291; Sun, 3 Mar 96 15:15:22 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA12628; Sun, 3 Mar 96 15:14:17 EST
Received: by relay.tis.com; id PAA04288; Sun, 3 Mar 1996 15:15:21 -0500
Received: from venera.isi.edu(128.9.0.32) by relay.tis.com via smap (V3.1)
id xma004282; Sun, 3 Mar 96 15:14:59 -0500
Received: from can.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
id <AA20129>; Sun, 3 Mar 1996 12:15:48 -0800
Date: Sun, 3 Mar 96 12:16:08 PST
Posted-Date: Sun, 3 Mar 96 12:16:08 PST
Message-Id: <9603032016.AA18663@can.isi.edu>
Received: by can.isi.edu (4.1/4.0.3-4)
id <AA18663>; Sun, 3 Mar 96 12:16:08 PST
To: ipsec@TIS.COM, smb@research.att.com
Subject: Re: traffic type header
Cc: braden@isi.edu, minshall@ipsilon.com
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
*> From smb@research.att.com Mon Feb 26 19:49:50 1996
*> From: smb@research.att.com
*> To: ipsec@tis.com
*> Subject: traffic type header
*> Cc: braden@ISI.EDU, minshall@ipsilon.com
*> Date: Mon, 26 Feb 96 22:44:47 EST
*> Content-Length: 1551
*> X-Lines: 36
*>
*> The suggestion has been made that we should have an optional traffic type header.
*> That is, we need something that will disclose protocol and port numbers. The
*> purpose would be (a) to permit traffic measurements, and (b) to permit routers
*> to optimize their handling of certain kinds of traffic.
and (c) support integrated services, in particular RSVP.
Bob Braden
Received: from relay.tis.com by neptune.TIS.COM id aa19919; 3 Mar 96 16:00 EST
Received: by relay.tis.com; id QAA04480; Sun, 3 Mar 1996 16:02:51 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma004478; Sun, 3 Mar 96 16:02:24 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA13149; Sun, 3 Mar 96 16:01:18 EST
Received: by relay.tis.com; id QAA04471; Sun, 3 Mar 1996 16:02:22 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma004462; Sun, 3 Mar 96 16:01:57 -0500
Received: from ktik0 (ktik0.ethz.ch) by interlock.ans.net with SMTP id AA20640
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Sun, 3 Mar 1996 16:02:57 -0500
Received: from komsys-pc-gc.ethz.ch (laptop30.ietf.interop.net [130.128.2.30]) by ktik0 (8.6.8.1/8.6.6) with SMTP id WAA19442 for <ipsec@ans.net>; Sun, 3 Mar 1996 22:02:49 +0100
Message-Id: <2.2.32.19960303211235.006a55ac@ktik0.ethz.ch>
X-Sender: caronni@ktik0.ethz.ch (Unverified)
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 03 Mar 1996 22:12:35 +0100
To: ipsec@ans.net
From: Germano Caronni <caronni@tik.ee.ethz.ch>
Subject: Re: An observation or two
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
At 13:15 7.1.96 -0800, you wrote:
>I will offer just a technical observation or two speaking only for myself.
>
>ANY hybrid Diffie-Hellman scheme can provide Perfect Forward Secrecy.
>Your mention of one-time pads was entirely extraneous. Moreover, there
>is a lot of experience with deployed systems indicating the Hybrid
>Diffie-Hellman is not too expensive computationally or otherwise impractical.
By now I have recovered Diffies paper, and done some more hunting for
literature. But sincerly I found no **definition** of the term 'perfect
forward secrecy', anywhere. Do you have a reference at hand, which
introduces this term? Otherwise I feel like defining it myself. And the
expression 'perfect' is a very dangerous one ;-) which really leads to OTPs.
Certainly I agree with you, hybrid DH _is_ practical. It's just not a
perfect solution.
>Second, as near as I can tell, none of the current drafts meet _all_ of the
>WG requirements. Hence, your misunderstanding that this is about SKIP
>(hint: the questions are NOT specific to SKIP) is not well founded.
Well, one learns ;-) I sometimes have the impression that the
non-progression of the different standards is not wholedly based due to
technical reasons. From an idealistic point of view (let's call it Secure
Internet) I want IPSEC to move on. I do not care if it moves into the
Photuris direction, Oakley, SKIP, or all of them at the same time, as long
has we finally get some progress. Compared to the initial WG schedule IPSEC
is about one year (or more?) late... Then naturally I have some personal
preferences, but I believe I need not elaborate on those ;->> -- and they
are not exactly relevant in the standardisation process.
I definitvely have a problem with the working group requirements. They - let
me exagerate - do NOT exist. What we have is a collage of emails and
proceedings, which contain partially colliding requirements. Also this
inexistant list has mutated more than once or twice. I fear most people that
'know' the WG requirements and talk about them on the mailing list, have
views of their own as to what these requirements are. I would really enjoy
seeing a list, perhaps even stating which draft satisfies which
requirements. Naturally this is no easy task, and as I am not even able to
bring out a little transorm (sigh) draft in time, I will not volunteer to do
this.
Well, sorry for this rather longish mail, perhaps I will now sleep better.
Talk to you soon,
Germano
Received: from relay.tis.com by neptune.TIS.COM id aa22047; 3 Mar 96 18:43 EST
Received: by relay.tis.com; id SAA05556; Sun, 3 Mar 1996 18:45:34 -0500
From: Bart.Preneel@esat.kuleuven.ac.be
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma005554; Sun, 3 Mar 96 18:45:14 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA15090; Sun, 3 Mar 96 18:44:00 EST
Received: by relay.tis.com; id SAA05551; Sun, 3 Mar 1996 18:45:04 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma005546; Sun, 3 Mar 96 18:45:00 -0500
Received: from mailserv.esat.kuleuven.ac.be by interlock.ans.net with SMTP id AA22209
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Sun, 3 Mar 1996 18:45:58 -0500
Received: from yourcenar.esat.kuleuven.ac.be by mailserv (5.67b8/IDA/v1.5)
id AA13359; Mon, 4 Mar 1996 00:43:41 +0100
Organization: ESAT, K.U.Leuven, Belgium
Received: by yourcenar.esat.kuleuven.ac.be (5.65/ESAT-v1.2)
id AA07467; Mon, 4 Mar 1996 00:43:27 +0100
Date: Mon, 4 Mar 1996 00:43:27 +0100
Message-Id: <9603032343.AA07467@yourcenar.esat.kuleuven.ac.be>
To: ipsec@ans.net
Subject: MACs based on hash
X-Charset: ISO_8859-1
X-Char-Esc: 29
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Some comments on the proposals for MAC constructions:
> * The "prepend key and length" scheme, PKL(msg) = Hash(key,length,msg)
> * The "envelope" scheme, ENV(msg) = Hash(key,pad,msg,key)
> * The HMAC scheme, HMAC(msg) = Hash(key,pad1, Hash(key,pad2,msg))
> * The NMAC scheme, NMAC(msg) = Hash_key1 (Hash_key2(msg))
For the first two of these schemes, we know that there is a reduction
to the pseudo-randomness of the underlying compression function (PKL ENV);
For the NMAC: "we know that if the hash function is collision-free
(for a secret IV) and the compression function is a good MAC on 512-bit
messages then NMAC is a good MAC".
For HMAC, we need an additional mixing property of the compression function.
You forgot to mention MDx-MAC (see the Crypto'95 paper of Paul van Oorschot
and myself), for which there exist a security proof based on the
pseudo-randomness of the underlying compression function which is keyed
in both the IV and the message input.
All these reductions are very nice from a theoretical standpoint
(really a good piece of work). However, as a practical cryptanalyst,
I have the following remarks:
1. very little cryptanalysis has been done on MD4 and MD5; nevertheless,
some quite good results have been obtained already (from the
cryptanalyst's point of view).
2. no work at all has been done on properties of MD5 when part of the input
is a secret key.
3. it is even not obvious at all where to put this key: which part of
the input is the "natural" place to put it?
(in my humble opinion, it should be put in every part of the input,
but this is based on my intuition).
4. for all of these there exists a forgery attack which is unrealistic if
the underlying function (with the same parameters) is really strong;
for the first two schemes, this (unrealistic) attack allows for key
recovery rather than forgery. However, no one has yet analyzed how much
this can be improved if MD5 is used as underlying function.
In view of all of this, for all of you who want to use any of these
constructions based on MD5, I recommend to be very careful and take the
most conservative one you can afford.
I wonder how many of you would be prepared to use any of these schemes
if the US government had proposed them... (sorry, couldn't resist).
The good news is that you can make many mistakes, since there are
only very few cryptanalysts, and their time is very scarce (there are
many algorithms). That means it can take many years before they find the
time to try to break any of these schemes.
It's up to you to decide whether you can ignore their warnings.
Good luck.
Bart Preneel
PS Below some more details (for those of you who want to know):
---------------------------------------------------------------------------
1. Up till now very little cryptanalysis has been performed on MD4 and MD5
(compared to for example the amount of work on DES). I believe the total
effort is less than 1 personyear.
MD4 was badly broken (research effort of about 5 manmonths; collisions in
1 second on a PC), and it can be anticipated based on this that collisions
will be found for MD5 in the next 12 to 24 months. The main issue is just
to find a few competent people who want to spend a sufficient amount of time.
2. Up till now NO work has been done on the evaluation of the compression
function of MD5 as a pseudo-random function.
Some people claim that the fact that the compression function of MD5 is
a MAC or a pseudorandom function is a design criterion for MD5.
In my opinion it is at best a by-product of the design, and a by-product
which _never_ has been checked for. The reason for this is that usually
MD5 is not used with secret input, but only with known/chosen inputs.
The only property which has been evaluated and which approximates this
is preimage resistance: if you are given the complete output, find a preimage.
What is required for a MAC are properties of the compression function for
which _part_ of the input is fixed and secret; one then is allowed to
look at many outputs for chosen values of the remaining inputs.
As far as I know, there is only one class of concrete primitives which
have been checked for such a property, namely ...block ciphers.
(unfortunately they are slower and cannot be exported).
The properties required are totally different from collision resistance
or one-wayness: for example, the existence of probabilistic linear
relations between part of the input (where you have put the key) and
the output could lead to linear cryptanalysis of MD5; such an attack would
not change anything to the security of the hash function as a collision
resistant or (second) preimage resistant function.
3. it is even not obvious at all where to put this key: which part of
the input is the "natural" place to put it?
If one uses MD5 as a MAC or as a pseudorandom function, you have to insert
the key somewhere. In my humble opinion, there is no obvious place to do this;
if you look at MD5 as a block cipher, the message input would be the key,
and the IV would be the plaintext.
NMAC enters the key in the IV, and the [BCK] paper contains
the following claim: "As it turns out, the latter approach
has some significant analytical advantages".
Moreover, if you one would design a hash function according to the
Merkle-Damgaard principle, i.e., derive the collision resistance of the
hash function from that of the compression function (such as Snefru of Merkle),
there would be no distinction between the IV and the message input. So it is
quite confusing to me that putting the key in the IV input can have
analytical advantages.
The fact that there is no obvious place to put the key, is the reason why
in MDx-MAC the key is put both in the IV and in the message input.
The idea behind this is that since the compression function is not designed
to hide any of its inputs in the way which a pseudo-random function should,
the key should be involved in _every_ input.
I agree that this is not a security proof, but in my opinion it is
a sound design principle.
4. for all of these schemes there exists a forgery attack which is unrealistic if
the underlying function (with the same parameters) is really strong;
for the first two schemes, this (unrealistic) attack allows for key
recovery rather than forgery. However, no one has yet analyzed how much
this can be improved if MD5 is used as underlying function.
Since the time of cryptanalysts is scarce, and our knowledge of
cryptographic algorithms is limited, we often have to rely on
certificational weaknesses. For example MD5 has as certificational
weakness that its compression function is not collision resistant,
and the construction of RFC 1828 has as certificational weakness that
an unrealistic forgery attack can be extended to an unrealistic key
recovery attack. For me as a cryptographer this would be sufficient
to never use RFC1828 based on MD5.
And the fact that the attack for any compression function takes $2^{66}$
chosen texts does not mean that this could not be improved for MD5..
----------------------------------------------------------------------------
Received: from relay.tis.com by neptune.TIS.COM id aa25115; 3 Mar 96 23:29 EST
Received: by relay.tis.com; id XAA06710; Sun, 3 Mar 1996 23:31:34 -0500
From: hugo@watson.ibm.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma006706; Sun, 3 Mar 96 23:31:06 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA18355; Sun, 3 Mar 96 23:30:00 EST
Received: by relay.tis.com; id XAA06703; Sun, 3 Mar 1996 23:31:04 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma006701; Sun, 3 Mar 96 23:30:37 -0500
Received: from watson.ibm.com by interlock.ans.net with SMTP id AA25705
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Sun, 3 Mar 1996 23:31:38 -0500
Message-Id: <199603040431.AA25705@interlock.ans.net>
Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 3023;
Sun, 03 Mar 96 23:31:14 EST
Date: Sun, 3 Mar 96 23:31:14 EST
To: Bart.Preneel@esat.kuleuven.ac.be, ipsec@ans.net
Subject: MACs based on hash
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Ref: Your note of Mon, 4 Mar 1996 00:43:27 +0100 (attached)
Bart Preneel writes:
> In view of all of this, for all of you who want to use any of these
> constructions based on MD5, I recommend to be very careful and take the
> most conservative one you can afford.
Agreed. Given that this group has decided to go with an MD5-based MAC,
we got to be careful and cautious.
This is the exact reason why we came up with HMAC and propose it as a
default MAC for AH: it is (among all studied candidates) the one scheme
to require the least assumptions on MD5 in order for the resultant
MAC to be secure (yet it requires no performance degradation or changes
to MD5).
Hugo
Received: from relay.tis.com by neptune.TIS.COM id aa27581; 4 Mar 96 2:53 EST
Received: by relay.tis.com; id CAA07845; Mon, 4 Mar 1996 02:54:49 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma007843; Mon, 4 Mar 96 02:54:24 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA20878; Mon, 4 Mar 96 02:53:15 EST
Received: by relay.tis.com; id CAA07839; Mon, 4 Mar 1996 02:54:19 -0500
Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1)
id xma007836; Mon, 4 Mar 96 02:54:18 -0500
Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id XAA03920 for ipsec@tis.com; Sun, 3 Mar 1996 23:55:17 -0800
Date: Sun, 3 Mar 1996 23:55:17 -0800
From: Ran Atkinson <rja@cisco.com>
Message-Id: <199603040755.XAA03920@puli.cisco.com>
To: ipsec@TIS.COM
Subject: IPsec transforms
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
[personal opinion]
I think the WG should seriously consider moving both RFC-1828 and
RFC-1829 to Historic. Hugo's HMAC transform should be seriously
considered to be moved to Proposed Standard and replace RFC-1828
as the mandatory-to-implement AH transform. Similarly, Jim Hughes'
DES+MD5+replay-protection ESP transform should be reviewed/edited
and then seriously considered to be moved to Proposed Standard
and replace RFC-1829 as the mandatory-to-implement ESP transform.
[WG chair speaking]
This is precisely the correct time to consider these kinds of
significant technical changes to the IPsec transforms.
Because RFC-1825 thru RFC-1827 are not yet ready to be considered
for advancement to Draft Standard, RFC-1828 and RFC-1829 cannot yet
be considered for advancement to Draft Standard in any event. Any
appeals of this decision should be made directly to the Security AD
and should NOT clutter this list further.
In general, if one believes the chair(s) have made a meaningful
incorrect process decision the correct procedure is to appeal to
the Security AD. The Security AD is empowered to overrule the
chair(s) of the WG.
Ran
rja@cisco.com
Received: from relay.tis.com by neptune.TIS.COM id aa04261; 5 Mar 96 17:02 EST
Received: by relay.tis.com; id RAA12288; Tue, 5 Mar 1996 17:04:32 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma012273; Tue, 5 Mar 96 17:04:02 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA08143; Tue, 5 Mar 96 17:02:56 EST
Received: by relay.tis.com; id RAA12264; Tue, 5 Mar 1996 17:04:00 -0500
Received: from stilton.cisco.com(171.69.1.161) by relay.tis.com via smap (V3.1)
id xma012256; Tue, 5 Mar 96 17:03:40 -0500
Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by stilton.cisco.com (8.6.8+c/8.6.5) with ESMTP id OAA12594 for <ipsec@tis.com>; Tue, 5 Mar 1996 14:04:41 -0800
Message-Id: <199603052204.OAA12594@stilton.cisco.com>
To: ipsec@TIS.COM
Subject: cisco ISAKMP/OAKLEY implementation
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <12588.826063480.1@cisco.com>
Date: Tue, 05 Mar 1996 14:04:40 -0800
From: David Carrel <carrel@cisco.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
This is just a recap of what I said at the IPSEC mtg Monday night for those
that weren't there or those who missed the URLs.
cisco is making available a reference implementation of ISAKMP with OAKLEY
extensions. We plan to make this available mid April or earlier. The
implementation works with the NRL PF Key socket and runs on BSD 4.4
platforms such as BSDi, NetBSD and FreeBSD. It should port to other OSes
easily as it runs entirely in user space.
We plan to do interoperability testing over the net between our
implementation, the NSA implementation (to be available soon from MIT, I'm
told) and the implementation from the Brittish Defense Research Agency.
Others are welcome and encouraged to join in.
The implementation is free in source code form and we have purchased
licensing that allows it to be copied and used in commercial or
non-commercial products without royalties. The intent is to move things in
the IPSEC forward by making code available and as unrestricted as possible.
The exact license will be online shortly after I get back to San Jose on
our anonymous ftp site. The README file in:
ftp://ftp.cisco.com/isakmp-oakley/README
will have the exact location of the license and other files including
instructions for downloading the code.
A mailing list has been set up for discussions and announcements relatng to
our implementation. The list is isakmp-oakley@cisco.com and you can add
yourself by sending email to majordomo@cisco.com with the line
subscribe isakmp-oakley
in the body of the message. The mailing list is being archived in the same
anonymous ftp directory.
Of course, access to our code is limited to sites in the US and Canada.
Dave
----------------------------------------------------------------------------
David Carrel | E-mail: carrel@cisco.com
Security Development, cisco Systems | phone: (408) 526-5207
170 W. Tasman Drive | fax: (408) 526-4952
San Jose, CA 95134-1706 |
----------------------------------------------------------------------------
Received: from relay.tis.com by neptune.TIS.COM id aa05229; 5 Mar 96 17:57 EST
Received: by relay.tis.com; id RAA13669; Tue, 5 Mar 1996 17:59:28 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma013666; Tue, 5 Mar 96 17:58:59 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA10328; Tue, 5 Mar 96 17:57:54 EST
Received: by relay.tis.com; id RAA13661; Tue, 5 Mar 1996 17:58:58 -0500
Received: from uucp5.netcom.com(163.179.3.5) by relay.tis.com via smap (V3.1)
id xma013657; Tue, 5 Mar 96 17:58:29 -0500
Received: by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1)
id OAA02428; Tue, 5 Mar 1996 14:36:04 -0800
Received: from cc:Mail by spysouth.spyrus.com
id AA826064531 Tue, 05 Mar 96 14:22:11
Date: Tue, 05 Mar 96 14:22:11
From: "Housley, Russ" <housley@spyrus.com>
Encoding: 2048 Text
Message-Id: <9602058260.AA826064531@spysouth.spyrus.com>
To: perry@piermont.com, hugo@watson.ibm.com
Cc: ipsec@TIS.COM
Subject: Re: Call for AH-MD5 and ESP-DES to move forward
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Perry:
I agree with Hugo. Replace is the correct action.
Russ
______________________________ Reply Separator _________________________________
Subject: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward
Author: hugo@watson.ibm.com at internet
Date: 2/29/96 4:22 PM
Ref: Your note of Thu, 29 Feb 1996 16:09:19 -0500 (attached)
Perry,
>
> I have no problem with the idea of ultimately advancing the HMAC
> transform to standard, especially after it has been out for a good
> while and there has been additional opportunity for cryptographers to
> attack it, but I disagree with the words "replace". As Paul's survey
> reveals, many implementations currently implement 1828. Let us instead
> speak of requiring this new superior transform rather than of
> "replacing" the old one, which would imply, for example, that
> identifiers for 1828 in key management protocols would have to point
> at HMAC instead, which would result in interoperability problems.
What I want is that implementations *do* move to this new function.
We are doing a lot of implementation work regarding IPSEC, and we talk
to many other implementation people involved with IPSEC.
The message is very clear: no one has any real problem to implement the
new transform, however they will not do that as long as there is another
one that is *officially* required by the IPSEC standard.
We need to find a way to break this loop. I don't care about the word
"replace" just about making clear that IPSEC-AH REQUIRES HMAC
(as the default implementation).
As a general note: if we can't modify the standards during the
standarization process why do we have that process in place.
Implementors need to know (and we know!) that changes will occur.
This particular one is easy to implement and upgrade.
If the decision is that it is too late to change the default algorithm
I would recommend this group to be even more careful on any decision about
moving any document to standards track.
Hugo
Received: from relay.tis.com by neptune.TIS.COM id aa01165; 7 Mar 96 2:48 EST
Received: by relay.tis.com; id CAA06772; Thu, 7 Mar 1996 02:49:36 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma006768; Thu, 7 Mar 96 02:49:08 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA13649; Thu, 7 Mar 96 02:48:03 EST
Received: by relay.tis.com; id CAA06762; Thu, 7 Mar 1996 02:49:06 -0500
Received: from copilot.is.chrysler.com(204.189.94.148) by relay.tis.com via smap (V3.1)
id xma006758; Thu, 7 Mar 96 02:49:02 -0500
Received: by pilotx.firewall.is.chrysler.com; id DAA27715; Thu, 7 Mar 1996 03:17:15 -0500
Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1)
id sma027703; Thu, 7 Mar 96 03:16:50 -0500
Received: from rgm3 ([172.16.8.15]) by clhubgw1.is.chrysler.com (5.x/SMI-4.1)
id AA07099; Thu, 7 Mar 1996 02:51:28 -0500
Message-Id: <2.2.32.19960307074720.00346d94@pop3hub.is.chrysler.com>
X-Sender: t3125rm@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 07 Mar 1996 02:47:20 -0500
To: Tatu Ylonen <ylo@cs.hut.fi>, perry@piermont.com
From: Robert Moskowitz <rgm3@is.chrysler.com>
Subject: Re: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward
Cc: hugo@watson.ibm.com, ipsec@TIS.COM
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
At 10:41 PM 3/1/96 +0200, Tatu Ylonen wrote:
>
>But, in my understanding IPSEC does not "exist" yet in the same sense
>as SMTP did. It does not yet have a wide user base, just a few small
>groups using various implementations. I think it is probably early
>enough to simply change the spec if it is otherwise justified.
>(It may not be a bad idea to change the protocol number though if
>confusion is likely.)
I should point out that TELNET went through a similar problem; right now I
forget the option, envirnoment, I think. They did it wrong, big time, and
there were already implementations, and Borman had to carefully architect
the movement to the 'right' way.
You have it much easier. with a new transform # and a clear statement that
HMAC is the required transform with the old one perhaps 'historical'
Let's do a last call on HMAC, please. As a consumer I expect you all to do
this.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from relay.tis.com by neptune.TIS.COM id aa01164; 7 Mar 96 2:48 EST
Received: by relay.tis.com; id CAA06773; Thu, 7 Mar 1996 02:49:36 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma006769; Thu, 7 Mar 96 02:49:08 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA13650; Thu, 7 Mar 96 02:48:03 EST
Received: by relay.tis.com; id CAA06763; Thu, 7 Mar 1996 02:49:06 -0500
Received: from copilot.is.chrysler.com(204.189.94.148) by relay.tis.com via smap (V3.1)
id xma006759; Thu, 7 Mar 96 02:49:03 -0500
Received: by pilotx.firewall.is.chrysler.com; id DAA27728; Thu, 7 Mar 1996 03:17:16 -0500
Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1)
id sma027705; Thu, 7 Mar 96 03:16:52 -0500
Received: from [172.16.8.15] by clhubgw1.is.chrysler.com (5.x/SMI-4.1)
id AB07099; Thu, 7 Mar 1996 02:51:32 -0500
Message-Id: <2.2.32.19960307074723.00346d94@pop3hub.is.chrysler.com>
X-Sender: t3125rm@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 07 Mar 1996 02:47:23 -0500
To: Ran Atkinson <rja@cisco.com>, ipsec@TIS.COM
From: Robert Moskowitz <rgm3@is.chrysler.com>
Subject: Re: IPsec transforms
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
At 11:55 PM 3/3/96 -0800, Ran Atkinson wrote:
>
>[personal opinion]
>
> I think the WG should seriously consider moving both RFC-1828 and
>RFC-1829 to Historic. Hugo's HMAC transform should be seriously
>considered to be moved to Proposed Standard and replace RFC-1828
>as the mandatory-to-implement AH transform. Similarly, Jim Hughes'
>DES+MD5+replay-protection ESP transform should be reviewed/edited
>and then seriously considered to be moved to Proposed Standard
>and replace RFC-1829 as the mandatory-to-implement ESP transform.
I agree, personally. With my IAB hat on, this is the process we should follow.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from relay.tis.com by neptune.TIS.COM id aa09263; 7 Mar 96 11:36 EST
Received: by relay.tis.com; id LAA13762; Thu, 7 Mar 1996 11:38:17 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma013760; Thu, 7 Mar 96 11:37:49 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA01834; Thu, 7 Mar 96 11:36:44 EST
Received: by relay.tis.com; id LAA13755; Thu, 7 Mar 1996 11:37:47 -0500
Received: from rsa.com(192.80.211.33) by relay.tis.com via smap (V3.1)
id xma013751; Thu, 7 Mar 96 11:37:37 -0500
Received: from snail.rsa.com by RSA.COM with SMTP
id AA02291; Thu, 7 Mar 96 08:29:45 PST
Received: from cc:Mail by snail.rsa.com
id AA826216778; Thu, 07 Mar 96 08:39:25 PST
Date: Thu, 07 Mar 96 08:39:25 PST
From: baldwin <baldwin@rsa.com>
Message-Id: <9602078262.AA826216778@snail.rsa.com>
To: ipsec@TIS.COM
Subject: AH vs. ESP with MD5
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
I have a couple questions about the goals for the revised ESP
that includes integrity and replay protection.
1) Is the new ESP suppose to eliminate the need for the AH transform?
- If so, the current draft does not provide any integrity checks
on the IP header, so an attacker can modify those fields in
transit. Maybe that is not considered to be a threat.
- If not, then a secuure implementation that includes both AH
and ESP will have to perform two MD5 digests on the payload.
That is a 33% performance hit for large packets [with the
original AH-ESP, the payload is scanned once for the AH digest
and once for the DES-CBC, the new ESP-DES-CBC-MD5 requires
an additional scan of MD5 on the plaintext payload].
2) Do ESP packets need to be self describing in terms of the features
they support (e.g., whether replay protection is included)?
The current design assumes that the SPI determines all the
required features.
--Bob
Received: from relay.tis.com by neptune.TIS.COM id aa10704; 7 Mar 96 13:05 EST
Received: by relay.tis.com; id NAA14740; Thu, 7 Mar 1996 13:07:17 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma014732; Thu, 7 Mar 96 13:06:48 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA05967; Thu, 7 Mar 96 13:05:43 EST
Received: by relay.tis.com; id NAA14729; Thu, 7 Mar 1996 13:06:47 -0500
Received: from unknown(128.127.2.122) by relay.tis.com via smap (V3.1)
id xma014727; Thu, 7 Mar 96 13:06:37 -0500
Received: from ftp.com by ftp.com ; Thu, 7 Mar 1996 13:07:36 -0500
Received: from mailserv-H.ftp.com by ftp.com ; Thu, 7 Mar 1996 13:07:36 -0500
Received: from naganand-1.ftp.com (laptop206.ietf.interop.net) by MAILSERV-H.FTP.COM (5.x/SMI-SVR4)
id AA11318; Thu, 7 Mar 1996 13:07:56 -0500
Date: Thu, 7 Mar 1996 13:07:56 -0500
Message-Id: <9603071807.AA11318@MAILSERV-H.FTP.COM>
X-Sender: naganand@mailserv-H.ftp.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: baldwin <baldwin@rsa.com>
From: Naganand Doraswamy <naganand@ftp.com>
Subject: Re: AH vs. ESP with MD5
Cc: ipsec@TIS.COM
X-Mailer: <Windows Eudora Version 2.0.2>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
>1) Is the new ESP suppose to eliminate the need for the AH transform?
> - If so, the current draft does not provide any integrity checks
> on the IP header, so an attacker can modify those fields in
> transit. Maybe that is not considered to be a threat.
> - If not, then a secuure implementation that includes both AH
> and ESP will have to perform two MD5 digests on the payload.
> That is a 33% performance hit for large packets [with the
> original AH-ESP, the payload is scanned once for the AH digest
> and once for the DES-CBC, the new ESP-DES-CBC-MD5 requires
> an additional scan of MD5 on the plaintext payload].
>
The new ESP transform does not eliminate AH. AH is still useful in cases
where you dont need to encrypt the data. Also, you may have may only perfrom
AH and not ESP for export.
>2) Do ESP packets need to be self describing in terms of the features
> they support (e.g., whether replay protection is included)?
> The current design assumes that the SPI determines all the
> required features.
>
>From what I understand talking to the editors, it is still not decided
whether replay protection is mandatory or optional. There should be some
discussion on this in the mailing list.
Regards,
--Naganand
Received: from relay.tis.com by neptune.TIS.COM id aa10986; 7 Mar 96 13:24 EST
Received: by relay.tis.com; id NAA14908; Thu, 7 Mar 1996 13:26:47 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma014903; Thu, 7 Mar 96 13:26:18 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA06483; Thu, 7 Mar 96 13:25:13 EST
Received: by relay.tis.com; id NAA14900; Thu, 7 Mar 1996 13:26:17 -0500
Received: from unknown(137.175.2.11) by relay.tis.com via smap (V3.1)
id xma014898; Thu, 7 Mar 96 13:26:02 -0500
Received: from gefilte.MorningStar.Com by volitans.MorningStar.Com (8.7.1/95070701)
id SAA24199; Thu, 7 Mar 1996 18:27:02 GMT
From: Karl Fox <karl@morningstar.com>
Received: by gefilte.MorningStar.Com (5.65a/94012401)
id AA04683; Thu, 7 Mar 96 13:27:02 -0500
Date: Thu, 7 Mar 96 13:27:02 -0500
Message-Id: <9603071827.AA04683@gefilte.MorningStar.Com>
To: ipsec@TIS.COM
Subject: Alternative transform encapsulation scheme
Reply-To: Karl Fox <karl@morningstar.com>
Organization: Morning Star Technologies, Inc.
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Now that we're heading toward individual do-everything transforms
rather than layered orthogonal functions, the concept of separate AH
and ESP protocols seems a bit awkward. Consider a different protocol,
perhaps called `Security Transform', that might look like this:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transform ID | Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Optional Transform Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Transforms could be layered if desired. The length field would make
it easy to parse even if you didn't understand a particular transform
type. All of our code would become simpler, and the RSVP folks would
love this more uniform format.
The Next Header field would be slightly problematic; encrypting
transforms would want to obscure it somehow (perhaps destroying it
after storing a copy down in the opaque area) while not obscuring
portions of the Optional Transform Data field such as initialization
vectors.
I know it's pretty late in the game to begin talking about something
like this, but it only recently became appropriate because of the
recent change in attitudes toward combined transforms.
--
Karl Fox, servant of God, employee of Morning Star Technologies
3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 451 1883
Received: from relay.tis.com by neptune.TIS.COM id aa11758; 7 Mar 96 14:03 EST
Received: by relay.tis.com; id OAA15538; Thu, 7 Mar 1996 14:05:47 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma015522; Thu, 7 Mar 96 14:05:20 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA08653; Thu, 7 Mar 96 14:04:15 EST
Received: by relay.tis.com; id OAA15515; Thu, 7 Mar 1996 14:05:17 -0500
Received: from unknown(206.1.51.15) by relay.tis.com via smap (V3.1)
id xma015509; Thu, 7 Mar 96 14:05:10 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id OAA11949; Thu, 7 Mar 1996 14:06:00 -0500 (EST)
Message-Id: <199603071906.OAA11949@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: baldwin <baldwin@rsa.com>
Cc: ipsec@TIS.COM
Subject: Re: AH vs. ESP with MD5
In-Reply-To: Your message of "Thu, 07 Mar 1996 08:39:25 PST."
<9602078262.AA826216778@snail.rsa.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Thu, 07 Mar 1996 14:05:55 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
baldwin writes:
> I have a couple questions about the goals for the revised ESP
> that includes integrity and replay protection.
>
> 1) Is the new ESP suppose to eliminate the need for the AH transform?
No, not at all. It was intended all the way back to the origins of the
current proposal that ESP would be able to contain arbitrary opaque
transforms.
> 2) Do ESP packets need to be self describing in terms of the features
> they support (e.g., whether replay protection is included)?
> The current design assumes that the SPI determines all the
> required features.
You answered your own question -- the ESP packets are totally opaque,
and no information other than the SPI is needed.
Perry
Received: from relay.tis.com by neptune.TIS.COM id aa12728; 7 Mar 96 14:50 EST
Received: by relay.tis.com; id OAA16511; Thu, 7 Mar 1996 14:52:17 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma016506; Thu, 7 Mar 96 14:51:49 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA12167; Thu, 7 Mar 96 14:50:44 EST
Received: by relay.tis.com; id OAA16500; Thu, 7 Mar 1996 14:51:47 -0500
Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1)
id xma016492; Thu, 7 Mar 96 14:51:30 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id OAA12006; Thu, 7 Mar 1996 14:52:31 -0500 (EST)
Message-Id: <199603071952.OAA12006@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: Karl Fox <karl@morningstar.com>
Cc: ipsec@TIS.COM
Subject: Re: Alternative transform encapsulation scheme
In-Reply-To: Your message of "Thu, 07 Mar 1996 13:27:02 EST."
<9603071827.AA04683@gefilte.MorningStar.Com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Thu, 07 Mar 1996 14:52:31 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Karl Fox writes:
> Now that we're heading toward individual do-everything transforms
> rather than layered orthogonal functions, the concept of separate AH
> and ESP protocols seems a bit awkward.
ESP is not the "encrypting protocol". It is the OPAQUE protocol. The
idea always was that AH was there to provide for non-opaque
encapsulated packets in which it was possible to determine what the
contents were without understanding the SPI, and ESP was always
intended to provide for any combination of
(encryption/authentication/replay/etc) that did not need to be
transparent.
Perry
Received: from relay.tis.com by neptune.TIS.COM id aa13929; 7 Mar 96 15:52 EST
Received: by relay.tis.com; id PAA17686; Thu, 7 Mar 1996 15:54:47 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma017671; Thu, 7 Mar 96 15:54:21 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA16075; Thu, 7 Mar 96 15:53:15 EST
Received: by relay.tis.com; id PAA17664; Thu, 7 Mar 1996 15:54:18 -0500
Received: from unknown(192.86.155.81) by relay.tis.com via smap (V3.1)
id xma017655; Thu, 7 Mar 96 15:54:08 -0500
Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7)
id MAA03590; Thu, 7 Mar 1996 12:55:06 -0800
Received: by mailsun2.us.oracle.com (8.7.1/37.8)
id MAA27585; Thu, 7 Mar 1996 12:57:22 -0800 (PST)
Message-Id: <199603072057.MAA27585@mailsun2.us.oracle.com>
Date: 07 Mar 96 11:42:23 -0800
From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>
To: ipsec@TIS.COM
Subject: Re: AH vs. ESP with MD5
X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.tis.com's message of 07-Mar-96 08:39
Mime-Version: 1.0
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
>From: baldwin
>1) Is the new ESP suppose to eliminate the need for the AH transform?
No. Requirements were identified for an authentication only protocol,
especially in the IPv6 environment. These requirements could be reexamined,
but are a separate issue from combining confidentiality and integrity in a
single ESP transform.
> - If so, the current draft does not provide any integrity checks
> on the IP header, so an attacker can modify those fields in
> transit. Maybe that is not considered to be a threat.
First no not so, we are not eliminating AH. Integrity checks can be provided
if required on the IP header using AH.
> - If not, then a secure implementation that includes both AH
> and ESP will have to perform two MD5 digests on the payload.
> That is a 33% performance hit for large packets [with the
> original AH-ESP, the payload is scanned once for the AH digest
> and once for the DES-CBC, the new ESP-DES-CBC-MD5 requires
> an additional scan of MD5 on the plaintext payload].
True, an end-system would be foolish to request unnecessary extra
encapsulations. The situation you describe could occur in various tunneling
scenarios that should be supported. For example using ESP end-to-end and AH
between firewalls that are carrying the end-to-end ESP.
>2) Do ESP packets need to be self describing in terms of the features
> they support (e.g., whether replay protection is included)?
No, this has not been the design paradigm for ESP. It is much more efficient
for processing and bits on the wire to have implicit definitions.
> The current design assumes that the SPI determines all the
> required features.
Yes.
Paul
--------------------------------------------------------------
Received: from relay.tis.com by neptune.TIS.COM id aa08331; 9 Mar 96 11:52 EST
Received: by relay.tis.com; id LAA00899; Sat, 9 Mar 1996 11:54:27 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma000889; Sat, 9 Mar 96 11:54:16 -0500
Received: from by tis.com (4.1/SUN-5.64)
id AC01693; Sat, 9 Mar 96 11:53:13 EST
Received: by relay; id FAA02316; Sat, 9 Mar 1996 05:40:17 -0500
Received: from unknown(205.179.16.1) by relay.tis.com via smap (V3.1)
id xma002300; Sat, 9 Mar 96 05:39:42 -0500
Received: (from thuy@localhost) by main.geminisecure.com (8.6.9/8.6.9) id OAA05598; Thu, 7 Mar 1996 14:51:34 -0800
Date: Thu, 7 Mar 1996 14:51:33 -0800 (PST)
From: Thuy Nguyen <thuy@geminisecure.com>
To: PALAMBER@us.oracle.com, ipsec@TIS.COM
Cc: swan-dev@rsa.com, "Dr. Tao" <tft@main.geminisecure.com>
Subject: Re: IPSEC Implementation Survey
Message-Id: <Pine.BSD/.3.91.960307144702.5593A-100000@main.geminisecure.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Name of Implementation: Gemini Trusted Security Firewall-Guard (GTFW-GD)
Security Protocols: 1. IPSec (ESP,AH): Public-Private
2. IPCSO & IPSec: Private-Private
(IP Crypto-Seal Option)
(Integrity, Authentication, Confidentiality)
Security Transforms: DES, Key MD5, Trusted Crypto-Seals
Key Management: 1. Manual for Trusted Public-Private Internetwork
2. A1 Trusted Distribution Key Management Extended
for Trusted Private-Private Internetwork
3. Customized
Lineage of Code: 1. Trusted Software
2. Platform: GTFW-GD on Gemini Trusted Network
Processor with Integrated Encryption
certified at Class A1
Location of Source Code: Proprietary
Point of Contact: Dr. Tien F. Tao, tft@main.geminisecure.com
Received: from relay.tis.com by neptune.TIS.COM id aa09498; 9 Mar 96 13:30 EST
Received: by relay.tis.com; id NAA01933; Sat, 9 Mar 1996 13:32:54 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma001931; Sat, 9 Mar 96 13:32:25 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA02984; Sat, 9 Mar 96 13:31:22 EST
Received: by relay.tis.com; id NAA01928; Sat, 9 Mar 1996 13:32:24 -0500
Received: from volitans.morningstar.com(137.175.2.11) by relay.tis.com via smap (V3.1)
id xma001926; Sat, 9 Mar 96 13:32:05 -0500
Received: from gefilte.MorningStar.Com by volitans.MorningStar.Com (8.7.1/95070701)
id SAA25491; Sat, 9 Mar 1996 18:33:10 GMT
From: Karl Fox <karl@morningstar.com>
Received: by gefilte.MorningStar.Com (5.65a/94012401)
id AA07448; Sat, 9 Mar 96 13:33:09 -0500
Date: Sat, 9 Mar 96 13:33:09 -0500
Message-Id: <9603091833.AA07448@gefilte.MorningStar.Com>
To: perry@piermont.com
Cc: ipsec@TIS.COM
Subject: Re: Alternative transform encapsulation scheme
In-Reply-To: <199603071952.OAA12006@jekyll.piermont.com>
References: <9603071827.AA04683@gefilte.MorningStar.Com>
<199603071952.OAA12006@jekyll.piermont.com>
Reply-To: Karl Fox <karl@morningstar.com>
Organization: Morning Star Technologies, Inc.
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Perry E. Metzger writes:
>
> Karl Fox writes:
> > Now that we're heading toward individual do-everything transforms
> > rather than layered orthogonal functions, the concept of separate AH
> > and ESP protocols seems a bit awkward.
>
> ESP is not the "encrypting protocol". It is the OPAQUE protocol.
My apologies; it's fairly easy to miss that point, since RFC 1827
mentions encryption and decryption 64 times while only mentioning
`opaque' twice in a fairly minor way in the syntax section.
> The idea always was that AH was there to provide for non-opaque
> encapsulated packets in which it was possible to determine what the
> contents were without understanding the SPI, and ESP was always
> intended to provide for any combination of
> (encryption/authentication/replay/etc) that did not need to be
> transparent.
So will these forthcoming authentication+opacity transforms
authenticate the outermost IP header the way AH does? If they don't,
won't we have to use AH anyway and thereby authenticate the packet
twice? If they do, then it looks like RFC 1827 will have to have some
significant changes to allow the transform to operate on the
encapsulating IP headers. For example, section 4.1, `ESP in
Tunnel-mode' says to discard the outside cleartext headers, and
section 4.3, `Authentication', says
Some transforms provide authentication as well as confidentiality and
integrity.
It then goes on to talk exclusively about how to use AH in combination
with ESP.
--
Karl Fox, servant of God, employee of Morning Star Technologies
3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 451 1883
Received: from relay.tis.com by neptune.TIS.COM id aa10431; 9 Mar 96 14:52 EST
Received: by relay.tis.com; id OAA02187; Sat, 9 Mar 1996 14:54:24 -0500
From: smb@research.att.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma002185; Sat, 9 Mar 96 14:53:55 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA03273; Sat, 9 Mar 96 14:52:52 EST
Received: by relay.tis.com; id OAA02182; Sat, 9 Mar 1996 14:53:54 -0500
Message-Id: <199603091953.OAA02182@relay.tis.com>
Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1)
id xma002180; Sat, 9 Mar 96 14:53:26 -0500
Received: from research.att.com by ns; Sat Mar 9 14:51:43 EST 1996
Received: from gryphon by research; Sat Mar 9 14:48:37 EST 1996
Received: by gryphon; Sat Mar 9 14:48:32 EST 1996
To: Karl Fox <karl@morningstar.com>
Cc: perry@piermont.com, ipsec@TIS.COM
Subject: Re: Alternative transform encapsulation scheme
Date: Sat, 09 Mar 96 14:48:32 EST
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
There's a lot that needs to be rethought. I could quite easily be
persuaded that we shouldn't, that we should simply decree that ESP
must be used only in conjunction with AH -- we've got to get this stuff
deployed ASAP. One small change -- the addition of replay protection --
does seem to be needed, though.
> So will these forthcoming authentication+opacity transforms
> authenticate the outermost IP header the way AH does? If they don't,
As David Wagner and I have pointed out before, in most contexts there's
little reason to authenticate the outer header. Fields are either (a)
constant, in which case there's no reason to authenticate them, (b) too
variable, such as the checksum, (c) hop-by-hop (TTL), or (d) bound to
the key, in which case why bother.
Received: from relay.tis.com by neptune.TIS.COM id aa10796; 9 Mar 96 15:19 EST
Received: by relay.tis.com; id PAA02274; Sat, 9 Mar 1996 15:21:54 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma002272; Sat, 9 Mar 96 15:21:25 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA03374; Sat, 9 Mar 96 15:20:22 EST
Received: by relay.tis.com; id PAA02269; Sat, 9 Mar 1996 15:21:24 -0500
Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1)
id xma002267; Sat, 9 Mar 96 15:21:11 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id PAA16596; Sat, 9 Mar 1996 15:22:00 -0500 (EST)
Message-Id: <199603092022.PAA16596@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: Karl Fox <karl@morningstar.com>
Cc: ipsec@TIS.COM
Subject: Re: Alternative transform encapsulation scheme
In-Reply-To: Your message of "Sat, 09 Mar 1996 13:33:09 EST."
<9603091833.AA07448@gefilte.MorningStar.Com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Sat, 09 Mar 1996 15:21:59 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Karl Fox writes:
> So will these forthcoming authentication+opacity transforms
> authenticate the outermost IP header the way AH does?
You bring up an interesting question. Perhaps they should. This is a
matter for discussion.
Perry
Received: from relay.tis.com by neptune.TIS.COM id aa21101; 11 Mar 96 17:26 EST
Received: by relay.tis.com; id RAA25196; Mon, 11 Mar 1996 17:28:39 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma025192; Mon, 11 Mar 96 17:28:14 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA07828; Mon, 11 Mar 96 17:27:10 EST
Received: by relay.tis.com; id RAA25185; Mon, 11 Mar 1996 17:28:09 -0500
Received: from unknown(35.1.1.42) by relay.tis.com via smap (V3.1)
id xma025181; Mon, 11 Mar 96 17:28:02 -0500
Received: from Bill.Simpson.DialUp.Mich.Net (pm001-01.dialip.mich.net [35.1.48.50]) by merit.edu (8.7.4/merit-2.0) with SMTP id RAA26655 for <ipsec@TIS.COM>; Mon, 11 Mar 1996 17:29:04 -0500 (EST)
Date: Mon, 11 Mar 96 21:42:41 GMT
From: William Allen Simpson <wsimpson@greendragon.com>
Message-Id: <5040.wsimpson@greendragon.com>
To: ipsec@TIS.COM
Subject: Re: Alternative transform encapsulation scheme
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
> 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
Received: from relay.tis.com by neptune.TIS.COM id aa21100; 11 Mar 96 17:26 EST
Received: by relay.tis.com; id RAA25197; Mon, 11 Mar 1996 17:28:39 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma025191; Mon, 11 Mar 96 17:28:14 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA07827; Mon, 11 Mar 96 17:27:10 EST
Received: by relay.tis.com; id RAA25186; Mon, 11 Mar 1996 17:28:09 -0500
Received: from unknown(35.1.1.42) by relay.tis.com via smap (V3.1)
id xma025182; Mon, 11 Mar 96 17:28:06 -0500
Received: from Bill.Simpson.DialUp.Mich.Net (pm001-01.dialip.mich.net [35.1.48.50]) by merit.edu (8.7.4/merit-2.0) with SMTP id RAA26659 for <ipsec@TIS.COM>; Mon, 11 Mar 1996 17:29:07 -0500 (EST)
Date: Mon, 11 Mar 96 22:07:45 GMT
From: William Allen Simpson <wsimpson@greendragon.com>
Message-Id: <5041.wsimpson@greendragon.com>
To: ipsec@TIS.COM
Subject: AH and ESP Orthogonality
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
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
Received: from relay.tis.com by neptune.TIS.COM id aa22588; 11 Mar 96 18:24 EST
Received: by relay.tis.com; id SAA26059; Mon, 11 Mar 1996 18:26:11 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma026055; Mon, 11 Mar 96 18:25:42 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA09736; Mon, 11 Mar 96 18:24:42 EST
Received: by relay.tis.com; id SAA26052; Mon, 11 Mar 1996 18:25:41 -0500
Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1)
id xma026050; Mon, 11 Mar 96 18:25:38 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id SAA29953; Mon, 11 Mar 1996 18:26:36 -0500 (EST)
Message-Id: <199603112326.SAA29953@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: William Allen Simpson <wsimpson@greendragon.com>
Cc: ipsec@TIS.COM
Subject: Re: AH and ESP Orthogonality
In-Reply-To: Your message of "Mon, 11 Mar 1996 22:07:45 GMT."
<5041.wsimpson@greendragon.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Mon, 11 Mar 1996 18:26:35 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
William Allen Simpson writes:
> 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.
I must admit that I actually somewhat agree with the all-in-one
approach. In Toronto, when the current formats were produced, we
agreed that we needed separate AH and ESP transforms not because one
would handle authentication and the other encryption, but because AH
was needed to provide a transparent encapsulation while ESP would
provide an opaque encapsulation. The reasons we had for permitting ESP
transforms to include any combination of encryption, authentication
and integrity checking was partially because this would save a
substantial number of bits on the wire for slow links. Our notion
initially was that we were cutting the gordion knot of which
particular services were to be provided by leaving most of that to the
transform documents, permitting transforms that essentially did
anything, and simply specifying a method (the SPI) for determining
which transform was in use.
This is not to say that only all-in-one transforms should exist, but I
think there is indeed a place for them some of the time.
Perry
Received: from relay.tis.com by neptune.TIS.COM id aa23163; 11 Mar 96 18:47 EST
Received: by relay.tis.com; id SAA26271; Mon, 11 Mar 1996 18:49:11 -0500
From: smb@research.att.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma026269; Mon, 11 Mar 96 18:48:42 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA10180; Mon, 11 Mar 96 18:47:42 EST
Received: by relay.tis.com; id SAA26266; Mon, 11 Mar 1996 18:48:41 -0500
Message-Id: <199603112348.SAA26266@relay.tis.com>
Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1)
id xma026264; Mon, 11 Mar 96 18:48:22 -0500
Received: from research.att.com by ns; Mon Mar 11 18:47:04 EST 1996
Received: from gryphon by research; Mon Mar 11 18:42:17 EST 1996
Received: by gryphon; Mon Mar 11 18:42:15 EST 1996
To: William Allen Simpson <wsimpson@greendragon.com>
Cc: ipsec@TIS.COM
Subject: Re: AH and ESP Orthogonality
Date: Mon, 11 Mar 96 18:42:14 EST
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
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?
While not completely worthless, ESP without both integrity protection
and replay prevention is significantly weakened in many real environments.
We therefore have a situation where ESP must be used in conjunction with
AH, and no document saying so. Worse yet, we're paying the overhead
price for a new header twice.
I'm planning on writing an RFC explaining this, but I won't be able to
get to it till next week, most likely -- I have other writing committments
to finish up first.
Received: from relay.tis.com by neptune.TIS.COM id aa24695; 11 Mar 96 19:46 EST
Received: by relay.tis.com; id TAA26868; Mon, 11 Mar 1996 19:48:41 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma026865; Mon, 11 Mar 96 19:48:16 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA11379; Mon, 11 Mar 96 19:47:15 EST
Received: by relay.tis.com; id TAA26854; Mon, 11 Mar 1996 19:48:14 -0500
Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1)
id xma026837; Mon, 11 Mar 96 19:47:39 -0500
Received: from Bill.Simpson.DialUp.Mich.Net (pm001-02.dialip.mich.net [35.1.48.51]) by merit.edu (8.7.4/merit-2.0) with SMTP id TAA00801 for <ipsec@TIS.COM>; Mon, 11 Mar 1996 19:48:47 -0500 (EST)
Date: Tue, 12 Mar 96 00:26:58 GMT
From: William Allen Simpson <wsimpson@greendragon.com>
Message-Id: <5044.wsimpson@greendragon.com>
To: ipsec@TIS.COM
Subject: Re: AH and ESP Orthogonality
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
> 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
Received: from relay.tis.com by neptune.TIS.COM id aa25152; 11 Mar 96 20:09 EST
Received: by relay.tis.com; id UAA27115; Mon, 11 Mar 1996 20:11:12 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma027113; Mon, 11 Mar 96 20:10:43 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA11814; Mon, 11 Mar 96 20:09:43 EST
Received: by relay.tis.com; id UAA27110; Mon, 11 Mar 1996 20:10:41 -0500
Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1)
id xma027104; Mon, 11 Mar 96 20:10:12 -0500
Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7)
id RAA03173; Mon, 11 Mar 1996 17:11:20 -0800
Received: by mailsun2.us.oracle.com (8.7.1/37.8)
id RAA16565; Mon, 11 Mar 1996 17:13:37 -0800 (PST)
Message-Id: <199603120113.RAA16565@mailsun2.us.oracle.com>
Date: 11 Mar 96 17:07:59 -0800
From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>
To: wsimpson@umich.edu
Subject: Re: AH and ESP Orthogonality
Cc: ipsec@TIS.COM
X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.tis.com's message of 11-Mar-96 22:07
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary=Boundary-3762205-0-0
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
--Boundary-3762205-0-0
Mr. Simpson
Your comments are out of line!
>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.
There is a very clear consensous for a mandatory transform with ESP that
contains both confidentiality and integrity.
I have no bias to drive the specifications toward anything but to complete the
best specification capturing the requirements and consensus of the working
group. While you may find long exchanges of rhetoric stimulating, most the
working group have better ways to spend their free time.
Please direct your delusions of intrigue to other venues. If your comments
have any purpose besides inflating the count of messages on this list
containing your return address, please rephrase them as specific technical
recommendations.
Paul A. Lambert
IPSEC Co-Chair
--Boundary-3762205-0-0
Content-Type: message/rfc822
Date: 11 Mar 96 22:07:45
From:"William Allen Simpson " <ipsec-request@neptune.tis.com>
To: ipsec@tis.com
Subject: AH and ESP Orthogonality
X-Orcl-Application: Sender: ipsec-request@neptune.tis.com
X-Orcl-Application: Precedence: bulk
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
--Boundary-3762205-0-0--
Received: from relay.tis.com by neptune.TIS.COM id aa25699; 11 Mar 96 20:38 EST
Received: by relay.tis.com; id UAA27698; Mon, 11 Mar 1996 20:40:54 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma027689; Mon, 11 Mar 96 20:40:25 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA12354; Mon, 11 Mar 96 20:39:25 EST
Received: by relay.tis.com; id UAA27684; Mon, 11 Mar 1996 20:40:24 -0500
Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1)
id xma027680; Mon, 11 Mar 96 20:40:21 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id UAA17978; Mon, 11 Mar 1996 20:41:09 -0500 (EST)
Message-Id: <199603120141.UAA17978@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: William Allen Simpson <wsimpson@greendragon.com>
Cc: ipsec@TIS.COM
Subject: Re: AH and ESP Orthogonality
In-Reply-To: Your message of "Tue, 12 Mar 1996 00:26:58 GMT."
<5044.wsimpson@greendragon.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Mon, 11 Mar 1996 20:41:08 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
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, and we were discussing
combined transforms as long ago as Toronto, though we didn't envision
making them mandatory at the time.
Anyway, lets just consider the situation on its current technical
merits, and not try to figure out who said what when...
Perry
Received: from relay.tis.com by neptune.TIS.COM id aa08142; 12 Mar 96 8:28 EST
Received: by relay.tis.com; id IAA02604; Tue, 12 Mar 1996 08:30:47 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma002599; Tue, 12 Mar 96 08:30:18 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA24470; Tue, 12 Mar 96 08:29:17 EST
Received: by relay.tis.com; id IAA02595; Tue, 12 Mar 1996 08:30:17 -0500
Received: from ftp.com(128.127.2.122) by relay.tis.com via smap (V3.1)
id xma002589; Tue, 12 Mar 96 08:29:55 -0500
Received: from ftp.com by ftp.com ; Tue, 12 Mar 1996 08:31:04 -0500
Received: from mailserv-H.ftp.com by ftp.com ; Tue, 12 Mar 1996 08:31:04 -0500
Received: from naganand-1.ftp.com (naganand-slippp.ftp.com) by MAILSERV-H.FTP.COM (5.x/SMI-SVR4)
id AA17052; Tue, 12 Mar 1996 08:31:24 -0500
Date: Tue, 12 Mar 1996 08:31:24 -0500
Message-Id: <9603121331.AA17052@MAILSERV-H.FTP.COM>
X-Sender: naganand@mailserv-H.ftp.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ipsec@TIS.COM
From: Naganand Doraswamy <naganand@ftp.com>
Subject: AH and ESP othogoanlity
X-Mailer: <Windows Eudora Version 2.0.2>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
I agree that there are merits performing integrity along with encapsulation.
The only problem I see with it is that there will be deployments for IPSEC
in the very near future and most of the the implementations have implemented
RFC's 1828 and 1829. We definitely cannot stop this as many customers have
been asking for it.
This may cause configuration problems for old implementation (implementing
only 1829) to interoperate with the newer implementation which may support
both 1829 and the new transform. Can we allocated numbers to the transforms
as most of the key management protocols do so that configuring with manual
keying is simplified?
--Naganand
Received: from relay.tis.com by neptune.TIS.COM id aa08807; 12 Mar 96 8:57 EST
Received: by relay.tis.com; id IAA03023; Tue, 12 Mar 1996 08:59:17 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma003010; Tue, 12 Mar 96 08:58:48 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA25717; Tue, 12 Mar 96 08:57:47 EST
Received: by relay.tis.com; id IAA03007; Tue, 12 Mar 1996 08:58:47 -0500
Received: from unknown(35.1.1.42) by relay.tis.com via smap (V3.1)
id xma002989; Tue, 12 Mar 96 08:58:30 -0500
Received: from Bill.Simpson.DialUp.Mich.Net (pm012-27.dialip.mich.net [141.211.7.195]) by merit.edu (8.7.4/merit-2.0) with SMTP id IAA18547 for <ipsec@TIS.COM>; Tue, 12 Mar 1996 08:59:34 -0500 (EST)
Date: Tue, 12 Mar 96 13:25:54 GMT
From: William Allen Simpson <wsimpson@greendragon.com>
Message-Id: <5048.wsimpson@greendragon.com>
To: ipsec@TIS.COM
Subject: Re: AH and ESP Orthogonality
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
> 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
Received: from relay.tis.com by neptune.TIS.COM id aa11213; 12 Mar 96 10:40 EST
Received: by relay.tis.com; id KAA05054; Tue, 12 Mar 1996 10:41:59 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma005050; Tue, 12 Mar 96 10:41:31 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA01926; Tue, 12 Mar 96 10:40:30 EST
Received: by relay.tis.com; id KAA05043; Tue, 12 Mar 1996 10:41:29 -0500
Date: Tue, 12 Mar 1996 10:41:29 -0500
Received: from labs-n.bbn.com(128.89.0.100) by relay.tis.com via smap (V3.1)
id xma005037; Tue, 12 Mar 96 10:41:12 -0500
Received: from COMSEC.BBN.COM by LABS-N.BBN.COM id aa12221; 12 Mar 96 10:41 EST
X-Sender: kent@eudora.bbn.com
Message-Id: <v02130500ad6a2131ee39@[128.89.0.110]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: William Allen Simpson <wsimpson@greendragon.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: AH and ESP Orthogonality
Cc: ipsec@TIS.COM
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Bill,
Having orthogonal transformations was not necessarily a bad idea,
but there are benefits to having a better division of responsibility
between AH and ESP. 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.
ESP, if it omits integrity and authenticity facilities, creates a
potential need for the embeded use of AH. However, if one were to redefine
ESP to include optional authentication and integrity facilities, then there
would be no need to embed AH when the required services spanned those now
provided separately. This would be more efficient from a bandwidth
standpoint, since a single header (ESP) could embody the fields necessary
for this larger set of services. As it stands, ESP is a shell and all the
detail is added in each transform defintion. This is unfortunate from a
document structuring standpoint. 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.
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. The motivation is to process and drop replayed
datagrams at an encrypting router, prior to letting them into a local net
environment. (At a host this doesn't offer as much protection from a
denial of service perspective, so it is most attractive in the context I
cited.) This is a reasonable service to offer either in the context of
AH or ESP. The former is especially appropriate if AH is used as an outer
layer of protection that is stripped off at a firewall (perhaps with an
inner ESP layer that goes all the way to the destination host), and the
latter is especially appropriate of an ESP layer (used in tunnel mode) is
stripped off at the firewall, with no inner layer IPSEC. The observation
that anti-replay is a reasonable feature for both AH and ESP further
motivates the creation of a single header that can provide all of the
services of AH and ESP, or any subset of the services.
I disagree with Perry about opacity being an important feature of
ESP. I participated in the Toronto WG meetings and hallway discussions and
I don't reacall opacity as a big deal, but I'm getting older so maybe my
memory ain't what it should be ;-). In fact, I don't like the fact that
the ESP spec is so detail-free and I'm not convinced that we can't have a
header that allows for a wide range of combinations of confidentiality,
integrity/authenticity, and anti-replay mechanisms, all of which can be
optional, combined in a mix-and-match fashion. I think that a new header,
providing such a set of features, might be what we should aim for.
Steve
Received: from relay.tis.com by neptune.TIS.COM id aa13781; 12 Mar 96 12:10 EST
Received: by relay.tis.com; id MAA06223; Tue, 12 Mar 1996 12:12:29 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma006221; Tue, 12 Mar 96 12:12:01 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA06279; Tue, 12 Mar 96 12:11:00 EST
Received: by relay.tis.com; id MAA06216; Tue, 12 Mar 1996 12:11:59 -0500
Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1)
id xma006212; Tue, 12 Mar 96 12:11:40 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id MAA01994; Tue, 12 Mar 1996 12:12:37 -0500 (EST)
Message-Id: <199603121712.MAA01994@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: William Allen Simpson <wsimpson@greendragon.com>
Cc: ipsec@TIS.COM
Subject: Re: AH and ESP Orthogonality
In-Reply-To: Your message of "Tue, 12 Mar 1996 13:25:54 GMT."
<5048.wsimpson@greendragon.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Tue, 12 Mar 1996 12:12:37 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
William Allen Simpson writes:
> > 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.
Actually, Bellovin came up with it in the hallway at Danvers outside
the terminal room. I was there when it happened. We had suspicions
that it was bad long before, but we didn't "know".
Again, however, this is history. Lets try to focus on what is best at
the moment, and not on what is historical.
> My point is that we are rehashing old arguments, and undermining the
> good work and deployment that this WG generated.
I don't think that we need to undermine anything, especially if we
declare the new transforms to be just that, *new* and better
transforms. Thats why I am against the notion of "replacement" and
want us to think instead in terms of things being "new and
improved". As I've said for a long time, our understanding of these
things gets refined with time and we have to expect to be coming up
with new transforms for new algorithims every few years for the rest
of the lifetime of the net. We should get used to it.
Perry
Received: from relay.tis.com by neptune.TIS.COM id aa16313; 12 Mar 96 13:44 EST
Received: by relay.tis.com; id NAA07503; Tue, 12 Mar 1996 13:46:39 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma007487; Tue, 12 Mar 96 13:46:10 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA09706; Tue, 12 Mar 96 13:45:09 EST
Received: by relay.tis.com; id NAA07484; Tue, 12 Mar 1996 13:46:08 -0500
Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1)
id xma007481; Tue, 12 Mar 96 13:46:00 -0500
Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id KAA08031; Tue, 12 Mar 1996 10:47:08 -0800
Date: Tue, 12 Mar 1996 10:47:08 -0800
From: Ran Atkinson <rja@cisco.com>
Message-Id: <199603121847.KAA08031@puli.cisco.com>
To: ipsec@TIS.COM
Subject: Re: AH and ESP othogoanlity
In-Reply-To: <9603121331.AA17052@MAILSERV-H.FTP.COM>
Organization: cisco Systems, Inc., Menlo Park, Ca.
Cc:
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
ASIDE:
I'm deliberately ignoring the notes to the IPsec list that focus on
"history" or "personal issues" rather than technology. My silence does NOT
imply that I agree with others' views of history or that I agree with the
words that others are putting in my mouth. Mainly, I'm focusing on writing
IP code. I prefer writing IP code to playing rhetorical games with history
or personal issues.
In article <9603121331.AA17052@MAILSERV-H.FTP.COM> Naganand wrote:
>I agree that there are merits performing integrity along with encapsulation.
>The only problem I see with it is that there will be deployments for IPSEC
>in the very near future and most of the the implementations have implemented
>RFC's 1828 and 1829. We definitely cannot stop this as many customers have
>been asking for it.
I don't think anyone has suggested that anyone stop deploying those
transforms, though it seems likely that at least RFC-1829 will move off the
standards-track to Historic status eventually. It might later become the
case that some new transform would be mandatory-to-implement in lieu of
RFC-1829, but this could be addressed by adding support for an additional
transform whilst not removing support for the RFC-1829 transform -- if an
implementer chose to do such.
>This may cause configuration problems for old implementation (implementing
>only 1829) to interoperate with the newer implementation which may support
>both 1829 and the new transform. Can we allocated numbers to the transforms
>as most of the key management protocols do so that configuring with manual
>keying is simplified?
I believe that more or less any publicly documented transform
should be allocated its own "transform identifier" by each of the various
key management proposals. I specifically asked the ISAKMP authors to add
transform identifiers for the current Experimental transforms so that nodes
that choose to use those transforms can use ISAKMP for key mgmt.
NOTE: I have not fully grok'd Perry's anxiety over the word "replace" and
don't want to get into that here and now because it doesn't seem terribly
productive here and now.
I will note that in my view if RFC-1829 were replaced on the
standards-track by an ESP DES-CBC+MD5+Replay transform, this would mean
that the replacement ESP DES-CBC+MD5+Replay transform would be allocated a
new "transform identifier" (i.e. transform identifier that is different
from the one that would remain allocated for RFC-1829). I use "replace" in
the context of what the mandatory-to-implement transform would be rather
than in the context of what is meant by a particular "transform identifier"
number.
This is just a matter of good protocol engineering. If a transform
changes in a material way, then it needs a new published specification and
it needs a new "transform identifier". We will probably continue to add
new and better transforms forever in the future as technology advances.
Implementers who don't design/build with the assumption that new transforms
will eventually come will probably regret it later on.
Bottom Line: Naganand and others with similar concerns should not
worry about this particular issue. Key mgmt draft authors
should allocate transform identifiers for each stable
openly-published transform (An Internet-Draft is, by
definition, not considered stable but an RFC is stable).
Ran
rja@cisco.com
Received: from relay.tis.com by neptune.TIS.COM id aa17007; 12 Mar 96 14:03 EST
Received: by relay.tis.com; id OAA08017; Tue, 12 Mar 1996 14:05:39 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma007999; Tue, 12 Mar 96 14:05:12 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA10647; Tue, 12 Mar 96 14:04:11 EST
Received: by relay.tis.com; id OAA07989; Tue, 12 Mar 1996 14:05:09 -0500
Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1)
id xma007971; Tue, 12 Mar 96 14:04:41 -0500
Received: from Bill.Simpson.DialUp.Mich.Net (pm012-22.dialip.mich.net [141.211.7.190]) by merit.edu (8.7.4/merit-2.0) with SMTP id OAA29250 for <ipsec@TIS.COM>; Tue, 12 Mar 1996 14:05:43 -0500 (EST)
Date: Tue, 12 Mar 96 18:15:56 GMT
From: William Allen Simpson <wsimpson@greendragon.com>
Message-Id: <5053.wsimpson@greendragon.com>
To: ipsec@TIS.COM
Subject: Re: AH and ESP Orthogonality
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
> 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
Received: from relay.tis.com by neptune.TIS.COM id aa17006; 12 Mar 96 14:03 EST
Received: by relay.tis.com; id OAA08016; Tue, 12 Mar 1996 14:05:39 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma007998; Tue, 12 Mar 96 14:05:12 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA10646; Tue, 12 Mar 96 14:04:10 EST
Received: by relay.tis.com; id OAA07988; Tue, 12 Mar 1996 14:05:09 -0500
Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1)
id xma007980; Tue, 12 Mar 96 14:04:42 -0500
Received: from Bill.Simpson.DialUp.Mich.Net (pm012-22.dialip.mich.net [141.211.7.190]) by merit.edu (8.7.4/merit-2.0) with SMTP id OAA29256 for <ipsec@TIS.COM>; Tue, 12 Mar 1996 14:05:46 -0500 (EST)
Date: Tue, 12 Mar 96 18:36:41 GMT
From: William Allen Simpson <wsimpson@greendragon.com>
Message-Id: <5054.wsimpson@greendragon.com>
To: ipsec@TIS.COM
Subject: Re: AH and ESP othogoanlity
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
> From: Naganand Doraswamy <naganand@ftp.com>
> The only problem I see with it is that there will be deployments for IPSEC
> in the very near future and most of the the implementations have implemented
> RFC's 1828 and 1829. We definitely cannot stop this as many customers have
> been asking for it.
>
I agree.
> This may cause configuration problems for old implementation (implementing
> only 1829) to interoperate with the newer implementation which may support
> both 1829 and the new transform. Can we allocated numbers to the transforms
> as most of the key management protocols do so that configuring with manual
> keying is simplified?
>
Well, I don't particularly like numbers for manual configuration, and
the RFC numbers can change as the documents are progressed along
standards track.
The way I'm doing it is by naming:
MD5E AH with MD5 "envelope"
MD5N AH with MD5 "nested"
SHA1E AH with SHA1 "envelope"
SHA1N AH with SHA1 "nested"
DES1IV32 ESP with Single DES with 32-bit IV
DES1IV64 ESP with Single DES with 64-bit IV
DES3IV32 ESP with Triple DES with 32-bit IV
DES3IV64 ESP with Triple DES with 64-bit IV
Make sense to you?
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
Received: from relay.tis.com by neptune.TIS.COM id aa19717; 12 Mar 96 15:30 EST
Received: by relay.tis.com; id PAA09804; Tue, 12 Mar 1996 15:32:11 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma009802; Tue, 12 Mar 96 15:31:43 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA15606; Tue, 12 Mar 96 15:30:42 EST
Received: by relay.tis.com; id PAA09799; Tue, 12 Mar 1996 15:31:41 -0500
Date: Tue, 12 Mar 1996 15:31:41 -0500
Received: from labs-n.bbn.com(128.89.0.100) by relay.tis.com via smap (V3.1)
id xma009797; Tue, 12 Mar 96 15:31:27 -0500
Received: from COMSEC.BBN.COM by LABS-N.BBN.COM id aa12323; 12 Mar 96 15:30 EST
X-Sender: kent@eudora.bbn.com
Message-Id: <v02130507ad6b454e8f8d@[128.89.0.110]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: William Allen Simpson <wsimpson@greendragon.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: AH and ESP Orthogonality
Cc: ipsec@TIS.COM
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Bill,
Some refinements on our dicussion:
>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.
AH applied to the whole datagram is useful and a necessary facility,
whether provided by the current form of AH or some other header. However,
the inside version of AH, applying only to upperlayer protocols, is
redundant if one defines ESP transforms that provide the same features.
That is why I would suggest that we redefine AH (or define another header)
that has one, well-defined scope.
>> 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.
I don't agree with your characterization of the tradeoffs here. One header
that permitted various combinations of security services, would be more
complex than our existing headers and an individual transform such as
single DES with 64-bit IV. However, as more transforms are added, each one
tends to duplicate significant pieces of previously defined transforms.
Moreover, when the transform includes not just one algorithm, but a
combination of algorithms (e.g., DES and MD5) and algorithm parameters, the
resulting set of documents gets pretty big in a hurry. general
interoperability requires either that everyone uses just the default
transform, or that all implementations support many transforms, many with
very small differences from one another.
It isn't clear to me that there are significant differences in supporting
various transforms (as currently defined) vs. supporting a single header
type with optional, discretely variable length fields. An implementor
still has to deal with some default subset of algorithms and combinations,
and then decide what optional ones also will be supported. I'd like to
think that the result would be better modularity in the transform
definitions, although you clearly believe that the opposite will result. I
guess those who would like to see this approach will have to try to write
the appropriate documents to see how it works out.
As for the cited message from Ran re the Photuris spec, I'm not sure I can
distinguish between criticism directed at those documents and the more
general issue of inclusion of anti-replay features in IPSEC.
Steve
Received: from relay.tis.com by neptune.TIS.COM id aa22973; 12 Mar 96 17:25 EST
Received: by relay.tis.com; id RAA11122; Tue, 12 Mar 1996 17:27:42 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma011120; Tue, 12 Mar 96 17:27:13 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA20559; Tue, 12 Mar 96 17:26:12 EST
Received: by relay.tis.com; id RAA11117; Tue, 12 Mar 1996 17:27:12 -0500
Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1)
id xma011115; Tue, 12 Mar 96 17:26:58 -0500
Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id OAA29380; Tue, 12 Mar 1996 14:28:07 -0800
Date: Tue, 12 Mar 1996 14:28:07 -0800
From: Ran Atkinson <rja@cisco.com>
Message-Id: <199603122228.OAA29380@puli.cisco.com>
To: ipsec@TIS.COM
Subject: Re: AH and ESP Orthogonality
In-Reply-To: <5053.wsimpson@greendragon.com>
Organization: cisco Systems, Inc., Menlo Park, Ca.
Cc:
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
In article <5053.wsimpson@greendragon.com> Bill Simpson wrote:
> 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.
Bill,
Not true. The chairs are opposed to a key management protocol changing
the specification of material that is outside the scope of that key
management protocol specification. Any attempt by any key management
specification to change the specifications contained in RFC-1825 thru
RFC-1827 is out of order. Key management proposals MUST conform with
RFC-1825 through RFC-1827 and MUST NOT alter those specifications.
Changes to RFC-1825 through RFC-1827 may be made only by the working
group as a whole. If such changes are to be made, they will be reflected
in the revisions of RFC-1825 through RFC-1829 (which I will prepare in I-D
form presently). If replay protection is added, then the key management
proposals can be modified to reflect that change afterwards.
Ran
rja@cisco.com
Received: from relay.tis.com by neptune.TIS.COM id aa17593; 13 Mar 96 14:44 EST
Received: by relay.tis.com; id OAA23262; Wed, 13 Mar 1996 14:46:14 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma023254; Wed, 13 Mar 96 14:45:47 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA13082; Wed, 13 Mar 96 14:44:45 EST
Received: by relay.tis.com; id OAA23244; Wed, 13 Mar 1996 14:45:44 -0500
Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1)
id xma023240; Wed, 13 Mar 96 14:45:43 -0500
Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id LAA07737; Wed, 13 Mar 1996 11:46:48 -0800
Date: Wed, 13 Mar 1996 11:46:48 -0800
From: Ran Atkinson <rja@cisco.com>
Message-Id: <199603131946.LAA07737@puli.cisco.com>
To: ipsec@TIS.COM
Subject: A comment from the co-chair
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
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
----------------------------------------------------------------------
Received: from relay.tis.com by neptune.TIS.COM id aa14066; 14 Mar 96 13:22 EST
Received: by relay.tis.com; id NAA07888; Thu, 14 Mar 1996 13:24:00 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma007886; Thu, 14 Mar 96 13:23:31 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA29794; Thu, 14 Mar 96 13:22:29 EST
Received: by relay.tis.com; id NAA07880; Thu, 14 Mar 1996 13:23:30 -0500
Received: from netcom9.netcom.com(192.100.81.119) by relay.tis.com via smap (V3.1)
id xma007877; Thu, 14 Mar 96 13:23:28 -0500
Received: by netcom9.netcom.com (8.6.13/Netcom)
id KAA14604; Thu, 14 Mar 1996 10:24:13 -0800
Date: Thu, 14 Mar 1996 10:24:13 -0800
From: John Kennedy <jkennedy@netcom.com>
Message-Id: <199603141824.KAA14604@netcom9.netcom.com>
To: cat-ietf@mit.edu, dns-security@TIS.COM, ietf-pkix@tandem.com,
ipsec@TIS.COM, spki@c2.org, www-security@nsmx.rutgers
Subject: CYLINK's Support for Open Public Key Standards
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
----------------------------------------------------------------------------
CYLINK Corporation
March 14, 1996
The following is a copy of an announcement I made in the IPSEC
and PKIX working group sessions at IETF Los Angeles. In response to
numerous requests, I am posting a copy of the announcement to the
applicable IETF working group mailing lists.
-John Kennedy, CYLINK
----------------------------------------------------------------------------
CYLINK'S SUPPORT FOR OPEN PUBLIC KEY STANDARDS
EXISTING AND PROSPECTIVE CYLINK LICENSEES OF THE STANFORD PUBLIC
KEY PATENTS MAY SUPPLEMENT THEIR LICENSES IN ACCORDANCE WITH THE
FOLLOWING STATEMENT.:
ATTACHMENT "A"
STATEMENT OF PATENT POSITION
Cylink Corporation, through its wholly owned subsidiary Caro-Kann
Corporation, holds exclusive sublicensing rights to the following
U.S. patents owned by the Leland Stanford Junior University:
Cryptographic Apparatus and Method
("Hellman-Diffie")......................... No. 4,200,770
Public Key Cryptographic Apparatus and Method
("Hellman-Merkle")............. No. 4,218,582
In order to promote the widespread use of these inventions
from Stanford University and adoption of the [Name IETF Standard]
reference by the IETF community, [Name of Licensee] has acquired
the right under its sublicense from Cylink to offer the [Name IETF
Standard] reference implementation to all third parties on a royalty free
basis.
This royalty free privilege is limited to use of the [Name IETF
Standard] reference implementation in accordance with proposed,
pending or approved IETF standards, and applies only when used with
Diffie- Hellman key exchange, the Digital Signature Standard, or any other
public key techniques which are publicly available for commercial
use on a royalty free basis. Any use of the [Name IETF Standard] reference
implementation which does not satisfy these conditions and incorporates
the practice of public key may require a separate patent license
to the Stanford Patents which must be negotiated with Cylink's
subsidiary, Caro-Kann Corporation.
For additional licensing information please contact:
Robert Fougner
Director of Licensing
CYLINK Corporation
910 Hermosa Court
Sunnyvale, CA 94086
(408) 735-5893
----------------------------------------------------------------------------
Received: from relay.tis.com by neptune.TIS.COM id aa16011; 14 Mar 96 14:10 EST
Received: by relay.tis.com; id OAA08747; Thu, 14 Mar 1996 14:12:30 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma008725; Thu, 14 Mar 96 14:12:01 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA02563; Thu, 14 Mar 96 14:10:59 EST
Received: by relay.tis.com; id OAA08722; Thu, 14 Mar 1996 14:12:00 -0500
Received: from chimay.mach.cs.cmu.edu(128.2.222.167) by relay.tis.com via smap (V3.1)
id xma008720; Thu, 14 Mar 96 14:11:59 -0500
Received: from CHIMAY.MACH.CS.CMU.EDU by CHIMAY.MACH.CS.CMU.EDU id aa19577;
14 Mar 96 14:10:48 EST
To: John Kennedy <jkennedy@netcom.com>
Cc: cat-ietf@mit.edu, dns-security@TIS.COM, ietf-pkix@tandem.com,
ipsec@TIS.COM, spki@c2.org
In-Reply-To: Your message of "Thu, 14 Mar 96 10:24:13 PST"
<199603141824.KAA14604@netcom9.netcom.com>
From: Dave Johnson <dbj@cs.cmu.edu>
Subject: Re: CYLINK's Support for Open Public Key Standards
Date: Thu, 14 Mar 96 14:10:46 EST
Message-Id: <19575.826830646@CHIMAY.MACH.CS.CMU.EDU>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
>----------------------------------------------------------------------------
>
>CYLINK Corporation
>March 14, 1996
>
>
>The following is a copy of an announcement I made in the IPSEC
>and PKIX working group sessions at IETF Los Angeles. In response to
>numerous requests, I am posting a copy of the announcement to the
>applicable IETF working group mailing lists.
>
>-John Kennedy, CYLINK
>
>
>----------------------------------------------------------------------------
>
>CYLINK'S SUPPORT FOR OPEN PUBLIC KEY STANDARDS
>
>EXISTING AND PROSPECTIVE CYLINK LICENSEES OF THE STANFORD PUBLIC
>KEY PATENTS MAY SUPPLEMENT THEIR LICENSES IN ACCORDANCE WITH THE
>FOLLOWING STATEMENT.:
>
>
>ATTACHMENT "A"
>
>
>STATEMENT OF PATENT POSITION
>
>Cylink Corporation, through its wholly owned subsidiary Caro-Kann
>Corporation, holds exclusive sublicensing rights to the following
>U.S. patents owned by the Leland Stanford Junior University:
>
> Cryptographic Apparatus and Method
> ("Hellman-Diffie")......................... No. 4,200,770
>
> Public Key Cryptographic Apparatus and Method
> ("Hellman-Merkle")............. No. 4,218,582
>
>In order to promote the widespread use of these inventions
>from Stanford University and adoption of the [Name IETF Standard]
>reference by the IETF community, [Name of Licensee] has acquired
>the right under its sublicense from Cylink to offer the [Name IETF
>Standard] reference implementation to all third parties on a royalty free
>basis.
>
>This royalty free privilege is limited to use of the [Name IETF
>Standard] reference implementation in accordance with proposed,
>pending or approved IETF standards, and applies only when used with
>Diffie- Hellman key exchange, the Digital Signature Standard, or any other
>public key techniques which are publicly available for commercial
>use on a royalty free basis. Any use of the [Name IETF Standard] reference
>implementation which does not satisfy these conditions and incorporates
>the practice of public key may require a separate patent license
>to the Stanford Patents which must be negotiated with Cylink's
>subsidiary, Caro-Kann Corporation.
>
>
>For additional licensing information please contact:
>
> Robert Fougner
> Director of Licensing
> CYLINK Corporation
> 910 Hermosa Court
> Sunnyvale, CA 94086
> (408) 735-5893
>
>----------------------------------------------------------------------------
How does this apply to a non-profit organization (such as a university)
that wants to make a "reference implementation" of an IETF protocol (that
uses Diffie-Hellman) freely available? Under the RSAREF license, I
think this was possible, but has this changed things?
Dave
--
David B. Johnson E-mail: dbj@cs.cmu.edu
Assistant Professor Home page: http://www.cs.cmu.edu/~dbj
Computer Science Department Phone: (412) 268-7399
Carnegie Mellon University Fax: (412) 268-5576
5000 Forbes Avenue
Pittsburgh, PA 15213-3891
Received: from relay.tis.com by neptune.TIS.COM id aa24936; 14 Mar 96 20:33 EST
Received: by relay.tis.com; id UAA15033; Thu, 14 Mar 1996 20:35:16 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma015031; Thu, 14 Mar 96 20:34:48 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA16651; Thu, 14 Mar 96 20:33:45 EST
Received: by relay.tis.com; id UAA15026; Thu, 14 Mar 1996 20:34:46 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma015022; Thu, 14 Mar 96 20:34:26 -0500
Received: from RSA.COM by interlock.ans.net with SMTP id AA05901
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Thu, 14 Mar 1996 20:35:30 -0500
Received: from snail.rsa.com by RSA.COM with SMTP
id AA18737; Thu, 14 Mar 96 17:26:18 PST
Received: from cc:Mail by snail.rsa.com
id AA826853770; Thu, 14 Mar 96 17:36:15 PST
Date: Thu, 14 Mar 96 17:36:15 PST
From: baldwin <baldwin@rsa.com>
Message-Id: <9602148268.AA826853770@snail.rsa.com>
To: ipsec@ans.net
Cc: bretth@newbridge.com, "Robert W. Baldwin" <baldwin@rsa.com>,
rivest@theory.lcs.mit.edu, Tim Matthews <tim@rsa.com>
Subject: ESP transform with RC5
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
IPsec members,
I have just submitted two informational RFCs to the Internet
Engineering Task Force that specify how the high performance RC5 cipher can
be used to add privacy to packets transmitted over the Internet. These two
documents were developed by RSA Data Security Inc. and TimeStep
Corporation. They are being submitted for review by the security working
groups of the IETF. They are currently available from RSA's web and FTP
sites.
The first document describes the RC5 cipher in sufficient detail to
create interoperable implementations. It is titled "The RC5, RC5-CBC,
RC5-CBC-Pad, and RC5-CTS Algorithms" by Bob Baldwin and Ronald Rivest and is
available via ftp://ftp.rsa.com/pub/rc5/draft-rsadsi-rc5-00.txt. The other
document describes how to use the RC5-CBC cipher to encrypt IP packets
following the framework defined by the IP Security Working Group of the
IETF. It is titled "The ESP RC5 Transform" and is available via:
ftp://ftp.rsa.com/pub/rc5/draft-rsadsi-esp-rc5-00.txt.
Please address comments and suggestions to baldwin@rsa.com or
to ipsec@ans.net.
--Bob Baldwin
Received: from relay.tis.com by neptune.TIS.COM id aa14999; 15 Mar 96 15:24 EST
Received: by relay.tis.com; id PAA27344; Fri, 15 Mar 1996 15:26:08 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma027316; Fri, 15 Mar 96 15:25:40 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA21746; Fri, 15 Mar 96 15:24:37 EST
Received: by relay.tis.com; id PAA27309; Fri, 15 Mar 1996 15:25:39 -0500
Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1)
id xma027303; Fri, 15 Mar 96 15:25:17 -0500
Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id MAA02882; Fri, 15 Mar 1996 12:26:23 -0800
Date: Fri, 15 Mar 1996 12:26:23 -0800
From: Ran Atkinson <rja@cisco.com>
Message-Id: <199603152026.MAA02882@puli.cisco.com>
To: ipsec@TIS.COM
Subject: Re: ESP transform with RC5
Cc:
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
In article <9602148268.AA826853770@snail.rsa.com>,
Bob Baldwin baldwin@rsa.com wrote:
> I have just submitted two informational RFCs to the Internet
>Engineering Task Force that specify how the high performance RC5 cipher can
>be used to add privacy to packets transmitted over the Internet.
FYI:
A previous conversation via email with Bob Baldwin seems to
indicate that RSADSI claims intellectual property rights on RC5 in some
countries.
Ran
rja@cisco.com
Received: from relay.tis.com by neptune.TIS.COM id aa16280; 15 Mar 96 16:23 EST
Received: by relay.tis.com; id QAA28446; Fri, 15 Mar 1996 16:25:39 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma028436; Fri, 15 Mar 96 16:25:19 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA24810; Fri, 15 Mar 96 16:24:07 EST
Received: by relay.tis.com; id QAA28431; Fri, 15 Mar 1996 16:25:09 -0500
Received: from unknown(204.189.94.148) by relay.tis.com via smap (V3.1)
id xma028412; Fri, 15 Mar 96 16:24:46 -0500
Received: by pilotx.firewall.is.chrysler.com; id QAA13799; Fri, 15 Mar 1996 16:25:43 -0500
Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1)
id sma013786; Fri, 15 Mar 96 16:25:41 -0500
Received: from [172.16.252.10] by clhubgw1.is.chrysler.com (5.x/SMI-4.1)
id AB02763; Fri, 15 Mar 1996 16:27:38 -0500
Message-Id: <2.2.32.19960315212443.009b4a90@pop3hub.is.chrysler.com>
X-Sender: t3125rm@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 15 Mar 1996 16:24:43 -0500
To: Ran Atkinson <rja@cisco.com>, ipsec@TIS.COM
From: Robert Moskowitz <rgm3@is.chrysler.com>
Subject: Re: A comment from the co-chair
Cc: jis@mit.edu
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
At 11:46 AM 3/13/96 -0800, Ran Atkinson wrote:
>
> 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.
>
Dear colleagues:
Well you all know what I mean.
I am sitting in the weekly AIAG (automotive industry action group) ANX
meeting. I have given them an update of last week's events.
Bottom line:
I have been instructed to craft an AIAG letter placing a goal of this summer
for "a" standard key management protocol. This will be the position of the
whole automotive industry, not just one OEM. This letter will go to the lot
of you and your senior management (for at least those companies that do
major business with the auto industry).
Many of you know my personal feelings. I have listened to your debates for
some time now. At times I have wanted to say, "children, children...", but
I have not as I respect each of your technical abilities. In this area, I
recognize that I am just the student. Now all of you as the 'teachers' had
better come together, quickly.
If any special meetings are needed, within limits I can be available to
attend (please avoid friday's and weekends, my family is up in arms about my
extended absences ;) ).
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from relay.tis.com by neptune.TIS.COM id aa17258; 15 Mar 96 17:08 EST
Received: by relay.tis.com; id RAA29193; Fri, 15 Mar 1996 17:10:09 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma029189; Fri, 15 Mar 96 17:09:41 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA26192; Fri, 15 Mar 96 17:08:37 EST
Received: by relay.tis.com; id RAA29184; Fri, 15 Mar 1996 17:09:39 -0500
Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1)
id xma029180; Fri, 15 Mar 96 17:09:21 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id RAA12369; Fri, 15 Mar 1996 17:10:16 -0500 (EST)
Message-Id: <199603152210.RAA12369@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: Ran Atkinson <rja@cisco.com>
Cc: ipsec@TIS.COM
Subject: Re: ESP transform with RC5
In-Reply-To: Your message of "Fri, 15 Mar 1996 12:26:23 PST."
<199603152026.MAA02882@puli.cisco.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Fri, 15 Mar 1996 17:10:10 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Ran Atkinson writes:
> In article <9602148268.AA826853770@snail.rsa.com>,
> Bob Baldwin baldwin@rsa.com wrote:
>
> > I have just submitted two informational RFCs to the Internet
> >Engineering Task Force that specify how the high performance RC5 cipher can
> >be used to add privacy to packets transmitted over the Internet.
>
> A previous conversation via email with Bob Baldwin seems to
> indicate that RSADSI claims intellectual property rights on RC5 in some
> countries.
I'm curious as to whether these are being published as drafts or not;
Baldwin lists these as "informational RFCs" rather than as "internet
drafts".
Perry
Received: from relay.tis.com by neptune.TIS.COM id aa12879; 18 Mar 96 12:08 EST
Received: by relay.tis.com; id IAA17945; Mon, 18 Mar 1996 08:50:29 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma017937; Mon, 18 Mar 96 08:50:05 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA20850; Mon, 18 Mar 96 08:48:55 EST
Received: by relay.tis.com; id IAA17934; Mon, 18 Mar 1996 08:49:58 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma017932; Mon, 18 Mar 96 08:49:54 -0500
Received: from pilotx.firewall.is.chrysler.com (copilot.is.chrysler.com) by interlock.ans.net with SMTP id AA15731
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Mon, 18 Mar 1996 08:50:55 -0500
Received: by pilotx.firewall.is.chrysler.com; id IAA03036; Mon, 18 Mar 1996 08:50:55 -0500
Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1)
id sma003002; Mon, 18 Mar 96 08:50:42 -0500
Received: from rgm3.is.chrysler.com by clhubgw1.is.chrysler.com (5.x/SMI-4.1)
id AB08276; Mon, 18 Mar 1996 08:52:40 -0500
Message-Id: <2.2.32.19960318134906.00c0b448@pop3hub.is.chrysler.com>
X-Sender: t3125rm@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 18 Mar 1996 08:49:06 -0500
To: baldwin <baldwin@rsa.com>, ipsec@ans.net
From: Robert Moskowitz <rgm3@is.chrysler.com>
Subject: Re: ESP transform with RC5
Cc: bretth@newbridge.com, "Robert W. Baldwin" <baldwin@rsa.com>,
rivest@theory.lcs.mit.edu, Tim Matthews <tim@rsa.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
At 05:36 PM 3/14/96 PST, baldwin wrote:
>IPsec members,
> I have just submitted two informational RFCs to the Internet
>Engineering Task Force that specify how the high performance RC5 cipher can
>be used to add privacy to packets transmitted over the Internet.
This is the second time in the week that I have heard 'RC5', and have not
heard it mentioned before this.
I realize that many things happen in the crypto field that I do not see
right away, but how recent is the introduction of RC5 to the broader crypto
community?
What review has it had?
I ASSUME that it is a symetrical cypher; what are typical key lengths? And
the strength of the cypher for a key length compared to other cyrphers: DES,
IDEA, RC2, RC4, etc.
Is the code in the draft sufficient for a full study? Is this thus a major
deviation to RSA's handling of cyphers (compared to RC4, say).
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from relay.tis.com by neptune.TIS.COM id aa13468; 18 Mar 96 12:43 EST
Received: by relay.tis.com; id MAA22349; Mon, 18 Mar 1996 12:45:31 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma022344; Mon, 18 Mar 96 12:45:03 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA08085; Mon, 18 Mar 96 12:43:57 EST
Received: by relay.tis.com; id MAA22341; Mon, 18 Mar 1996 12:45:01 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma022335; Mon, 18 Mar 96 12:44:50 -0500
Received: from relay.hp.com by interlock.ans.net with SMTP id AA23533
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Mon, 18 Mar 1996 12:45:36 -0500
Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP
(1.37.109.16/15.5+ECS 3.3) id AA232411081; Mon, 18 Mar 1996 09:44:42 -0800
Message-Id: <199603181744.AA232411081@relay.hp.com>
Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com
id AA146081356; Mon, 18 Mar 1996 12:49:16 -0500
X-Mailer: exmh version 1.6.2 7/18/95
To: Robert Moskowitz <rgm3@is.chrysler.com>
Cc: baldwin <baldwin@rsa.com>, ipsec@ans.net, bretth@newbridge.com,
rivest@theory.lcs.mit.edu, Tim Matthews <tim@rsa.com>
Subject: Re: ESP transform with RC5
In-Reply-To: rgm3's message of Mon, 18 Mar 1996 08:49:06 -0500.
<2.2.32.19960318134906.00c0b448@pop3hub.is.chrysler.com>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Mon, 18 Mar 1996 12:44:41 -0500
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
content-type: text/plain; charset=us-ascii
At 05:36 PM 3/14/96 PST, baldwin wrote:
>IPsec members,
> I have just submitted two informational RFCs to the Internet
>Engineering Task Force that specify how the high performance RC5 cipher can
>be used to add privacy to packets transmitted over the Internet.
This is the second time in the week that I have heard 'RC5', and have not
heard it mentioned before this.
I realize that many things happen in the crypto field that I do not see
right away, but how recent is the introduction of RC5 to the broader crypto
community?
~1995 or thereabouts. This is a *very* new cipher, so it's not
something I'd actually want to implement or use until it's had a
lot more shakeout time.
See Ron Rivest's publications web page:
http://theory.lcs.mit.edu/~rivest/publications.html
which contains:
The RC5 Encryption Algorithm by Ronald L. Rivest. (To appear in
Proceedings of the 1994 Leuven Workshop on Algorithms (Springer).)
which is a link to:
http://theory.lcs.mit.edu/~rivest/rc5.ps
The source code included in the paper is "(C) 1995 RSA Data Security
Inc.".
- Bill
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMU2hAVpj/0M1dMJ/AQEpsgP+I2pvNx2bKdJjwMwNEbCwveKFAZspXSfH
mFZ2kn8qL5+IGUoCHToA9bV69kdcfR5ThXWOHvU+YOD44xF718dkwmXli85op0r+
R0k9pCAR0DwNFJkw6drUpF0i6fv6oB20x2XCYH/XIfdaUpq/52VPqb7id0whFnH/
8dVcspd9pew=
=hYgq
-----END PGP SIGNATURE-----
Received: from relay.tis.com by neptune.TIS.COM id aa14467; 18 Mar 96 13:25 EST
Received: by relay.tis.com; id NAA23036; Mon, 18 Mar 1996 13:27:32 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma023024; Mon, 18 Mar 96 13:27:04 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA00994; Mon, 18 Mar 96 13:25:57 EST
Received: by relay.tis.com; id NAA23021; Mon, 18 Mar 1996 13:27:01 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma023010; Mon, 18 Mar 96 13:26:35 -0500
Received: from jekyll.piermont.com by interlock.ans.net with SMTP id AA24635
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Mon, 18 Mar 1996 13:27:36 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id NAA22704; Mon, 18 Mar 1996 13:26:55 -0500 (EST)
Message-Id: <199603181826.NAA22704@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: Robert Moskowitz <rgm3@is.chrysler.com>
Cc: baldwin <baldwin@rsa.com>, ipsec@ans.net
Subject: Re: ESP transform with RC5
In-Reply-To: Your message of "Mon, 18 Mar 1996 08:49:06 EST."
<2.2.32.19960318134906.00c0b448@pop3hub.is.chrysler.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Mon, 18 Mar 1996 13:26:45 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Robert Moskowitz writes:
> I realize that many things happen in the crypto field that I do not see
> right away, but how recent is the introduction of RC5 to the broader crypto
> community?
Fairly recent. RC5 is a proprietary algorithm owned by (who else) RSA
Data Security Inc.
> What review has it had?
A little; not what I'd call "strong review" the way that, say, 3DES
has had. I don't want to demean its creators, but in general one wants
to let these things be examined for quite a while before one trusts
them.
Perry
Received: from relay.tis.com by neptune.TIS.COM id aa14796; 18 Mar 96 13:36 EST
Received: by relay.tis.com; id NAA23392; Mon, 18 Mar 1996 13:38:20 -0500
From: touch@isi.edu
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma023383; Mon, 18 Mar 96 13:37:52 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA01388; Mon, 18 Mar 96 13:36:46 EST
Received: by relay.tis.com; id NAA23380; Mon, 18 Mar 1996 13:37:50 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma023368; Mon, 18 Mar 96 13:37:35 -0500
Received: from venera.isi.edu by interlock.ans.net with SMTP id AA25015
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Mon, 18 Mar 1996 13:38:32 -0500
Received: from ash-s.isi.edu (ash-a.isi.edu) by venera.isi.edu (5.65c/5.61+local-22)
id <AA03642>; Mon, 18 Mar 1996 10:37:24 -0800
Date: Mon, 18 Mar 1996 10:33:53 -0800
Posted-Date: Mon, 18 Mar 1996 10:33:53 -0800
Message-Id: <199603181833.AA04929@ash-s.isi.edu>
Received: by ash-s.isi.edu (5.65c/4.0.3-4)
id <AA04929>; Mon, 18 Mar 1996 10:33:53 -0800
To: rgm3@is.chrysler.com, sommerfeld@apollo.hp.com
Subject: Re: ESP transform with RC5
Cc: baldwin@rsa.com, ipsec@ans.net, bretth@newbridge.com,
rivest@theory.lcs.mit.edu, tim@rsa.com
X-Auto-Sig-Adder-By: faber@isi.edu
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
> From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
>
> At 05:36 PM 3/14/96 PST, baldwin wrote:
> >IPsec members,
> > I have just submitted two informational RFCs to the Internet
> >Engineering Task Force that specify how the high performance RC5 cipher can
>
> >be used to add privacy to packets transmitted over the Internet.
>
> This is the second time in the week that I have heard 'RC5', and have not
> heard it mentioned before this.
>
> I realize that many things happen in the crypto field that I do not see
> right away, but how recent is the introduction of RC5 to the broader crypto
> community?
>
> ~1995 or thereabouts. This is a *very* new cipher, so it's not
> something I'd actually want to implement or use until it's had a
> lot more shakeout time.
>
FYI - the algorithm is based on data-dependent rotates.
Not to beat a dead horse, but rotates can take anywhere
from 3-5 operations on a RISC (which typically don't
have rotates), and data-dependent rotates can double that.
Joe
----------------------------------------------------------------------
Joe Touch - touch@isi.edu http://www.isi.edu/~touch/
ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/
USC / Research Assistant Prof. http://www.isi.edu/lsam/
Received: from relay.tis.com by neptune.TIS.COM id aa15016; 18 Mar 96 13:41 EST
Received: by relay.tis.com; id NAA23526; Mon, 18 Mar 1996 13:43:50 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma023520; Mon, 18 Mar 96 13:43:23 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA01520; Mon, 18 Mar 96 13:42:17 EST
Received: by relay.tis.com; id NAA23512; Mon, 18 Mar 1996 13:43:21 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma023491; Mon, 18 Mar 96 13:42:53 -0500
Received: from jekyll.piermont.com by interlock.ans.net with SMTP id AA25267
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Mon, 18 Mar 1996 13:43:54 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id NAA22734; Mon, 18 Mar 1996 13:42:24 -0500 (EST)
Message-Id: <199603181842.NAA22734@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Cc: Robert Moskowitz <rgm3@is.chrysler.com>, ipsec@ans.net
Subject: Re: ESP transform with RC5
In-Reply-To: Your message of "Mon, 18 Mar 1996 12:44:41 EST."
<199603181744.AA232411081@relay.hp.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Mon, 18 Mar 1996 13:42:11 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Bill Sommerfeld writes:
> I realize that many things happen in the crypto field that I do
> not see right away, but how recent is the introduction of RC5 to
> the broader crypto community?
>
> ~1995 or thereabouts. This is a *very* new cipher, so it's not
> something I'd actually want to implement or use until it's had a
> lot more shakeout time.
Just for context for everyone, the RSA DSI folks are (or at least,
were) attempting to push this thing they call S/WAN, which is
basically IPsec using RC5 to make it into something proprietary that
RSA DSI has a patent on and thus gets royalties for. It doesn't have
any real advantages to anyone other than RSA DSI, which has an obvious
stake in its widespread deployment...
Perry
Received: from relay.tis.com by neptune.TIS.COM id aa15607; 18 Mar 96 14:07 EST
Received: by relay.tis.com; id OAA24003; Mon, 18 Mar 1996 14:09:51 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma023997; Mon, 18 Mar 96 14:09:22 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA02608; Mon, 18 Mar 96 14:08:16 EST
Received: by relay.tis.com; id OAA23985; Mon, 18 Mar 1996 14:09:21 -0500
Received: from unknown(192.86.155.81) by relay.tis.com via smap (V3.1)
id xma023964; Mon, 18 Mar 96 14:08:51 -0500
Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7)
id LAA11118; Mon, 18 Mar 1996 11:09:46 -0800
Received: by mailsun2.us.oracle.com (8.7.1/37.8)
id LAA03544; Mon, 18 Mar 1996 11:12:13 -0800 (PST)
Message-Id: <199603181912.LAA03544@mailsun2.us.oracle.com>
Date: 18 Mar 96 11:04:40 -0800
From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>
To: ipsec@TIS.COM
Subject: Re: ESP transform with RC5
Mime-Version: 1.0
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Bob,
>Is this thus a major deviation to RSA's handling of
>cyphers (compared to RC4, say).
Major, maybe. Different, yes:
Algorithm Intellectual Property Protection
-------------------------------------------------------
RC4 Trade Secret
RC5 Patent (applied for?)
IDEA Patent
DES Open
Does anyone have the patent numbers for RC5 and IDEA?
Paul
--------------------------------------------------------------
Paul Lambert Director of Security Products
Oracle Corporation Phone: (415) 506-0370
500 Oracle Parkway, Box 659410 Fax: (415) 413-2963
Redwood Shores, CA 94065 palamber@us.oracle.com
--------------------------------------------------------------
Received: from relay.tis.com by neptune.TIS.COM id aa15929; 18 Mar 96 14:15 EST
Received: by relay.tis.com; id OAA24258; Mon, 18 Mar 1996 14:17:51 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma024251; Mon, 18 Mar 96 14:17:25 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA03022; Mon, 18 Mar 96 14:16:17 EST
Received: by relay.tis.com; id OAA24243; Mon, 18 Mar 1996 14:17:21 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma024237; Mon, 18 Mar 96 14:17:03 -0500
Received: from pilot.firewall.is.chrysler.com (pilot.is.chrysler.com) by interlock.ans.net with SMTP id AA26499
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Mon, 18 Mar 1996 14:17:52 -0500
Received: by pilot.firewall.is.chrysler.com; id OAA08008; Mon, 18 Mar 1996 14:17:53 -0500
Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilot.is.chrysler.com via smap (g3.0.1)
id sma007990; Mon, 18 Mar 96 14:17:28 -0500
Received: from rgm3 (rgm3.is.chrysler.com) by clhubgw1.is.chrysler.com (5.x/SMI-4.1)
id AA13344; Mon, 18 Mar 1996 14:19:25 -0500
Message-Id: <2.2.32.19960318191550.00ab667c@pop3hub.is.chrysler.com>
X-Sender: t3125rm@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 18 Mar 1996 14:15:50 -0500
To: touch@isi.edu, sommerfeld@apollo.hp.com
From: Robert Moskowitz <rgm3@is.chrysler.com>
Subject: Re: ESP transform with RC5
Cc: baldwin@rsa.com, ipsec@ans.net, bretth@newbridge.com,
rivest@theory.lcs.mit.edu, tim@rsa.com
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
At 10:33 AM 3/18/96 -0800, touch@ISI.EDU wrote:
>> ~1995 or thereabouts. This is a *very* new cipher, so it's not
>> something I'd actually want to implement or use until it's had a
>> lot more shakeout time.
>>
>
>FYI - the algorithm is based on data-dependent rotates.
>Not to beat a dead horse, but rotates can take anywhere
>from 3-5 operations on a RISC (which typically don't
>have rotates), and data-dependent rotates can double that.
Joe,
Sorry for my inability to parse your words, but
Are you saying that:
A) RC5 is not high performance on a RISC
or
B) RC5 is relatively easy to brute strength attack on a RISC.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from relay.tis.com by neptune.TIS.COM id aa16676; 18 Mar 96 14:40 EST
Received: by relay.tis.com; id OAA24720; Mon, 18 Mar 1996 14:42:21 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma024718; Mon, 18 Mar 96 14:41:53 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA04384; Mon, 18 Mar 96 14:40:47 EST
Received: by relay.tis.com; id OAA24705; Mon, 18 Mar 1996 14:41:51 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma024695; Mon, 18 Mar 96 14:41:40 -0500
Received: from optima.CS.Arizona.EDU by interlock.ans.net with SMTP id AA27371
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Mon, 18 Mar 1996 14:42:42 -0500
Received: from uncial.CS.Arizona.EDU by optima.cs.arizona.edu (5.65c/15) via SMTP
id AA15064; Mon, 18 Mar 1996 12:42:38 MST
Received: by uncial.CS.Arizona.EDU; (5.65/1.1.8.2/08Nov94-0446PM)
id AA12798; Mon, 18 Mar 1996 12:42:34 -0700
Date: Mon, 18 Mar 1996 12:42:34 -0700
From: Hilarie Orman <ho@cs.arizona.edu>
Message-Id: <9603181942.AA12798@uncial.CS.Arizona.EDU>
To: rgm3@is.chrysler.com
Cc: ipsec@ans.net
In-Reply-To: Yourmessage <2.2.32.19960318134906.00c0b448@pop3hub.is.chrysler.com>
Subject: Re: ESP transform with RC5
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
> I realize that many things happen in the crypto field that I do not see
> right away, but how recent is the introduction of RC5 to the broader crypto
> community?
Was being distributed on the net in 1994; published Dr. Dobb's
Journal, January 1995
> What review has it had?
See Crypto '95 proceedings; Kaliski has a paper about it.
> Is the code in the draft sufficient for a full study?
Yes, it's a very short algorithm, full source code is available, and
it's probably easier to understand it by reading the code than a
description of it.
Received: from relay.tis.com by neptune.TIS.COM id aa17065; 18 Mar 96 14:55 EST
Received: by relay.tis.com; id OAA25060; Mon, 18 Mar 1996 14:57:51 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma025053; Mon, 18 Mar 96 14:57:26 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA05382; Mon, 18 Mar 96 14:56:16 EST
Received: by relay.tis.com; id OAA25046; Mon, 18 Mar 1996 14:57:21 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma025022; Mon, 18 Mar 96 14:56:51 -0500
Received: from internet.milkyway.com (milkyway.com) by interlock.ans.net with SMTP id AA27842
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Mon, 18 Mar 1996 14:57:41 -0500
Received: from jupiter.milkyway.com (jupiter.milkyway.com [192.168.77.9])
by internet with ESMTP (DuhMail/2.0)
id OAA08761; Mon, 18 Mar 1996 14:51:15 -0500
Received: from milkyway.com (root@metis.milkyway.com [192.168.77.21]) by jupiter.milkyway.com (8.6.12/8.6.12) with ESMTP id OAA13040 for <ipsec@ans.net>; Mon, 18 Mar 1996 14:51:47 -0500
Received: from metis.milkyway.com by milkyway.com (8.6.12/BSDI-Client)
id PAA03185; Mon, 18 Mar 1996 15:01:52 -0500
Message-Id: <199603182001.PAA03185@milkyway.com>
X-Mailer: exmh version 1.6.4 10/10/95
X-Face: x7OynEM*dB$e.2'7pigelLk>5:Nu:%r*iV96{F2XIT.apbrc-vOFSi{yI$3=nJ-Qi)allj4
=)4cWlX@IQ1Dsmk}T4qX~{XI5Z01>PV^cYR'~cL]&ma<{rYg~Ao-:~:sM%z}^M65`;1TZ}Tze"4/=F
~o&8;"SKHwB?%"xpP/=pkhdZVP$rQQ{"{QT`#kcx7!\/y+crQa4^nLEms6_k4O*o#fo[WBs~~&.%jf
|;W@E2K#{U~%vhvth^uDLWD`<OLQ;48T].laq_}3abY7nO5
X-Uri: http://www.milkyway.com/People/Michael_Richardson/Bio.html
To: ipsec@ans.net
Subject: Re: ESP transform with RC5
References: <199603181842.NAA22734@jekyll.piermont.com>
In-Reply-To: Your message of "Mon, 18 Mar 1996 13:42:11 EST."
<199603181842.NAA22734@jekyll.piermont.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 18 Mar 1996 15:01:51 -0500
From: Michael Richardson <mcr@milkyway.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
In a galaxy far, far away, perry@piermont.com said:
> Just for context for everyone, the RSA DSI folks are (or at least,
> were) attempting to push this thing they call S/WAN, which is
> basically IPsec using RC5 to make it into something proprietary that
> RSA DSI has a patent on and thus gets royalties for. It doesn't have
> any real advantages to anyone other than RSA DSI, which has an obvious
For a little more context: the RSA folks got most of the firewall vendors
together last August to discuss RSA DSI and firewalls. We had a problem: we
needed to interoperate on virtual private network technology, particularly
when it came to road-warrior notebooks. We agreed that swipe and SKIP were
interesting, but that the firewall vendors had to implement something that
the PC/Mac stack vendors were going to implement.
Thus S/WAN was born. Just take the then current ipsec, nail some parameters
down, and take the first step.
The various vendors didn't really have anyone that they felt could coordinate
their efforts. While RSA Data Systems isn't a dis-interested party, at least
they are non-firewall-vendor aligned: we know what their interests are.
--
mcr@milkyway.com | <A HREF="http://www.milkyway.com/";>Milkyway
Networks Corporation</A>
Michael C. Richardson | Makers of the Black Hole firewall
Senior Research Specialist | info@milkyway.com for BlackHole questions
Home: <A HREF="http://www.sandelman.ocunix.on.ca/People/Michael_Richardson/Bio
.html">mcr@sandelman.ocunix.on.ca</A>.
Received: from relay.tis.com by neptune.TIS.COM id aa18899; 18 Mar 96 16:06 EST
Received: by relay.tis.com; id QAA27088; Mon, 18 Mar 1996 16:08:51 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma027075; Mon, 18 Mar 96 16:08:23 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA09576; Mon, 18 Mar 96 16:07:17 EST
Received: by relay.tis.com; id QAA27067; Mon, 18 Mar 1996 16:08:22 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma027061; Mon, 18 Mar 96 16:07:54 -0500
Received: from jekyll.piermont.com by interlock.ans.net with SMTP id AA00304
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Mon, 18 Mar 1996 16:08:50 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id QAA22956; Mon, 18 Mar 1996 16:08:29 -0500 (EST)
Message-Id: <199603182108.QAA22956@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: Michael Richardson <mcr@milkyway.com>
Cc: ipsec@ans.net
Subject: Re: ESP transform with RC5
In-Reply-To: Your message of "Mon, 18 Mar 1996 15:01:51 EST."
<199603182001.PAA03185@milkyway.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Mon, 18 Mar 1996 16:08:28 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Michael Richardson writes:
> For a little more context: the RSA folks got most of the firewall vendors
> together last August to discuss RSA DSI and firewalls. We had a problem: we
> needed to interoperate on virtual private network technology, particularly
> when it came to road-warrior notebooks. We agreed that swipe and SKIP were
> interesting, but that the firewall vendors had to implement something that
> the PC/Mac stack vendors were going to implement.
Er, there is perhaps a misperception here.
swIPe was a long dead experiment. SKIP is a key management protocol,
which fits in the same place in the stack as Photuris or Oakley.
We already had perfectly good IPsec transforms written and in place,
by the way.
> Thus S/WAN was born. Just take the then current ipsec, nail some parameters
> down, and take the first step.
The only difference I can see between IPsec and S/WAN is that S/WAN
uses RC5 instead of something like 3DES. Can you correct me on this?
> The various vendors didn't really have anyone that they felt could
> coordinate their efforts.
The IETF, perhaps?
Perry
Received: from relay.tis.com by neptune.TIS.COM id aa19293; 18 Mar 96 16:25 EST
Received: by relay.tis.com; id QAA27568; Mon, 18 Mar 1996 16:27:22 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma027532; Mon, 18 Mar 96 16:26:53 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA10749; Mon, 18 Mar 96 16:25:47 EST
Received: by relay.tis.com; id QAA27528; Mon, 18 Mar 1996 16:26:51 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma027522; Mon, 18 Mar 96 16:26:44 -0500
Received: from internet.milkyway.com (milkyway.com) by interlock.ans.net with SMTP id AA00833
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Mon, 18 Mar 1996 16:27:39 -0500
Received: from jupiter.milkyway.com (jupiter.milkyway.com [192.168.77.9])
by internet with ESMTP (DuhMail/2.0)
id QAA09636; Mon, 18 Mar 1996 16:21:17 -0500
Received: from milkyway.com (root@metis.milkyway.com [192.168.77.21]) by jupiter.milkyway.com (8.6.12/8.6.12) with ESMTP id QAA15963; Mon, 18 Mar 1996 16:22:47 -0500
Received: from metis.milkyway.com by milkyway.com (8.6.12/BSDI-Client)
id QAA06003; Mon, 18 Mar 1996 16:32:53 -0500
Message-Id: <199603182132.QAA06003@milkyway.com>
X-Mailer: exmh version 1.6.4 10/10/95
X-Face: x7OynEM*dB$e.2'7pigelLk>5:Nu:%r*iV96{F2XIT.apbrc-vOFSi{yI$3=nJ-Qi)allj4
=)4cWlX@IQ1Dsmk}T4qX~{XI5Z01>PV^cYR'~cL]&ma<{rYg~Ao-:~:sM%z}^M65`;1TZ}Tze"4/=F
~o&8;"SKHwB?%"xpP/=pkhdZVP$rQQ{"{QT`#kcx7!\/y+crQa4^nLEms6_k4O*o#fo[WBs~~&.%jf
|;W@E2K#{U~%vhvth^uDLWD`<OLQ;48T].laq_}3abY7nO5
X-Uri: http://www.milkyway.com/People/Michael_Richardson/Bio.html
To: ipsec@ans.net, perry@piermont.com
Subject: Re: ESP transform with RC5
References: <199603182108.QAA22956@jekyll.piermont.com>
In-Reply-To: Your message of "Mon, 18 Mar 1996 16:08:28 EST."
<199603182108.QAA22956@jekyll.piermont.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 18 Mar 1996 16:32:51 -0500
From: Michael Richardson <mcr@milkyway.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
In a galaxy far, far away, : Mon, 18 Mar 1996 16:08:28 EST
> swIPe was a long dead experiment. SKIP is a key management protocol,
> which fits in the same place in the stack as Photuris or Oakley.
This was August 1995. Vendors wanted to interoperate *soon*
swIPe was on the list because it was out there.
SKIP as implemented by SunScreen (not IPsec based) was also out there.
Neither had any likelyhood of being found on a 4Mb 486/33 running Win3.11.
> We already had perfectly good IPsec transforms written and in place,
> by the way.
Yes. Which is why the other "options" were quickly discarded.
> The only difference I can see between IPsec and S/WAN is that S/WAN
> uses RC5 instead of something like 3DES. Can you correct me on this?
The original "spec" said MD5 and DES. RSA quickly added RC5. Whether or
not anyone actually tested that I don't remember.
> The IETF, perhaps?
:-)
That was my suggestion actually. In the end, we (Milkyway Networks) didn't
have the scheduling flexibility to come up with anything to test. Our current
VPN is Entrust based.
--
mcr@milkyway.com | <A HREF="http://www.milkyway.com/";>Milkyway Networks Corporation</A>
Michael C. Richardson | Makers of the Black Hole firewall
Senior Research Specialist | info@milkyway.com for BlackHole questions
Home: <A HREF="http://www.sandelman.ocunix.on.ca/People/Michael_Richardson/Bio.html";>mcr@sandelman.ocunix.on.ca</A>.
Received: from relay.tis.com by neptune.TIS.COM id aa19603; 18 Mar 96 16:34 EST
Received: by relay.tis.com; id QAA27858; Mon, 18 Mar 1996 16:36:23 -0500
From: stroh@vnet.ibm.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma027841; Mon, 18 Mar 96 16:35:55 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA11272; Mon, 18 Mar 96 16:34:49 EST
Received: by relay.tis.com; id QAA27834; Mon, 18 Mar 1996 16:35:53 -0500
Received: from unknown(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma027828; Mon, 18 Mar 96 16:35:51 -0500
Received: from vnet.ibm.com by interlock.ans.net with SMTP id AA01123
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Mon, 18 Mar 1996 16:36:50 -0500
Message-Id: <199603182136.AA01123@interlock.ans.net>
Received: from AUSVM6.VNET.IBM.COM by vnet.IBM.COM (IBM VM SMTP V2R3)
with BSMTP id 8525; Mon, 18 Mar 96 16:36:29 EST
Date: Mon, 18 Mar 96 16:36:29 EST
To: ipsec@ans.net
Subject: Re: ESP transform with RC5
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
*** Reply to note of 03/18/96 14:06
>From the desk of:
IBM Internal Use Only
SUBJECT: Re: ESP transform with RC5
Re: absence of rotate on RISC processors
Do you mean that an encryption algorithm must not be chosen which
uses rotates because RISC processors don't have them, and everyone
knows it?
(dead horse - argued to death, well decided )
This is not well decided. Its invalid. The RS6000 / PowerPC has
single instruction variable count rotates which work in a single cycle.
This cycle is likely to be overlapped with something else like I/O
and disappear.
Even other superscalar RISC processors which do not could still
parallelize the sub-operations to some extent and overlap them
with I/O.
The pentium and 486 have rotate instructions but they are many
cycle instructions. Presumably they don't use a barrel shifter.
regards,
Oscar Strohacker
Advisory Engineer/Scientist
Data Compression Systems Architecture
IBM Microelectronics Division
11400 Burnet Road
Austin Texas 78758
o (512) 838-4077 f (512) 838-7004 Internet: stroh @ vnet.ibm.com
Received: from relay.tis.com by neptune.TIS.COM id aa19772; 18 Mar 96 16:41 EST
Received: by relay.tis.com; id QAA28126; Mon, 18 Mar 1996 16:43:53 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma028109; Mon, 18 Mar 96 16:43:24 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA11753; Mon, 18 Mar 96 16:42:19 EST
Received: by relay.tis.com; id QAA28106; Mon, 18 Mar 1996 16:43:23 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma028101; Mon, 18 Mar 96 16:43:15 -0500
Received: from jekyll.piermont.com by interlock.ans.net with SMTP id AA01298
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Mon, 18 Mar 1996 16:44:17 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id QAA23018; Mon, 18 Mar 1996 16:44:05 -0500 (EST)
Message-Id: <199603182144.QAA23018@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: Michael Richardson <mcr@milkyway.com>
Cc: ipsec@ans.net
Subject: Re: ESP transform with RC5
In-Reply-To: Your message of "Mon, 18 Mar 1996 16:32:51 EST."
<199603182132.QAA06003@milkyway.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Mon, 18 Mar 1996 16:44:04 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
I want to make it clear in advance that I'm not trying to be hostile
here. E-Mail often removes niceties like facial expression. I'm more
trying to figure out what was going on at RSA DSI than anything else.
Michael Richardson writes:
> In a galaxy far, far away, : Mon, 18 Mar 1996 16:08:28 EST
> > swIPe was a long dead experiment. SKIP is a key management protocol,
> > which fits in the same place in the stack as Photuris or Oakley.
>
> This was August 1995. Vendors wanted to interoperate *soon*
August 1995 was after the IPsec documents had gone to RFC (indeed, the
documents are dated August, 1995). They had long since been in last
call and were very stable. You have apparently been misinformed about
the timing of our efforts.
> swIPe was on the list because it was out there.
Actually it wasn't out there any longer; it had more or less been
informally withdrawn long before, after the Toronto IETF as I
recall. It was just an experiment.
> SKIP as implemented by SunScreen (not IPsec based) was also out there.
Actually SKIP *is* IPsec based (though I've had interoperation
disputes with the SKIP people).
> > We already had perfectly good IPsec transforms written and in place,
> > by the way.
>
> Yes. Which is why the other "options" were quickly discarded.
>
> > The only difference I can see between IPsec and S/WAN is that S/WAN
> > uses RC5 instead of something like 3DES. Can you correct me on this?
>
> The original "spec" said MD5 and DES. RSA quickly added RC5.
Why did they have a "spec" at all when we had RFC's 1825-1829 already
out? This all strikes me as odd.
Perry
Received: from relay.tis.com by neptune.TIS.COM id aa20142; 18 Mar 96 16:59 EST
Received: by relay.tis.com; id RAA28598; Mon, 18 Mar 1996 17:01:23 -0500
From: touch@isi.edu
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma028596; Mon, 18 Mar 96 17:00:54 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA12850; Mon, 18 Mar 96 16:59:48 EST
Received: by relay.tis.com; id RAA28593; Mon, 18 Mar 1996 17:00:53 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma028591; Mon, 18 Mar 96 17:00:27 -0500
Received: from venera.isi.edu by interlock.ans.net with SMTP id AA01869
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Mon, 18 Mar 1996 17:01:28 -0500
Received: from ash-s.isi.edu (ash-a.isi.edu) by venera.isi.edu (5.65c/5.61+local-22)
id <AA17000>; Mon, 18 Mar 1996 13:56:08 -0800
Date: Mon, 18 Mar 1996 13:52:33 -0800
Posted-Date: Mon, 18 Mar 1996 13:52:33 -0800
Message-Id: <199603182152.AA05148@ash-s.isi.edu>
Received: by ash-s.isi.edu (5.65c/4.0.3-4)
id <AA05148>; Mon, 18 Mar 1996 13:52:33 -0800
To: touch@isi.edu, sommerfeld@apollo.hp.com, rgm3@is.chrysler.com
Subject: Re: ESP transform with RC5
Cc: baldwin@rsa.com, ipsec@ans.net, bretth@newbridge.com,
rivest@theory.lcs.mit.edu, tim@rsa.com
X-Auto-Sig-Adder-By: faber@isi.edu
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
> From: Robert Moskowitz <rgm3@is.chrysler.com>
> Subject: Re: ESP transform with RC5
>
> At 10:33 AM 3/18/96 -0800, touch@ISI.EDU wrote:
>
> >> ~1995 or thereabouts. This is a *very* new cipher, so it's not
> >> something I'd actually want to implement or use until it's had a
> >> lot more shakeout time.
> >>
> >
> >FYI - the algorithm is based on data-dependent rotates.
> >Not to beat a dead horse, but rotates can take anywhere
> >from 3-5 operations on a RISC (which typically don't
> >have rotates), and data-dependent rotates can double that.
>
> Joe,
>
> Sorry for my inability to parse your words, but
>
> Are you saying that:
>
> A) RC5 is not high performance on a RISC
This.
I suspect it is just "not high performance", period.
Joe
----------------------------------------------------------------------
Joe Touch - touch@isi.edu http://www.isi.edu/~touch/
ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/
USC / Research Assistant Prof. http://www.isi.edu/lsam/
Received: from relay.tis.com by neptune.TIS.COM id aa20528; 18 Mar 96 17:13 EST
Received: by relay.tis.com; id RAA28888; Mon, 18 Mar 1996 17:15:23 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma028874; Mon, 18 Mar 96 17:14:55 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA13573; Mon, 18 Mar 96 17:13:49 EST
Received: by relay.tis.com; id RAA28868; Mon, 18 Mar 1996 17:14:53 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma028864; Mon, 18 Mar 96 17:14:40 -0500
Received: from internet.milkyway.com (milkyway.com) by interlock.ans.net with SMTP id AA02281
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Mon, 18 Mar 1996 17:15:39 -0500
Received: from jupiter.milkyway.com (jupiter.milkyway.com [192.168.77.9])
by internet with ESMTP (DuhMail/2.0)
id RAA10228; Mon, 18 Mar 1996 17:10:44 -0500
Received: from milkyway.com (root@metis.milkyway.com [192.168.77.21]) by jupiter.milkyway.com (8.6.12/8.6.12) with ESMTP id RAA17292 for <ipsec@ans.net>; Mon, 18 Mar 1996 17:12:30 -0500
Received: from metis.milkyway.com by milkyway.com (8.6.12/BSDI-Client)
id RAA10425; Mon, 18 Mar 1996 17:22:37 -0500
Message-Id: <199603182222.RAA10425@milkyway.com>
X-Mailer: exmh version 1.6.4 10/10/95
X-Face: x7OynEM*dB$e.2'7pigelLk>5:Nu:%r*iV96{F2XIT.apbrc-vOFSi{yI$3=nJ-Qi)allj4
=)4cWlX@IQ1Dsmk}T4qX~{XI5Z01>PV^cYR'~cL]&ma<{rYg~Ao-:~:sM%z}^M65`;1TZ}Tze"4/=F
~o&8;"SKHwB?%"xpP/=pkhdZVP$rQQ{"{QT`#kcx7!\/y+crQa4^nLEms6_k4O*o#fo[WBs~~&.%jf
|;W@E2K#{U~%vhvth^uDLWD`<OLQ;48T].laq_}3abY7nO5
X-Uri: http://www.milkyway.com/People/Michael_Richardson/Bio.html
To: ipsec@ans.net
Subject: Re: ESP transform with RC5
References: <199603182144.QAA23018@jekyll.piermont.com>
In-Reply-To: Your message of "Mon, 18 Mar 1996 16:44:04 EST."
<199603182144.QAA23018@jekyll.piermont.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 18 Mar 1996 17:22:36 -0500
From: Michael Richardson <mcr@milkyway.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
In a galaxy far, far away, : Mon, 18 Mar 1996 16:44:04 EST
> > This was August 1995. Vendors wanted to interoperate *soon*
>
> August 1995 was after the IPsec documents had gone to RFC (indeed, the
> documents are dated August, 1995). They had long since been in last
Again, I'm reporting what was discussed. I don't think the timing of the
RFCs has much to do with what has been implemented and what has not been
implemented.
Why was swIPe on the table? I believe that TIS and Raptor have firewalls
out their in the field running it.
Why was SKIP on the table (and yes, there *is* a pre-IPsec version)? Sun
was there talking about it. They *said* there were two versions that that
the IPsec version was being worked on as they spoke.
> Actually it wasn't out there any longer; it had more or less been
> informally withdrawn long before, after the Toronto IETF as I
> recall. It was just an experiment.
S/WAN is *not* a proposed IETF standard. It is a set of parameters that
explains how to interoperate *today*. We could have picked swIPe, for instance.
> Why did they have a "spec" at all when we had RFC's 1825-1829 already
> out? This all strikes me as odd.
The 'spec' is says what S/WAN is going to test. I'd call it a "test spec"
more than a design spec.
I don't recall discussion about RC4 or RC5 from other than RSA people. But,
again, we were pretty clear about what there interests were.
Received: from relay.tis.com by neptune.TIS.COM id aa21034; 18 Mar 96 17:33 EST
Received: by relay.tis.com; id RAA29336; Mon, 18 Mar 1996 17:35:53 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma029334; Mon, 18 Mar 96 17:35:25 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA14701; Mon, 18 Mar 96 17:34:19 EST
Received: by relay.tis.com; id RAA29331; Mon, 18 Mar 1996 17:35:23 -0500
Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1)
id xma029329; Mon, 18 Mar 96 17:35:12 -0500
Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7)
id OAA07192; Mon, 18 Mar 1996 14:36:12 -0800
Received: by mailsun2.us.oracle.com (8.7.1/37.8)
id OAA02871; Mon, 18 Mar 1996 14:38:34 -0800 (PST)
Message-Id: <199603182238.OAA02871@mailsun2.us.oracle.com>
Date: 18 Mar 96 14:22:48 -0800
From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>
To: perry@piermont.com
Subject: Re: ESP transform with RC5
Cc: ipsec@TIS.COM
X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:perry@piermont.com's message of 18-Mar-96 15:12
Mime-Version: 1.0
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Perry,
Please be fair.
>No fee for the use of the patent in free software, <IDEA..>
>for example, and they don't attempt to assert
>rights when they have none. RSA hasn't shown the
>same sort of behavior.
RSA to their credit has published RSAREF for free non-commercial usage.
The IETF process must support the definition of technologies that can be
produced by vendors for a profit. Selecting technologies that have no fee for
free software limits the creation of "commercial" software.
While we all may not like to pay for patented technologies, this mailing list
is not an appropriate forum to attack companies attempting to make money on
their inventions. Where we can in the standards process we should avoid
patented technologies. Where patents are unavoidable or provide significant
advantages the working group they are acceptable only when available with a
"reasonable" and non-exclusive license.
Paul
--------------------------------------------------------------
Paul Lambert Director of Security Products
Oracle Corporation Phone: (415) 506-0370
500 Oracle Parkway, Box 659410 Fax: (415) 413-2963
Redwood Shores, CA 94065 palamber@us.oracle.com
--------------------------------------------------------------
Received: from relay.tis.com by neptune.TIS.COM id aa21141; 18 Mar 96 17:38 EST
Received: by relay.tis.com; id RAA29438; Mon, 18 Mar 1996 17:40:24 -0500
From: touch@isi.edu
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma029431; Mon, 18 Mar 96 17:39:56 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA14853; Mon, 18 Mar 96 17:38:50 EST
Received: by relay.tis.com; id RAA29418; Mon, 18 Mar 1996 17:39:54 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma029408; Mon, 18 Mar 96 17:39:31 -0500
Received: from venera.isi.edu by interlock.ans.net with SMTP id AA03062
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Mon, 18 Mar 1996 17:40:32 -0500
Received: from ash-s.isi.edu (ash-a.isi.edu) by venera.isi.edu (5.65c/5.61+local-22)
id <AA20462>; Mon, 18 Mar 1996 14:40:29 -0800
Date: Mon, 18 Mar 1996 14:36:58 -0800
Posted-Date: Mon, 18 Mar 1996 14:36:58 -0800
Message-Id: <199603182236.AA05238@ash-s.isi.edu>
Received: by ash-s.isi.edu (5.65c/4.0.3-4)
id <AA05238>; Mon, 18 Mar 1996 14:36:58 -0800
To: ipsec@ans.net, stroh@vnet.ibm.com
Subject: Re: ESP transform with RC5
Cc: touch@isi.edu
X-Auto-Sig-Adder-By: faber@isi.edu
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
> From: stroh@vnet.ibm.com
> Re: absence of rotate on RISC processors
> Do you mean that an encryption algorithm must not be chosen which
> uses rotates because RISC processors don't have them, and everyone > knows it?
> (dead horse - argued to death, well decided )
No. Only that variable-count rotates are not one-cycle opcodes
on many processors, and that their use can substantially affect
performance of the algorithm.
> This is not well decided. Its invalid. The RS6000 / PowerPC has
> single instruction variable count rotates which work in a single cycle.
SPARC and MIPS don't. Alphas do, but only for 32-bit operands
(by doubling the data and shifting it within 64-bit registers).
> Even other superscalar RISC processors which do not could still
> parallelize the sub-operations to some extent and overlap them
> with I/O.
Only if the computation is I/O intensive. Authentication and
encryption algorithms tend to be compute-intensive, and the
one's I've had a chance to look at are also highly linear.
The result is that the computations don't overlap at all, and that
the number of clocks per basic operation affects the overall
algorithm performance.
The Sigcomm paper on MD5 ('95) indicated ways to design algorithms
which could be computationally efficient, both in hardware and
in software. Data-dependent rotates are not one of those ways.
Joe
>
> The pentium and 486 have rotate instructions but they are many
> cycle instructions. Presumably they don't use a barrel shifter.
----------------------------------------------------------------------
Joe Touch - touch@isi.edu http://www.isi.edu/~touch/
ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/
USC / Research Assistant Prof. http://www.isi.edu/lsam/
Received: from relay.tis.com by neptune.TIS.COM id aa22581; 18 Mar 96 18:47 EST
Received: by relay.tis.com; id SAA00199; Mon, 18 Mar 1996 18:49:24 -0500
From: smb@research.att.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma000192; Mon, 18 Mar 96 18:48:54 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA16420; Mon, 18 Mar 96 18:47:49 EST
Received: by relay.tis.com; id SAA00189; Mon, 18 Mar 1996 18:48:53 -0500
Message-Id: <199603182348.SAA00189@relay.tis.com>
Received: from unknown(192.20.225.4) by relay.tis.com via smap (V3.1)
id xma000185; Mon, 18 Mar 96 18:48:29 -0500
Received: from research.att.com by ns; Mon Mar 18 18:46:59 EST 1996
Received: from gryphon by research; Mon Mar 18 18:42:30 EST 1996
Received: by gryphon; Mon Mar 18 18:42:24 EST 1996
To: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>
Cc: perry@piermont.com, ipsec@TIS.COM
Subject: Re: ESP transform with RC5
Date: Mon, 18 Mar 96 18:42:23 EST
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
The IETF process must support the definition of technologies that
can e produced by vendors for a profit.
Since this is an informational RFC in any event, it doesn't matter
much. RFC 1602 puts certain restrictions on standards-track RFCs;
it says nothing whatsoever about patents and non-standards documents.
It's also worth noting that RC5 poses some interesting technical issues.
For example, it is parameterized, and none of the key management mechanisms
we are considering seem to support that. Possibly, the parameters could
be encoded as part of the key -- but we're moving down a track in which
keys are true-random numbers. Besides, it may be necessary to negotiate
some of the parameters under certain circumstances -- some folks may only
have 40-bit RC5 implementations available to them, for the usual obvious
reasons.
Received: from relay.tis.com by neptune.TIS.COM id aa24431; 18 Mar 96 20:26 EST
Received: by relay.tis.com; id UAA00926; Mon, 18 Mar 1996 20:28:26 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma000924; Mon, 18 Mar 96 20:27:57 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA18470; Mon, 18 Mar 96 20:26:51 EST
Received: by relay.tis.com; id UAA00919; Mon, 18 Mar 1996 20:27:56 -0500
Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1)
id xma000915; Mon, 18 Mar 96 20:27:34 -0500
Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7)
id RAA23395; Mon, 18 Mar 1996 17:28:32 -0800
Received: by mailsun2.us.oracle.com (8.7.1/37.8)
id RAA25111; Mon, 18 Mar 1996 17:31:00 -0800 (PST)
Message-Id: <199603190131.RAA25111@mailsun2.us.oracle.com>
Date: 18 Mar 96 17:05:58 -0800
From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>
To: ipsec@TIS.COM
Subject: Re: ESP transform with RC5
X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.tis.com's message of 18-Mar-96 17:22
Mime-Version: 1.0
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
>From: Michael Richardson
<....
> Again, I'm reporting what was discussed.
<... stuff removed
> Why was swIPe on the table?
< ... etc. ..
I am not sure where the discussion is going in trying to examine the history
of IP layer security mechanisms and proposals. The technology represents many
years of research and our Internet focus is often myopic in viewing only the
free software or mailing list posted efforts.
The original ARPA work was started in the late 70's. Public specifications
were available for SP3 in 1988 for IP security complete with a key management
protocol (KMP). NLSP circa 1991 is an international specification (derived
from SP3) with many implementations in Europe. Commercial implementations
based on SP3 and NLSP started to appear in 1992. swIPe was one of the first
free implementations posted and so was adopted quickly by some vendors.
Significant "commercial" vendor interest did not appear until last year with
many Firewall and router vendors backing the use of IP layer security.
To my knowledge, all of the S/WAN testing has been directed at the "baseline"
definitions of AH and ESP. These are DES and MD5 based encapsulations.
Additional algorithms, like RC5, have been added by vendors for "extra credit"
(aka perception of market benefits).
ESP with RC5 will be an Informational RFCs. ESP-RC5 will not be a "baseline"
mechanism since the consensus of the group for a long time has been to use DES
as the "mandatory" algorithm for confidentiality.
Paul
Received: from relay.tis.com by neptune.TIS.COM id aa27676; 19 Mar 96 0:05 EST
Received: by relay.tis.com; id AAA02964; Tue, 19 Mar 1996 00:07:58 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma002962; Tue, 19 Mar 96 00:07:30 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA21543; Tue, 19 Mar 96 00:06:23 EST
Received: by relay.tis.com; id AAA02956; Tue, 19 Mar 1996 00:07:28 -0500
Received: from big-screw.mit.edu(18.72.0.176) by relay.tis.com via smap (V3.1)
id xma002953; Tue, 19 Mar 96 00:07:25 -0500
Received: by big-screw
id AA04102; Tue, 19 Mar 96 00:07:56 -0500
X-Sender: jis@e40-po.mit.edu (Unverified)
Message-Id: <ad73f0a7000210047469@[18.162.1.1]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 19 Mar 1996 00:08:20 -0500
To: William Allen Simpson <wsimpson@greendragon.com>
From: "Jeffrey I. Schiller" <jis@mit.edu>
Subject: Your Appeal to me regarding replacing IPSEC WG Chair(s)
Cc: ipsec@TIS.COM, iesg@ietf.cnri.reston.va.us
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
Monday, March 18, 1996
Bill:
I have considered your request to remove the chairs of the
IPSEC Working Group. I have taken this matter seriously and have
consulted with many people about what they believe is happening in the
Working Group. I have also been attending most of the face to face
meetings myself and read the mailing list, so I have my own
observations as well.
My Findings:
o Chairing the IPSEC Working Group is a difficult job. There are
competing proposals, differing views of the requirements (mostly in
terms of how important various requirements are), and investment made
by proposal submitters.
o You have in the past made significant technical contributions to the
IPsec standards. Your technical abilities are considerable when you
choose to use them and you are always an active participant.
o Your behavior in the working group has been less than professional.
You tend to dominate any discussion that interests you. You do not
respect the prerogative of the chair(s) to facilitate the working
group.
o Your behavior causes many people to become intimidated and unwilling
to contribute their ideas when you are present. You tend to dominate
any discussion that interests you so that other people's useful
technical inputs are drowned out or otherwise impeded.
Other:
I have also had people report to me that you have threatened
them with lawsuits and otherwise used intimidation tactics when other
avenues of argument were not available to you. Furthermore I interpret
your message to the Working Group on 3/14/96 as an attempt to
intimidate the chairs and Working Group by making your appeal to me
public and threatening to continue to appeal until some body finds in
your favor.
Remember the motto: "Rough consensus and running code." Rough
consensus does not mean a consensus that Bill Simpson will always
agree with. By threatening appeals, lawsuits and by just plain
shouting people down, you are not participating in a consensus
process. You are in violation of the Spirit of the IETF process, in my
opinion.
Therefore I Conclude:
I can find no reason to believe that the Working Group Chairs
should be removed on the basis of your appeal. In fact I have
discovered that the Working Group chairs have often gone out of their
way to ensure that they were as fair as possible to you and your
proposals.
Furthermore I agree with the Working Group chairs that your
behavior has been unacceptable. I interpret Paul's use of the word
"fire" to convey to the Working Group members that you have no special
status in the working group and members do not have to pay any
particular attention to you.
I would go so far as to add that as long as your behavior
continues to be unacceptable, members of the working group should feel
free to ignore you, consensus can well be reached without you.
I am sorry that it had to come to this. I believe that you
have a strong technical background and good insights. However your
talent is wasted if you cannot work and communicate in a civilized
manner.
At this point you have two choices. You can either appeal my
decision to the IESG if you so choose or you can alter your behavior
and become a contributing productive member of the IPSEC working group
and the IETF as a whole. The choice is yours.
-Jeff Schiller
Area Director for Security
Internet Engineering Steering Group
Internet Engineering Task Force
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMU4/88UtR20Nv5BtAQGsDQP/YeWGDQLcNnNGSQRyaxGei2yf6XA5pBGz
up7asMKORhbYtM+cQTvF07RbCKslZc9pcUwH9E4i0O4CnY4m3OFx9uvI4rKwcIP1
Csb22Lkd2BwnbV7+732vkkFA4lNHuiDML1NCU5lQaBH43iXXmJklFLpjF1AMsHpc
gbJnFc2bbtY=
=Owey
-----END PGP SIGNATURE-----
Received: from relay.tis.com by neptune.TIS.COM id aa29576; 19 Mar 96 2:16 EST
Received: by relay.tis.com; id CAA04260; Tue, 19 Mar 1996 02:18:07 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma004258; Tue, 19 Mar 96 02:17:39 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA23408; Tue, 19 Mar 96 02:16:32 EST
Received: by relay.tis.com; id CAA04253; Tue, 19 Mar 1996 02:17:37 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma004249; Tue, 19 Mar 96 02:17:17 -0500
Received: from unix.ka9q.ampr.org by interlock.ans.net with SMTP id AA11853
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Tue, 19 Mar 1996 02:18:19 -0500
Received: (from karn@localhost) by unix.ka9q.ampr.org (8.7.3/8.6.12) id XAA00300; Mon, 18 Mar 1996 23:20:43 -0800 (PST)
Date: Mon, 18 Mar 1996 23:20:43 -0800 (PST)
Message-Id: <199603190720.XAA00300@unix.ka9q.ampr.org>
From: Phil Karn <karn@unix.ka9q.ampr.org>
To: ipsec@ans.net
Subject: NSA denies our 3DES license
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Last month, Qualcomm filed with the State Department an application to
export my IP Security (ESP) code for KA9Q NOS to Singapore.
Our stated purpose was to encrypt an Internet "tunnel" between
Qualcomm's US facilities and our office in Singapore, which is staffed
by two US citizens. We stated that the software would be used solely
for this purpose and would not be transferred to anyone else.
Our application indicated that the software in question supported both
single and triple DES.
On March 11, the Office of Defense Trade Controls returned our application
stamped "RETURNED WITHOUT ACTION". The following form was attached:
United States Department of State
Bureau of Political-Military Affairs
Office of Defense Trade Controls
Washington, DC 20520-0602
MAR 11 1996 [stamped]
IN REPLY REFER TO
DTC CASE - 664149
The enclosed application has been voided and is being RETURNED WITHOUT
ACTION for the reasons indicated below:
_X_1. Submit a new application including all required background and
documentation. Do not return the enclosed application.
[25 other unchecked items omitted. These referred mainly to administrative
problems like "you used the wrong form", "you didn't file enough copies
of the supporting technical data", etc.
_X_27. Please submit another license [sic] once your software has been
modified so that it no longer contains triple DES. Please specify
object code only on your license application.
[signed]
Darlene Staniszewski
Licensing Officer
(703) 875-5677
[end of form]
So there you have it. NSA makes good on its threat to ANSI X9 that
triple DES would not be exportable.
This was a case where keeping strong crypto out of the hands of
terrorists and unfriendly governments was clearly not at issue. It
dealt strictly with the ability of a US corporation to defend its
international operations against against industrial espionage. Or,
perhaps more to the point, espionage by the NSA.
Certainly seems like a good argument in favor of the Leahy bill to me.
One mildly interesting thing about this form letter response is that
item 27 appeared to be part of the standard form -- it wasn't typed
into an "other" field of an existing form. Perhaps they added it to
the word processing file for this one occasion. Or perhaps they deny
triple DES exports so regularly that they now have a standard form
item to deal with it.
Phil Karn
Received: from relay.tis.com by neptune.TIS.COM id aa05527; 19 Mar 96 8:16 EST
Received: by relay.tis.com; id IAA06724; Tue, 19 Mar 1996 08:18:48 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma006721; Tue, 19 Mar 96 08:18:19 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA29873; Tue, 19 Mar 96 08:17:13 EST
Received: by relay.tis.com; id IAA06718; Tue, 19 Mar 1996 08:18:18 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma006713; Tue, 19 Mar 96 08:17:56 -0500
Received: from pilotx.firewall.is.chrysler.com (copilot.is.chrysler.com) by interlock.ans.net with SMTP id AA15626
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Tue, 19 Mar 1996 08:18:57 -0500
Received: by pilotx.firewall.is.chrysler.com; id IAA15178; Tue, 19 Mar 1996 08:18:58 -0500
Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1)
id sma015167; Tue, 19 Mar 96 08:18:47 -0500
Received: from rgm3.is.chrysler.com by clhubgw1.is.chrysler.com (5.x/SMI-4.1)
id AD20555; Tue, 19 Mar 1996 08:20:47 -0500
Message-Id: <2.2.32.19960319131657.00e115ec@pop3hub.is.chrysler.com>
X-Sender: t3125rm@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 19 Mar 1996 08:16:57 -0500
To: Michael Richardson <mcr@milkyway.com>, ipsec@ans.net
From: Robert Moskowitz <rgm3@is.chrysler.com>
Subject: Re: ESP transform with RC5
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
At 03:01 PM 3/18/96 -0500, Michael Richardson wrote:
>
> For a little more context: the RSA folks got most of the firewall vendors
>together last August to discuss RSA DSI and firewalls. We had a problem: we
>needed to interoperate on virtual private network technology, particularly
>when it came to road-warrior notebooks. We agreed that swipe and SKIP were
>interesting, but that the firewall vendors had to implement something that
>the PC/Mac stack vendors were going to implement.
> Thus S/WAN was born. Just take the then current ipsec, nail some parameters
>down, and take the first step.
> The various vendors didn't really have anyone that they felt could coordinate
>their efforts. While RSA Data Systems isn't a dis-interested party, at least
>they are non-firewall-vendor aligned: we know what their interests are.
This, of course, is of key interest to the auto industry. We need this sort
of interoperability on a fairly large scale. This is why I have been active
in the IPSEC wg, in case you haven't guessed ;)
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from relay.tis.com by neptune.TIS.COM id aa06318; 19 Mar 96 9:00 EST
Received: by relay.tis.com; id JAA07373; Tue, 19 Mar 1996 09:02:48 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma007371; Tue, 19 Mar 96 09:02:21 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA03889; Tue, 19 Mar 96 09:01:14 EST
Received: by relay.tis.com; id JAA07364; Tue, 19 Mar 1996 09:02:18 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma007358; Tue, 19 Mar 96 09:02:07 -0500
Received: from pilotx.firewall.is.chrysler.com (copilot.is.chrysler.com) by interlock.ans.net with SMTP id AA16421
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Tue, 19 Mar 1996 09:03:07 -0500
Received: by pilotx.firewall.is.chrysler.com; id JAA16125; Tue, 19 Mar 1996 09:03:08 -0500
Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1)
id sma016112; Tue, 19 Mar 96 09:02:52 -0500
Received: from rgm3 (rgm3.is.chrysler.com) by clhubgw1.is.chrysler.com (5.x/SMI-4.1)
id AA21057; Tue, 19 Mar 1996 09:04:52 -0500
Message-Id: <2.2.32.19960319140102.00e1e19c@pop3hub.is.chrysler.com>
X-Sender: t3125rm@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 19 Mar 1996 09:01:02 -0500
To: Phil Karn <karn@unix.ka9q.ampr.org>, ipsec@ans.net
From: Robert Moskowitz <rgm3@is.chrysler.com>
Subject: Re: NSA denies our 3DES license
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
At 11:20 PM 3/18/96 -0800, Phil Karn wrote:
>
>So there you have it. NSA makes good on its threat to ANSI X9 that
>triple DES would not be exportable.
>
>This was a case where keeping strong crypto out of the hands of
>terrorists and unfriendly governments was clearly not at issue. It
>dealt strictly with the ability of a US corporation to defend its
>international operations against against industrial espionage. Or,
>perhaps more to the point, espionage by the NSA.
This raises an interesting question WRT RC5 and smb's note.
Can RC5 parameters be set so that it reaches 3DES strength, and if so, if
the keying protocol allows for full parameter control, might NSA do the same
with RC5 as it is doing to 3DES? Or specify that the keying protocol lock
down a certain set of RC5 parameters?
OOOps, what have I done? The NSA watchers of this list (not meaning Mark
and his fellows, but the 'other side') way now go off and have to figure
this all out :)
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from relay.tis.com by neptune.TIS.COM id aa08163; 19 Mar 96 10:16 EST
Received: by relay.tis.com; id KAA09335; Tue, 19 Mar 1996 10:18:54 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma009327; Tue, 19 Mar 96 10:18:25 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA09173; Tue, 19 Mar 96 10:17:18 EST
Received: by relay.tis.com; id KAA09323; Tue, 19 Mar 1996 10:18:24 -0500
Received: from copilot.is.chrysler.com(204.189.94.148) by relay.tis.com via smap (V3.1)
id xma009310; Tue, 19 Mar 96 10:18:03 -0500
Received: by pilotx.firewall.is.chrysler.com; id KAA17360; Tue, 19 Mar 1996 10:19:09 -0500
Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1)
id sma017348; Tue, 19 Mar 96 10:19:04 -0500
Received: from rgm3.is.chrysler.com by clhubgw1.is.chrysler.com (5.x/SMI-4.1)
id AB22159; Tue, 19 Mar 1996 10:21:03 -0500
Message-Id: <2.2.32.19960319151713.00ca37f8@pop3hub.is.chrysler.com>
X-Sender: t3125rm@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 19 Mar 1996 10:17:13 -0500
To: smb@research.att.com, "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>
From: Robert Moskowitz <rgm3@is.chrysler.com>
Subject: Re: ESP transform with RC5
Cc: perry@piermont.com, ipsec@TIS.COM
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
At 06:42 PM 3/18/96 EST, smb@research.att.com wrote:
>
>It's also worth noting that RC5 poses some interesting technical issues.
>For example, it is parameterized, and none of the key management mechanisms
>we are considering seem to support that. Possibly, the parameters could
>be encoded as part of the key -- but we're moving down a track in which
>keys are true-random numbers. Besides, it may be necessary to negotiate
>some of the parameters under certain circumstances -- some folks may only
>have 40-bit RC5 implementations available to them, for the usual obvious
>reasons.
Seems that an RC4 ESP would have a simliar need? Of course, I'd suspect
that only RSA would submit an RC4 ESP and they have already moved on to 5...
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from relay.tis.com by neptune.TIS.COM id aa08685; 19 Mar 96 10:37 EST
Received: by relay.tis.com; id KAA10226; Tue, 19 Mar 1996 10:39:22 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma010222; Tue, 19 Mar 96 10:38:56 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA10677; Tue, 19 Mar 96 10:37:47 EST
Received: by relay.tis.com; id KAA10214; Tue, 19 Mar 1996 10:38:52 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma010205; Tue, 19 Mar 96 10:38:26 -0500
Received: from Fluffy.TGV.COM by interlock.ans.net with SMTP id AA19038
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Tue, 19 Mar 1996 10:39:24 -0500
Received: from localhost (localhost [127.0.0.1]) by fluffy.tgv.com (8.7.5/8.7.3) with SMTP id HAA06195 for ipsec@ans.net; Tue, 19 Mar 1996 07:39:08 -0800 (PST)
From: Derrell Piper <piper@tgv.com>
Message-Id: <199603191539.HAA06195@fluffy.tgv.com>
To: ipsec@ans.net
Subject: Re: NSA denies our 3DES license
In-Reply-To: Your message of "Tue, 19 Mar 96 09:01:02 EST."
<2.2.32.19960319140102.00e1e19c@pop3hub.is.chrysler.com>
Date: Tue, 19 Mar 96 07:39:08 -0800
X-Mts: smtp
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
>Can RC5 parameters be set so that it reaches 3DES strength, and if so, if
>the keying protocol allows for full parameter control, might NSA do the same
>with RC5 as it is doing to 3DES? Or specify that the keying protocol lock
>down a certain set of RC5 parameters?
RC5 is a stream cipher that allows for variable length keys. I would guess
that RC5 using 40-bit (or less) keys would be exportable, but greater than
40 bits would not. That's what's been done for other ciphers that employ
variable length keys.
Derrell Piper | piper@tgv.com | 408/457-5384
TGV, Inc. | 101 Cooper Street | Santa Cruz, CA 95060 USA
Received: from relay.tis.com by neptune.TIS.COM id aa09312; 19 Mar 96 11:05 EST
Received: by relay.tis.com; id LAA11064; Tue, 19 Mar 1996 11:07:52 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma011051; Tue, 19 Mar 96 11:07:26 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA12503; Tue, 19 Mar 96 11:06:18 EST
Received: by relay.tis.com; id LAA11038; Tue, 19 Mar 1996 11:07:22 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma011031; Tue, 19 Mar 96 11:07:21 -0500
Received: from columbia.sparta.com (bugs_bunny.columbia.SPARTA.COM) by interlock.ans.net with SMTP id AA20083
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Tue, 19 Mar 1996 11:08:17 -0500
Received: from katahdin.columbia.sparta.com by columbia.sparta.com (4.1/cfm-7-21-95)
id AA08198; Tue, 19 Mar 96 11:07:43 EST
Received: by katahdin.columbia.sparta.com (5.61/SMI-4.1)
id AA19845; Tue, 19 Mar 96 11:07:40 -0500
From: Howard Weiss <hsw@columbia.sparta.com>
Message-Id: <9603191607.AA19845@katahdin.columbia.sparta.com>
Subject: ISO 10164-8 Security Audit Trails
To: ipsec@ans.net
Date: Tue, 19 Mar 1996 11:07:37 -0500 (EST)
Organization: SPARTA Inc. (Secure Systems Engineering Division)
Usmail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046
Phone: (410) 381-9400 x201
Fax: (410) 381-5559
X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 898
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
I fully realize the IETF aversion to ISO standards (including my own),
but I need to ask anyway .....
Does anyone know of any systems that implement standard security
audit trails as specified in ISO/IEC 10164-8, 1993 (Information
Technology - Open Systems Interconnection - Systems Management - Part
8: Security Audit Trail Function (ITU-T X.740)?
Thanks,
Howard Weiss
________________________________________________________________________
| |
| Howard Weiss phone (410) 381-9400 x201 |
| SPARTA, Inc. (301) 621-8145 x201 (DC)|
| 9861 Broken Land Parkway, suite 300 fax: (410) 381-5559 |
| Columbia, MD 21046 email: hsw@columbia.sparta.com|
|________________________________________________________________________|
Received: from relay.tis.com by neptune.TIS.COM id aa09506; 19 Mar 96 11:09 EST
Received: by relay.tis.com; id LAA11159; Tue, 19 Mar 1996 11:11:52 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma011146; Tue, 19 Mar 96 11:11:24 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA12722; Tue, 19 Mar 96 11:10:17 EST
Received: by relay.tis.com; id LAA11137; Tue, 19 Mar 1996 11:11:22 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma011128; Tue, 19 Mar 96 11:10:53 -0500
Received: from RSA.COM by interlock.ans.net with SMTP id AA20219
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Tue, 19 Mar 1996 11:11:55 -0500
Received: from snail.rsa.com by RSA.COM with SMTP
id AA12673; Tue, 19 Mar 96 08:02:45 PST
Received: from cc:Mail by snail.rsa.com
id AA827251847; Mon, 18 Mar 96 12:12:24 PST
Date: Mon, 18 Mar 96 12:12:24 PST
From: baldwin <baldwin@rsa.com>
Message-Id: <9602198272.AA827251847@snail.rsa.com>
To: ipsec@ans.net
Subject: RC5 Security Information
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
For those interested in the security of RC5. Here is the
section from the RC5 description document.
--Bob
9. Security Considerations
The RC5 cipher is relatively new so critical reviews are still being
performed. However, the cipher's simple structure makes it easy to analyze
and hopefully easier to assess its strength. Reviews so far are very
promising.
Early results [1] suggest that for RC5 with a 64 bit block size (32 bit
word size), 12 rounds will suffice to resist linear and differential
cyptanalysis. The 128 bit block version has not been studied as much as
the 64 bit version, but it appears that 16 rounds would be an appropriate
minimum. Block sizes less than 64 bits are academically interesting but
should not be used for cryptographic security. Greater security can be
achieved by increasing the number of rounds at the cost of decreasing the
throughput of the cipher.
The length of the secret key helps determine the cipher's resistance to
brute force key searching attacks. A key length of 128 bits should give
adequate protection against brute force key searching by a well funded
opponent for a couple decades [7]. For RC5 with 12 rounds, the key setup
time and data encryption time are the same for all key lengths less than
832 bits, so there is no performance reason for choosing short keys. For
larger keys, the key expansion step will run slower because the user key
table, LL, will be longer than the expanded key table, S. However, the
encryption time will be unchanged since it is only a function of the number
of rounds.
To comply with export regulations it may be necessary to choose keys that
only have 40 unknown bits. A poor way to do this would be to choose a
simple 5 byte key. This should be avoided because it would be easy for an
opponent to pre-compute key searching information. Another common
mechanism is to pick a 128 bit key and publish the first 88 bits. This
method may be weak because it reveals a large number of the entries in the
user key table, LL, and the key expansion algorithm was not designed to
resist attacks when most of LL is known. A better way to conform to the 40
bit rule is to pick a seed value of 128 bits, publish 88 bits of this seed,
run the entire seed through a hash function like MD5 [4], and use the 128
bit output of the hash function as the RC5 key.
In the case of 40 unknown key bits with 88 known key bits (i.e., 88 salt
bits) there should still be 12 or more rounds for the 64 bit block version
of RC5, otherwise the value of adding salt bits to the key is likely to be
lost.
The lifetime of the key also influences security. For high security
applications, the key to any 64 bit block cipher should be changed after
encrypting 2**32 blocks (2**64 blocks for a 128 bit block cipher). For the
case of 64 bit blocks, this rule would recommend changing the key after
2**40 (i.e. 10**12) bytes are encrypted. See Schneier [6] page 183 for
further discussion.
References
[1] Kaliski, Burton S., and Yinqun Lisa Yin, "On Differential and Linear
Cryptanalysis of the RC5 Encryption Algorithm", In Advances in Cryptology -
Crypto '95, pages 171-184, Springer-Verlag, New York, 1995.
[2] Rivest, Ronald L., "The RC5 Encryption Algorithm", In Proceedings of
the Second International Workshop on Fast Software Encryption, pages 86-96,
Leuven Belgium, December 1994.
[3] Rivest, Ronald L., "RC5 Encryption Algorithm", In Dr. Dobbs Journal,
number 226, pages 146-148, January 1995.
[4] Rivest, Ronald L., "The MD5 Message-Digest Algorithm", RFC 1321.
[5] RSA Laboratories, "Public Key Cryptography Standards (PKCS)", RSA Data
Security Inc. See ftp.rsa.com.
[6] Schneier, Bruce, "Applied Cryptography", Second Edition, John Wiley and
Sons, New York, 1996.
[7] Business Software Alliance, Matt Blaze et al., "Minimum Key Length for
Symmetric Ciphers to Provide Adequate Commercial Security",
http://www.bsa.org/bsa/cryptologists.html.
Received: from relay.tis.com by neptune.TIS.COM id aa09450; 19 Mar 96 11:08 EST
Received: by relay.tis.com; id LAA11122; Tue, 19 Mar 1996 11:10:52 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma011114; Tue, 19 Mar 96 11:10:23 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA12664; Tue, 19 Mar 96 11:09:17 EST
Received: by relay.tis.com; id LAA11111; Tue, 19 Mar 1996 11:10:22 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma011109; Tue, 19 Mar 96 11:10:21 -0500
Received: from RSA.COM by interlock.ans.net with SMTP id AA20195
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Tue, 19 Mar 1996 11:11:23 -0500
Received: from snail.rsa.com by RSA.COM with SMTP
id AA12665; Tue, 19 Mar 96 08:02:06 PST
Received: from cc:Mail by snail.rsa.com
id AA827251845; Mon, 18 Mar 96 12:09:43 PST
Date: Mon, 18 Mar 96 12:09:43 PST
From: baldwin <baldwin@rsa.com>
Message-Id: <9602198272.AA827251845@snail.rsa.com>
To: ipsec@ans.net
Subject: RC5 Background Information
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Here is a short section from the informational RFC on
the RC5 cipher. It seems to answer many of the questions we have
seen posted to the list.
--Bob
1. Executive Summary
This document defines three ciphers with enough detail to ensure
interoperability between different implementations. The first cipher is
the raw RC5 block cipher. The RC5 cipher takes a fixed size input block
and produces a fixed sized output block using a transformation that depends
on a key. The second cipher, RC5-CBC, is the Cipher Block Chaining (CBC)
mode for RC5. It can process messages whose length is a multiple of the
RC5 block size. The third cipher, RC5-CBC-Pad, includes padding in the CBC
mode to allow it to process inputs of any byte length.
The RC5 cipher was invented by Professor Ronald L. Rivest of the
Massachusetts Institute of Technology in 1994. It is a very fast and
simple algorithm that is parameterized by the block size, the number of
rounds, and key length. These parameters can be adjusted to meet different
goals for security, performance, and exportability.
A patent application has been filed for the RC5 cipher. The terms RC5,
RC5-CBC, RC5-CBC-Pad and assorted variations on these are trademarks.
Received: from relay.tis.com by neptune.TIS.COM id aa09535; 19 Mar 96 11:10 EST
Received: by relay.tis.com; id LAA11171; Tue, 19 Mar 1996 11:12:22 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma011168; Tue, 19 Mar 96 11:11:54 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA12751; Tue, 19 Mar 96 11:10:47 EST
Received: by relay.tis.com; id LAA11160; Tue, 19 Mar 1996 11:11:52 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma011147; Tue, 19 Mar 96 11:11:35 -0500
Received: from RSA.COM by interlock.ans.net with SMTP id AA20256
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Tue, 19 Mar 1996 11:12:36 -0500
Received: from snail.rsa.com by RSA.COM with SMTP
id AA12688; Tue, 19 Mar 96 08:03:25 PST
Received: from cc:Mail by snail.rsa.com
id AA827251852; Mon, 18 Mar 96 12:14:36 PST
Date: Mon, 18 Mar 96 12:14:36 PST
From: baldwin <baldwin@rsa.com>
Message-Id: <9602198272.AA827251852@snail.rsa.com>
To: ipsec@ans.net
Subject: RC5 Performance Information
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
One reason for using RC5 in an ESP is to get higher performance.
Here are some performance numbers comparing DES and RC5 when encrypting
1024 byte blocks on a 100MHz Pentium and a 200MHz DEC Alpha. Both numbers
come from RSADSI's BSAFE 3.0 cryptography toolkit. The DES implementation
in BSAFE 3.0 is a slight variation of Eric Young's libdes software and is
used with his permission.
DES uses a 56 bit key. The RC5 version measured below uses
a 128 bit key, 12 rounds of the inner loop, and like DES, is a 64 bit
block cipher.
90 MHz Pentium 200 MHz DEC Alpha
DES Key Setup 17 MicroSeconds 16 MicroSeconds
RC4 Key Setup 57 MicroSeconds 138 MicroSeconds
RC5 Key Setup 48 MicroSeconds 26 MicroSeconds
DES Encrypt 8.0 MegaBits/Sec 10.6 MegaBits/Sec
RC4 Encrypt 65.6 MegaBits/Sec 34.4 MegaBits/Sec
RC5 Encrypt 26.3 MegaBits/Sec 24.5 MegaBits/Sec
--Bob
Received: from relay.tis.com by neptune.TIS.COM id aa09599; 19 Mar 96 11:11 EST
Received: by relay.tis.com; id LAA11195; Tue, 19 Mar 1996 11:13:22 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma011189; Tue, 19 Mar 96 11:12:53 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA12808; Tue, 19 Mar 96 11:11:47 EST
Received: by relay.tis.com; id LAA11186; Tue, 19 Mar 1996 11:12:52 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma011178; Tue, 19 Mar 96 11:12:42 -0500
Received: from RSA.COM by interlock.ans.net with SMTP id AA20315
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Tue, 19 Mar 1996 11:13:44 -0500
Received: from snail.rsa.com by RSA.COM with SMTP
id AA12756; Tue, 19 Mar 96 08:04:15 PST
Received: from cc:Mail by snail.rsa.com
id AA827251893; Mon, 18 Mar 96 13:40:41 PST
Date: Mon, 18 Mar 96 13:40:41 PST
From: baldwin <baldwin@rsa.com>
Message-Id: <9602198272.AA827251893@snail.rsa.com>
To: perry@piermont.com
Cc: ipsec@ans.net
Subject: ESP RC5 and S/WAN
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Perry,
You might want to check out the S/WAN information on
http://www.rsa.com/rsa/SWAN. The current effort is aimed at
helping vendors to implement AH and ESP with manual DES key loading.
There is an interoperability matrix on a sub-page that shows
how far the 11 current vendors have gotten (a long way!).
S/WAN is basically an initiative run by vendors who are
actually implementing the IPsec working group standards, and so
far it has been quite successful.
A few of the vendors have requested that RSADSI help them
get 1) better performance than DES in software, and 2) the ability
to sell an IPsec product internationally, or at least being able
to create a demo versions that can be downloaded internationally,
and 3) a cipher that is stronger than DES.
The ESP based on RC5 is a response to these requests.
RC5 with 128 bit keys and 12 rounds meets requirements 1 and 3,
and a 40 bit RC5 we hope will meet requirements 1 and 2 (so far
no vendors has formally requested export of 40 bit RC5).
I think the main thing to notice is that 11 vendors now have
implementations of DES based ESP. They also all support the
MD5 AH header and some of them support the new HMAC nested MD5
integrity check for AH. In this respect, I hope that you can see that
RSADSI is help the IPsec group further many of its goals.
The vendors of IPsec products will only license technologies
from RSADSI if it benefits them and their customers. The S/WAN
initiative seeks to complement the good work of the IPsec group
to incorporate the perspective of the TCP/IP vendors, many of whom
have an global market.
--Bob
______________________________ Reply Separator _________________________________
Subject: Re: ESP transform with RC5
Author: perry@piermont.com at INTERNET
Date: 3/18/96 11:55 AM
Just for context for everyone, the RSA DSI folks are (or at least,
were) attempting to push this thing they call S/WAN, which is
basically IPsec using RC5 to make it into something proprietary that
RSA DSI has a patent on and thus gets royalties for. It doesn't have
any real advantages to anyone other than RSA DSI, which has an obvious
stake in its widespread deployment...
Perry
Received: from relay.tis.com by neptune.TIS.COM id aa10197; 19 Mar 96 11:30 EST
Received: by relay.tis.com; id LAA11850; Tue, 19 Mar 1996 11:32:18 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma011840; Tue, 19 Mar 96 11:31:51 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA13950; Tue, 19 Mar 96 11:30:45 EST
Received: by relay.tis.com; id LAA11834; Tue, 19 Mar 1996 11:31:50 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma011814; Tue, 19 Mar 96 11:31:21 -0500
Received: from igw2.watson.ibm.com by interlock.ans.net with SMTP id AA20796
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Tue, 19 Mar 1996 11:32:22 -0500
Received: from hawpub.watson.ibm.com ([9.2.90.19]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id LAA23382; Tue, 19 Mar 1996 11:32:30 -0500
Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/2/16/96)
id AA32475; Tue, 19 Mar 1996 11:32:21 -0500
Message-Id: <9603191632.AA32475@hawpub.watson.ibm.com>
Subject: Re: NSA denies our 3DES license
To: Robert Moskowitz <rgm3@is.chrysler.com>
Date: Tue, 19 Mar 1996 11:32:20 -0500 (EST)
From: Uri Blumenthal <uri@watson.ibm.com>
Cc: ipsec@ans.net
In-Reply-To: <2.2.32.19960319140102.00e1e19c@pop3hub.is.chrysler.com> from "Robert Moskowitz" at Mar 19, 96 09:01:02 am
Reply-To: uri@watson.ibm.com
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Robert Moskowitz says:
> >So there you have it. NSA makes good on its threat to ANSI X9 that
> >triple DES would not be exportable.
>
> This raises an interesting question WRT RC5 and smb's note.
> Can RC5 parameters be set so that it reaches 3DES strength, and if so, if
> the keying protocol allows for full parameter control, might NSA do the same
> with RC5 as it is doing to 3DES? Or specify that the keying protocol lock
> down a certain set of RC5 parameters?
1. Since the number of rounds can be as large as 255 and the same is true
for the key length, probably RC5 can approach 3DES strength, further
analysis pending.
2. It seems obvious, that no software will be licensed, unless the
institution in question can provide guarantees that the
limit on number of rounds and length of key are
unmodifiable. If such a guarantee is not
satisfactory, I'd expect the license
to be denied.
> OOOps, what have I done? The NSA watchers of this list (not meaning Mark
> and his fellows, but the 'other side') way now go off and have to figure
> this all out :)
(:-)
--
Regards,
Uri uri@watson.ibm.com
-=-=-=-=-=-=-
<Disclaimer>
Received: from relay.tis.com by neptune.TIS.COM id aa10324; 19 Mar 96 11:34 EST
Received: by relay.tis.com; id LAA11959; Tue, 19 Mar 1996 11:36:18 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma011953; Tue, 19 Mar 96 11:35:49 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA14248; Tue, 19 Mar 96 11:34:42 EST
Received: by relay.tis.com; id LAA11950; Tue, 19 Mar 1996 11:35:48 -0500
Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1)
id xma011944; Tue, 19 Mar 96 11:35:21 -0500
Received: from Bill.Simpson.DialUp.Mich.Net (pm012-26.dialip.mich.net [141.211.7.194]) by merit.edu (8.7.5/merit-2.0) with SMTP id LAA14884; Tue, 19 Mar 1996 11:35:56 -0500 (EST)
Date: Tue, 19 Mar 96 16:09:26 GMT
From: William Allen Simpson <wsimpson@greendragon.com>
Message-Id: <5086.wsimpson@greendragon.com>
To: "Jeffrey I. Schiller" <jis@mit.edu>
Cc: ipsec@TIS.COM, iesg@ietf.cnri.reston.va.us
Subject: Re: Your Appeal to me regarding replacing IPSEC WG Chair(s)
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
> Date: Tue, 19 Mar 1996 00:08:20 -0500
> From: "Jeffrey I. Schiller" <jis@mit.edu>
> I have considered your request to remove the chairs of the
> IPSEC Working Group. I have taken this matter seriously and have
> consulted with many people about what they believe is happening in the
> Working Group. I have also been attending most of the face to face
> meetings myself and read the mailing list, so I have my own
> observations as well.
>...
> I can find no reason to believe that the Working Group Chairs
> should be removed on the basis of your appeal.
Thank you for your decision on my Feb 11 request, with additional issues
raised Feb 14, Feb 15, Mar 5, and Mar 10. However, despite your
"serious" research, you have based the decision on (at least) two errors
of fact:
> I have also had people report to me that you have threatened
> them with lawsuits and otherwise used intimidation tactics when other
> avenues of argument were not available to you.
Perhaps you could give more detail on these apocryphal and anonymous
charges?
> Furthermore I interpret
> your message to the Working Group on 3/14/96 as an attempt to
> intimidate the chairs and Working Group by making your appeal to me
> public and threatening to continue to appeal until some body finds in
> your favor.
>
Perhaps you could specify what message to the Working Group? I cannot
find any message from me to the WG on or near that date.
Since you failed to answer _any_ of the specifics raised in my appeal,
and both of your negative findings are factually unsupported, I will
appeal to the IESG as a whole, pursuant to our Standards Process.
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
Received: from relay.tis.com by neptune.TIS.COM id aa10868; 19 Mar 96 11:59 EST
Received: by relay.tis.com; id MAA12830; Tue, 19 Mar 1996 12:01:13 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma012823; Tue, 19 Mar 96 12:00:40 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA15767; Tue, 19 Mar 96 11:59:34 EST
Received: by relay.tis.com; id MAA12820; Tue, 19 Mar 1996 12:00:39 -0500
Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1)
id xma012815; Tue, 19 Mar 96 12:00:24 -0500
Received: from Bill.Simpson.DialUp.Mich.Net (pm012-26.dialip.mich.net [141.211.7.194]) by merit.edu (8.7.5/merit-2.0) with SMTP id LAA14908 for <ipsec@TIS.COM>; Tue, 19 Mar 1996 11:36:06 -0500 (EST)
Date: Tue, 19 Mar 96 16:05:22 GMT
From: William Allen Simpson <wsimpson@greendragon.com>
Message-Id: <5085.wsimpson@greendragon.com>
To: ipsec@TIS.COM
Subject: Re: ESP transform with RC5
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
> From: smb@research.att.com
> Date: Mon, 18 Mar 96 18:42:23 EST
> It's also worth noting that RC5 poses some interesting technical issues.
> For example, it is parameterized, and none of the key management mechanisms
> we are considering seem to support that.
Photuris provides for parameterization, and in particular, the Photuris
extensions document proposes negotiation of parameters for RC5.
But then, you may be correct that we are not officially considering
Photuris.
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
Received: from relay.tis.com by neptune.TIS.COM id aa10897; 19 Mar 96 12:00 EST
Received: by relay.tis.com; id MAA12874; Tue, 19 Mar 1996 12:02:09 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma012851; Tue, 19 Mar 96 12:01:42 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA15831; Tue, 19 Mar 96 12:00:35 EST
Received: by relay.tis.com; id MAA12844; Tue, 19 Mar 1996 12:01:40 -0500
Received: from unknown(206.1.51.15) by relay.tis.com via smap (V3.1)
id xma012832; Tue, 19 Mar 96 12:01:14 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id MAA25678; Tue, 19 Mar 1996 12:01:38 -0500 (EST)
Message-Id: <199603191701.MAA25678@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: Robert Moskowitz <rgm3@is.chrysler.com>
Cc: ipsec@TIS.COM
Subject: Re: ESP transform with RC5
In-Reply-To: Your message of "Tue, 19 Mar 1996 10:17:13 EST."
<2.2.32.19960319151713.00ca37f8@pop3hub.is.chrysler.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Tue, 19 Mar 1996 12:01:37 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Robert Moskowitz writes:
> Seems that an RC4 ESP would have a simliar need? Of course, I'd suspect
> that only RSA would submit an RC4 ESP and they have already moved on to 5...
RC4 has entered the public domain, so RSA has no reason to push it
since they can't make any money by selling it. It is unknown how good
a cipher it is, but it is being studied.
Perry
Received: from relay.tis.com by neptune.TIS.COM id aa10896; 19 Mar 96 12:00 EST
Received: by relay.tis.com; id MAA12873; Tue, 19 Mar 1996 12:02:09 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma012852; Tue, 19 Mar 96 12:01:42 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA15832; Tue, 19 Mar 96 12:00:35 EST
Received: by relay.tis.com; id MAA12842; Tue, 19 Mar 1996 12:01:40 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma012826; Tue, 19 Mar 96 12:00:58 -0500
Received: from jekyll.piermont.com by interlock.ans.net with SMTP id AA21795
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Tue, 19 Mar 1996 12:01:53 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id MAA25670; Tue, 19 Mar 1996 12:00:20 -0500 (EST)
Message-Id: <199603191700.MAA25670@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: Robert Moskowitz <rgm3@is.chrysler.com>
Cc: Phil Karn <karn@unix.ka9q.ampr.org>, ipsec@ans.net
Subject: Re: NSA denies our 3DES license
In-Reply-To: Your message of "Tue, 19 Mar 1996 09:01:02 EST."
<2.2.32.19960319140102.00e1e19c@pop3hub.is.chrysler.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Tue, 19 Mar 1996 12:00:08 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Robert Moskowitz writes:
> This raises an interesting question WRT RC5 and smb's note.
>
> Can RC5 parameters be set so that it reaches 3DES strength,
If it can be, you can bet it can't be exported. We can't answer that
question, however, because we haven't studied RC5 long enough to have
anything like a reasonable answer.
However, I don't see what the problem is. If you need IPSec for your
overseas plants, buy from the Swiss or the Israelis or someone else
who isn't stopped at the border. There are lots of overseas vendors
for this stuff, so there is no reason to worry.
Perry
Received: from relay.tis.com by neptune.TIS.COM id aa11139; 19 Mar 96 12:07 EST
Received: by relay.tis.com; id MAA13105; Tue, 19 Mar 1996 12:09:15 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma013100; Tue, 19 Mar 96 12:08:47 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA16171; Tue, 19 Mar 96 12:07:40 EST
Received: by relay.tis.com; id MAA13097; Tue, 19 Mar 1996 12:08:45 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma013095; Tue, 19 Mar 96 12:08:43 -0500
Received: from jekyll.piermont.com by interlock.ans.net with SMTP id AA22244
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Tue, 19 Mar 1996 12:09:45 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id MAA25709; Tue, 19 Mar 1996 12:09:22 -0500 (EST)
Message-Id: <199603191709.MAA25709@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: Derrell Piper <piper@tgv.com>
Cc: ipsec@ans.net
Subject: Re: NSA denies our 3DES license
In-Reply-To: Your message of "Tue, 19 Mar 1996 07:39:08 PST."
<199603191539.HAA06195@fluffy.tgv.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Tue, 19 Mar 1996 12:09:17 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Derrell Piper writes:
> RC5 is a stream cipher that allows for variable length keys.
I believe RC5 is actually a block cipher.
Perry
Received: from relay.tis.com by neptune.TIS.COM id aa11284; 19 Mar 96 12:13 EST
Received: by relay.tis.com; id MAA13194; Tue, 19 Mar 1996 12:15:45 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma013187; Tue, 19 Mar 96 12:15:17 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA16347; Tue, 19 Mar 96 12:14:11 EST
Received: by relay.tis.com; id MAA13179; Tue, 19 Mar 1996 12:15:16 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma013170; Tue, 19 Mar 96 12:14:47 -0500
Received: from jekyll.piermont.com by interlock.ans.net with SMTP id AA22477
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Tue, 19 Mar 1996 12:15:45 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id MAA25701; Tue, 19 Mar 1996 12:08:10 -0500 (EST)
Message-Id: <199603191708.MAA25701@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: baldwin (Robert W. Baldwin) <baldwin@rsa.com>
Cc: ipsec@ans.net
Subject: Re: ESP RC5 and S/WAN
In-Reply-To: Your message of "Mon, 18 Mar 1996 13:40:41 PST."
<9602198272.AA827251893@snail.rsa.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Tue, 19 Mar 1996 12:08:10 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
"baldwin" writes:
> The ESP based on RC5 is a response to these requests.
> RC5 with 128 bit keys and 12 rounds meets requirements 1 and 3,
> and a 40 bit RC5 we hope will meet requirements 1 and 2 (so far
> no vendors has formally requested export of 40 bit RC5).
A more honest effort would have pushed 3DES for high security instead
of an RSA patented algorithm of still dubious merit. 40 bit keys can
be achieved easily for DES by the expedient of doing something like
exposing 16 of the bits. There is no good reason for anyone to use RSA
DSI proprietary conventional cipher algorithms.
Perry
Received: from relay.tis.com by neptune.TIS.COM id aa11662; 19 Mar 96 12:30 EST
Received: by relay.tis.com; id MAA13472; Tue, 19 Mar 1996 12:32:45 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma013466; Tue, 19 Mar 96 12:32:17 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA16760; Tue, 19 Mar 96 12:31:10 EST
Received: by relay.tis.com; id MAA13463; Tue, 19 Mar 1996 12:32:15 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma013458; Tue, 19 Mar 96 12:31:49 -0500
Received: from jekyll.piermont.com by interlock.ans.net with SMTP id AA22953
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Tue, 19 Mar 1996 12:32:42 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id MAA25728; Tue, 19 Mar 1996 12:19:05 -0500 (EST)
Message-Id: <199603191719.MAA25728@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: baldwin <baldwin@rsa.com>
Cc: ipsec@ans.net
Subject: Re: RC5 Background Information
In-Reply-To: Your message of "Mon, 18 Mar 1996 12:09:43 PST."
<9602198272.AA827251845@snail.rsa.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Tue, 19 Mar 1996 12:19:05 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
baldwin writes:
> Here is a short section from the informational RFC on
> the RC5 cipher. It seems to answer many of the questions we have
> seen posted to the list.
Actually, it doesn't answer the biggest question, which is "is RC5
secure?" The answer its "no one really knows".
However, your posting does note something I continue to emphasize...
> A patent application has been filed for the RC5 cipher. The terms RC5,
> RC5-CBC, RC5-CBC-Pad and assorted variations on these are trademarks.
The reason that RSA DSI pushes RC5 is because they own it and will
make money off of every user if it is widely used. They have no other
good reason for pushing it.
If people are really concerned about speed and are willing to use
patented algorithms, there are other, better choices that run fast and
have better security analysis behind them. Meanwhile, Phil Karn has
DES running at over 10Mbps in software on Pentium chips, and there are
3DES chips that run at gigabit speeds. I see no reason that anyone
should be seriously considering the use of RC5 unless they have stock
in RSA DSI.
Perry
Received: from relay.tis.com by neptune.TIS.COM id aa11798; 19 Mar 96 12:34 EST
Received: by relay.tis.com; id MAA13554; Tue, 19 Mar 1996 12:36:46 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma013548; Tue, 19 Mar 96 12:36:17 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA16862; Tue, 19 Mar 96 12:35:11 EST
Received: by relay.tis.com; id MAA13543; Tue, 19 Mar 1996 12:36:16 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma013539; Tue, 19 Mar 96 12:36:09 -0500
Received: from jekyll.piermont.com by interlock.ans.net with SMTP id AA23050
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Tue, 19 Mar 1996 12:37:09 -0500
Received: (from perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) id MAA25772; Tue, 19 Mar 1996 12:37:08 -0500 (EST)
Date: Tue, 19 Mar 1996 12:37:08 -0500 (EST)
Message-Id: <199603191737.MAA25772@jekyll.piermont.com>
From: "Perry E. Metzger" <perry@piermont.com>
To: ipsec@ans.net
Subject: RC5
Reply-To: perry@piermont.com
X-Reposting-Policy: please ask before redistributing
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
I really didn't want to get into a war with marketing flacks from RSA
Data Security Inc. over their patented "RC5" encryption algorithm.
I believe I've made my point on the topic, and I don't want to waste
people's time further with it. I simply encourage people to remember
that regardless of your need, there is no good reason to buy RC5 from
RSA, although RSA certainly has an economic interest in making you
think otherwise, and will doubtless push very hard to get people to
use it.
Perry
Received: from relay.tis.com by neptune.TIS.COM id aa11846; 19 Mar 96 12:35 EST
Received: by relay.tis.com; id MAA13578; Tue, 19 Mar 1996 12:37:45 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma013575; Tue, 19 Mar 96 12:37:18 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA16881; Tue, 19 Mar 96 12:36:11 EST
Received: by relay.tis.com; id MAA13566; Tue, 19 Mar 1996 12:37:16 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma013559; Tue, 19 Mar 96 12:36:49 -0500
Received: from jekyll.piermont.com by interlock.ans.net with SMTP id AA23059
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Tue, 19 Mar 1996 12:37:51 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id MAA25747; Tue, 19 Mar 1996 12:28:45 -0500 (EST)
Message-Id: <199603191728.MAA25747@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: baldwin <baldwin@rsa.com>
Cc: ipsec@ans.net
Subject: Re: RC5 Performance Information
In-Reply-To: Your message of "Mon, 18 Mar 1996 12:14:36 PST."
<9602198272.AA827251852@snail.rsa.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Tue, 19 Mar 1996 12:28:44 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
baldwin writes:
> One reason for using RC5 in an ESP is to get higher performance.
If one wants higher performance and one is willing to use patented
algorithms, there are better ones out there. IBM's SEAL, developed by
Don Coppersmith, comes to mind. It also hasn't been studied well
enough, but it has been studied better than RC5 and is blazingly fast
-- far faster than RC5.
If one needs real performance in a firewall or routing product,
however, the right answer is hardware. Gigabit 3DES encrypting chips
exist.
If one insists on software and is willing to use things that are
insufficiently studied, code known to be compatible with RC4 and free
of any intellectual property restrictions is available on the net, and
is faster than RC5.
In any case, I believe it is time to get off this topic. The point has
been made.
Perry
Received: from relay.tis.com by neptune.TIS.COM id aa11962; 19 Mar 96 12:38 EST
Received: by relay.tis.com; id MAA13666; Tue, 19 Mar 1996 12:40:45 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma013649; Tue, 19 Mar 96 12:40:17 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA16991; Tue, 19 Mar 96 12:39:10 EST
Received: by relay.tis.com; id MAA13646; Tue, 19 Mar 1996 12:40:15 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma013644; Tue, 19 Mar 96 12:40:05 -0500
Received: from pilotx.firewall.is.chrysler.com (copilot.is.chrysler.com) by interlock.ans.net with SMTP id AA23159
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Tue, 19 Mar 1996 12:41:06 -0500
Received: by pilotx.firewall.is.chrysler.com; id MAA19470; Tue, 19 Mar 1996 12:41:08 -0500
Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1)
id sma019445; Tue, 19 Mar 96 12:40:55 -0500
Received: from rgm3 (rgm3.is.chrysler.com) by clhubgw1.is.chrysler.com (5.x/SMI-4.1)
id AA23701; Tue, 19 Mar 1996 12:42:55 -0500
Message-Id: <2.2.32.19960319173904.00cb42bc@pop3hub.is.chrysler.com>
X-Sender: t3125rm@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 19 Mar 1996 12:39:04 -0500
To: perry@piermont.com
From: Robert Moskowitz <rgm3@is.chrysler.com>
Subject: Re: NSA denies our 3DES license
Cc: Phil Karn <karn@unix.ka9q.ampr.org>, ipsec@ans.net
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
At 12:00 PM 3/19/96 -0500, Perry E. Metzger wrote:
>
>However, I don't see what the problem is. If you need IPSec for your
>overseas plants, buy from the Swiss or the Israelis or someone else
>who isn't stopped at the border. There are lots of overseas vendors
>for this stuff, so there is no reason to worry.
Oh, I'm not worried for 'us', but I am worried a little at 'US' ;)
Of course it might be interesting to see what the various governments will
do when an encrypted tunnel using a very strong RC5 or a 3DES is going
between say Chrysler's TIS firewall in Detroit and Robert Bosch's firewall
in Frankfurt (I think it is).
The international aspect of our industry will challenge a lot of standard
positions. Chrysler just opened an office in Antwerp. I haven't
investigated if we got the Cylink gear for there like we did for the Austria
plant ( only DES based)....
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from relay.tis.com by neptune.TIS.COM id aa12139; 19 Mar 96 12:42 EST
Received: by relay.tis.com; id MAA13781; Tue, 19 Mar 1996 12:44:16 -0500
From: smb@research.att.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma013774; Tue, 19 Mar 96 12:43:47 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA17170; Tue, 19 Mar 96 12:42:40 EST
Received: by relay.tis.com; id MAA13771; Tue, 19 Mar 1996 12:43:45 -0500
Message-Id: <199603191743.MAA13771@relay.tis.com>
Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1)
id xma013769; Tue, 19 Mar 96 12:43:32 -0500
Received: from research.att.com by ns; Tue Mar 19 12:42:05 EST 1996
Received: from gryphon by research; Tue Mar 19 12:41:50 EST 1996
Received: by gryphon; Tue Mar 19 12:41:46 EST 1996
To: Robert Moskowitz <rgm3@is.chrysler.com>
Cc: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>, perry@piermont.com,
ipsec@TIS.COM
Subject: Re: ESP transform with RC5
Date: Tue, 19 Mar 96 12:41:45 EST
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Seems that an RC4 ESP would have a simliar need? Of course, I'd
suspect that only RSA would submit an RC4 ESP and they have
already moved on to 5...
Well, the SKIP folks like RC4, too. But RC4 is a stream cipher, and
RC5 is a block cipher, so they address different needs. For practical
purposes, there are only two RC4 versions that matter, 40-bit and 128-bit.
RC5 has several other variables as well.
Received: from relay.tis.com by neptune.TIS.COM id aa12268; 19 Mar 96 12:46 EST
Received: by relay.tis.com; id MAA13971; Tue, 19 Mar 1996 12:48:46 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma013953; Tue, 19 Mar 96 12:48:18 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA17348; Tue, 19 Mar 96 12:47:11 EST
Received: by relay.tis.com; id MAA13946; Tue, 19 Mar 1996 12:48:15 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma013938; Tue, 19 Mar 96 12:48:08 -0500
Received: from relay.hp.com by interlock.ans.net with SMTP id AA23360
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Tue, 19 Mar 1996 12:49:04 -0500
Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP
(1.37.109.16/15.5+ECS 3.3) id AA104667732; Tue, 19 Mar 1996 09:48:53 -0800
Message-Id: <199603191748.AA104667732@relay.hp.com>
Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com
id AA251058012; Tue, 19 Mar 1996 12:53:32 -0500
X-Mailer: exmh version 1.6.2 7/18/95
To: baldwin <baldwin@rsa.com>
Cc: perry@piermont.com, ipsec@ans.net
Subject: Re: ESP RC5 and S/WAN
In-Reply-To: baldwin's message of Mon, 18 Mar 1996 13:40:41 -0800.
<9602198272.AA827251893@snail.rsa.com>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Tue, 19 Mar 1996 12:48:51 -0500
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
content-type: text/plain; charset=us-ascii
You recently asserted that RC5 with 128 bit keys and 12 rounds is
definitely stronger than DES.
Given the youth of RC5, I find it difficult to accept your assertion
at this time.
- Bill
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMU7zfFpj/0M1dMJ/AQFKeAP9H2Z7C+H5py+a9uNfSqUegix/QaKaESQN
bEQZcJt+Fm2YeLJfwphGE+ry5GNPW9/UZEYDncOk+oWZ4zc33NGo708ghZdQspqs
iF5G6XFEsyAUhRVTjUllkUXhfmZ9Fmhf0tZ6jUuEZCbm6LUFCzdjQrocD+K8NVPs
bBxR80eQt5s=
=wScO
-----END PGP SIGNATURE-----
Received: from relay.tis.com by neptune.TIS.COM id aa12557; 19 Mar 96 12:55 EST
Received: by relay.tis.com; id MAA14253; Tue, 19 Mar 1996 12:57:15 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma014249; Tue, 19 Mar 96 12:56:48 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA17727; Tue, 19 Mar 96 12:55:42 EST
Received: by relay.tis.com; id MAA14237; Tue, 19 Mar 1996 12:56:46 -0500
Received: from stilton.cisco.com(171.69.1.161) by relay.tis.com via smap (V3.1)
id xma014227; Tue, 19 Mar 96 12:56:37 -0500
Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id JAA12220; Tue, 19 Mar 1996 09:57:37 -0800
X-Sender: fred@stilton.cisco.com
Message-Id: <v02140b53ad74a4ed9045@[171.69.128.114]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 19 Mar 1996 09:57:40 -0800
To: iesg@ietf.cnri.reston.va.us
From: Fred Baker <fred@cisco.com>
Subject: Re: Your Appeal to me regarding replacing IPSEC WG Chair(s)
Cc: ipsec@TIS.COM
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
At 8:09 AM 3/19/96, William Allen Simpson wrote:
>Since you failed to answer _any_ of the specifics raised in my appeal,
>and both of your negative findings are factually unsupported, I will
>appeal to the IESG as a whole, pursuant to our Standards Process.
I am prepared to send something like the following to Bill: comments?
______________________________________________________________________
Bill:
We have received your appeal. In fact, Jeff's comments do not come from him
alone, but were discussed among us in person at the IETF and by email over
the last week. His comments represent our consensus.
It is the considered opinion of the IESG that the working group chairs
hould remain in place, and that you should restrict your position, in this
context, to that of a member of the IPSEC working group.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
It has recently been discovered that research causes cancer in rats.
Received: from relay.tis.com by neptune.TIS.COM id aa12896; 19 Mar 96 13:07 EST
Received: by relay.tis.com; id NAA14630; Tue, 19 Mar 1996 13:09:15 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma014616; Tue, 19 Mar 96 13:08:47 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA18513; Tue, 19 Mar 96 13:07:41 EST
Received: by relay.tis.com; id NAA14609; Tue, 19 Mar 1996 13:08:46 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma014605; Tue, 19 Mar 96 13:08:45 -0500
Received: from optima.CS.Arizona.EDU by interlock.ans.net with SMTP id AA23988
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Tue, 19 Mar 1996 13:09:47 -0500
Received: from uncial.CS.Arizona.EDU by optima.cs.arizona.edu (5.65c/15) via SMTP
id AA16022; Tue, 19 Mar 1996 11:09:44 MST
Received: by uncial.CS.Arizona.EDU; (5.65/1.1.8.2/08Nov94-0446PM)
id AA17746; Tue, 19 Mar 1996 11:09:43 -0700
Date: Tue, 19 Mar 1996 11:09:43 -0700
From: Hilarie Orman <ho@cs.arizona.edu>
Message-Id: <9603191809.AA17746@uncial.CS.Arizona.EDU>
To: baldwin@rsa.com
Cc: ipsec@ans.net
In-Reply-To: Yourmessage <9602198272.AA827251852@snail.rsa.com>
Subject: Re: RC5 Performance Information
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
> 90 MHz Pentium 200 MHz DEC Alpha
> DES Encrypt 8.0 MegaBits/Sec 10.6 MegaBits/Sec
> RC5 Encrypt 26.3 MegaBits/Sec 24.5 MegaBits/Sec
I think best DES speed is closer to 18 MBits/Sec on a 200 MHz Alpha;
I'd imagine the RC5 time cannot be improved, so a 2/3 ratio is realistic
for that machine.
Received: from relay.tis.com by neptune.TIS.COM id aa13295; 19 Mar 96 13:25 EST
Received: by relay.tis.com; id NAA15291; Tue, 19 Mar 1996 13:27:31 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma015285; Tue, 19 Mar 96 13:27:04 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA19532; Tue, 19 Mar 96 13:25:57 EST
Received: by relay.tis.com; id NAA15281; Tue, 19 Mar 1996 13:27:01 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma015267; Tue, 19 Mar 96 13:26:44 -0500
Received: from pilotx.firewall.is.chrysler.com (copilot.is.chrysler.com) by interlock.ans.net with SMTP id AA24417
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Tue, 19 Mar 1996 13:27:44 -0500
Received: by pilotx.firewall.is.chrysler.com; id NAA20504; Tue, 19 Mar 1996 13:27:45 -0500
Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1)
id sma020493; Tue, 19 Mar 96 13:27:35 -0500
Received: from rgm3 (rgm3.is.chrysler.com) by clhubgw1.is.chrysler.com (5.x/SMI-4.1)
id AA24353; Tue, 19 Mar 1996 13:29:35 -0500
Message-Id: <2.2.32.19960319182544.00e26d04@pop3hub.is.chrysler.com>
X-Sender: t3125rm@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 19 Mar 1996 13:25:44 -0500
To: perry@piermont.com, baldwin (Robert W. Baldwin) <baldwin@rsa.com>
From: Robert Moskowitz <rgm3@is.chrysler.com>
Subject: Re: ESP RC5 and S/WAN
Cc: ipsec@ans.net
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
At 12:08 PM 3/19/96 -0500, Perry E. Metzger wrote:
>There is no good reason for anyone to use RSA
>DSI proprietary conventional cipher algorithms.
Hah! The money pot is big here, why shouldn't RSA get a bigger shot at it
(beyond their public key stuff).
I'm on the business side of things and I understand this. I will not deny
RSA's efforts to get more licensees. Heck, they are only following in
IBM's, TI's, Microsoft's and other's footsteps.
I do get concern when rape and pillage licensing practices are used. We
fought this a lot back in the bad-old IBM days (good old Amdahl and NEC
always there when you need them :).
I am also concerned about effects on our piece pricing. If I end up adding
$1000 cost to 8,000 Chrysler suppliers, our car retail price will go up too.
We are not a rich uncle that can be continiously touched for some loose
change. If a Pentium 90 can do DES at 8Mb/s that ain't so bad, considering
that most of our suppliers wouldn't have more than an ISDN link for some
time to come.
There are needs for SOFTWARE high speeds that might need a fast cypher (as
compared to a cheap hardware pump for a slightly slower cypher). But most
real time needs don't need to get over 4Mb/s even on LANs.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from relay.tis.com by neptune.TIS.COM id aa13371; 19 Mar 96 13:27 EST
Received: by relay.tis.com; id NAA15383; Tue, 19 Mar 1996 13:30:02 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma015371; Tue, 19 Mar 96 13:29:34 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA19673; Tue, 19 Mar 96 13:28:27 EST
Received: by relay.tis.com; id NAA15364; Tue, 19 Mar 1996 13:29:32 -0500
Received: from newdev.harvard.edu(128.103.65.15) by relay.tis.com via smap (V3.1)
id xma015349; Tue, 19 Mar 96 13:29:08 -0500
Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id NAA11381; Tue, 19 Mar 1996 13:27:25 -0500 (EST)
Date: Tue, 19 Mar 1996 13:27:25 -0500 (EST)
From: Scott Bradner <sob@newdev.harvard.edu>
Message-Id: <199603191827.NAA11381@newdev.harvard.edu>
To: fred@cisco.com, iesg@ietf.cnri.reston.va.us
Subject: Re: Your Appeal to me regarding replacing IPSEC WG Chair(s)
Cc: ipsec@TIS.COM
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Fred,
I would claim that we have not received an appeal from Bill.
The question of the clarity of an appeal cam eup during the
discussion over Dave Perkin's SMI process. 1602bis says that
---
All appeals must include a detailed and specific description of the
facts of the dispute.
---
I claim we have not received a specific message from Bill that meets
anything like these requirements. I ask that we
1/ wait for a specific detailed message
or
2/ tell Bill that he should create such a letter then wait
I talked to Bill in LA about appeals & the need to be clear and request
specific actions - so he has heard this message
Scott
Received: from relay.tis.com by neptune.TIS.COM id aa13519; 19 Mar 96 13:31 EST
Received: by relay.tis.com; id NAA15515; Tue, 19 Mar 1996 13:34:02 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma015504; Tue, 19 Mar 96 13:33:44 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA19924; Tue, 19 Mar 96 13:32:31 EST
Received: by relay.tis.com; id NAA15488; Tue, 19 Mar 1996 13:33:36 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma015458; Tue, 19 Mar 96 13:33:02 -0500
Received: from info.forthnet.gr by interlock.ans.net with SMTP id AA24579
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Tue, 19 Mar 1996 13:34:00 -0500
Received: from vicky.forthnet.gr by info.forthnet.gr via FORTHnet with SMTP;
id UAA17167 (8.6.12/FORTHNET-2.0); Tue, 19 Mar 1996 20:29:59 +0200 (EET DST)
Message-Id: <199603191829.UAA17167@info.forthnet.gr>
Organization:
To: Derrell Piper <piper@tgv.com>
Cc: ipsec@ans.net
Subject: Re: NSA denies our 3DES license
In-Reply-To: Your message of "Tue, 19 Mar 1996 07:39:08 PST."
<199603191539.HAA06195@fluffy.tgv.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <1545.827260203.1@forthnet.gr>
Date: Tue, 19 Mar 1996 20:30:04 +0200
From: "Angelos D. Keromytis" <kermit@forthnet.gr>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
In message <199603191539.HAA06195@fluffy.tgv.com>, Derrell Piper writes:
>
>RC5 is a stream cipher that allows for variable length keys. I would guess
>that RC5 using 40-bit (or less) keys would be exportable, but greater than
>40 bits would not. That's what's been done for other ciphers that employ
>variable length keys.
>
RC5 is a block cipher. RC4 is the stream cipher.
-Angelos
Received: from relay.tis.com by neptune.TIS.COM id aa14339; 19 Mar 96 13:59 EST
Received: by relay.tis.com; id OAA16421; Tue, 19 Mar 1996 14:02:02 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma016412; Tue, 19 Mar 96 14:01:34 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA21372; Tue, 19 Mar 96 14:00:27 EST
Received: by relay.tis.com; id OAA16401; Tue, 19 Mar 1996 14:01:32 -0500
Received: from stilton.cisco.com(171.69.1.161) by relay.tis.com via smap (V3.1)
id xma016378; Tue, 19 Mar 96 14:01:15 -0500
Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id LAA17014; Tue, 19 Mar 1996 11:02:04 -0800
X-Sender: fred@stilton.cisco.com
Message-Id: <v02140b5cad74afaf174d@[171.69.128.114]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 19 Mar 1996 11:02:07 -0800
To: Scott Bradner <sob@newdev.harvard.edu>
From: Fred Baker <fred@cisco.com>
Subject: Re: Your Appeal to me regarding replacing IPSEC WG Chair(s)
Cc: iesg@ietf.cnri.reston.va.us, ipsec@TIS.COM
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
At 1:27 PM 3/19/96, Scott Bradner wrote:
>I would claim that we have not received an appeal from Bill.
Would you suggest, then, that we sit tight and wait (which is most likely
to result in Bill doing nothing, and then taking some more public forum to
say that we have not responded to his appeal, whereupon we point to the
text and say that we're waiting to receive one) or that I drop him a note
that says "please forward a 1602bis compliant appeal"?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
It has recently been discovered that research causes cancer in rats.
Received: from relay.tis.com by neptune.TIS.COM id aa14580; 19 Mar 96 14:07 EST
Received: by relay.tis.com; id OAA16585; Tue, 19 Mar 1996 14:10:02 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma016578; Tue, 19 Mar 96 14:09:35 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA21801; Tue, 19 Mar 96 14:08:28 EST
Received: by relay.tis.com; id OAA16564; Tue, 19 Mar 1996 14:09:32 -0500
Received: from stilton.cisco.com(171.69.1.161) by relay.tis.com via smap (V3.1)
id xma016553; Tue, 19 Mar 96 14:09:17 -0500
Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id LAA18128; Tue, 19 Mar 1996 11:10:19 -0800
X-Sender: fred@stilton.cisco.com
Message-Id: <v02140b5fad74b5ea8e00@[171.69.128.114]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 19 Mar 1996 11:10:22 -0800
To: ipsec@TIS.COM
From: Fred Baker <fred@cisco.com>
Subject: Re: Your Appeal to me regarding replacing IPSEC WG Chair(s)
Cc: iesg@ietf.cnri.reston.va.us
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
It has been pointed out to me that I mis-edited the CC line, and the
preceeding discussion has therefore not been among the IESG. You will, I
trust, forgive the error, which is mine.
Having said which, the statements made are true: Jeff's comments to Bill do
in fact represent the current consensus of the IESG. And, Bill has not made
a formal further appeal in the sense described by RFC 1602bis.
My suggestion is that if Bill would like to make such an appeal, he should
refer to the draft and make a formal appeal, and we will consider it.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
It has recently been discovered that research causes cancer in rats.
Received: from relay.tis.com by neptune.TIS.COM id aa15142; 19 Mar 96 14:27 EST
Received: by relay.tis.com; id OAA17107; Tue, 19 Mar 1996 14:29:54 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma017101; Tue, 19 Mar 96 14:29:28 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA22812; Tue, 19 Mar 96 14:28:19 EST
Received: by relay.tis.com; id OAA17095; Tue, 19 Mar 1996 14:29:24 -0500
Received: from newdev.harvard.edu(128.103.65.15) by relay.tis.com via smap (V3.1)
id xma017060; Tue, 19 Mar 96 14:28:49 -0500
Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id OAA11777; Tue, 19 Mar 1996 14:28:20 -0500 (EST)
Date: Tue, 19 Mar 1996 14:28:20 -0500 (EST)
From: Scott Bradner <sob@newdev.harvard.edu>
Message-Id: <199603191928.OAA11777@newdev.harvard.edu>
To: fred@cisco.com, sob@newdev.harvard.edu
Subject: Re: Your Appeal to me regarding replacing IPSEC WG Chair(s)
Cc: iesg@ietf.cnri.reston.va.us, ipsec@TIS.COM
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
I would suggest someone (I'll be happy to do so) sending Bill
a note requesting a clear appeal if he intends to appeal
Scott
Received: from relay.tis.com by neptune.TIS.COM id aa16285; 19 Mar 96 15:12 EST
Received: by relay.tis.com; id PAA18197; Tue, 19 Mar 1996 15:14:24 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma018187; Tue, 19 Mar 96 15:13:59 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA26128; Tue, 19 Mar 96 15:12:49 EST
Received: by relay.tis.com; id PAA18180; Tue, 19 Mar 1996 15:13:54 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma018177; Tue, 19 Mar 96 15:13:53 -0500
Received: from eagle1.raptor.com (raptor.com) by interlock.ans.net with SMTP id AA27559
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Tue, 19 Mar 1996 15:14:51 -0500
Received: from raptor1.raptor.com ([204.7.242.10]) by eagle1.raptor.com
via smtpd (for interlock.ans.net [147.225.5.2]) with SMTP; 19 Mar 1996 20:14:37 UT
Received: from Joe_Tardo.raptor.com (pool031.Max4.San-Francisco.CA.DYNIP.ALTER.NET [153.37.101.31]) by raptor1.raptor.com (8.7.3/8.7.3) with SMTP id PAA07795; Tue, 19 Mar 1996 15:13:29 -0500 (EST)
Message-Id: <2.2.32.19960319200830.00690738@204.7.242.10>
X-Sender: jtardo@204.7.242.10
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 19 Mar 1996 12:08:30 -0800
To: Hilarie Orman <ho@cs.arizona.edu>
From: Joe Tardo <tardo@raptor.com>
Subject: Re: RC5 Performance Information
Cc: ipsec@ans.net
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
At 11:09 AM 3/19/96 -0700, Hilarie Orman wrote:
>> 90 MHz Pentium 200 MHz DEC Alpha
>> DES Encrypt 8.0 MegaBits/Sec 10.6 MegaBits/Sec
>> RC5 Encrypt 26.3 MegaBits/Sec 24.5 MegaBits/Sec
>
>I think best DES speed is closer to 18 MBits/Sec on a 200 MHz Alpha;
>I'd imagine the RC5 time cannot be improved, so a 2/3 ratio is realistic
>for that machine.
>
So the Alpha does DES 2.5 times faster but RC5 slower? Explain, please.
Received: from relay.tis.com by neptune.TIS.COM id aa19063; 19 Mar 96 17:26 EST
Received: by relay.tis.com; id RAA21140; Tue, 19 Mar 1996 17:29:04 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma021136; Tue, 19 Mar 96 17:28:36 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA02886; Tue, 19 Mar 96 17:27:29 EST
Received: by relay.tis.com; id RAA21131; Tue, 19 Mar 1996 17:28:34 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma021127; Tue, 19 Mar 96 17:28:31 -0500
Received: from theory.lcs.mit.edu by interlock.ans.net with SMTP id AA01901
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Tue, 19 Mar 1996 17:29:22 -0500
Received: from swan.lcs.mit.edu by theory.lcs.mit.edu (5.65c/TOC-1.2S)
id AA11790; Tue, 19 Mar 96 17:29:19 EST
From: Ron Rivest <rivest@theory.lcs.mit.edu>
Received: by swan.lcs.mit.edu (5.65c/TOC-1.2C)
id AA27646; Tue, 19 Mar 96 17:29:18 EST
Date: Tue, 19 Mar 96 17:29:18 EST
Message-Id: <199603192229.AA27646@swan.lcs.mit.edu>
To: ipsec@ans.net
Subject: RC5 paper available on the Web
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Since there has been some inquiry here about RC5, I'd like to note that
my original paper describing RC5 is available on the Web in postscript.
You can find it from my publications page. My home page is
http://theory.lcs.mit.edu/~rivest
Cheers,
Ron Rivest
Received: from relay.tis.com by neptune.TIS.COM id aa19592; 19 Mar 96 17:52 EST
Received: by relay.tis.com; id RAA21471; Tue, 19 Mar 1996 17:54:34 -0500
From: stroh@vnet.ibm.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma021469; Tue, 19 Mar 96 17:54:05 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA03580; Tue, 19 Mar 96 17:52:58 EST
Received: by relay.tis.com; id RAA21466; Tue, 19 Mar 1996 17:54:04 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma021464; Tue, 19 Mar 96 17:54:02 -0500
Received: from vnet.ibm.com by interlock.ans.net with SMTP id AA02627
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Tue, 19 Mar 1996 17:54:56 -0500
Message-Id: <199603192254.AA02627@interlock.ans.net>
Received: from AUSVM6 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 8561;
Tue, 19 Mar 96 17:54:34 EST
Date: Tue, 19 Mar 96 16:51:07 CST
To: ipsec@ans.net
Subject: rc5 perf and rotates
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Bill Sommerfeld <sommerfeld@apollo.hp.com> writes
>> So on the "variable shifts are efficient" front:
>>
>> yes: HP, IBM, DEC, Intel
>> no: Sun, SGI..
I would label your lists "yes" and "maybe". If the SPARC and MIPS
implementations use barrel shifters, I still claim its only a couple extra
cycles that might even be buried.
...
>> Of course, if the algorithm isn't secure, who cares how fast it is..
Right.
Who cares if a rotate is fast in an absolute sense? - the question is how
fast is the operation versus the operations needed for its cryptanalytic
inverse, i.e. its one-way-ness, compared to the alternative. Presumably the
crypto paper cited is well reasoned, I'll look it up.
If so then they do not depend on the claim that modern processors are
slow to rotate in an absolute cycle count sense, which is the claim I dispute.
I will need some convincing that algorithms incorporating rotates are inferior
in cryptographic efficiency to those excluding them. Rotates would seem to
be the best way of achieving information diffusion between bit positions (sub
modulo 8) without loss of information. Averaging over all possible shift counts,
shifts only move half as much information between bit positions as rotates. The
other ALU operations alone are much slower to diffuse information between bit
positions (other than adjacent ones).
>>
>> - Bill
Nice analysis.
...
>> *I was under the impression that the pentium had a barrel shifter,
>> though the 486 didn't, but I may be wrong...
You are right, I was mistaken, good catch. Although the RCL/RCR (rotate through
carry) variable count instructions take 7-27 clocks, the ROL/ROR variable count
instructions take a constant 4. Which only reinforces our point.
regards,
Oscar Strohacker
Advisory Engineer/Scientist
Data Compression Systems Architecture
IBM Microelectronics Division
11400 Burnet Road
Austin Texas 78758
o (512) 838-4077 f (512) 838-7004 Internet: stroh @ vnet.ibm.com
Received: from relay.tis.com by neptune.TIS.COM id aa20712; 19 Mar 96 18:54 EST
Received: by relay.tis.com; id SAA22171; Tue, 19 Mar 1996 18:56:06 -0500
From: touch@isi.edu
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma022169; Tue, 19 Mar 96 18:55:38 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA04997; Tue, 19 Mar 96 18:54:31 EST
Received: by relay.tis.com; id SAA22164; Tue, 19 Mar 1996 18:55:36 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma022160; Tue, 19 Mar 96 18:55:28 -0500
Received: from venera.isi.edu by interlock.ans.net with SMTP id AA03985
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Tue, 19 Mar 1996 18:56:29 -0500
Received: from ash-s.isi.edu (ash-a.isi.edu) by venera.isi.edu (5.65c/5.61+local-22)
id <AA23091>; Tue, 19 Mar 1996 15:56:19 -0800
Date: Tue, 19 Mar 1996 15:52:47 -0800
Posted-Date: Tue, 19 Mar 1996 15:52:47 -0800
Message-Id: <199603192352.AA07889@ash-s.isi.edu>
Received: by ash-s.isi.edu (5.65c/4.0.3-4)
id <AA07889>; Tue, 19 Mar 1996 15:52:47 -0800
To: ipsec@ans.net, stroh@vnet.ibm.com
Subject: Re: rc5 perf and rotates
Cc: touch@isi.edu
X-Auto-Sig-Adder-By: faber@isi.edu
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
> From: stroh@vnet.ibm.com
> Date: Tue, 19 Mar 96 16:51:07 CST
> To: ipsec@ans.net
> Subject: rc5 perf and rotates
>
> Bill Sommerfeld <sommerfeld@apollo.hp.com> writes
>
> >> So on the "variable shifts are efficient" front:
> >>
> >> yes: HP, IBM, DEC, Intel
> >> no: Sun, SGI..
>
> I would label your lists "yes" and "maybe". If the SPARC and MIPS
> implementations use barrel shifters, I still claim its only a couple extra
> cycles that might even be buried.
They will not get buried if they are in the critical path, which
they appear to be. That couple of cycles multiplies by 24 (2 rotates
per round, 12 rounds).
> Who cares if a rotate is fast in an absolute sense? - the question is how
I do. I run IP at 150 Mbps, and would like to run _some_ security
that can keep pace.
> I will need some convincing that algorithms incorporating rotates are inferior
> in cryptographic efficiency to those excluding them. Rotates would seem to
> be the best way of achieving information diffusion between bit positions (sub
> modulo 8) without loss of information. Averaging over all possible shift counts,
Table lookups might be an alternative, especially if the table is small.
Joe
----------------------------------------------------------------------
Joe Touch - touch@isi.edu http://www.isi.edu/~touch/
ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/
USC / Research Assistant Prof. http://www.isi.edu/lsam/
Received: from relay.tis.com by neptune.TIS.COM id aa20965; 19 Mar 96 19:01 EST
Received: by relay.tis.com; id TAA22294; Tue, 19 Mar 1996 19:04:06 -0500
From: smb@research.att.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma022292; Tue, 19 Mar 96 19:03:37 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA05178; Tue, 19 Mar 96 19:02:31 EST
Received: by relay.tis.com; id TAA22289; Tue, 19 Mar 1996 19:03:36 -0500
Message-Id: <199603200003.TAA22289@relay.tis.com>
Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1)
id xma022287; Tue, 19 Mar 96 19:03:27 -0500
Received: from research.att.com by ns; Tue Mar 19 19:01:41 EST 1996
Received: from gryphon by research; Tue Mar 19 19:00:50 EST 1996
Received: by gryphon; Tue Mar 19 19:00:48 EST 1996
To: ipsec@TIS.COM
Subject: draft paper available
Date: Tue, 19 Mar 96 19:00:47 EST
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Folks on this list may be interested in a draft of a new paper of mine
entitled ``Problem Areas for the IP Security Protocols''. It outlines
some of the older attacks we've been discussing, plus a few new ones.
Here's the abstract:
The Internet Engineering Task Force (IETF) is in the process of
adopting standards for IP-layer encryption and authentication
(IPSEC). We describe a number of attacks against various
versions of these protocols, including confidentiality failures
and authentication failures. The implications of these attacks
are troubling for the utility of this entire effort.
The paper can be picked up from ftp://ftp.research.att.com/dist/smb/badesp.ps.
Received: from relay.tis.com by neptune.TIS.COM id aa23828; 19 Mar 96 21:24 EST
Received: by relay.tis.com; id VAA23691; Tue, 19 Mar 1996 21:26:06 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma023685; Tue, 19 Mar 96 21:25:38 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA07864; Tue, 19 Mar 96 21:24:31 EST
Received: by relay.tis.com; id VAA23677; Tue, 19 Mar 1996 21:25:36 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma023671; Tue, 19 Mar 96 21:25:21 -0500
Received: from volitans.MorningStar.Com by interlock.ans.net with SMTP id AA06080
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Tue, 19 Mar 1996 21:26:02 -0500
Received: from gefilte.MorningStar.Com by volitans.MorningStar.Com (8.7.1/95070701)
id CAA26207; Wed, 20 Mar 1996 02:26:01 GMT
From: Karl Fox <karl@morningstar.com>
Received: by gefilte.MorningStar.Com (5.65a/94012401)
id AA09602; Tue, 19 Mar 96 21:26:00 -0500
Date: Tue, 19 Mar 96 21:26:00 -0500
Message-Id: <9603200226.AA09602@gefilte.MorningStar.Com>
To: stroh@vnet.ibm.com
Cc: ipsec@ans.net
Subject: rc5 perf and rotates
In-Reply-To: <199603192254.AA02627@interlock.ans.net>
References: <199603192254.AA02627@interlock.ans.net>
Reply-To: Karl Fox <karl@morningstar.com>
Organization: Morning Star Technologies, Inc.
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
stroh@vnet.ibm.com writes:
> Who cares if a rotate is fast in an absolute sense?
I would, if I were using RC5 on a machine without a barrel shifter and
I were concerned about timing attacks.
--
Karl Fox, servant of God, employee of Morning Star Technologies
3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 451 1883
Received: from relay.tis.com by neptune.TIS.COM id aa10496; 20 Mar 96 13:37 EST
Received: by relay.tis.com; id NAA06979; Wed, 20 Mar 1996 13:39:36 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma006970; Wed, 20 Mar 96 13:39:08 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA08086; Wed, 20 Mar 96 13:38:01 EST
Received: by relay.tis.com; id NAA06967; Wed, 20 Mar 1996 13:39:06 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma006962; Wed, 20 Mar 96 13:38:50 -0500
Received: from RSA.COM by interlock.ans.net with SMTP id AA23770
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Wed, 20 Mar 1996 13:39:46 -0500
Received: from snail.rsa.com by RSA.COM with SMTP
id AA21071; Wed, 20 Mar 96 10:28:58 PST
Received: from cc:Mail by snail.rsa.com
id AA827347185; Wed, 20 Mar 96 10:39:02 PST
Date: Wed, 20 Mar 96 10:39:02 PST
From: baldwin <baldwin@rsa.com>
Message-Id: <9602208273.AA827347185@snail.rsa.com>
To: Karl Fox <karl@morningstar.com>, ipsec@ans.net
Subject: RC5 and timing attacks
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Karl,
The way we avoid timing attacks on RC5 is to make sure that
our implementation runs in constant time. The methods are:
1) Using a fixed-time rotate instruction if the CPU has one, or
2) Performing rotation by two shift and mask operations that
together take a fixed amount of time (e.g., rotate right three
positions is implemented as a shift right 3 that takes 3 cycles
and a shift left 29 (= 32 - 3) that takes 29 cycles for a
constant total of 32 cycles.
3) Other tricks are possible on CPUs that perform shifts in
variable time (e.g., shift one and shift eight may both take
one cycle, but shift two takes two cycles).
One of the reasons for buying the BSAFE 3.0 crypto toolkit
is to make sure these are done right on each platform. OK, I
know that was a product plug, but I couldn't resist :-).
--Bob
______________________________ Reply Separator _________________________________
Subject: rc5 perf and rotates
Author: Karl Fox <karl@morningstar.com> at INTERNET
Date: 3/19/96 9:26 PM
stroh@vnet.ibm.com writes:
> Who cares if a rotate is fast in an absolute sense?
I would, if I were using RC5 on a machine without a barrel shifter and
I were concerned about timing attacks.
--
Karl Fox, servant of God, employee of Morning Star Technologies
3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 451 1883
Received: from relay.tis.com by neptune.TIS.COM id aa27699; 22 Mar 96 11:25 EST
Received: by relay.tis.com; id LAA15645; Fri, 22 Mar 1996 11:27:40 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma015637; Fri, 22 Mar 96 11:27:12 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA06445; Fri, 22 Mar 96 11:26:05 EST
Received: by relay.tis.com; id LAA15627; Fri, 22 Mar 1996 11:27:10 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma015615; Fri, 22 Mar 96 11:26:41 -0500
Received: from bnr.ca (x400gate.bnr.ca) by interlock.ans.net with SMTP id AA19070
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Fri, 22 Mar 1996 11:27:41 -0500
X400-Received:
by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 22 Mar 1996 10:46:11 -0500
X400-Received:
by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 22 Mar 1996 10:46:01 -0500
X400-Received:
by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 22 Mar 1996 10:46:00 -0500
X400-Received:
by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 22 Mar 1996 10:46:00 -0500
Date: Fri, 22 Mar 1996 10:46:00 -0500
X400-Originator: mleech@bcarh6dc.ott.bnr.ca
X400-Mts-Identifier:
[/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;<199603221546.AA242249560@bcarh6]
X400-Content-Type: P2-1984 (2)
Content-Identifier: SMBs "Problem...
From: "marcus (m.d.) leech" <mleech@bnr.ca>
Message-Id: <199603221546.AA242249560@bcarh6dc.ott.bnr.ca>
To: ipsec@ans.net
Subject: SMBs "Problem Areas for the IP Security Protocols"--where do we go
from here?
Organization: Nortel Technologies, System Security Services
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2364
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
Having read Steve Bellovins thoughtful paper, I'm not as depressed as I
could be.
Some things become clear after reading the paper:
If you care about confidentiality, then you must also care about
integrity/authenticity.
Replay is definitely a problem, particularly in light of UDP socket re-use.
Because of this, replay protection would need to be built into all three
of AH only, ESP only, AH+ESP.
It's likely that a combined ESP transform that provides all three of:
Confidentiality
Integrity/Authenticity
Replay protection
Would be a useful thing for us to do as a WG. Jim Hughes' document
is almost there, except for unkeyed MD5.
Bill Simpson has an all-in-one document that, at least superficially,
seems OK. I haven't seen any discussion of his document, I suspect due
to censure by the WG chairs.
Ran had said that Photuris, as it stands now, does not address all of the
requirements of a key-management protocol for endorsement by the
IETF. I'd Ran to review his perceptions of what those requirements are.
I know that I'm no longer clear on what the "hard" requirements are,
and I believe that there is some confusion about those requirements.
In view of Steve Bellovins recent paper, a new requirement has emerged of
a "special case" of rapid-rekey in that a block of SPIs (and associated
keying material) could potentially be negotiated in a single key management
exchange. This seems to me to be a useful model to investigate; particularly
in those situations where a given host may need to rapidly establish
security associations to a number of other hosts, but security requirements
indicate that per-connection/session keying is desirable.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQBVAwUBMVLLNap9EtiCAjydAQEZvAH9GcI7zjTwTpxzPFUlztyqsYma5S6DaozP
rPoU2pc5voD44NpNmWn055W5WSty37KFQCon+eH9tdE6tNfkzAlYQQ==
=+NA0
-----END PGP SIGNATURE-----
--
----------------------------------------------------------------------
Marcus Leech Mail: Dept 4C16, MS 238, CAR
Systems Security Architect Phone : (ESN) 395-4901 (613) 763-9145
Systems Security Services Fax : (ESN) 393-7679 (613) 763-7679
Nortel Technologies mleech@bnr.ca
-----------------Expressed opinions are my own, not my employers------
Received: from relay.tis.com by neptune.TIS.COM id aa01583; 22 Mar 96 14:46 EST
Received: by relay.tis.com; id OAA19838; Fri, 22 Mar 1996 14:48:54 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma019824; Fri, 22 Mar 96 14:48:25 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA21381; Fri, 22 Mar 96 14:47:18 EST
Received: by relay.tis.com; id OAA19818; Fri, 22 Mar 1996 14:48:24 -0500
Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1)
id xma019815; Fri, 22 Mar 96 14:48:19 -0500
Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id LAA05739 for ipsec@tis.com; Fri, 22 Mar 1996 11:49:22 -0800
Date: Fri, 22 Mar 1996 11:49:22 -0800
From: Ran Atkinson <rja@cisco.com>
Message-Id: <199603221949.LAA05739@puli.cisco.com>
To: ipsec@TIS.COM
Subject: Request for Implementation Status
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
All,
This is the draft revised IETF IPsec WG's Implementation Status
"template". Suggestions on new data fields or revised structure should be
sent to me and Paul via private email.
If you have an implementation of any portion of the IETF IPsec
specifications and are willing to let this be known in public, please fill
this in and email it to me for consolidation into the master list.
I expect to post a revised summary in a few days time.
Folks who were listed in previous summaries have already been sent
a ping by me and so can safely ignore this note.
Suggested answers are in parenthesis ready for you to edit.
Thanks,
Randall Atkinson <rja@cisco.com>
Co-Chair, IPsec WG, IETF
______________________________________________________________________
Name of Implementation: (name of your implementation/product)
Organisation: (name of your organisation)
Which IP versions are supported: (IPv4, IPv6, or IPv4 and IPv6)
Implements RFC-1825 & RFC-1826 AH: (YES, NO, In Progress, Planned, Partial)
Implements RFC-1825 & RFC-1827 ESP: (YES, NO, In Progress, Planned, Partial)
Implements RFC-1828 AH MD5: (YES, NO, In Progress, Planned, Partial)
Implements RFC-1829 ESP DES-CBC:(YES, NO, In Progress, Planned, Partial)
Other AH Implemented Transforms: (none, AH-HMAC-MD5, AH-SHA,
proprietary)
Other ESP Implemented Transforms: (none, ESP-3DES, ESP-RC4, ESP-RC5,
ESP-DES-MD5-Replay, proprietary)
Key Management: (manual, ISAKMP, ISAKMP+Oakley, Oakley, Photuris,
SKIP, proprietary)
Platforms: (4.4-Lite BSD, Solaris, IRIX, <product name>,
STREAMS, LINUX, etc)
Lineage of IPsec Code: (<name of your organisation>, ETHZ, JI, KA9Q,
NIST, NRL, SUN, not applicable)
Lineage of Key Mgmt Code: (<name of your organisation>, SUN, ETHZ, JI,
cisco, not applicable)
Location of Source Code: (provide URL if freely available, use the word
"proprietary" if isn't freely available)
Point of Contact: (email address, optionally also phone/fax/name)
Claimed Interoperability: (list of systems that your implementation fully
interoperates with)
_______________________________________________________________________
Received: from relay.tis.com by neptune.TIS.COM id aa01950; 22 Mar 96 14:56 EST
Received: by relay.tis.com; id OAA20113; Fri, 22 Mar 1996 14:58:55 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma020096; Fri, 22 Mar 96 14:58:26 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA22494; Fri, 22 Mar 96 14:57:19 EST
Received: by relay.tis.com; id OAA20089; Fri, 22 Mar 1996 14:58:24 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma020083; Fri, 22 Mar 96 14:58:19 -0500
Received: from relay.hp.com by interlock.ans.net with SMTP id AA25408
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Fri, 22 Mar 1996 14:59:17 -0500
Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP
(1.37.109.16/15.5+ECS 3.3) id AA094134753; Fri, 22 Mar 1996 11:59:14 -0800
Message-Id: <199603221959.AA094134753@relay.hp.com>
Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com
id AA119165047; Fri, 22 Mar 1996 15:04:07 -0500
X-Mailer: exmh version 1.6.2 7/18/95
To: "marcus (m.d.) leech" <mleech@bnr.ca>
Cc: ipsec@ans.net
Subject: Re: SMBs "Problem Areas for the IP Security Protocols"--where do we
go from here?
In-Reply-To: mleech's message of Fri, 22 Mar 1996 10:46:00 -0500.
<199603221546.AA242249560@bcarh6dc.ott.bnr.ca>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Fri, 22 Mar 1996 14:59:11 -0500
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
content-type: text/plain; charset=us-ascii
I saw at least one other important observation of Steve's:
The IP layer deals with one-way datagrams, but just about anything
non-trivial above the IP layer involves two-way communication at some
point (Ok, the mbone broadcasts of NASA select are one-way, but that's
an exception..), and it's important to correctly associate a message
with its reply.
therefore, there must be some facility in the key management protocol
to allow SPI's to be "paired", so that an "incoming SPI" can be
associated with a "outgoing SPI", with the result that replies to
incoming traffic received using the incoming SPI are sent using the
outgoing SPI.
I'm not quite sure how this generalizes to multicast traffic.
- Bill
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMVMGg1pj/0M1dMJ/AQEHlQP9GdOZzCRv9UQ85lyLM2OL9SOPYNH0co97
8M7+5la6TV9ZCfqoeyUjY+iG+Qib4v36quFbmq2pqHo7tY5XxOPDXVdSvz4aa8eJ
BT8ly7J+aqDN1Ed0UddyXUA4S58PlQJKb/pSIH2Ju0w2xSE5n2RlkhTqfsj8FKim
5Pk0sWYmqPE=
=0NLi
-----END PGP SIGNATURE-----
Received: from relay.tis.com by neptune.TIS.COM id aa02125; 22 Mar 96 15:01 EST
Received: by relay.tis.com; id PAA20229; Fri, 22 Mar 1996 15:03:24 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma020219; Fri, 22 Mar 96 15:02:57 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA22986; Fri, 22 Mar 96 15:01:49 EST
Received: by relay.tis.com; id PAA20210; Fri, 22 Mar 1996 15:02:54 -0500
Received: from unknown(192.86.155.81) by relay.tis.com via smap (V3.1)
id xma020191; Fri, 22 Mar 96 15:02:23 -0500
Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7)
id LAA04364; Fri, 22 Mar 1996 11:54:57 -0800
Received: by mailsun2.us.oracle.com (8.7.1/37.8)
id LAA09305; Fri, 22 Mar 1996 11:57:27 -0800 (PST)
Message-Id: <199603221957.LAA09305@mailsun2.us.oracle.com>
Date: 22 Mar 96 11:48:34 -0800
From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>
To: ipsec@TIS.COM
Subject: IPsec Implementation Survey - March 22
Cc: swan-dev@rsa.com
Mime-Version: 1.0
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Minor errors (like the mailing list address) and one addition to the ipsec
implementation survey are attached below.
Paul
--------------
The following 18 individuals and vendors have responded to the IPSEC
implementation survey.
ERPIPSEC
ETHZ / ENskip
GTFW-GD
IBM
JI
KA9Q NOS
Morning Star
Network Systems
NIST/NSA
NRL
Raptor Systems
Sidewinder
Sun ICG
TimeStep PERMIT
TIS Gauntlet
USC/ISI
V-ONE SmartWall
The results of this survey (as of March 22, 1996) are provided below. Please
submit any updates or new entries to the ipsec mailing list (ipsec@tis.com)
Paul A. Lambert
IPsec Co-Chair
_______________________________________________________________________
Name of Implementation: ERPIPSEC, BELLCORE, Antonio Fernandez
Security Protocols: ESP, AH
Security Transforms: ESP-DES, AH-MD5_128,64,32
Key Management: manual
Location of Source Code: proprietary
Point of Contact: Antonio Fernandez,
afa@bellcore.com
_______________________________________________________________________
Name of Implementation: ETHZ / ENskip
Security Protocols: SKIP (draft 6), limited AH & ESP (SPI=1)
Security Transforms: ESP-DES, ESP-3DES, ESP-IDEA, ESP-RC4, AH-MD5
(some of these transforms are
not yet standarized)
Key Management: only via SKIP, (manual, X.509 and
'DH public value' keying).
(plus non-standardized PFS)
Lineage of Code: Works under Solaris 2.4+, IRIX, NetBSD, Nextstep.
Location of Source Code: ftp://ftp.tik.ee.ethz.ch/pub/packages/skip
(X.509 and PFS not yet publicly available)
Point of Contact: skip@tik.ee.ethz.ch
_______________________________________________________________________
Name of Implementation: Gemini Trusted Security Firewall-Guard (GTFW-GD)
Security Protocols: 1. IPSec (ESP,AH): Public-Private
2. IPCSO & IPSec: Private-Private
(IP Crypto-Seal Option)
(Integrity, Authentication, Confidentiality)
Security Transforms: DES, Key MD5, Trusted Crypto-Seals
Key Management: 1. Manual for Trusted Public-Private Internetwork
2. A1 Trusted Distribution Key Management Extended
for Trusted Private-Private Internetwork
3. Customized
Lineage of Code: 1. Trusted Software
2. Platform: GTFW-GD on Gemini Trusted Network
Processor with Integrated Encryption
certified at Class A1
Location of Source Code: Proprietary
Point of Contact: Dr. Tien F. Tao, tft@main.geminisecure.com
_______________________________________________________________________
Name of Implementation: IBM
Security Protocols: ESP, AH, both tunnel and transport mode
Security Transforms: ESP-DES (32-bit and 64-bit IV), keyed-MD5,
new keyed-MD5 proposed by Hugo
Key Management : Manual+Fast Key Refreshment>,
SKEME (in progress), Photuris (in Progress)
Lineage of Code: IBM Proprietary, about 10k to 15K lines
(rough estimate, including ESP,
AH, and Key Management).
Location of Source Code: Proprietary
Point of Contact: pau@yktvmv.vnet.ibm.com
_______________________________________________________________________
Name of Implementation: JI
Security Protocols: ESP, AH, Protocol-4 encapsultation
Security Transforms: ESP-DES, AH-MD5
Key Management: manual, Photuris; PF_ENCAP keying i/f,
PF_ROUTE extensionsl
Lineage of Code: Written from scratch,
entirely in Greece, for BSD/OS 2.0,
Location of Source Code: ji's home machine
The promised end-January-96 release
is not ready yet; it should be (freely) available
from ftp.ripe.net RSN.
Point of Contact: ji@hol.gr
_______________________________________________________________________
Name of Implementation: KA9Q NOS
Security Protocols: ESP, AH
Security Transforms: ESP-DES & ESP-DES3, each with 0,32 and 64-bit IVs;
keyed MD5
Key Management: manual
Lineage of Code: scratch
Location of Source Code: Not yet released. Will release soon,
modulo export rules
Point of Contact: karn@unix.ka9q.ampr.org
________________________________________________________________________
Name of Implementation: Morning Star SecureConnect
Security Protocols: ESP, AH
Security Transforms: ESP-DES, AH-MD5
Key Management: manual
Lineage of Code: scratch
Location of Source Code: proprietary
Point of Contact: Karl Fox
<karl@morningstar.com>
_______________________________________________________________________
Name of Implementation: Network Systems BorderGuard and Security Router
Security Protocols: Proprietary
Security Transforms: Des, Idea, 3DES, NSC1 (proprietary),
MD5, Replay, D-H and RSA
Key Management: Proprietary
Lineage of Code: scratch
Location of Source Code: proprietary
Point of Contact: Ted Doty
<ted@kgbvax.network.com>
_______________________________________________________________________
Name of Implementation: NIST/NSA ESP/AH Implementation
Security Protocols: ESP, AH
Security Transforms: ESP-DES, AH-MD5, AH-SHA, and various others
Key Management: manual, PF_SADB interface
for key management daemons
Lineage of Code: derived from BSD platforms.
Successful installation on
BSD/OS, NetBSD, FreeBSD, and DTOS
Location of Source Code: Public distribution within the US
expected March 1996.
Point of Contact: glenn@snad.ncsl.nist.gov
________________________________________________________________________
Name of Implementation: NRL
Security Protocols: ESP, AH -- for BOTH IPv4 and IPv6
Security Transforms: ESP-DES, AH-MD5
Key Management: manual,
PF_KEY interface for key management daemons
Lineage of Code: derived from and portable to 4.4-Lite BSD
Location of Source Code: ftp://ftp.ripe.net/ipv6/nrl/IPv6_domestic.tar.gz
for the September 1995 alpha release.
January 1996 alpha-2 release is not yet at an
ftp site, but should appear soon in the
protected "US-only" archives at ftp.c2.org.
Point of Contact: ipv6-bugs@cs.nrl.navy.mil
_______________________________________________________________________
Name of Implementation: ONNET, FTP Software, Inc.
Security Protocols: ESP, AH
Security Transforms: ESP-DES, AH-MD5
Key Management: manual
Location of Source Code: proprietary
Point of Contact: Naganand Doraswamy
naganand@ftp.com
Name of Implementation: Raptor Systems
Security Protocols: ESP, AH, both tunnel and transport modes
Security Transforms: ESP-DES (32-bit and 64-bit IV), keyed-MD5
Key Management: manual
Lineage of Code: proprietary
Location of Source Code: proprietary
Point of Contact: jkraemer@raptor.com
_______________________________________________________________________
Name of Implementation: Sun ICG
Security Protocols: ESP, AH, proprietary
Security Transforms: ESP-DES, ESP-DES3, AH/KEYED MD5
Key Management: SKIP
Lineage of Code:
Location of Source Code: http://skip.incog.com
Point of Contact: markson@incog.com
_______________________________________________________________________
Name of Implementation: Secure Computing's Sidewinder Firewall
Security Protocols: ESP, AH
Security Transforms: DES, MD5
Key Management: manual
Lineage of Code: BSD based
Location of Source Code: proprietary
Point of Contact: Troy de Jongh (dejongh@sctc.com)
_______________________________________________________________________
Name of Implementation: TimeStep PERMIT
Security Protocols: ESP, AH, proprietary
Security Transforms: ESP-DES
Key Management: proprietary, manual
Lineage of Code: from scratch
Location of Source Code: proprietary
Point of Contact: Stephane Lacelle
slacelle@timestep.com
_______________________________________________________________________
Name of Implementation: Trusted Information Systems Gauntlet
Security Protocols: ESP, AH Tunnel and Transport modes
Security Transforms: ESP-DES, ESP-3DES
Key Management: Custom, manual
Lineage of Code: NRL derived, BSD/OS
Location of Source Code: proprietary
Point of Contact: Rick Murphy, rick@tis.com
_______________________________________________________________________
Name of Implementation: USC/ISI
Security Protocols: IPv4 AH
Security Transforms: null, Internet checksum, MD5, proprietary
null and Internet checksum
for performance measurement
Key Management: Statically configured keys
implementation for performance measurement only
Lineage of Code: SunOS 4.1.3, using "from scratch" and code
adapted from the NRL IPv6 BSDI implementation
Location of Source Code: to be announced in March
Point of Contact: Joe Touch,
touch@isi.edu
_______________________________________________________________________
Name of Implementation: V-ONE SmartWall
Security Protocols: ESP, AH Tunnel and Transport modes, V-ONE
Mutual Authentication
Security Transforms: ESP-DES, ESP-3DES, RC4, Stream-DES
Key Management: Custom, manual
Lineage of Code: NRL derived, BSD/OS
Location of Source Code: proprietary
Point of Contact: Jason Wang, jswang@v-one.com
_______________________________________________________________________
---- End of Message ----
Received: from [192.94.214.100] by neptune.TIS.COM id aa03065;
22 Mar 96 15:37 EST
Received: by relay.tis.com; id PAA21115; Fri, 22 Mar 1996 15:39:01 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma021109; Fri, 22 Mar 96 15:38:34 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA26189; Fri, 22 Mar 96 15:37:26 EST
Received: by relay.tis.com; id PAA21100; Fri, 22 Mar 1996 15:38:31 -0500
Received: from optima.cs.arizona.edu(192.12.69.5) by relay.tis.com via smap (V3.1)
id xma021089; Fri, 22 Mar 96 15:38:19 -0500
Received: from avenir.cs.arizona.edu by optima.cs.arizona.edu (5.65c/15) via SMTP
id AA25708; Fri, 22 Mar 1996 13:39:19 MST
Date: Fri, 22 Mar 1996 13:39:16 MST
From: Oliver Spatscheck <spatsch@cs.arizona.edu>
Message-Id: <199603222039.AA12055@avenir.cs.arizona.edu>
Received: by avenir.cs.arizona.edu; Fri, 22 Mar 1996 13:39:16 MST
To: ipsec@TIS.COM
Subject: IPsec Implementation
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
______________________________________________________________________
Name of Implementation: IPSEC
Organisation: University of Arizona.
Which IP versions are supported: IPv4
Implements RFC-1825 & RFC-1826 AH: YES
Implements RFC-1825 & RFC-1827 ESP: YES
Implements RFC-1828 AH MD5: YES
Implements RFC-1829 ESP DES-CBC:YES
Other AH Implemented Transforms: none
Other ESP Implemented Transforms: ESP-3DES
Key Management: manual, Photuris (draft version 8) includeing elliptic curve groups.
Platforms: xKernel
Lineage of IPsec Code: University of Arizona
Lineage of Key Mgmt Code: University of Arizona
Location of Source Code: ftp://ftp.cs.arizona.edu/xkernel/xkernel.v3.2.security.tar.Z
Point of Contact: ho@cs.arizona.edu
Claimed Interoperability: KA9Q NOS (AH MD5, ESP DES-CBC), JI (Photuris, AH MD5)
_______________________________________________________________________
Oliver
- -----
Grad student and research assistant in computer science at the University of Arizona, Tucson, USA
For my PGP public key please check my homepage URL: http://www.cs.arizona.edu/people/spatsch
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMVMP8DnVPgUZ7uZJAQGdNAP+NwV40AAE4iocXYxgnvR1o8T50LMa0jXe
ptILDf/EcCyJ4sfogvHkpNsDz0ZjRVwCo0t5TVhp4dwRniTN28RAPeB2zbxt6SGC
SzZQUupgpp4H4+T78xa10puGNRjZnqTt5Mx8Yg5BoXxeGKeJEk7xRoTLE1XNWfJ/
56sbCoHZryg=
=b6+P
-----END PGP SIGNATURE-----
Received: from relay.tis.com by neptune.TIS.COM id aa04222; 22 Mar 96 16:24 EST
Received: by relay.tis.com; id QAA22214; Fri, 22 Mar 1996 16:26:31 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma022205; Fri, 22 Mar 96 16:26:03 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA29926; Fri, 22 Mar 96 16:24:56 EST
Received: by relay.tis.com; id QAA22198; Fri, 22 Mar 1996 16:26:01 -0500
Received: from arl-img-4.compuserve.com(198.4.7.4) by relay.tis.com via smap (V3.1)
id xma022175; Fri, 22 Mar 96 16:25:46 -0500
Received: by arl-img-4.compuserve.com (8.6.10/5.950515)
id QAA26834; Fri, 22 Mar 1996 16:24:24 -0500
Date: 22 Mar 96 16:23:07 EST
From: Dave Schroeder <73543.2035@compuserve.com>
To: Shelly <ipsec@TIS.COM>
Subject: We would like to participate in survey..
Message-Id: <960322212306_73543.2035_FHD19-2@CompuServe.COM>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
The following 18 individuals and vendors have responded to the IPSEC
implementation survey.
ERPIPSEC
ETHZ / ENskip
GTFW-GD
IBM
JI
KA9Q NOS
Morning Star
Network Systems
NIST/NSA
NRL
Raptor Systems
Sidewinder
Sun ICG
TimeStep PERMIT
TIS Gauntlet
USC/ISI
V-ONE SmartWall
The results of this survey (as of March 22, 1996) are provided below. Please
submit any updates or new entries to the ipsec mailing list (ipsec@tis.com)
************************************************************
Posted: 22-Mar-1996, 16:23:02 EST
From: Dave Schroeder, Director of Marketing
The Software Group Limited / USA Office
209 N. Columbia, Chapel Hill, NC 27514
Tel: 919-933-6770 Fax: 919-933-8862
daves@software.group.com Compuserve: 73543,2035
URL = http://www.group.com
************************************************************
Received: from relay.tis.com by neptune.TIS.COM id aa03822; 24 Mar 96 9:35 EST
Received: by relay.tis.com; id JAA04365; Sun, 24 Mar 1996 09:37:34 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma004363; Sun, 24 Mar 96 09:37:13 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA02120; Sun, 24 Mar 96 09:35:57 EST
Received: by relay.tis.com; id JAA04360; Sun, 24 Mar 1996 09:37:04 -0500
Received: from ktik0.ethz.ch(129.132.66.42) by relay.tis.com via smap (V3.1)
id xma004358; Sun, 24 Mar 96 09:37:01 -0500
Received: from komsys-pc-gc.ethz.ch (dynppp40.dialup.ethz.ch [192.33.93.40]) by ktik0 (8.6.8.1/8.6.6) with SMTP id PAA25447; Sun, 24 Mar 1996 15:37:32 +0100
Message-Id: <2.2.32.19960324143927.0073bb2c@ktik0.ethz.ch>
X-Sender: caronni@ktik0.ethz.ch
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 24 Mar 1996 15:39:27 +0100
To: ipsec@TIS.COM
From: Germano Caronni <caronni@tik.ee.ethz.ch>
Subject: IPSEC Key Mgmt Requirements
Cc: skip@tik.ee.ethz.ch
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Hello everybody,
some weeks ago, I asked myself: What are THE requirements of the IPSEC
working group where key management issues are concerned. After hunting the
archives, and seeing some contradictory informations, none all to clear to
me. I tried to collect them, and Paul Lambert was most helpful. (Thank you!)
Please, could you read these, and send me feedback as to which are missing,
and which are not valid anymore? I would like to have *one* document
describing the requirements of this group. If I get enough feedback, I will
try and make an updated version in about 10 days.
Requirements, first try
-----------------------
- Support AH/ESP security transforms on the IP Layer
- Support optional use of Perfect Forward Secrecy.
Mandatory to implement but optional to use.
- Support Multiple Types of Security Exchanges
What does this mean??
- Application Layer Key Management
An application that establishes a connection must be able to indicate what
keying material to use, and must be able to understand if the peer is
authenticated or not. -- I personally would like to make this optional.
Providing security on a per-host basis should be sufficient,
should it not?
- Use Public Key Techniques for Key Establishment
such as establishing a shared secret using DH, or RSA
- Support Discovery of applicable netowrk layer transforms, e.g.
finding out if ESP-DES or ESP-DES3 or AH-MD5 or ... is to be used.
- Support User Oriented Authentication Services
- Support Optional Use of Anti-Clogging Techniques
- Provide Authentication with Anonymity agains passive attackers
- Anonymous Key Establishment (key exchange with no authentication)
- Certificate Support for X.509 ??
Glossary
--------
Perfect forward secrecy: It signifies that master encryption keys are short
lived (ranging from minutes to weeks), and are (or can be) authenticated
using long lived authentication keys.
Security exchanges: I don't know. Please tell me.
Anti-Clogging: A mechanism (such as cookie exchange) to limit the
possibility of non-man-in-the-middle active attacks. Provides a weak
(non-cryptographic) authentication of the initiator of a request that is
usually computationally costly by exchanging a simple challenge-response.
Thus denies the attacker the possibility to swamp a host with requests.
Rationale
---------
Each requirement should offer a rationale why it is there. Anybody having
them at hand?
Thank you very much & friendly greetings,
Germano Caronni
Received: from relay.tis.com by neptune.TIS.COM id aa24270; 25 Mar 96 13:00 EST
Received: by relay.tis.com; id NAA14423; Mon, 25 Mar 1996 13:02:22 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma014414; Mon, 25 Mar 96 13:02:06 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA08108; Mon, 25 Mar 96 13:00:52 EST
Received: by relay.tis.com; id NAA14399; Mon, 25 Mar 1996 13:01:59 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma014390; Mon, 25 Mar 96 13:01:40 -0500
Received: from puli.cisco.com by interlock.ans.net with SMTP id AA15982
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Mon, 25 Mar 1996 13:02:32 -0500
Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id KAA19344 for ipsec@ans.net; Mon, 25 Mar 1996 10:02:09 -0800
Date: Mon, 25 Mar 1996 10:02:09 -0800
From: Ran Atkinson <rja@cisco.com>
Message-Id: <199603251802.KAA19344@puli.cisco.com>
To: ipsec@ans.net
Subject: ADMIN: Straw Poll Results on Key Mgmt
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Folks,
The key management requirements were published in the note Paul and
I sent to the IPsec list on 12 February regarding Straw Poll Results.
There ought not be a lot of mystery or confusion about them. Germano's
recent note does not seem to be entirely the same as the published
requirements. (NB: I've appended that note below in case folks didn't
save it off.)
For those new to the IETF process, the IETF does not mandate how functions
are used but it does mandate how functions are implemented. So a conforming
key management specification will mandate "implementation" of support
for the key management requirements. This does not mean that a particular
implementation of such a conforming specification is precluded from having
options or knobs to permit the user to do things somewhat differently.
Ran
rja@cisco.com
----- Begin Included Message -----
From rja Mon Feb 12 14:47:36 1996
Date: Mon, 12 Feb 1996 14:47:32 -0800
From: Ran Atkinson <rja>
Message-Id: <199602122247.OAA02865@puli.cisco.com>
To: ipsec@ans.net
Subject: ADMIN: Straw Poll Results on Key Mgmt
Content-Length: 3005
% Date: Thu, 4 Jan 1996 10:44:11 -0800
% From: Ran Atkinson <rja@cisco.com>
%
% 1) Can the IPsec WG produce multiple standards-track
% protocols for key management ?
The consensus is that multiple standards-track protocols can be produced
by the working group provided that there are significant differences
in applicability among the protocols. The most common example that
was mentioned was that multicast key distribution will probably need to
be a separate protocol than unicast key distribution.
% 2) If yes to the above, then can a protocol not conforming
% to the WG requirements for a key management protocol
% be on the IETF standards-track ?
The consensus is NO. All standards-track protocols MUST conform with
the IPsec WG requirements. As of now there are 2 main agreed-upon
requirements:
(1) Perfect Forward Secrecy (PFS) must be available to users of
the protocol that desire PFS. This means that a conforming
protocol might have a mode that provides PFS and another mode
that doesn't, for example.
(2) The key management protocol must be able to negotiate/
indicate the value of each of the components of an IPsec
Security Association (RFC-1825) with/to all of the parties to
that IPsec Security Association. Users are not necessarily
required to use all of those components, but the protocol MUST
be capable of providing that support and conforming implementations
of the protocol MUST support negotiation/indication of
all of those components.
% 3) If yes to both of the above, should the WG chairs write up a formal
% applicability statement to be accompany each standards-track
% key management protocol so that the intended use of that protocol
% is made clear?
There is overwhelming (possibly unanimous) consensus that the WG chairs
should be required to write up a formal applicability statement to accompany
each standards-track key management protocol so that the intended use of
that protocol is made clear in an RFC. Hence, the co-chairs will do this
if/when some protocol moves to standards-track RFC.
CONCLUSIONS:
(1) None of the proposals currently online appear to fully meet all
of the requirements, though it does appear that all of them could
be modified to meet all of the requirements.
(2) None of the current proposals can go to Last Call at this time
because of (1).
(3) All of the editors of the current documents should work on refining
their proposals to fully meet all of the WG requirements.
The co-chairs look forward to seeing revised proposals in LA.
In a situation like this one where the WG consensus is clear, the WG chairs
do not have any real discretion on handling matters. We are forbidden by
IETF standards process from doing anything contrary to WG consensus, so our
hands are completely tied on holding a Last Call at this time.
Paul Lambert <palamber@us.oracle.com>
Randall Atkinson <rja@inet.org>
----- End Included Message -----
Received: from relay.tis.com by neptune.TIS.COM id aa24346; 25 Mar 96 13:04 EST
Received: by relay.tis.com; id NAA14560; Mon, 25 Mar 1996 13:06:52 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma014554; Mon, 25 Mar 96 13:06:36 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA08268; Mon, 25 Mar 96 13:05:17 EST
Received: by relay.tis.com; id NAA14544; Mon, 25 Mar 1996 13:06:25 -0500
Received: from ktik0.ethz.ch(129.132.66.42) by relay.tis.com via smap (V3.1)
id xma014534; Mon, 25 Mar 96 13:06:15 -0500
Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by ktik0 (8.6.8.1/8.6.6) with ESMTP id TAA02742; Mon, 25 Mar 1996 19:01:11 +0100
From: Germano Caronni <caronni@tik.ee.ethz.ch>
Received: (caronni@localhost) by kom30.ethz.ch (8.6.8.1/8.6.6) id TAA08343; Mon, 25 Mar 1996 19:01:08 +0100
Message-Id: <199603251801.TAA08343@kom30.ethz.ch>
Subject: Re: IPSEC Key Mgmt Requirements
To: ipsec@TIS.COM
Date: Mon, 25 Mar 1996 19:01:07 +0100 (MET)
Cc: palamber@us.oracle.com, jis@mit.edu, rja@cisco.com
In-Reply-To: <199603251704.JAA16536@puli.cisco.com> from "Ran Atkinson" at Mar 25, 96 09:04:02 am
X-Mailer: ELM [version 2.4 PL24 PGP6]
Content-Type: text
Content-Length: 444
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
I have been informed that my question & proposal about Key Management
Requirements is out of order. I apologize to the group for the unneeded
mail, and am sorry for mis-stepping.
*** Everybody please ignore my previous mail. ***
I hereby retract my question & proposal. Could somebody of you please send
me the official WG requirements, as they are valid **now** ?
My excuses & thank you very much for your patience,
Germano Caronni
Received: from relay.tis.com by neptune.TIS.COM id aa27296; 25 Mar 96 15:48 EST
Received: by relay.tis.com; id PAA17660; Mon, 25 Mar 1996 15:50:47 -0500
From: gmcgreal@ire.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma017648; Mon, 25 Mar 96 15:50:24 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA18410; Mon, 25 Mar 96 15:49:10 EST
Received: by relay.tis.com; id PAA17645; Mon, 25 Mar 1996 15:50:18 -0500
Received: from uu5.psi.com(38.145.226.3) by relay.tis.com via smap (V3.1)
id xma017635; Mon, 25 Mar 96 15:49:46 -0500
Received: by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP;
id AA03633 for ; Mon, 25 Mar 96 15:33:33 -0500
Received: from cc:Mail by uu1023.ire.com
id AA827795544 Mon, 25 Mar 96 15:12:24
Date: Mon, 25 Mar 96 15:12:24
Encoding: 1223 Text
Message-Id: <9602258277.AA827795544@uu1023.ire.com>
To: ipsec@TIS.COM, Ran Atkinson <rja@cisco.com>
Subject: Re: Request for Implementation Status
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
______________________________ Reply Separator _________________________________
Name of Implementation: SafeNet Organisation: Information Resources
Engineering, Inc.
Which IP versions are supported: IPv4
Implements RFC-1825 & RFC-1826 AH: Planned
Implements RFC-1825 & RFC-1827 ESP: YES
Implements RFC-1828 AH MD5: Planned, Partial
Implements RFC-1829 ESP DES-CBC:In Progress, Partial
Other AH Implemented Transforms: none
Other ESP Implemented Transforms: ESP-DES-Counter-ANSI X9.9
Key Management: ANSI X9.17ckd, ANSI X9.57, ANSI X9.42 (in progress) SKIP (in
progess) Northern Telecom (planned)
Platforms: V.34 modem IP over PPP (SafeNet/Dial) (OS independent), Ethernet
gateway (SafeNet/LAN), Ethernet host interface (SafeNet/LAN)
Lineage of IPsec Code: Information Resources Engineering, Inc.
Lineage of Key Mgmt Code: Information Resources Engineering, Inc.
Location of Source Code: proprietary
Point of Contact: gmcgreal@ire.com 410-931-7500 FAX 410-931-7524
Claimed Interoperability: Sun (in progress), S/WAN (in progress), Northern
(planned)
_______________________________________________________________________
Received: from relay.tis.com by neptune.TIS.COM id aa02706; 25 Mar 96 22:11 EST
Received: by relay.tis.com; id WAA22714; Mon, 25 Mar 1996 22:13:46 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma022712; Mon, 25 Mar 96 22:13:17 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA28416; Mon, 25 Mar 96 22:12:09 EST
Received: by relay.tis.com; id WAA22709; Mon, 25 Mar 1996 22:13:16 -0500
Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1)
id xma022707; Mon, 25 Mar 96 22:13:03 -0500
Received: from research.att.com by ns; Mon Mar 25 22:12:06 EST 1996
Received: from smb.research.att.com by research; Mon Mar 25 22:11:24 EST 1996
Received: from smb.research.att.com (smb@localhost) by smb.research.att.com (8.6.12/8.6.10) with ESMTP id WAA04910 for <ipsec@tis.com>; Mon, 25 Mar 1996 22:11:22 -0500
Message-Id: <199603260311.WAA04910@smb.research.att.com>
X-Authentication-Warning: smb.research.att.com: smb owned process doing -bs
From: Steve Bellovin <smb@research.att.com>
To: ipsec@TIS.COM
Subject: new draft of my paper
Date: Mon, 25 Mar 1996 22:11:21 -0500
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
I normally wouldn't announce a new version of a draft paper this
soon; however, David Wagner has found a fascinating new attack
called the ``short block'' attack. It's described in Section 3.8.
The attack can recover read most user-to-host traffic on a large
class of telnet sessions (though not all), using 2^8 known plaintext
blocks and a simple active attack. This attack can be defeated if AH
is used outside of ESP, protecting the integrity of the encrypted
message (i.e., IP-AH-ESP-TCP is safe); using AH inside of ESP is not
safe.
The paper is in ftp://ftp.research.att.com/dist/smb/badesp.ps
Received: from relay.tis.com by neptune.TIS.COM id aa10537; 26 Mar 96 7:49 EST
Received: by relay.tis.com; id HAA27909; Tue, 26 Mar 1996 07:51:40 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma027905; Tue, 26 Mar 96 07:51:12 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA08215; Tue, 26 Mar 96 07:50:02 EST
Received: by relay.tis.com; id HAA27902; Tue, 26 Mar 1996 07:51:10 -0500
Received: from unknown(204.189.94.148) by relay.tis.com via smap (V3.1)
id xma027899; Tue, 26 Mar 96 07:50:44 -0500
Received: by pilotx.firewall.is.chrysler.com; id HAA16512; Tue, 26 Mar 1996 07:51:44 -0500
Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1)
id sma016504; Tue, 26 Mar 96 07:51:19 -0500
Received: from rgm3 by clhubgw1.is.chrysler.com (SMI-8.6/SMI-4.1)
id HAA23571; Tue, 26 Mar 1996 07:53:26 -0500
Message-Id: <2.2.32.19960326124754.00bc0d00@pop3hub.is.chrysler.com>
X-Sender: t3125rm@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 26 Mar 1996 07:47:54 -0500
To: Steve Bellovin <smb@research.att.com>, ipsec@TIS.COM
From: Robert Moskowitz <rgm3@is.chrysler.com>
Subject: Re: new draft of my paper
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
At 10:11 PM 3/25/96 -0500, Steve Bellovin wrote:
>I normally wouldn't announce a new version of a draft paper this
>soon; however, David Wagner has found a fascinating new attack
>called the ``short block'' attack. It's described in Section 3.8.
>The attack can recover read most user-to-host traffic on a large
>class of telnet sessions (though not all), using 2^8 known plaintext
>blocks and a simple active attack. This attack can be defeated if AH
>is used outside of ESP, protecting the integrity of the encrypted
>message (i.e., IP-AH-ESP-TCP is safe); using AH inside of ESP is not
>safe.
Excuse, please, my naivety, but to what extent would a compression before
encryption defeat known plaintext attacks? It would seem that compression
could eliminate all known plaintext unless the plaintext was so long a block
to always get compressed the same way.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from relay.tis.com by neptune.TIS.COM id aa10633; 26 Mar 96 7:56 EST
Received: by relay.tis.com; id HAA27960; Tue, 26 Mar 1996 07:58:40 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma027956; Tue, 26 Mar 96 07:58:11 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA08510; Tue, 26 Mar 96 07:57:02 EST
Received: by relay.tis.com; id HAA27953; Tue, 26 Mar 1996 07:58:10 -0500
Received: from unknown(192.20.225.4) by relay.tis.com via smap (V3.1)
id xma027951; Tue, 26 Mar 96 07:58:02 -0500
Received: from research.att.com by ns; Tue Mar 26 07:57:14 EST 1996
Received: from raptor.research.att.com by research; Tue Mar 26 07:53:49 EST 1996
Received: from roc (localhost [127.0.0.1]) by raptor.research.att.com (8.7.5/8.7) with ESMTP id HAA06625; Tue, 26 Mar 1996 07:53:49 -0500 (EST)
Message-Id: <199603261253.HAA06625@raptor.research.att.com>
To: Robert Moskowitz <rgm3@is.chrysler.com>
Cc: ipsec@TIS.COM
Subject: Re: new draft of my paper
Date: Tue, 26 Mar 1996 07:53:49 -0500
From: Steven Bellovin <smb@research.att.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
At 10:11 PM 3/25/96 -0500, Steve Bellovin wrote:
>I normally wouldn't announce a new version of a draft paper this
>soon; however, David Wagner has found a fascinating new attack
>called the ``short block'' attack. It's described in Section 3.8.
>The attack can recover read most user-to-host traffic on a large
>class of telnet sessions (though not all), using 2^8 known plaintext
>blocks and a simple active attack. This attack can be defeated if AH
>is used outside of ESP, protecting the integrity of the encrypted
>message (i.e., IP-AH-ESP-TCP is safe); using AH inside of ESP is not
>safe.
Excuse, please, my naivety, but to what extent would a compression bef
ore
encryption defeat known plaintext attacks? It would seem that compres
sion
could eliminate all known plaintext unless the plaintext was so long a
block
to always get compressed the same way.
Compression would help, but perhaps not that much -- there's still the
IP header, the compression dictionary, any incompressible sections, etc.
2^8 blocks isn't that much, and because of the way CBC works even repeated
plaintext like IP header addresses will be different each time.
Received: from relay.tis.com by neptune.TIS.COM id aa13071; 26 Mar 96 10:02 EST
Received: by relay.tis.com; id JAA29582; Tue, 26 Mar 1996 09:56:10 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma029580; Tue, 26 Mar 96 09:55:42 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA14348; Tue, 26 Mar 96 09:54:33 EST
Received: by relay.tis.com; id JAA29577; Tue, 26 Mar 1996 09:55:40 -0500
Received: from servo.qualcomm.com(129.46.128.14) by relay.tis.com via smap (V3.1)
id xma029573; Tue, 26 Mar 96 09:55:15 -0500
Received: (from karn@localhost) by servo.qualcomm.com (8.7.3/8.7.2/1.7.1) id GAA27027; Tue, 26 Mar 1996 06:56:10 -0800 (PST)
Date: Tue, 26 Mar 1996 06:56:10 -0800 (PST)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199603261456.GAA27027@servo.qualcomm.com>
To: smb@research.att.com
Cc: rgm3@is.chrysler.com, ipsec@TIS.COM
In-Reply-To: <199603261253.HAA06625@raptor.research.att.com> (message from Steven Bellovin on Tue, 26 Mar 1996 07:53:49 -0500)
Subject: Re: new draft of my paper
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
I seem to recall that I originally proposed padding with zeros, with the
receiver required to drop packets that didn't comply. My original thinking
was to provide some measure against garbage flooding, but it seems like
that also helps resist Wagner's attack.
I don't remember how the text got changed, but it's not important. The
question is, do we want to change the ESP spec re padding?
Phil
Received: from relay.tis.com by neptune.TIS.COM id aa16228; 26 Mar 96 12:51 EST
Received: by relay.tis.com; id MAA02221; Tue, 26 Mar 1996 12:53:50 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma002217; Tue, 26 Mar 96 12:53:21 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA24021; Tue, 26 Mar 96 12:52:12 EST
Received: by relay.tis.com; id MAA02211; Tue, 26 Mar 1996 12:53:20 -0500
Received: from ns.research.att.com(192.20.225.4) by relay.tis.com via smap (V3.1)
id xma002205; Tue, 26 Mar 96 12:53:02 -0500
Received: from research.att.com by ns; Tue Mar 26 12:52:08 EST 1996
Received: from raptor.research.att.com by research; Tue Mar 26 12:47:19 EST 1996
Received: from roc (loopback [127.0.0.1]) by raptor.research.att.com (8.7.5/8.7) with ESMTP id MAA11204; Tue, 26 Mar 1996 12:47:18 -0500 (EST)
Message-Id: <199603261747.MAA11204@raptor.research.att.com>
To: Phil Karn <karn@qualcomm.com>
Cc: rgm3@is.chrysler.com, ipsec@TIS.COM
Subject: Re: new draft of my paper
Date: Tue, 26 Mar 1996 12:47:18 -0500
From: Steven Bellovin <smb@research.att.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
I seem to recall that I originally proposed padding with
zeros, with the receiver required to drop packets that didn't
comply. My original thinking was to provide some measure
against garbage flooding, but it seems like that also helps
resist Wagner's attack.
Yup.
I don't remember how the text got changed, but it's not
important. The question is, do we want to change the ESP spec
re padding?
We could make that change, but I suspect that it's a palliative measure
at best. The real answer is integrity-checking, done right.
Received: from relay.tis.com by neptune.TIS.COM id aa23270; 26 Mar 96 19:40 EST
Received: by relay.tis.com; id TAA09018; Tue, 26 Mar 1996 19:42:36 -0500
From: hugo@watson.ibm.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma009006; Tue, 26 Mar 96 19:42:07 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA13236; Tue, 26 Mar 96 19:40:58 EST
Received: by relay.tis.com; id TAA09002; Tue, 26 Mar 1996 19:42:06 -0500
Message-Id: <199603270042.TAA09002@relay.tis.com>
Received: from watson.ibm.com(129.34.139.4) by relay.tis.com via smap (V3.1)
id xma008998; Tue, 26 Mar 96 19:41:51 -0500
Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 3913;
Tue, 26 Mar 96 19:41:49 EST
Date: Tue, 26 Mar 96 19:38:56 EST
To: ipsec@TIS.COM
Cc: smb@research.att.com
Subject: new draft of my paper
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Ref: Your note of Tue, 26 Mar 1996 12:47:18 -0500 (attached)
smb@research.att.com says
>
> We could make that change, but I suspect that it's a palliative measure
> at best. The real answer is integrity-checking, done right.
Bravo, bravo! Let's do it right (as decided in LA).
Hugo
Received: from relay.tis.com by neptune.TIS.COM id aa07034; 27 Mar 96 12:23 EST
Received: by relay.tis.com; id MAA20342; Wed, 27 Mar 1996 12:25:02 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma020335; Wed, 27 Mar 96 12:24:34 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA14761; Wed, 27 Mar 96 12:23:24 EST
Received: by relay.tis.com; id MAA20332; Wed, 27 Mar 1996 12:24:32 -0500
Received: from copilot.is.chrysler.com(204.189.94.148) by relay.tis.com via smap (V3.1)
id xma020320; Wed, 27 Mar 96 12:24:01 -0500
Received: by pilotx.firewall.is.chrysler.com; id MAA11640; Wed, 27 Mar 1996 12:24:41 -0500
Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1)
id sma011627; Wed, 27 Mar 96 12:24:13 -0500
Received: from rgm3 by clhubgw1.is.chrysler.com (SMI-8.6/SMI-4.1)
id MAA16027; Wed, 27 Mar 1996 12:26:19 -0500
Message-Id: <2.2.32.19960327172410.00caf354@pop3hub.is.chrysler.com>
X-Sender: t3125rm@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 27 Mar 1996 12:24:10 -0500
To: ipsec@TIS.COM
From: Robert Moskowitz <rgm3@is.chrysler.com>
Subject: PPTP ????
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Has anyone looked into this new PPTP ? That is Point-to-point Tunnel Protocol?
It is being marketed much to what many of us are working IPSec (and probably
MobileIP)....
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from relay.tis.com by neptune.TIS.COM id aa08100; 27 Mar 96 13:09 EST
Received: by relay.tis.com; id NAA20970; Wed, 27 Mar 1996 13:11:32 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma020947; Wed, 27 Mar 96 13:11:03 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA16546; Wed, 27 Mar 96 13:09:54 EST
Received: by relay.tis.com; id NAA20944; Wed, 27 Mar 1996 13:11:02 -0500
Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1)
id xma020940; Wed, 27 Mar 96 13:10:50 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id NAA02838; Wed, 27 Mar 1996 13:11:32 -0500 (EST)
Message-Id: <199603271811.NAA02838@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: Robert Moskowitz <rgm3@is.chrysler.com>
Cc: ipsec@TIS.COM
Subject: Re: PPTP ????
In-Reply-To: Your message of "Wed, 27 Mar 1996 12:24:10 EST."
<2.2.32.19960327172410.00caf354@pop3hub.is.chrysler.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Wed, 27 Mar 1996 13:11:31 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
Robert Moskowitz writes:
> Has anyone looked into this new PPTP ? That is Point-to-point
> Tunnel Protocol?
>
> It is being marketed much to what many of us are working IPSec (and probably
> MobileIP)....
Haven't heard of it. Who has done it, and where?
.pm
Received: from relay.tis.com by neptune.TIS.COM id aa08845; 27 Mar 96 13:42 EST
Received: by relay.tis.com; id NAA21498; Wed, 27 Mar 1996 13:44:32 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma021493; Wed, 27 Mar 96 13:44:04 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA18455; Wed, 27 Mar 96 13:42:54 EST
Received: by relay.tis.com; id NAA21488; Wed, 27 Mar 1996 13:44:02 -0500
Received: from unknown(199.71.190.98) by relay.tis.com via smap (V3.1)
id xma021482; Wed, 27 Mar 96 13:43:36 -0500
Received: by janus.border.com id <18433-1>; Wed, 27 Mar 1996 13:45:03 -0500
Message-Id: <96Mar27.134503est.18433-1@janus.border.com>
To: perry@piermont.com
Cc: Robert Moskowitz <rgm3@is.chrysler.com>, ipsec@TIS.COM
Subject: Re: PPTP ????
References: <199603271811.NAA02838@jekyll.piermont.com>
In-Reply-To: perry's message of "Wed, 27 Mar 1996 13:11:31 -0500".
<199603271811.NAA02838@jekyll.piermont.com>
From: "C. Harald Koch" <chk@border.com>
Organization: Border Network Technologies Inc.
Phone: +1 416 368 7157
X-Uri: <URL:http://www.border.com/homes/chk/>
Date: Wed, 27 Mar 1996 13:44:08 -0500
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
In message <199603271811.NAA02838@jekyll.piermont.com>, "Perry E. Metzger" writes:
>
> Robert Moskowitz writes:
> > Has anyone looked into this new PPTP ? That is Point-to-point
> > Tunnel Protocol?
> >
>
> Haven't heard of it. Who has done it, and where?
It's from Microsoft and a couple of terminal server people. It's PPP from a
remote dialup hub tunnelled (over IP) to your home office PPP server for
"secure remote access", i.e. user dials into local ISP; ISP relays PPP
packets directly to head-office, encapsulated inside IP; user thinks he's
got a direct PPP link to the office, but with a local telephone call.
I haven't looked closely at the spec, but I vaguely remember some sort of
encryption or authentication on the tunnel portion of the link...
A press release is at
<http://www.microsoft.com/backoffice/ntserver/pptppr.htm>
The spec is available from:
<ftp://ftp.microsoft.com/developr/drg/pptp/Pptp.doc>
and
<ftp://ftp.microsoft.com/developr/drg/pptp/PPTP.ZIP>
In Microsoft Word format, of course :-(
Naturally, any errors in this description are mine, and no doubt the result
of bugs in my wetware...
--
C. Harald Koch | Border Network Technologies Inc.
chk@border.com | Senior System Developer
+1 416 368 7157 (voice) | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8
+1 416 368 7789 (fax) | Tary: a unit of intelligence; As in "military".
Received: from relay.tis.com by neptune.TIS.COM id aa26573; 28 Mar 96 10:20 EST
Received: by relay.tis.com; id KAA07322; Thu, 28 Mar 1996 10:22:59 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma007319; Thu, 28 Mar 96 10:22:31 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA26154; Thu, 28 Mar 96 10:21:22 EST
Received: by relay.tis.com; id KAA07303; Thu, 28 Mar 1996 10:22:29 -0500
Received: from joseph.cs.berkeley.edu(128.32.37.122) by relay.tis.com via smap (V3.1)
id xma007294; Thu, 28 Mar 96 10:22:00 -0500
Received: (from daw@localhost) by joseph.cs.berkeley.edu (8.6.12/8.6.9) id HAA08984; Thu, 28 Mar 1996 07:24:23 -0800
To: ipsec@TIS.COM
Path: not-for-mail
From: David Wagner <daw@cs.berkeley.edu>
Newsgroups: isaac.lists.ipsec
Subject: Re: new draft of my paper
Date: 28 Mar 1996 07:23:56 -0800
Organization: ISAAC Group, UC Berkeley
Lines: 12
Message-Id: <4jeauc$8oc@joseph.cs.berkeley.edu>
References: <199603260311.WAA04910@smb.research.att.com>
Reply-To: daw@cs.berkeley.edu
Sender: ipsec-request@neptune.tis.com
Precedence: bulk
In article <199603260311.WAA04910@smb.research.att.com>,
Steve Bellovin <smb@research.att.com> wrote:
> I normally wouldn't announce a new version of a draft paper this
> soon; however, David Wagner has found a fascinating new attack
> called the ``short block'' attack.
I should point out that the current state of the art attack
described in his paper contains numerous significant contributions
from Steve Bellovin as well; credit where credit is due.
I thank him for his help!
-- Dave Wagner
Received: from relay.tis.com by neptune.TIS.COM id aa05281; 28 Mar 96 16:53 EST
Received: by relay.tis.com; id QAA16322; Thu, 28 Mar 1996 16:55:57 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma016315; Thu, 28 Mar 96 16:55:29 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA17188; Thu, 28 Mar 96 16:54:19 EST
Received: by relay.tis.com; id QAA16311; Thu, 28 Mar 1996 16:55:27 -0500
Received: from mail11.digital.com(192.208.46.10) by relay.tis.com via smap (V3.1)
id xma016306; Thu, 28 Mar 96 16:55:25 -0500
Received: from vanna.ljo.dec.com by mail11.digital.com (5.65v3.2/1.0/WV)
id AA31338; Thu, 28 Mar 1996 16:45:27 -0500
Received: from ibgcore2.ibg.ljo.dec.com by vanna.ljo.dec.com; (5.65/1.1.8.2/10Oct94-8.2MPM)
id AA02661; Thu, 28 Mar 1996 16:38:16 -0500
Received: from ibgmail.ljo.dec.com by ibgcore1.ibg.ljo.dec.com; (5.65v3.2/1.1.8.2/17Oct95-0542PM)
id AA26297; Thu, 28 Mar 1996 12:43:27 -0500
Received: from plugh.ibg.ljo.dec.com by ibgmail.ljo.dec.com; (5.65/1.1.8.2/01Jan96-0534PM)
id AA14451; Thu, 28 Mar 1996 12:43:22 -0500
Received: by plugh.ibg.ljo.dec.com; (5.65v3.2/1.1.8.2/29Aug95-1247PM)
id AA01221; Thu, 28 Mar 1996 12:43:20 -0500
Date: Thu, 28 Mar 1996 12:43:20 -0500 (EST)
From: Jeff Needle <needle@ibg.ljo.dec.com>
To: "Perry E. Metzger" <perry@piermont.com>
Cc: ipsec@TIS.COM
Subject: Re: PPTP ????
In-Reply-To: <199603271811.NAA02838@jekyll.piermont.com>
Message-Id: <Pine.OSF.3.91.960328124001.1187A-100000@plugh.ibg.ljo.dec.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> > Has anyone looked into this new PPTP ? That is Point-to-point
> > Tunnel Protocol?
> >
> > It is being marketed much to what many of us are working IPSec (and probably
> > MobileIP)....
>
> Haven't heard of it. Who has done it, and where?
Microsoft is doing it, with the help of 3Com, Ascend, ECI Telematics, and
U.S. Robotics. Information is available at:
ftp://ftp.microsoft.com/developr/drg/pptp
It's Microsoft's stab at tunneling with Windows NT.
Jeff
+------------------------------+------------------------------------------+
|Jeff Needle |needle@ibg.ljo.dec.com |
|Digital Equipment Corporation | http://www.tiac.net/users/needle |
|30 Porter Road LJO2-1/D13 |Phone: 508-486-2160 |
|Littleton, MA 01460-1446 |FAX: 508-467-2851 |
+-------------------------------------------------------------------------+
|Internet Software Business Unit, Technical Support |
+------------------------------+------------------------------------------+
Received: from relay.tis.com by neptune.TIS.COM id aa07560; 28 Mar 96 18:54 EST
Received: by relay.tis.com; id SAA18509; Thu, 28 Mar 1996 18:57:14 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma018502; Thu, 28 Mar 96 18:56:47 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA21377; Thu, 28 Mar 96 18:55:36 EST
Received: by relay.tis.com; id SAA18499; Thu, 28 Mar 1996 18:56:44 -0500
Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1)
id xma018495; Thu, 28 Mar 96 18:56:20 -0500
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id SAA11430; Thu, 28 Mar 1996 18:54:51 -0500 (EST)
Message-Id: <199603282354.SAA11430@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: Jeff Needle <needle@ibg.ljo.dec.com>
Cc: ipsec@TIS.COM
Subject: Re: PPTP ????
In-Reply-To: Your message of "Thu, 28 Mar 1996 12:43:20 EST."
<Pine.OSF.3.91.960328124001.1187A-100000@plugh.ibg.ljo.dec.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Thu, 28 Mar 1996 18:54:50 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Jeff Needle writes:
> Microsoft is doing it, with the help of 3Com, Ascend, ECI Telematics, and
> U.S. Robotics. Information is available at:
>
> ftp://ftp.microsoft.com/developr/drg/pptp
>
> It's Microsoft's stab at tunneling with Windows NT.
All the docs are in word, which I don't have. Does anyone have a
translation into ASCII?
.pm
Received: from relay.tis.com by neptune.TIS.COM id aa09254; 28 Mar 96 20:50 EST
Received: by relay.tis.com; id UAA20628; Thu, 28 Mar 1996 20:53:14 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma020626; Thu, 28 Mar 96 20:52:50 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA23408; Thu, 28 Mar 96 20:51:35 EST
Received: by relay.tis.com; id UAA20623; Thu, 28 Mar 1996 20:52:44 -0500
Received: from mail13.digital.com(192.208.46.30) by relay.tis.com via smap (V3.1)
id xma020621; Thu, 28 Mar 96 20:52:33 -0500
Received: from vanna.ljo.dec.com by mail13.digital.com (5.65v3.2/1.0/WV)
id AA03070; Thu, 28 Mar 1996 20:51:01 -0500
Received: from ibgcore2.ibg.ljo.dec.com by vanna.ljo.dec.com; (5.65/1.1.8.2/10Oct94-8.2MPM)
id AA06988; Thu, 28 Mar 1996 20:40:37 -0500
Received: from tunnel2.imc.das.dec.com by ibgcore2.ibg.ljo.dec.com; (5.65v3.2/1.1.8.2/23Oct95-1203AM)
id AA03980; Thu, 28 Mar 1996 20:47:31 -0500
Message-Id: <2.2.32.19960329015132.00697f14@pop.ibg.ljo.dec.com>
X-Sender: needle@pop.ibg.ljo.dec.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 28 Mar 1996 20:51:32 -0500
To: perry@piermont.com
From: Jeff Needle <needle@ibg.ljo.dec.com>
Subject: Re: PPTP ????
Cc: ipsec@TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
>All the docs are in word, which I don't have. Does anyone have a
>translation into ASCII?
Sure, I've put it up at http://www.spitbrook.destek.com:81/pptp.txt.
While you're there, you can read about and download an evaluation copy of
the solution that Digital is shipping today ;-).
Jeff
+------------------------------+------------------------------------------+
|Jeff Needle |needle@ibg.ljo.dec.com |
|Digital Equipment Corporation | http://www.tiac.net/users/needle |
|30 Porter Road LJO2-1/D13 |Phone: 508-486-2160 |
|Littleton, MA 01460-1446 |FAX: 508-467-2851 |
+-------------------------------------------------------------------------+
| Internet Software Business Unit, Technical Support |
| *** via the Digital Internet Tunnel *** |
+------------------------------+------------------------------------------+
Received: from relay.tis.com by neptune.TIS.COM id aa19634; 29 Mar 96 9:00 EST
Received: by relay.tis.com; id JAA27295; Fri, 29 Mar 1996 09:02:41 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma027287; Fri, 29 Mar 96 09:02:13 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA06288; Fri, 29 Mar 96 09:01:04 EST
Received: by relay.tis.com; id JAA27281; Fri, 29 Mar 1996 09:02:11 -0500
Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (V3.1)
id xma027265; Fri, 29 Mar 96 09:01:48 -0500
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15271;
29 Mar 96 9:02 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;, tis.com@TIS.COM
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Cc: ipsec@TIS.COM
From: Internet-Drafts@cnri.reston.va.us
Reply-To: Internet-Drafts@cnri.reston.va.us
Subject: I-D ACTION:draft-ietf-ipsec-hmac-md5-00.txt
Date: Fri, 29 Mar 96 09:02:30 -0500
Message-Id: <9603290902.aa15271@IETF.CNRI.Reston.VA.US>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Security Protocol Working
Group of the IETF.
Title : HMAC-MD5: Keyed-MD5 for Message Authentication
Author(s) : H. Krawczyk, M. Bellare, R. Canetti
Filename : draft-ietf-ipsec-hmac-md5-00.txt
Pages : 8
Date : 03/28/1996
This document describes a keyed-MD5 mechanism (called HMAC-MD5) for use as
a message authentication code (or, integrity check value). It is mainly
intended for integrity verification of information transmitted over open
networks (e.g., Internet) between parties that share a common secret key.
The proposed mechanism combines the (key-less) MD5 hash function [RFC-1321]
with a shared secret key. The description of HMAC-MD5 in this document is
independent of its use in any particular protocol. An analogous mechanism
can be used in combination with other iterative hash functions, e.g., SHA.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-hmac-md5-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-hmac-md5-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv@ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-hmac-md5-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts@cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ds.internic.net"
Content-Type: text/plain
Content-ID: <19960328141449.I-D@CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-hmac-md5-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-hmac-md5-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960328141449.I-D@CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from relay.tis.com by neptune.TIS.COM id aa23006; 29 Mar 96 11:36 EST
Received: by relay.tis.com; id LAA00211; Fri, 29 Mar 1996 11:39:11 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma000203; Fri, 29 Mar 96 11:38:43 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA15239; Fri, 29 Mar 96 11:37:34 EST
Received: by relay.tis.com; id LAA00192; Fri, 29 Mar 1996 11:38:41 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma000175; Fri, 29 Mar 96 11:38:20 -0500
Received: from RSA.COM by interlock.ans.net with SMTP id AA25430
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Fri, 29 Mar 1996 11:39:09 -0500
Received: from snail.rsa.com by RSA.COM with SMTP
id AA15426; Fri, 29 Mar 96 08:29:39 PST
Received: from cc:Mail by snail.rsa.com
id AA828117333; Fri, 29 Mar 96 08:40:20 PST
Date: Fri, 29 Mar 96 08:40:20 PST
From: baldwin <baldwin@rsa.com>
Message-Id: <9602298281.AA828117333@snail.rsa.com>
To: ipsec@ans.net
Cc: rivest@theory.lcs.mit.edu
Subject: draft-baldwin-esp-rc5-00.txt
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
The draft we have written on how to use RC5 in
an IPsec ESP is now on the IETF file servers. The access information
is given below. All comments and suggestions are appreciated.
--Bob Baldwin
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The ESP RC5 Transform
Author(s) : B. W. Howard and R. W. Baldwin
Filename : draft-baldwin-esp-rc5-00.txt
Pages : 10
Date : 03/20/1996
This document describes the RC5-CBC security transform for the IP
Encapsulating Security Payload (ESP) based on the DES-CBC transform
described in RFC-1829 and RFC-1827. The RC5 cipher allows for greater
performance, security and exportability than the DES cipher. A companion
document [Baldwin96] describes RC5 in sufficient detail to construct
interoperable systems.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-baldwin-esp-rc5-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-baldwin-esp-rc5-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv@ds.internic.net. In the body type:
"FILE /internet-drafts/draft-baldwin-esp-rc5-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts@cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ds.internic.net"
Content-Type: text/plain
Content-ID: <19960328141449.I-D@CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-baldwin-esp-rc5-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-baldwin-esp-rc5-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960328141449.I-D@CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from relay.tis.com by neptune.TIS.COM id aa23048; 29 Mar 96 11:37 EST
Received: by relay.tis.com; id LAA00231; Fri, 29 Mar 1996 11:39:41 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma000217; Fri, 29 Mar 96 11:39:13 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA15249; Fri, 29 Mar 96 11:38:04 EST
Received: by relay.tis.com; id LAA00212; Fri, 29 Mar 1996 11:39:11 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma000207; Fri, 29 Mar 96 11:39:09 -0500
Received: from RSA.COM by interlock.ans.net with SMTP id AA25467
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Fri, 29 Mar 1996 11:40:09 -0500
Received: from snail.rsa.com by RSA.COM with SMTP
id AA15446; Fri, 29 Mar 96 08:30:39 PST
Received: from cc:Mail by snail.rsa.com
id AA828117393; Fri, 29 Mar 96 08:41:19 PST
Date: Fri, 29 Mar 96 08:41:19 PST
From: baldwin <baldwin@rsa.com>
Message-Id: <9602298281.AA828117393@snail.rsa.com>
To: ipsec@ans.net, rivest@theory.lcs.mit.edu
Subject: draft-baldwin-rc5-00.txt
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
The draft that describes how to create interoperable implementations
of the RC5 cipher and its various modes is now available for the IETF file
servers. We would appreciate any comments and suggestions on this draft.
--Bob Baldwin
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms
Author(s) : R. W. Baldwin and R. L. Rivest
Filename : draft-baldwin-rc5-00.txt
Pages : 35
Date : 03/20/1996
This document defines four ciphers with enough detail to ensure
interoperability between different implementations. The first cipher is the
raw RC5 block cipher. The RC5 cipher takes a fixed size input block and
produces a fixed sized output block using a transformation that depends on a
key. The second cipher, RC5-CBC, is the Cipher Block Chaining (CBC) mode
for RC5. It can process messages whose length is a multiple of the RC5
block size. The third cipher, RC5-CBC-Pad, handles plaintext of any length,
though the ciphertext will be longer than the plaintext by at most the size
of a single RC5 block. The RC5-CTS cipher is the Cipher Text Stealing mode
of RC5, which handles plaintext of any length and the ciphertext length
matches the plaintext length. The RC5 cipher was invented by Professor
Ronald L. Rivest of the Massachusetts Institute of Technology in 1994. It
is a very fast and simple algorithm that is parameterized by the block size,
the number of rounds, and key length. These parameters can be adjusted to
meet different goals for security, performance, and exportability. RSA Data
Security Incorporated has filed a patent application on the RC5 cipher and
for trademark protection for RC5, RC5-CBC, RC5-CBC-Pad, RC5-CTS and assorted
variations.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-baldwin-rc5-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-baldwin-rc5-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv@ds.internic.net. In the body type:
"FILE /internet-drafts/draft-baldwin-rc5-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts@cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ds.internic.net"
Content-Type: text/plain
Content-ID: <19960328141449.I-D@CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-baldwin-rc5-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-baldwin-rc5-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960328141449.I-D@CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from relay.tis.com by neptune.TIS.COM id aa01740; 29 Mar 96 19:51 EST
Received: by relay.tis.com; id TAA07237; Fri, 29 Mar 1996 19:53:16 -0500
From: hugo@watson.ibm.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma007233; Fri, 29 Mar 96 19:52:47 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA03250; Fri, 29 Mar 96 19:51:38 EST
Received: by relay.tis.com; id TAA07228; Fri, 29 Mar 1996 19:52:46 -0500
Message-Id: <199603300052.TAA07228@relay.tis.com>
Received: from unknown(129.34.139.4) by relay.tis.com via smap (V3.1)
id xma007224; Fri, 29 Mar 96 19:52:40 -0500
Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9197;
Fri, 29 Mar 96 19:52:02 EST
Date: Fri, 29 Mar 96 19:51:42 EST
To: IPSEC@TIS.COM
Subject: HMAC-MD5
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
An internet draft with specifications of HMAC-MD5 has been posted.
(draft-ietf-ipsec-hmac-md5-txt.00).
It is intended especialy for implementers of the IPSEC standards
since this transform was the one chosen in the LA meeting of IPSEC
as the mandatory to implement transform in AH (and combined AH/ESP).
The draft contains the definition of the function, some discussion
of security, and sample code (and test vectors).
(A couple of successful interoperability tests of AH using HMAC-MD5
as described in this draft were already accomplished)
Anyone with significant comments on the presentation please
let me know so I can reflect them in the RFC where this function
will be described.
Hugo
Received: from relay.tis.com by neptune.TIS.COM id aa09902; 30 Mar 96 8:24 EST
Received: by relay.tis.com; id IAA11837; Sat, 30 Mar 1996 08:27:11 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma011833; Sat, 30 Mar 96 08:26:42 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA11539; Sat, 30 Mar 96 08:25:32 EST
Received: by relay.tis.com; id IAA11830; Sat, 30 Mar 1996 08:26:41 -0500
Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1)
id xma011828; Sat, 30 Mar 96 08:26:13 -0500
Received: from Bill.Simpson.DialUp.Mich.Net (pm002-23.dialip.mich.net [141.211.7.159]) by merit.edu (8.7.5/merit-2.0) with SMTP id IAA23847 for <ipsec@TIS.COM>; Sat, 30 Mar 1996 08:27:10 -0500 (EST)
Date: Fri, 29 Mar 96 02:30:56 GMT
From: William Allen Simpson <bsimpson@morningstar.com>
Message-Id: <5160.bsimpson@morningstar.com>
To: ipsec@TIS.COM
Subject: Re: PPTP ????
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> From: "C. Harald Koch" <chk@border.com>
> It's from Microsoft and a couple of terminal server people. It's PPP from a
> remote dialup hub tunnelled (over IP) to your home office PPP server for
> "secure remote access", i.e. user dials into local ISP; ISP relays PPP
> packets directly to head-office, encapsulated inside IP; user thinks he's
> got a direct PPP link to the office, but with a local telephone call.
>
> I haven't looked closely at the spec, but I vaguely remember some sort of
> encryption or authentication on the tunnel portion of the link...
>
Sounds like what Morningstar was doing a few years back. And they just
got bought by Ascend....
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
Received: from relay.tis.com by neptune.TIS.COM id aa21098; 31 Mar 96 3:17 EST
Received: by relay.tis.com; id DAA18269; Sun, 31 Mar 1996 03:19:25 -0500
From: ERI2@frcu.eun.eg
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma018267; Sun, 31 Mar 96 03:18:56 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA22728; Sun, 31 Mar 96 03:17:47 EST
Received: by relay.tis.com; id DAA18264; Sun, 31 Mar 1996 03:18:55 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma018258; Sun, 31 Mar 96 03:18:25 -0500
Received: from FRCU.EUN.EG by interlock.ans.net with SMTP id AA28437
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Sun, 31 Mar 1996 03:19:16 -0500
Received: from FRCU.EUN.EG by FRCU.EUN.EG (PMDF V4.2-11 #3805) id
<01I2ZGQYFE7K000EV2@FRCU.EUN.EG>; Sun, 31 Mar 1996 10:17:02 O
Date: Sun, 31 Mar 1996 10:17:02 +0000 (O)
Subject: Request of information
To: ipsec@ans.net
Message-Id: <01I2ZGQYFXIA000EV2@FRCU.EUN.EG>
X-Vms-To: IN%"ipsec@ans.net"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Hello every body
I am looking for references which describe the operation of Kerberos in
several domains. I will be very grateful if someone could help me.
Regards,
Heba Aslan
Electronics Research Institute
El Tahrir St.
Dokki
Cairo, Egypt
E-mail: ERI2@FRCU.EUN.EG
Received: from relay.tis.com by neptune.TIS.COM id aa18645; 2 Apr 96 23:41 EST
Received: by relay.tis.com; id QAA29296; Tue, 2 Apr 1996 16:45:14 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma029287; Tue, 2 Apr 96 16:44:46 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA11785; Tue, 2 Apr 96 16:43:35 EST
Received: by relay.tis.com; id QAA29281; Tue, 2 Apr 1996 16:44:44 -0500
Received: from exchange.microsoft.com(131.107.243.48) by relay.tis.com via smap (V3.1)
id xma029264; Tue, 2 Apr 96 16:44:17 -0500
Received: by yuri.microsoft.com with Microsoft Exchange (IMC 4.0.837.3)
id <01BB209A.4943C090@yuri.microsoft.com>; Tue, 2 Apr 1996 13:42:50 -0800
Message-Id: <c=US%a=_%p=Microsoft%l=ROADKILL-960402214243Z-5356@yuri.microsoft.com>
From: "Dwight Krossa (Exchange)" <dwightk@exchange.microsoft.com>
To: "'ipsec@TIS.COM'" <ipsec@TIS.COM>
Cc: "Dwight Krossa (Exchange)" <dwightk@exchange.microsoft.com>
Subject: PPTP ????
Date: Tue, 2 Apr 1996 13:42:43 -0800
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
PPTP is point-to-point tunneling protocol, a networking technology that
supports multiprotocol virtual private networks (VPN), enabling remote
users to access corporate networks securely across the Internet.=20
Using PPTP, remote users can employ the Microsoft=AE Windows=AE 95 and
Windows NT=99 Workstation operating systems and other point-to-point
protocol (PPP)-enabled systems to dial into a local Internet service to
connect to their corporate network via the Internet.
For more information,=20
http://www.microsoft.com/backoffice/ntserver/pptppr.htm
For the complete specification:
http://www.microsoft.com/intdev/inttech/pptp.htm
Cheers
Dwight Krossa
Microsoft Corporation
>
>----------
>From: Robert Moskowitz[SMTP:rgm3@is.chrysler.com]
>Sent: Wednesday, March 27, 1996 9:24 AM
>To: ipsec@TIS.COM
>Subject: PPTP ????
>
>Has anyone looked into this new PPTP ? That is Point-to-point Tunnel
>Protocol?
>
>It is being marketed much to what many of us are working IPSec (and
>probably
>MobileIP)....
>
>Robert Moskowitz
>Chrysler Corporation
>(810) 758-8212
>
>
>
>
>
>
Received: from relay.tis.com by neptune.TIS.COM id aa07742; 3 Apr 96 17:40 EST
Received: by relay.tis.com; id RAA28516; Wed, 3 Apr 1996 17:42:52 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma028506; Wed, 3 Apr 96 17:42:33 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA26965; Wed, 3 Apr 96 17:41:21 EST
Received: by relay.tis.com; id RAA28479; Wed, 3 Apr 1996 17:42:29 -0500
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma028473; Wed, 3 Apr 96 17:41:57 -0500
Received: from relay-2.mail.demon.net (disperse.demon.co.uk) by interlock.ans.net with SMTP id AA07268
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Wed, 3 Apr 1996 17:42:52 -0500
Received: from post.demon.co.uk ([158.152.1.72]) by relay-2.mail.demon.net
id aa16624; 3 Apr 96 22:27 +0100
Received: from drsec.demon.co.uk ([158.152.74.182]) by relay-3.mail.demon.net
id aa23906; 3 Apr 96 22:25 +0100
Message-Id: <HzzPgCAkyuYxEweu@drsec.demon.co.uk>
Date: Wed, 3 Apr 1996 22:24:52 +0100
To: ERI2@frcu.eun.eg
Cc: ipsec@ans.net
From: Dave Rogers <drogers@drsec.demon.co.uk>
Subject: Re: Request of information
In-Reply-To: <01I2ZGQYFXIA000EV2@FRCU.EUN.EG>
Mime-Version: 1.0
X-Mailer: Turnpike Version 1.10 <JRWYHwKgVGh0jgPeg8AZByKEBU>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
In message <01I2ZGQYFXIA000EV2@FRCU.EUN.EG>, ERI2@frcu.eun.eg writes
>
>Hello every body
>
> I am looking for references which describe the operation of Kerberos in
>several domains. I will be very grateful if someone could help me.
>
>
Try looking at :
http://www.es.net/pub/esnet-doc/auth-and-security
This is a report on the use of Kerberos within a multi-realm
environment. Other documents in the same location provide general
information on Kerberos.
--
-------------------------------------------------------------------------
David Rogers Email: drogers@drsec.demon.co.uk
OpenVision Technologies Ltd daver@openv.co.uk
Yorktown House, 8 Frimley Road Tel: +44 (0) 1276 683060
Camberley, Surrey, UK GU15 3HS Fax: +44 (0) 1276 683755
-------------------------------------------------------------------------
Received: from relay.tis.com by neptune.TIS.COM id aa02278; 8 Apr 96 10:39 EDT
Received: by relay.tis.com; id KAA03828; Mon, 8 Apr 1996 10:41:33 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma003824; Mon, 8 Apr 96 10:41:11 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA03844; Mon, 8 Apr 96 10:40:02 EDT
Received: by relay.tis.com; id KAA03814; Mon, 8 Apr 1996 10:41:04 -0400
Received: from host33.epoch.ncsc.mil(144.51.25.33) by relay.tis.com via smap (V3.1)
id xma003806; Mon, 8 Apr 96 10:40:54 -0400
Received: from dolphin.ncsc.mil (dolphin.epoch.ncsc.mil) by zeus.epoch.ncsc.mil (4.1/SMI-SVR4)
id AA17168; Mon, 8 Apr 96 10:30:59 EDT
Received: by dolphin.ncsc.mil (4.1/SMI-4.1)
id AA04398; Mon, 8 Apr 96 10:39:47 EDT
Date: Mon, 8 Apr 96 10:39:47 EDT
From: "W. Douglas Maughan" <wdm@epoch.ncsc.mil>
Message-Id: <9604081439.AA04398@dolphin.ncsc.mil>
To: ipsec@TIS.COM
Subject: ANNOUNCE: ISAKMP v0.1 is now available
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
We are pleased to announce that the first release of ISAKMP is now
available. It is based on draft-ietf-ipsec-isakmp-04 which was
distributed prior to the Los Angeles IETF. The software can be
downloaded from:
http://web.mit.edu/network/isakmp
We would like to thank MIT for providing the anonymous FTP service and,
specifically, Jeff Schiller for assisting in this process.
Douglas Maughan
Mark Schertler
Received: from relay.tis.com by neptune.TIS.COM id aa12945; 8 Apr 96 22:03 EDT
Received: by relay.tis.com; id WAA18533; Mon, 8 Apr 1996 22:05:54 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma018531; Mon, 8 Apr 96 22:05:26 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA02379; Mon, 8 Apr 96 22:04:19 EDT
Received: by relay.tis.com; id WAA18528; Mon, 8 Apr 1996 22:05:24 -0400
Received: from interlock.ans.net(147.225.5.2) by relay.tis.com via smap (V3.1)
id xma018526; Mon, 8 Apr 96 22:05:08 -0400
Received: from ctrvx1.Vanderbilt.Edu by interlock.ans.net with SMTP id AA05966
(InterLock SMTP Gateway 3.0 for <ipsec@ans.net>);
Mon, 8 Apr 1996 22:06:07 -0400
Received: from ctrvax.Vanderbilt.Edu by ctrvax.Vanderbilt.Edu
(PMDF V5.0-5 #11488) id <01I3B9Q8SFOG8XEC6E@ctrvax.Vanderbilt.Edu> for
listys@ctrvax.Vanderbilt.Edu; Mon, 08 Apr 1996 21:03:19 -0500 (CDT)
Date: Mon, 08 Apr 1996 21:03:19 -0500 (CDT)
From: BEZALEL GAVISH <GAVISHB@ctrvax.vanderbilt.edu>
Subject: Proceedings of 4th International Conference on Telecommunications
Systems
To: listys: ;, tis.com@TIS.COM
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Message-Id: <01I3B9Q8SPBM8XEC6E@ctrvax.Vanderbilt.Edu>
X-Vms-To: IN%"listys"
X-Vms-Cc: GAVISHB
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
The fourth International Conference on Telecommunication Systems was held
March 21-24, 1996, in Nashville, TN. Close to 150 participants from 27
countries gave over 85 presentations on a variety of topics. Proceedings
containing the papers presented during the conference have been produced.
A few remaining copies of the proceedings are available for sale.
The table of contents and ordering information are located at URL
http://www.vanderbilt.edu/Owen/gavish/tsm96proceedings.html
-------------------------------------------------------------------------------
Bezalel Gavish
Owen Graduate School of Management
Vanderbilt University
Nashville, TN, 37203
Bitnet: GAVISHB@VUCTRVAX
Internet: GAVISHB@CTRVAX.VANDERBILT.EDU
Tel: (615) 322-3659 Home: (615) 370-0813
FAX: (615) 343-7177
-------------------------------------------------------------------------------
Received: from relay.tis.com by neptune.TIS.COM id aa24823; 19 Apr 96 9:36 EDT
Received: by relay.tis.com; id JAA29383; Fri, 19 Apr 1996 09:38:34 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma029378; Fri, 19 Apr 96 09:38:05 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA28160; Fri, 19 Apr 96 09:37:04 EDT
Received: by relay.tis.com; id JAA29366; Fri, 19 Apr 1996 09:38:03 -0400
Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay.tis.com via smap (V3.1)
id xma029358; Fri, 19 Apr 96 09:37:54 -0400
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10457;
19 Apr 96 9:14 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;, tis.com@TIS.COM
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Cc: ipsec@TIS.COM
From: Internet-Drafts@cnri.reston.va.us
Reply-To: Internet-Drafts@cnri.reston.va.us
Subject: I-D ACTION:draft-simpson-photuris-schemes-00.txt
Date: Fri, 19 Apr 96 09:14:49 -0400
Message-Id: <9604190914.aa10457@IETF.CNRI.Reston.VA.US>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Photuris Schemes and Privacy Protection
Author(s) : P. Karn, W. Simpson
Filename : draft-simpson-photuris-schemes-00.txt
Pages : 9
Date : 04/18/1996
Photuris is an experimental session-key management protocol intended for
use with the IP Security Protocols (AH and ESP). Extensible Exchange
Schemes are provided to enable future implementation changes without
affecting the basic protocol. An important improvement in security is
provided by protecting exchanges with encryption.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-simpson-photuris-schemes-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-simpson-photuris-schemes-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv@ds.internic.net. In the body type:
"FILE /internet-drafts/draft-simpson-photuris-schemes-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts@cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ds.internic.net"
Content-Type: text/plain
Content-ID: <19960418141116.I-D@CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-simpson-photuris-schemes-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-simpson-photuris-schemes-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960418141116.I-D@CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from relay.tis.com by neptune.TIS.COM id aa00265; 21 Apr 96 18:28 EDT
Received: by relay.tis.com; id SAA27469; Sun, 21 Apr 1996 18:29:40 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma027466; Sun, 21 Apr 96 18:29:20 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA00890; Sun, 21 Apr 96 18:29:33 EDT
Received: by relay.tis.com; id SAA27462; Sun, 21 Apr 1996 18:29:10 -0400
Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1)
id xma027460; Sun, 21 Apr 96 18:29:09 -0400
Received: from ktik0 (ktik0 [129.132.66.42]) by tik1.ethz.ch (8.7.5/8.7.3) with ESMTP id AAA00857; Mon, 22 Apr 1996 00:30:45 +0200 (MET DST)
Received: from komsys-pc-gc.ethz.ch (komsys-pc-gc.ethz.ch [129.132.66.22]) by ktik0 (8.6.8.1/8.6.6) with SMTP id AAA22462; Mon, 22 Apr 1996 00:30:38 +0200
Message-Id: <2.2.32.19960421223444.006e30f8@ktik0.ethz.ch>
X-Sender: caronni@ktik0.ethz.ch
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 22 Apr 1996 00:34:44 +0200
To: ipsec@TIS.COM
From: Germano Caronni <caronni@tik.ee.ethz.ch>
Subject: IETF Draft for ESP with stream ciphers
Cc: skip-info@tik.ee.ethz.ch, skip@tik.ee.ethz.ch
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Hello everybody,
some time ago, Marcel (Waldvogel) and I have submitted an internet draft,
which gives a proposal on how 'Encapsulated Security Payload' can be
implemented for stream ciphers, at the same time offering mechanisms for
replay protection.
Now we would be very interested in the opinion of the IPSEC working group,
and possible other readers. Is 'esp-stream' of interest? What do the members
and chairs think about the fitness of this document? If it is relevant,
perhaps we could move it into the 'draft-ietf-ipsec-*' name domain? We are
also very much looking forward to technical comments...
Friendly greetings,
Germano
p.s. the doucment is online as draft-caronni-esp-stream-00.txt, or as
http://www.tik.ee.ethz.ch/~skip/esp-stream.txt
Received: from relay.tis.com by neptune.TIS.COM id aa18471; 22 Apr 96 13:31 EDT
Received: by relay.tis.com; id NAA09472; Mon, 22 Apr 1996 13:32:24 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma009463; Mon, 22 Apr 96 13:31:59 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA01012; Mon, 22 Apr 96 13:32:21 EDT
Received: by relay.tis.com; id NAA09447; Mon, 22 Apr 1996 13:31:57 -0400
Received: from franklin.seas.gwu.edu(128.164.9.2) by relay.tis.com via smap (V3.1)
id xma009432; Mon, 22 Apr 96 13:31:37 -0400
Received: from felix.seas.gwu.edu (root@felix.seas.gwu.edu [128.164.9.3]) by franklin.seas.gwu.edu (8.7.1/8.7.1) with ESMTP id NAA07020 for <ipsec@tis.com>; Mon, 22 Apr 1996 13:34:16 -0400 (EDT)
Received: from reto.seas.gwu.edu (reto@felix [128.164.9.3]) by felix.seas.gwu.edu (8.7.1/8.7.1) with SMTP id NAA00230 for <ipsec@tis.com>; Mon, 22 Apr 1996 13:34:11 -0400 (EDT)
Message-Id: <199604221734.NAA00230@felix.seas.gwu.edu>
X-Sender: reto@seas.gwu.edu
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 22 Apr 1996 13:35:47 -0400
To: ipsec@TIS.COM
From: Reto Haeni <reto@seas.gwu.edu>
Subject: Routing Header info of IPng against traffic analysis?
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Hi
As I was working through the IPng specifications, I realized that
no options are implemented to prevent traffic analysis in IPsec.
Could the Routing Header information been set up that the list of
intermediate nodes changes when the system setting provide a
list of alternative routing paths? An error condition could arise
similar to the definition in the fragmentation header, if not all
packets are received to complete reassembly of the message within 60
seconds (a long time but I think this would be a reasonable waiting
time if you are concerned about traffic analysis).
This would prevent most attempts to traffic analysis and complete
the good IPsec spec.
I am looking forward to your comments
greetings
Reto
------------------------------------------------------------------
at the George Washington University, Washington DC
reto@seas.gwu.edu
Received: from relay.tis.com by neptune.TIS.COM id aa19253; 22 Apr 96 14:16 EDT
Received: by relay.tis.com; id OAA00910; Mon, 22 Apr 1996 14:17:33 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma000907; Mon, 22 Apr 96 14:17:06 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA04204; Mon, 22 Apr 96 14:17:28 EDT
Received: by relay.tis.com; id OAA00900; Mon, 22 Apr 1996 14:17:04 -0400
Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1)
id xma000894; Mon, 22 Apr 96 14:16:51 -0400
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id OAA18138; Mon, 22 Apr 1996 14:19:14 -0400 (EDT)
Message-Id: <199604221819.OAA18138@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: Reto Haeni <reto@seas.gwu.edu>
Cc: ipsec@TIS.COM
Subject: Re: Routing Header info of IPng against traffic analysis?
In-Reply-To: Your message of "Mon, 22 Apr 1996 13:35:47 EDT."
<199604221734.NAA00230@felix.seas.gwu.edu>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Mon, 22 Apr 1996 14:19:08 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Reto Haeni writes:
> As I was working through the IPng specifications, I realized that
> no options are implemented to prevent traffic analysis in IPsec.
>
> Could the Routing Header information been set up that the list of
> intermediate nodes changes when the system setting provide a
> list of alternative routing paths? An error condition could arise
> similar to the definition in the fragmentation header, if not all
> packets are received to complete reassembly of the message within 60
> seconds (a long time but I think this would be a reasonable waiting
> time if you are concerned about traffic analysis).
Changing routing paths isn't sufficient to prevent traffic analysis.
Stopping traffic analysis is fairly complicated and beyond the scope
of the IPSec work...
.pm
Received: from relay.tis.com by neptune.TIS.COM id aa23587; 22 Apr 96 17:36 EDT
Received: by relay.tis.com; id RAA05414; Mon, 22 Apr 1996 17:37:36 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma005411; Mon, 22 Apr 96 17:37:08 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA17233; Mon, 22 Apr 96 17:37:31 EDT
Received: by relay.tis.com; id RAA05404; Mon, 22 Apr 1996 17:37:06 -0400
Received: from unknown(171.69.1.174) by relay.tis.com via smap (V3.1)
id xma005398; Mon, 22 Apr 96 17:36:46 -0400
Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id OAA20423; Mon, 22 Apr 1996 14:38:49 -0700
Date: Mon, 22 Apr 1996 14:38:49 -0700
From: Ran Atkinson <rja@cisco.com>
Message-Id: <199604222138.OAA20423@puli.cisco.com>
To: caronni@tik.ee.ethz.ch
Subject: Re: IETF Draft for ESP with stream ciphers
In-Reply-To: <2.2.32.19960421223444.006e30f8@ktik0.ethz.ch>
Organization: cisco Systems, Inc., Menlo Park, Ca.
Cc: ipsec@TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
In article <2.2.32.19960421223444.006e30f8@ktik0.ethz.ch> Germanno wrote:
>some time ago, Marcel (Waldvogel) and I have submitted an internet draft,
>which gives a proposal on how 'Encapsulated Security Payload' can be
>implemented for stream ciphers, at the same time offering mechanisms for
>replay protection.
>
>Now we would be very interested in the opinion of the IPSEC working group,
>and possible other readers. Is 'esp-stream' of interest?
The main issue with the current draft is that it does not specify a
particular stream algorithm. An ESP transform MUST specify a particular
algorithm as part of the transform so that when key management negotiates
use of that transform, both sides know which algorithm to use.
So perhaps my fundamental request is that this be edited into a transform
for a specific algorithm or possibly for two specific algorithms (with some
note that each algorithm would need its own "transform identifier" for key
management use.
It is NOT the case that the current spec works for all stream algorithms,
for example the "Stream Offset" as currently defined will not work when
more than 64 bits of crypto-sync are needed for some algorithm. While
algorithm-independence is important for the base AH and ESP specs, it
should not be a goal for a transform document since transform documents are
supposed to specify how to use a single particular crypto algorithm with AH
or ESP.
>What do the members and chairs think about the fitness of this document?
As an ordinary person, my take on this is that it has limited applicability
and should probably become an Experimental RFC or Informational RFC. I do
not know the patent status of SEAL in various countries, but IETF practice
is to avoid standardising patented techniques when unpatented techniques
(e.g. DES CFB) exist.
Given the existence of fairly fast DES code (e.g. Karn's i386 assembly) and
commercial high-speed DES chips, I'm not sure that this particular tradeoff
of speed for less security is one that I'd be making.
I would want MD5 (or equivalent) integrity/authentication to be added to
the transform because we know that strong integrity/authentication is
needed to obtain commercial-grade security. I'm aware of MD5 code in
software that does better than OC-3 rate now on a commercial 64-bit RISC
processor. I'm also aware of MD5 hardware that is well above OC-3 rates.
In general, I do not agree with all of the conclusions of RFC-1810 because
of private discussions I've had with employees of National Semiconductor
(these discussions actually date back prior to my arrival at cisco).
>If it is relevant, perhaps we could move it into the 'draft-ietf-ipsec-*'
>name domain?
Only if the WG decides it should be a standards-track document. It is not
yet clear to me that there is anything like consensus that this draft
should be on the standards-track.
I've been told from above that we should not be standardising any transform
that is vulnerable to published attacks. The WG in LA made it clear that
RFC-1828 and RFC-1829 should be replaced-on-the-standards-track with new
transforms having improved security properties. So I'd view addition of
MD5 (or similar, SHA would be fine with me personally) integrity/
authentication to be needed before this draft goes anywhere.
Ran
rja@cisco.com
Received: from relay.tis.com by neptune.TIS.COM id aa23650; 22 Apr 96 17:39 EDT
Received: by relay.tis.com; id RAA05445; Mon, 22 Apr 1996 17:40:36 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma005438; Mon, 22 Apr 96 17:40:08 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA17298; Mon, 22 Apr 96 17:40:31 EDT
Received: by relay.tis.com; id RAA05432; Mon, 22 Apr 1996 17:40:06 -0400
Received: from unknown(171.69.1.174) by relay.tis.com via smap (V3.1)
id xma005422; Mon, 22 Apr 96 17:39:55 -0400
Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id OAA00456; Mon, 22 Apr 1996 14:42:29 -0700
Date: Mon, 22 Apr 1996 14:42:29 -0700
From: Ran Atkinson <rja@cisco.com>
Message-Id: <199604222142.OAA00456@puli.cisco.com>
To: ipsec@TIS.COM
Subject: Re: Routing Header info of IPng against traffic analysis?
In-Reply-To: <199604221819.OAA18138@jekyll.piermont.com>
References: <199604221734.NAA00230@felix.seas.gwu.edu>
Organization: cisco Systems, Inc., Menlo Park, Ca.
Cc:
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Reto Haeni wrote:
% As I was working through the IPng specifications, I realized that
% no options are implemented to prevent traffic analysis in IPsec.
In article <199604221819.OAA18138@jekyll.piermont.com> Perry wrote:
>Changing routing paths isn't sufficient to prevent traffic analysis.
>
>Stopping traffic analysis is fairly complicated and beyond the scope
>of the IPSec work...
It is not clear to me that it is feasible to prevent traffic analysis
anywhere above the link layer. Folks really interested in this might want
to consult [VK85] for relevant background material.
Ran
rja@cisco.com
Received: from relay.tis.com by neptune.TIS.COM id aa24671; 22 Apr 96 18:40 EDT
Received: by relay.tis.com; id SAA06085; Mon, 22 Apr 1996 18:41:10 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma006083; Mon, 22 Apr 96 18:40:42 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA18663; Mon, 22 Apr 96 18:41:05 EDT
Received: by relay.tis.com; id SAA06078; Mon, 22 Apr 1996 18:40:41 -0400
Received: from foo-5-10.ipsilon.com(205.226.5.12) by relay.tis.com via smap (V3.1)
id xma006074; Mon, 22 Apr 96 18:40:34 -0400
Received: from mailhost.ipsilon.com (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id PAA10174; Mon, 22 Apr 1996 15:43:04 -0700
Message-Id: <199604222243.PAA10174@mailhost.Ipsilon.COM>
X-Mailer: exmh version 1.6.4 10/10/95
To: Ran Atkinson <rja@cisco.com>
Cc: ipsec@TIS.COM
Subject: ports in the clear...
In-Reply-To: Your message of "Mon, 22 Apr 1996 14:42:29 PDT."
<199604222142.OAA00456@puli.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 22 Apr 1996 15:43:04 -0700
From: Greg Minshall <minshall@ipsilon.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> It is not clear to me that it is feasible to prevent traffic analysis
> anywhere above the link layer. Folks really interested in this might want
> to consult [VK85] for relevant background material.
Did i mention my desire to expose the source and destination TCP/UDP ports
(via some new fields in the IPSEC header) when doing encryption?
There are lots of reasons, from bean counting ("what % of the internet traffic
is web traffic?") to firewalls to "best effort QoS" (make telnet port low
latency; make ftp data port high throughput).
Greg
Received: from relay.tis.com by neptune.TIS.COM id aa24847; 22 Apr 96 18:50 EDT
Received: by relay.tis.com; id SAA06194; Mon, 22 Apr 1996 18:51:10 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma006192; Mon, 22 Apr 96 18:50:42 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA18847; Mon, 22 Apr 96 18:51:05 EDT
Received: by relay.tis.com; id SAA06189; Mon, 22 Apr 1996 18:50:41 -0400
Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1)
id xma006187; Mon, 22 Apr 96 18:50:17 -0400
Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id PAA27485; Mon, 22 Apr 1996 15:52:26 -0700
Date: Mon, 22 Apr 1996 15:52:26 -0700
From: Ran Atkinson <rja@cisco.com>
Message-Id: <199604222252.PAA27485@puli.cisco.com>
To: minshall@ipsilon.com
Subject: Re: ports in the clear...
Cc: ipsec@TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Greg Minshall <minshall@ipsilon.com> wrote:
% Did i mention my desire to expose the source and destination TCP/UDP ports
% (via some new fields in the IPSEC header) when doing encryption?
Yes. You've mentioned this several times. My answers remain the same.
You'll shoud concentrate on convincing everyone else first,
because there is ZERO chance I'll be convinced to open up the ports
and ULP identifier with ESP.
% There are lots of reasons, from bean counting ("what % of the internet
% traffic is web traffic?")
So add a counter for encrypted traffic. Not a good argument.
% to firewalls
Should be implementing IPsec anyway. Most firewalls are becoming encrypting
firewalls already. Not a good argument.
% to "best effort QoS" (make telnet port low latency;
% make ftp data port high throughput).
Use RSVP instead. See the RSVP+IPsec draft for how to make it work.
Your unstated reason is that it relates to how the Ipsilon product works
and that won't persuade me either.
Nothing says that users must use encryption. If they choose to do so,
then they ought not have their ports and ULP identifier in cleartext.
Ran
rja@inet.org
Received: from relay.tis.com by neptune.TIS.COM id aa25287; 22 Apr 96 19:18 EDT
Received: by relay.tis.com; id TAA06638; Mon, 22 Apr 1996 19:19:30 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma006634; Mon, 22 Apr 96 19:19:02 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA19292; Mon, 22 Apr 96 19:19:24 EDT
Received: by relay.tis.com; id TAA06631; Mon, 22 Apr 1996 19:19:00 -0400
Received: from unknown(194.100.8.234) by relay.tis.com via smap (V3.1)
id xma006627; Mon, 22 Apr 96 19:18:30 -0400
Received: from pilari.ssh.fi (pilari.ssh.fi [192.168.2.1]) by muuri.ssh.fi (8.7.5/8.7.3) with ESMTP id CAA16607; Tue, 23 Apr 1996 02:20:58 +0300 (EET DST)
Received: (from ylo@localhost) by pilari.ssh.fi (8.7.5/8.7.3) id CAA24256; Tue, 23 Apr 1996 02:20:57 +0300 (EET DST)
Date: Tue, 23 Apr 1996 02:20:57 +0300 (EET DST)
Message-Id: <199604222320.CAA24256@pilari.ssh.fi>
From: Tatu Ylonen <ylo@ssh.fi>
To: Greg Minshall <minshall@ipsilon.com>
Cc: ipsec@TIS.COM
Subject: ports in the clear...
In-Reply-To: <199604222243.PAA10174@mailhost.Ipsilon.COM>
References: <199604222142.OAA00456@puli.cisco.com>
<199604222243.PAA10174@mailhost.Ipsilon.COM>
Organization: Helsinki University of Technology, Finland
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> There are lots of reasons, from bean counting ("what % of the
> internet traffic is web traffic?") to firewalls to "best effort QoS"
> (make telnet port low latency; make ftp data port high throughput).
Using port numbers for quality of service is The Wrong Way To Do It.
The TOS (Type of Service) field is for this, and it reveals much less
other information.
Attaching type of service semantics to port numbers makes adding new
services extremely painful, because it is impossible to control their
routing priority. IPTOS is much more flexible, extensible, and
scalable. Almost all machines already set IPTOS in outgoing packets
according to the type of the service.
Tatu
Received: from relay.tis.com by neptune.TIS.COM id aa26166; 22 Apr 96 20:14 EDT
Received: by relay.tis.com; id UAA07276; Mon, 22 Apr 1996 20:14:41 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma007270; Mon, 22 Apr 96 20:14:13 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA20084; Mon, 22 Apr 96 20:14:36 EDT
Received: by relay.tis.com; id UAA07267; Mon, 22 Apr 1996 20:14:11 -0400
Received: from foo-5-10.ipsilon.com(205.226.5.12) by relay.tis.com via smap (V3.1)
id xma007260; Mon, 22 Apr 96 20:13:52 -0400
Received: from mailhost.ipsilon.com (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id RAA13196; Mon, 22 Apr 1996 17:16:22 -0700
Message-Id: <199604230016.RAA13196@mailhost.Ipsilon.COM>
X-Mailer: exmh version 1.6.4 10/10/95
To: Ran Atkinson <rja@cisco.com>
Cc: ipsec@TIS.COM
Subject: Re: ports in the clear...
In-Reply-To: Your message of "Mon, 22 Apr 1996 15:52:26 PDT."
<199604222252.PAA27485@puli.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 22 Apr 1996 17:16:22 -0700
From: Greg Minshall <minshall@ipsilon.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Ran,
> Your unstated reason is that it relates to how the Ipsilon product works
> and that won't persuade me either.
Foo. I'm fairly principled; my discomfort with hiding the port numbers
predates Ipsilon. (But, you are right that this would also make some of our
stuff easier in operational networks.) [But, maybe you didn't mean this
statement to be for public consumption?]
> Nothing says that users must use encryption. If they choose to do so,
> then they ought not have their ports and ULP identifier in cleartext.
I guess i don't know any argument from first principles that says what should,
and what shouldn't, be in the clear (except that it's clear that people want
their telnet passwords and their payroll data, etc., to be encrypted). If,
for example, ports and ULP were in the IPng header (sort of like in XNS), then
one might not think of encrypting them (thinking of them as part of the
"address").
Greg
Received: from relay.tis.com by neptune.TIS.COM id aa26674; 22 Apr 96 20:42 EDT
Received: by relay.tis.com; id UAA07723; Mon, 22 Apr 1996 20:43:41 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
id xma007716; Mon, 22 Apr 96 20:43:13 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA20541; Mon, 22 Apr 96 20:43:36 EDT
Received: by relay.tis.com; id UAA07707; Mon, 22 Apr 1996 20:43:11 -0400
Received: from foo-5-10.ipsilon.com(205.226.5.12) by relay.tis.com via smap (V3.1)
id xma007702; Mon, 22 Apr 96 20:43:04 -0400
Received: from mailhost.ipsilon.com (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id RAA13992; Mon, 22 Apr 1996 17:45:02 -0700
Message-Id: <199604230045.RAA13992@mailhost.Ipsilon.COM>
X-Mailer: exmh version 1.6.4 10/10/95
To: Tatu Ylonen <ylo@ssh.fi>
Cc: ipsec@TIS.COM
Subject: Re: ports in the clear...
In-Reply-To: Your message of "Tue, 23 Apr 1996 02:20:57 +0300."
<199604222320.CAA24256@pilari.ssh.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 22 Apr 1996 17:45:02 -0700
From: Greg Minshall <minshall@ipsilon.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Tatu,
Actually, the poor IP TOS field has an inglorious history of having been
somewhat useless. The original definition never had very much use. The more
current separation of precedence, etc., may have a bit more utility, though
the fact that it is set at the end station (and, therefore, of dubious
correctness) is a bit troubling. (You might look at Christian Huitema's
"Routing in the Internet", section 3.3.2, for a *very* brief discussion.)
(The canonical danger is an e'mail program that advertises "i'll get your mail
there faster than that other e'mail program", and then doing that by setting
bits in TOS.)
*One* advantage of looking at port numbers is that it scales, to some degree.
It also *may* reflect closer to what is actually going on (i.e., this really
*is* a telnet session; unless, of course, the two ends are conspiring). (For
some of the background, you might want to look at Floyd, S., and Jacobson, V.,
Link-sharing and Resource Management Models for Packet Networks. IEEE/ACM
Transactions on Networking, Vol. 3 No. 4, pp. 365-386, August 1995.)
(But, you are right, by doing this, when you field a new "