From owner-ipsec Mon Mar 3 07:58:22 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA00818 for ipsec-outgoing; Mon, 3 Mar 1997 07:48:21 -0500 (EST)
Message-Id: <199703031252.HAA10181@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol
To: Phil Karn <karn@laptop.ka9q.ampr.org>
cc: kent@bbn.com, ipsec@tis.com
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
In-reply-to: Your message of "Sun, 02 Mar 1997 23:40:48 PST."
<m0w1SMa-000Rx6C@laptop.ka9q.ampr.org>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Mon, 03 Mar 1997 07:52:54 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Phil Karn writes:
> I used the term "transport layer security" to refer to SSL and SSH
> because that's the term in common IETF usage. Perhaps we should rename
> them to "presentation layer security", because that's what it really
> is. And the Internet may even have a true presentation layer for the
> first time. :-)
>
> Your other point about being able to sabotage TCP connections when the
> security is layered on top is also quite true. It all depends on your threat
> model -- are you more worried about active attacks or passive eavesdropping?
One has to worry about both in certain circumstances. The most
canonical example is, of course, disrupting BGP connections between
routers.
Perry
From owner-ipsec Mon Mar 3 07:58:27 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA00929 for ipsec-outgoing; Mon, 3 Mar 1997 07:54:50 -0500 (EST)
Message-Id: <199703031254.HAA00929@portal.ex.tis.com>
Date: Sun, 2 Mar 1997 23:40:48 -0800 (PST)
From: Phil Karn <karn@laptop.ka9q.ampr.org>
To: kent@bbn.com
CC: perry@piermont.com, rmonsour@earthlink.net, ipsec@tis.com
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Steve,
I used the term "transport layer security" to refer to SSL and SSH
because that's the term in common IETF usage. Perhaps we should rename
them to "presentation layer security", because that's what it really
is. And the Internet may even have a true presentation layer for the
first time. :-)
Your other point about being able to sabotage TCP connections when the
security is layered on top is also quite true. It all depends on your threat
model -- are you more worried about active attacks or passive eavesdropping?
Phil
From owner-ipsec Mon Mar 3 08:07:23 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA01003 for ipsec-outgoing; Mon, 3 Mar 1997 08:03:52 -0500 (EST)
Message-Id: <199703031217.OAA06263@morden.ssh.fi>
To: ipsec@tis.com
CC: parkosar@pb.com
Subject: Re: transport vs network and ipsec syn
In-reply-to: Your message of "Fri, 28 Feb 1997 13:15:23 EST."
<9701288571.AA857165346@smtppc.ct.pb.com>
Date: Mon, 03 Mar 1997 14:16:09 +0200
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Arthur" == Arthur Parkos <parkosar@pb.com> writes:
Arthur> - it's not guaranteed that all connections will be
Arthur> attempted with ipsec authentication
Arthur> instantiated. therefore a host will still need to respond
Arthur> to the request for a connection. or will a host refuse all
Refusing non-authenticated connections is a matter of local policy.
I expect many sites to start doing this. One way would that authenticated
connections would get priority over non-authenticated connections when
it comes to resource allocations. Or there would be seperate pools.
Arthur> connect attempts from non-ipsec host. - if ipsec is
Arthur> implemented, the host will still need to perform an
Arthur> authentication on the potential partner which would eat
The key management protocols have been carefully designed to deal
with this.
Arthur> cpu cycles. - if ipsec is there, the host receives the
Arthur> connect attempt and retrieves the address, so what if it
Arthur> was signed. couldn't a bad entity sign fake ip addresses
Arthur> and then send them on to a potential host to be attacked?
Yes, it might cost CPU cycles. Denial of service attacks are very
difficult to prevent. The best that I think we can do is to assure that
existing connections will still get their fair share of CPU.
Arthur> - when will the infrastructure be in place so that a host
Arthur> can authenticate a connection attempt from the myriad
Arthur> potential connectees where certificates may have been
Arthur> issued by different certificate authorities
Different CA's? This sounds like a certificate management problem,
and I suggest we take this to SPKI or PKIX.
] Temporarily located in balmy Helsinki, Finland, at SSH | one quark [
] Michael Richardson, Sandelman Software Works, Ottawa, ON | two quark [
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red q blue q[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQB1AwUBMxrA/MmxxiPyUBAxAQGbyAL8DqhCtS6COfjUW7IUPEKuXKUHNs0OUL60
qCyTQb4QCbgKaNqFi5MeChsBz0oOAUO+jOKlh29Dz6vhXKK/aMEpNN3Dzb453QXP
N0wNrw+5AfROqxkn4cMnXHgsi0yZk7vc
=ser4
-----END PGP SIGNATURE-----
From owner-ipsec Mon Mar 3 17:05:32 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA04467 for ipsec-outgoing; Mon, 3 Mar 1997 17:01:58 -0500 (EST)
From: Dan.McDonald@Eng.sun.com (Dan McDonald)
Message-Id: <199703032206.OAA29233@kebe.eng.sun.com>
Subject: How many algorithms per SA/Transform?
To: ipsec@tis.com
Date: Mon, 3 Mar 1997 14:06:22 -0800 (PST)
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Hi folks!
I've a question about algorithms per transform/SA. The question is:
Will there realistically be more than one algorithm of a given
type (i.e. 2 or more ENCRYPTION algorithms or 2 or more
AUTHENTICATION algorithms) in a single security association?
I don't mean more than one algorithm, period. The Hughes DES/HMAC-MD5
transform proves that we need at least one encryption AND one authentication
algorithm in a single security association. What I'm talking about is if
there will ever be:
DES,Blowfish,Rot13/HMAC-MD5,HMAC-SHA,cksum
in a SINGLE SECURITY ASSOCIATION or a SINGLE TRANSFORM?
It's a question that I personally think the answer to is, "no". I can't
think of any good case (save perhaps protecting headers with one algorithm,
and the data with another...) where you'd need more than one algorithm of
each type in a single association.
Any comments, opinions, etc. are welcome.
--
Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT
Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S!
Phone: (415) 786-6815 |"rising falling at force ten
WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush
From owner-ipsec Mon Mar 3 17:05:49 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA04488 for ipsec-outgoing; Mon, 3 Mar 1997 17:03:28 -0500 (EST)
Message-ID: <01BC27DC.7D4CBA00@Tastid.cisco.com>
From: adams@cisco.com (Rob Adams)
To: ipsec@tis.com ('ipsec@tis.com')
Subject: truncation
Date: Mon, 3 Mar 1997 14:08:42 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Did we ever decide definitively on truncating MD5 and SHA hash's to 96 bits?
I think we did but I just want to be clear.
Also, how does this apply to the Hughes Combined transform? Do we truncate
the MD5 hash there also? I hope so for uniformity's sake.
-Rob
From owner-ipsec Mon Mar 3 18:23:02 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA04901 for ipsec-outgoing; Mon, 3 Mar 1997 18:20:03 -0500 (EST)
Posted-Date: Mon, 03 Mar 1997 18:18:30 +0000
Message-Id: <9703032324.AA89891@aurora.cis.upenn.edu>
To: Dan.McDonald@Eng.sun.com (Dan McDonald)
Cc: ipsec@tis.com
Subject: Re: How many algorithms per SA/Transform?
In-Reply-To: Your message of "Mon, 03 Mar 1997 14:06:22 PST."
<199703032206.OAA29233@kebe.eng.sun.com>
Date: Mon, 03 Mar 1997 18:18:30 +0000
From: "Angelos D. Keromytis" <angelos@aurora.cis.upenn.edu>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
In message <199703032206.OAA29233@kebe.eng.sun.com>, Dan McDonald writes:
>
>It's a question that I personally think the answer to is, "no". I can't
>think of any good case (save perhaps protecting headers with one algorithm,
>and the data with another...) where you'd need more than one algorithm of
>each type in a single association.
>
One could also have a mixed algorithm; instead of 3-DES, use DES for
first round, blowfish for second, etc...i can see this used for 2
reasons:
a) DES/Blowfish would be faster than 3-DES, more secure than 2-DES,
and prevent the DES keysearch problem (Blowfish/DES wouldn't
prevent that however - assuming the same key was used for both algorithms).
b) Use a stream cipher and then DES (or the other way around) to
obscure known-plaintext analysis.
- -Angelos
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBMxtcRb0pBjh2h1kFAQEiCgQAjFgD5vxqdmK2ffDUTI8Lv9R86SY4pFbR
PoDjUH2gNAMrg1p5q1PvU3hF49yFbxY8TfNvKo5n9xo46OFOC2Z6RHIdUOKMVBPN
WiiMCZ4VR482vkzzfp7/apOnE8PmJTbcxEtS4PejmBhZ/xvYn+nIXkZmeP4jObnL
1rpxCEkh2Rk=
=yeYy
-----END PGP SIGNATURE-----
From owner-ipsec Mon Mar 3 18:53:09 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA05095 for ipsec-outgoing; Mon, 3 Mar 1997 18:51:49 -0500 (EST)
Date: Mon, 3 Mar 1997 18:54:14 -0500
From: ho@earth.hpc.org (Hilarie Orman)
Message-Id: <199703032354.SAA24987@earth.hpc.org>
To: ipsec@tis.com
In-reply-to: Yourmessage <199703032336.QAA14832@baskerville.CS.Arizona.EDU>
Subject: Re: How many algorithms per SA/Transform?
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I think that the more creative uses of multiple algorithms should await
a future "active ipsec" architecture, where packets carry authenticated
applets that describe their crypto processing. The applet might be the
crypto routine(s) itself (themselves).
For the IETF here and now, one algorithm at a time. Hey, I never liked
putting the encryption and authentication algorithms into one transform
in the first place.
Hilarie
From owner-ipsec Mon Mar 3 21:20:09 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA05765 for ipsec-outgoing; Mon, 3 Mar 1997 21:17:45 -0500 (EST)
Date: Mon, 3 Mar 1997 21:21:54 -0500
From: Norman Shulman <norm@border.com>
X-Sender: norm@rafael.rnd.border.com
To: Dan McDonald <Dan.McDonald@Eng.sun.com>
cc: ipsec@tis.com
Subject: Re: How many algorithms per SA/Transform?
In-Reply-To: <199703032206.OAA29233@kebe.eng.sun.com>
Message-Id: <97Mar3.212302est.11650@elgreco.rnd.border.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
On Mon, 3 Mar 1997, Dan McDonald wrote:
> I've a question about algorithms per transform/SA. The question is:
>
> Will there realistically be more than one algorithm of a given
> type (i.e. 2 or more ENCRYPTION algorithms or 2 or more
> AUTHENTICATION algorithms) in a single security association?
>
> I don't mean more than one algorithm, period. The Hughes DES/HMAC-MD5
> transform proves that we need at least one encryption AND one authentication
> algorithm in a single security association. What I'm talking about is if
> there will ever be:
>
> DES,Blowfish,Rot13/HMAC-MD5,HMAC-SHA,cksum
>
> in a SINGLE SECURITY ASSOCIATION or a SINGLE TRANSFORM?
>
> It's a question that I personally think the answer to is, "no". I can't
> think of any good case (save perhaps protecting headers with one algorithm,
> and the data with another...) where you'd need more than one algorithm of
> each type in a single association.
>
> Any comments, opinions, etc. are welcome.
Recent relaxation of US export controls make DES more readily available
internationally. Someone who wants more security than DES provides might well
consider using AH-DES-DES-DES.
Norm
Norman Shulman Secure Computing Canada
Systems Developer Tel 1 416 813 2075
norm@border.com Fax 1 416 813 2001
From owner-ipsec Mon Mar 3 21:53:53 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA06014 for ipsec-outgoing; Mon, 3 Mar 1997 21:52:22 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v0300780eaf413fa43b10@[128.33.229.234]>
In-Reply-To: <97Mar3.212302est.11650@elgreco.rnd.border.com>
References: <199703032206.OAA29233@kebe.eng.sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 3 Mar 1997 21:57:47 -0500
To: Norman Shulman <norm@border.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: How many algorithms per SA/Transform?
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Norm,
I'm confused by your example, specifically "AH-DES-DES-DES." We
don't use DES with AH; we use keyed hash functions, e.g., HMAC. AH does
not offer encryption, ESP does.
But, in the broader context of this discussion, I agree with
Hilarie. Let's not make this even more complex than it already is.
Steve
From owner-ipsec Tue Mar 4 09:50:20 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA10113 for ipsec-outgoing; Tue, 4 Mar 1997 09:35:22 -0500 (EST)
Date: Tue, 4 Mar 1997 09:40:04 -0500
From: Norman Shulman <norm@border.com>
X-Sender: norm@rafael.rnd.border.com
To: Stephen Kent <kent@bbn.com>
cc: ipsec@tis.com
Subject: Re: How many algorithms per SA/Transform?
In-Reply-To: <v0300780eaf413fa43b10@[128.33.229.234]>
Message-Id: <97Mar4.094043est.11649@elgreco.rnd.border.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
On Mon, 3 Mar 1997, Stephen Kent wrote:
> I'm confused by your example, specifically "AH-DES-DES-DES." We
> don't use DES with AH; we use keyed hash functions, e.g., HMAC. AH does
> not offer encryption, ESP does.
Sorry for the confusing notation. My point is that someone who has DES but not triple
DES might want to use three DES transforms to achieve the effect of triple DES.
Norm
Norman Shulman Secure Computing Canada
Systems Developer Tel 1 416 813 2075
norm@border.com Fax 1 416 813 2001
From owner-ipsec Tue Mar 4 10:20:48 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA10322 for ipsec-outgoing; Tue, 4 Mar 1997 10:10:40 -0500 (EST)
Message-Id: <01BC2884.F8D2F420@erussell-2.ftp.com>
From: "Edward A. Russell" <erussell@ftp.com>
To: "'angelos@aurora.cis.upenn.edu'" <angelos@aurora.cis.upenn.edu>,
"'Dan.McDonald@Eng.sun.com'" <Dan.McDonald@Eng.sun.com>
Cc: "'ipsec@tis.com'" <ipsec@tis.com>
Subject: RE: How many algorithms per SA/Transform?
Date: Tue, 4 Mar 1997 10:15:22 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
>>Angelos D. Keromytis (angelos@aurora.cis.upenn.edu) said on 3/3/97 6:44 PM about Re: How many algorithms per SA/Transform?
-----BEGIN PGP SIGNED MESSAGE-----
>One could also have a mixed algorithm; instead of 3-DES, use DES for
>first round, blowfish for second, etc..
My guess is that would be labelled as a new singular transform with a definition
of how it should be applied (e.g. first do DES, them blowfish, etc.)
Just throwing a bunch of transforms into an SA does not give enough information
for interoperability. So even if the imaginary example you give were to come into
existance, it would be a single transform called the DES-BLOWS transform or
something like that and have its own draft for standard implementation.
Edward Russell
erussell@ftp.com
From owner-ipsec Tue Mar 4 11:12:54 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA10743 for ipsec-outgoing; Tue, 4 Mar 1997 11:07:34 -0500 (EST)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce
cc: ipsec@tis.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-ipsec-doi-02.txt
Date: Tue, 04 Mar 1997 09:49:49 -0500
Message-ID: <9703040949.aa18612@ietf.org>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
--NextPart
A Revised 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 : The Internet IP Security Domain of Interpretation
for ISAKMP
Author(s) : D. Piper
Filename : draft-ietf-ipsec-ipsec-doi-02.txt
Pages : 20
Date : 03/03/1997
The Internet Security Association and Key Management Protocol (ISAKMP)
defines a framework for security association management and cryptographic
key establishment for the Internet. This framework consists of defined
exchanges and processing guidelines that occur within a given Domain of
Interpretation (DOI). This document details the Internet IP Security DOI,
which is defined to cover the IP security protocols that use ISAKMP to
negotiate their security associations.
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-ipsec-doi-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ipsec-doi-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
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-ipsec-doi-02.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.
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: <19970303120116.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-ipsec-doi-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-ipsec-doi-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303120116.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ipsec Tue Mar 4 14:00:39 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA11844 for ipsec-outgoing; Tue, 4 Mar 1997 13:55:59 -0500 (EST)
Message-Id: <199703041900.LAA02411@fluffy.cisco.com>
To: Dan.McDonald@Eng.sun.com (Dan McDonald)
Cc: ipsec@tis.com
Subject: Re: How many algorithms per SA/Transform?
In-reply-to: Your message of "Mon, 03 Mar 1997 14:06:22 PST."
<199703032206.OAA29233@kebe.eng.sun.com>
Date: Tue, 04 Mar 1997 11:00:34 -0800
From: Derrell Piper <piper@tgv.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Dan,
While there's probably not a strong technical argument for something like
this, it's not forbidden by the architecture. It would require a base
Transform ID in the IPSEC DOI, some defined set (possibly null) of
associated attributes, and a draft describing the encapsulation format.
(For something this "unique", I'd strongly recommend a self-describing
Transform ID and a null attribute set.)
FWIW, I really don't expect anyone to propose anything like this...
Derrell
From owner-ipsec Wed Mar 5 18:44:17 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA21097 for ipsec-outgoing; Wed, 5 Mar 1997 18:36:06 -0500 (EST)
Message-Id: <3.0.32.19970305154052.009a5100@ibeam.jf.intel.com>
X-Sender: baiju@ibeam.jf.intel.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 05 Mar 1997 15:40:52 -0800
To: ipsec@tis.com
From: "Baiju V. Patel" <baiju@ibeam.jf.intel.com>
Subject: To compress or not to compress.
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I vote against including compression as part of IPSEC protocol for the
following reasons.
If each packet is compressed individually, and the dictionary is
refreshed for each and every packet, the gain in performance is not
clear at all (because there are many small packets on the Internet,
and there is lot of compressed content). The only gain is in compressing
large data packets which are not previously compressed by the
applications. So, I don't see how this will improve the performance
significantly.
The efficiency of compression improves with increasing
data size. Therefore, one can argue for compressing many packets using
a single dictionary. If such a scheme is deployed at network layer, it
can lead to significant problems for TCP because loss of single packet
can lead to loss of many TCP packets and timeouts.
Here is an example (Assume that dictionary is updated every 10
packets.)
- Host A is sending packets to B (these are TCP packets).
- Host A transmits packet 1, 2 and 3 in that order to host B.
- Host B receives packet 1 and decompresses it, updates its
dictionary.
- Packet 2 is lost and packet 3 is received successfully. The packet
three cannot be correctly decompressed at B because 2 is lost. It
also gets dictionary out of sinc.
- After TCP timeout, host A retransmits packet 2 and 3 to B (note that
these packets are compressed again because at IP layer, the
compression algorithm has no knowledge that it is indeed a
retransmitted packet).
- since the dictionary is out of sink, the packets are incorrectly
decompressed and hence discarded.
- This goes on until the dictionary is updated.
In conclusion, loss of single packet (or out of order delivery), can
lead to serious problems for TCP traffic.
Therefore, I vote ``no'' for including compression at IPSEC layer.
I am all for applications compressing.
Note that this not the situation with SSL where the TCP transmits
compressed stream. Therefore, the compressed data is reliably received
prior to decompression. (It is no different from transmitting a
compressed file). So, just because it is true for SSL does not
guarantee that it will work for IPSEC (as efficiently).
From owner-ipsec Thu Mar 6 12:30:36 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA26327 for ipsec-outgoing; Thu, 6 Mar 1997 12:25:30 -0500 (EST)
Message-Id: <2.2.32.19970305191238.00b439bc@mailserv-H.ftp.com>
X-Sender: naganand@mailserv-H.ftp.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 05 Mar 1997 14:12:38 -0500
To: Dan.McDonald@Eng.sun.com (Dan McDonald)
From: Naganand Doraswamy <naganand@ftp.com>
Subject: Re: How many algorithms per SA/Transform?
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 02:06 PM 3/3/97 -0800, Dan McDonald wrote:
>Hi folks!
>
>I've a question about algorithms per transform/SA. The question is:
>
> Will there realistically be more than one algorithm of a given
> type (i.e. 2 or more ENCRYPTION algorithms or 2 or more
> AUTHENTICATION algorithms) in a single security association?
>
>I don't mean more than one algorithm, period. The Hughes DES/HMAC-MD5
>transform proves that we need at least one encryption AND one authentication
>algorithm in a single security association. What I'm talking about is if
>there will ever be:
>
> DES,Blowfish,Rot13/HMAC-MD5,HMAC-SHA,cksum
>
>in a SINGLE SECURITY ASSOCIATION or a SINGLE TRANSFORM?
>
>It's a question that I personally think the answer to is, "no". I can't
>think of any good case (save perhaps protecting headers with one algorithm,
>and the data with another...) where you'd need more than one algorithm of
>each type in a single association.
>
>Any comments, opinions, etc. are welcome.
>
I would also say NO.
--Naganand
----------------------------------------------------------------
naganand@ftp.com
Tel #: (508)684-6743 (O)
From owner-ipsec Thu Mar 6 13:05:05 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA26637 for ipsec-outgoing; Thu, 6 Mar 1997 13:03:21 -0500 (EST)
Date: Thu, 6 Mar 1997 12:58:25 -0500 (EST)
Message-Id: <199703061758.MAA09960@carp.morningstar.com>
From: Ben Rogers <ben@Ascend.COM>
To: Naganand Doraswamy <naganand@ftp.com>
Cc: Dan.McDonald@Eng.sun.com (Dan McDonald), ipsec@tis.com
Subject: Re: How many algorithms per SA/Transform?
In-Reply-To: <2.2.32.19970305191238.00b439bc@mailserv-H.ftp.com>
References: <2.2.32.19970305191238.00b439bc@mailserv-H.ftp.com>
Reply-To: ben@Ascend.COM (Ben Rogers)
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Naganand Doraswamy writes:
> At 02:06 PM 3/3/97 -0800, Dan McDonald wrote:
> >Hi folks!
> >
> >I've a question about algorithms per transform/SA. The question is:
> >
> > Will there realistically be more than one algorithm of a given
> > type (i.e. 2 or more ENCRYPTION algorithms or 2 or more
> > AUTHENTICATION algorithms) in a single security association?
>From the latest draft (draft-ietf-ipsec-arch-sec-01.txt), I understand
that that you should never have more than one transform per SA:
1.5 Security Association Management
...
A single IPsec Security Association is a simplex (unidirectional)
connection with which either AH or ESP (but not both) is employed. If both
AH and ESP protection is to be applied to a traffic stream, then two (or
more) security associations are created to control processing of the
traffic stream.
To me, this seems to be a clarifcation of RFC1825, and not a change in
intent. Is this not the case?
ben
From owner-ipsec Thu Mar 6 13:39:55 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA26888 for ipsec-outgoing; Thu, 6 Mar 1997 13:37:08 -0500 (EST)
Message-Id: <3.0.16.19970306133925.1d1f5ae8@pop3.pn.com>
X-Pgp-Key: <http://www.shore.net/~sable/info/rltkey.htm>
X-Sender: rodney@pop3.pn.com
X-Mailer: Windows Eudora Pro Version 3.0 (16)
Date: Thu, 06 Mar 1997 13:41:52 -0500
To: ipsec@tis.com
From: Rodney Thayer <rodney@sabletech.com>
Subject: Re: How many algorithms per SA/Transform?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Please remind me we don't ever want to be in a situation where we both
encrypt and sign each packet, thus using an encryption algorithm, a
signing algorithm, and an authentication algorithm....
At 02:12 PM 3/5/97 -0500, you wrote:
>At 02:06 PM 3/3/97 -0800, Dan McDonald wrote:
>>Hi folks!
>>
>>I've a question about algorithms per transform/SA. The question is:
>>
>> Will there realistically be more than one algorithm of a given
>> type (i.e. 2 or more ENCRYPTION algorithms or 2 or more
>> AUTHENTICATION algorithms) in a single security association?
>>
>>I don't mean more than one algorithm, period. The Hughes DES/HMAC-MD5
>>transform proves that we need at least one encryption AND one authentication
>>algorithm in a single security association. What I'm talking about is if
>>there will ever be:
>>
>> DES,Blowfish,Rot13/HMAC-MD5,HMAC-SHA,cksum
>>
>>in a SINGLE SECURITY ASSOCIATION or a SINGLE TRANSFORM?
>>
>>It's a question that I personally think the answer to is, "no". I can't
>>think of any good case (save perhaps protecting headers with one algorithm,
>>and the data with another...) where you'd need more than one algorithm of
>>each type in a single association.
>>
>>Any comments, opinions, etc. are welcome.
>>
>I would also say NO.
>
>--Naganand
>----------------------------------------------------------------
>naganand@ftp.com
>Tel #: (508)684-6743 (O)
>
>
>
--------
Rodney Thayer <rodney@sabletech.com>
PGP Fingerprint: BB1B6428 409129AC 076B9DE1 4C250DD8
From owner-ipsec Thu Mar 6 14:21:08 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA27139 for ipsec-outgoing; Thu, 6 Mar 1997 14:19:35 -0500 (EST)
Message-Id: <97Mar6.142500est.11651@elgreco.rnd.border.com>
To: ipsec@tis.com
Subject: Grouping SAs (was Re: How many algorithms per SA/Transform?)
References: <2.2.32.19970305191238.00b439bc@mailserv-H.ftp.com>
<199703061758.MAA09960@carp.morningstar.com>
In-reply-to: ben's message of "Thu, 06 Mar 1997 12:58:25 -0500".
<199703061758.MAA09960@carp.morningstar.com>
From: "C. Harald Koch" <chk@utcc.utoronto.ca>
X-uri: <URL:http://chk.home.ml.org/>
X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw
z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ)
did@Pr9
Date: Thu, 6 Mar 1997 14:24:07 -0500
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
In message <199703061758.MAA09960@carp.morningstar.com>, Ben Rogers writes:
>
> A single IPsec Security Association is a simplex (unidirectional)
> connection with which either AH or ESP (but not both) is employed. If both
> AH and ESP protection is to be applied to a traffic stream, then two (or
> more) security associations are created to control processing of the
> traffic stream.
>
> To me, this seems to be a clarifcation of RFC1825, and not a change in
> intent. Is this not the case?
Which brings us back to an old question: what do you call the set of
Security Associations that describe the actual desired results, as in
"use AH(HMAC-ND5) for authentication, ESP(DES)(tunnel mode) for encryption,
------------------------------- ------------------------------------
SA 1 SA 2
and only accept traffic that has AH(HMAC-MD5) , ESP(DES)(tunnel mode)."
----------- ---------------------
SA 3 SA 4
Is this perhaps a "Security Association Bundle"? Anyone got a better name?
--
Harald Koch
chk@utcc.utoronto.ca
From owner-ipsec Thu Mar 6 15:14:55 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA27486 for ipsec-outgoing; Thu, 6 Mar 1997 15:12:29 -0500 (EST)
Date: Thu, 6 Mar 1997 15:17:05 -0500
From: Norman Shulman <norm@border.com>
X-Sender: norm@rafael.rnd.border.com
To: "C. Harald Koch" <chk@utcc.utoronto.ca>
cc: ipsec@tis.com
Subject: Re: Grouping SAs (was Re: How many algorithms per SA/Transform?)
In-Reply-To: <97Mar6.142500est.11651@elgreco.rnd.border.com>
Message-Id: <97Mar6.151803est.11650@elgreco.rnd.border.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
On Thu, 6 Mar 1997, C. Harald Koch wrote:
> Which brings us back to an old question: what do you call the set of
> Security Associations that describe the actual desired results, as in
>
> "use AH(HMAC-ND5) for authentication, ESP(DES)(tunnel mode) for encryption,
> ------------------------------- ------------------------------------
> SA 1 SA 2
>
> and only accept traffic that has AH(HMAC-MD5) , ESP(DES)(tunnel mode)."
> ----------- ---------------------
> SA 3 SA 4
>
>
> Is this perhaps a "Security Association Bundle"? Anyone got a better name?
How about just "Security Bundle" or "Security Package"?
Norm
Norman Shulman Secure Computing Canada
Systems Developer Tel 1 416 813 2075
norm@border.com Fax 1 416 813 2001
From owner-ipsec Thu Mar 6 15:36:08 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA27640 for ipsec-outgoing; Thu, 6 Mar 1997 15:34:41 -0500 (EST)
Message-Id: <199703062034.PAA27640@portal.ex.tis.com>
Date: Thu, 06 Mar 1997 15:10:49 -0500
From: Rob & Rachel Glenn <rrglenn@erols.com>
Reply-To: rrglenn@erols.com
X-Mailer: Mozilla 3.0Gold (Win95; I)
MIME-Version: 1.0
To: Rob Adams <adams@cisco.com>
CC: ipsec@tis.com
Subject: Re: truncation
References: <01BC27DC.7D4CBA00@Tastid.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Yes, the HMAC hash's will be truncated to 96 bits. I hope to have the
"new" AH-HMAC drafts out sometime next week. I can't speak for
Jim Hughes draft.
Rob G.
Rob Adams wrote:
>
> Did we ever decide definitively on truncating MD5 and SHA hash's to 96 bits?
> I think we did but I just want to be clear.
>
> Also, how does this apply to the Hughes Combined transform? Do we truncate
> the MD5 hash there also? I hope so for uniformity's sake.
>
> -Rob
From owner-ipsec Thu Mar 6 15:37:34 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA27656 for ipsec-outgoing; Thu, 6 Mar 1997 15:36:11 -0500 (EST)
From: owner-ipsec@ex.tis.com
Message-Id: <199703062036.PAA27656@portal.ex.tis.com>
Subject: question about draft semantics
To: ipsec@tis.com
Date: Thu, 6 Mar 1997 22:18:27 +0200 (EET)
Organization: Helsinki University of Technology, TCM-laboratory
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Best ipsec mailing list members,
The following text is from draft-ietf-ipsec-arch-sec-01.txt:
> 1.4 Minimal Essential Support
>
......
>
> The following sequences of combinations of AH and ESP, each
> represented by a separate security association, must be supported by an
> IPsec-compliant host: AH, ESP (tunnel), ESP(transport), AH-ESP(transport),
> AH-ESP(tunnel), ESP(tunnel)-AH, AH-ESP(tunnel)-ESP(transport), and
> ESP(tunnel)-ESP(transport).
>
......
>Atkinson [Page 5]
>
>Internet Draft Security Architecture for IP 10 November 1996
To me, this part of the text seems a bit unclear. I would interpret it
so, that the word "each" would refer to the word "combinations". Then
this text would in my opinion mean that e.g. the combination
AH-ESP(transport) would have one SPI value, not one SPI value for AH
and one SPI for ESP(transport). Am I misinterpreting the text? Will
always all transforms have an SPI of their own?
Kindly,
Bengt Sahlin
From owner-ipsec Thu Mar 6 17:20:33 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA28204 for ipsec-outgoing; Thu, 6 Mar 1997 17:17:51 -0500 (EST)
Date: 6 Mar 97 16:20:54 -0600
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
From: "James Hughes" <hughes@nsco.network.com>
To: dharkins@cisco.com
Cc: rmonsour@earthlink.net, ipsec@tis.com
X-Mailer: Cyberdog/2.0b1
Mime-Version: 1.0
Message-Id: <AF449F70-173CB6@129.191.63.3>
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I have been hesitant to reply to this.
Network Systems presented compression as a feature for an ESP to the IETF
IPSEc group in san jose in 1994. NSC has since productized the proprietary
ESP that includes compression and pays royalties to IBM for this privilege.
We also have numbers on the compression ratios in real world, long run
time situations, and even clearing the dictionary on every packet, we
average 2:1 compression of data. Even on most small packets, the overhead
of the encapsulationis removed by what compression there is.
(Sarcasm on) Frankly it is in our best interest that the status quo of the
IPSEC group's inability to converge on a compression standard continue
(Sarcasm off).
After igniting this issue, I would also suggest that this is not very easy
issue to resolve.
Even if there is someone willing to claim that their compression is
unencumbered by patent, are they willing to indemnify you if someone claims
it is not? Our contract with IBM includes a statement that they would
defend us if their code violates someone else's patent. NSC made a
conscious decision to buy because our parent (StorageTek) has deep pockets
and would be deeply vulnerable if a claimed public domain compression
algorithm was not.
I do not know how to handle this.
jim
On Thu, Feb 27, 1997 7:57 PM, Phil Karn <mailto:karn@qualcomm.com> wrote:
> >I support the use of compression but not in IPsec. It should be done up
> >higher, perhaps the transport level. It's better to compress the stream
> >of data before it's divided into packets than to wait and compress each
> >packet. I'd rather see 50 packets then 100 smaller ones.
>
> I feel exactly the same way. I've seen nothing that can beat the
> performance of gzip-style compress up above TCP, e.g., in SSH with the
> -C option. The fact that gzip is widely distributed GNUware, free of
> patent concerns, is just icing on the cake.
>
> Phil
>
>
From owner-ipsec Thu Mar 6 17:56:11 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA28487 for ipsec-outgoing; Thu, 6 Mar 1997 17:54:37 -0500 (EST)
Message-ID: <c=US%a=_%p=IRE%l=WHO-970306230708Z-368@who.ire.com>
From: Raul Olaya <rolaya@ire.com>
To: "'ipsec@ex.tis.com'" <ipsec@ex.tis.com>
Subject: IP packet fragmentation
Date: Thu, 6 Mar 1997 18:07:08 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
How are IP security transforms applied to fragmented packets (for
example a 2000 byte PING which is fragmented into a 1500 byte fragment
(header+data) and 548 byte fragment (header+data))?. Is the packet
reassembled in the outbound direction and then the security transform
applied to the entire reassembled packet?, or is the security transform
applied to the first 1500 byte fragment, and 548 byte fragment
independently?
Raul Olaya
From owner-ipsec Thu Mar 6 18:18:13 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA28625 for ipsec-outgoing; Thu, 6 Mar 1997 18:16:37 -0500 (EST)
From: Dan.McDonald@Eng.sun.com (Dan McDonald)
Message-Id: <199703062319.PAA08906@kebe.eng.sun.com>
Subject: Re: IP packet fragmentation
To: rolaya@ire.com (Raul Olaya)
Date: Thu, 6 Mar 1997 15:19:33 -0800 (PST)
Cc: ipsec@tis.com
In-Reply-To: <c=US%a=_%p=IRE%l=WHO-970306230708Z-368@who.ire.com> from "Raul Olaya" at Mar 6, 97 06:07:08 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> How are IP security transforms applied to fragmented packets (for
> example a 2000 byte PING which is fragmented into a 1500 byte fragment
> (header+data) and 548 byte fragment (header+data))?. Is the packet
> reassembled in the outbound direction and then the security transform
> applied to the entire reassembled packet?
IPsec _must_ be done before fragmentation. This is specified in RFC 1825,
and why this is a good idea is documented in Bellovin's USENIX Security paper
from last summer.
Bump-in-the-stack encryptors are a nice short-term fix, but in the long term,
IPsec NEEDS to dig its meathooks into the general IP code. Basically,
outbound processing is:
1.) create IP headers
2.) Fill in headers
3.) Apply IPsec
4.) Do I fragment? If so, fragment.
5.) Send out the wire.
On inbound packets...
1.) Get off the wire, check if for me. If not, forward.
2.) Reassemble
3.) Apply IPsec
4.) Determine HLP/endpoint/etc.
> or is the security transform applied to the first 1500 byte fragment, and
> 548 byte fragment independently?
NO NO NO! This is bad. I'm sure lots of implementations currently do this,
but it's bad because either:
1.) You have to keep security information per reassembly queue
** OR **
2.) The bad guy can inject fragments of his choosing.
IMPORTANT SAFETY TIP: IPsec, THEN fragment.
--
Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT
Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S!
Phone: (415) 786-6815 |"rising falling at force ten
WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush
From owner-ipsec Thu Mar 6 19:13:01 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA28901 for ipsec-outgoing; Thu, 6 Mar 1997 19:09:02 -0500 (EST)
Date: Thu, 6 Mar 1997 16:13:30 -0800
Message-Id: <199703070013.QAA26923@gump.eng.ascend.com>
From: Karl Fox <karl@Ascend.COM>
To: Dan.McDonald@Eng.sun.com (Dan McDonald)
Cc: rolaya@ire.com (Raul Olaya), ipsec@tis.com
Subject: Re: IP packet fragmentation
In-Reply-To: <199703062319.PAA08906@kebe.eng.sun.com>
References: <c=US%a=_%p=IRE%l=WHO-970306230708Z-368@who.ire.com>
<199703062319.PAA08906@kebe.eng.sun.com>
Reply-To: Karl Fox <karl@Ascend.COM>
Organization: Ascend Communications
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> > How are IP security transforms applied to fragmented packets (for
> > example a 2000 byte PING which is fragmented into a 1500 byte fragment
> > (header+data) and 548 byte fragment (header+data))?. Is the packet
> > reassembled in the outbound direction and then the security transform
> > applied to the entire reassembled packet?
>
> IPsec _must_ be done before fragmentation. This is specified in RFC 1825,
> and why this is a good idea is documented in Bellovin's USENIX Security paper
> from last summer.
If you're running on a host, yes. If you're running on an encrypting
gateway, you wrap each fragment in a tunnel mode packet. Of course,
you might fragment the resulting encrypted datagram if it's too big.
--
Karl Fox, servant of God, employee of Ascend Communications
3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841
From owner-ipsec Thu Mar 6 19:15:56 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA28952 for ipsec-outgoing; Thu, 6 Mar 1997 19:14:33 -0500 (EST)
From: Dan.McDonald@Eng.sun.com (Dan McDonald)
Message-Id: <199703070019.QAA09101@kebe.eng.sun.com>
Subject: Re: IP packet fragmentation
To: karl@Ascend.COM
Date: Thu, 6 Mar 1997 16:19:18 -0800 (PST)
Cc: ipsec@tis.com
In-Reply-To: <199703070013.QAA26923@gump.eng.ascend.com> from "Karl Fox" at Mar 6, 97 04:13:30 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> If you're running on a host, yes. If you're running on an encrypting
> gateway, you wrap each fragment in a tunnel mode packet.
Good point, but those aren't YOUR fragments. Before YOU fragment, you
encrypt. And let's not forget IPv6, where you aren't supposed to have
intermediate fragmentation, but it _technically_ happens when you
encapsulate. The same analogy applies to IPv4 datagrams with the "don't
fragment" bit set. You don't fragment the packet to be forwarded, but if you
encapsulate in a tunnel, the tunnel source/dst addresses are of the tunnel
endpoints. The end-to-end is tunnel-end to tunnel-end in this case.
> Of course, you might fragment the resulting encrypted datagram if it's too
> big.
See above.
Good call, Karl.
Dan
From owner-ipsec Fri Mar 7 03:07:21 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA01202 for ipsec-outgoing; Fri, 7 Mar 1997 03:03:31 -0500 (EST)
Message-Id: <199703070756.JAA04190@morden.ssh.fi>
To: ipsec@tis.com
Subject: Re: Grouping SAs (was Re: How many algorithms per SA/Transform?)
In-reply-to: Your message of "Thu, 06 Mar 1997 15:17:05 EST."
<97Mar6.151803est.11650@elgreco.rnd.border.com>
Date: Fri, 07 Mar 1997 09:55:35 +0200
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
>>>>> "Norman" == Norman Shulman <norm@border.com> writes:
>> Is this perhaps a "Security Association Bundle"? Anyone got a
>> better name?
Norman> How about just "Security Bundle" or "Security Package"?
Uh... "policy" ??
] Temporarily located in balmy Helsinki, Finland, at SSH | one quark [
] Michael Richardson, Sandelman Software Works, Ottawa, ON | two quark [
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red q blue q[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
From owner-ipsec Fri Mar 7 11:26:01 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA03952 for ipsec-outgoing; Fri, 7 Mar 1997 11:21:23 -0500 (EST)
Date: Fri, 7 Mar 1997 10:53:40 -0500 (EST)
Message-Id: <199703071553.KAA03840@carp.morningstar.com>
From: Ben Rogers <ben@Ascend.COM>
To: "C. Harald Koch" <chk@utcc.utoronto.ca>
Cc: ipsec@tis.com
Subject: Grouping SAs (was Re: How many algorithms per SA/Transform?)
In-Reply-To: <97Mar6.142500est.11651@elgreco.rnd.border.com>
Reply-To: ben@Ascend.COM (Ben Rogers)
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
C. Harald Koch writes:
> Which brings us back to an old question: what do you call the set of
> Security Associations that describe the actual desired results, as in
>
> "use AH(HMAC-ND5) for authentication, ESP(DES)(tunnel mode) for encryption,
> ------------------------------- ------------------------------------
> SA 1 SA 2
>
> and only accept traffic that has AH(HMAC-MD5) , ESP(DES)(tunnel mode)."
> ----------- ---------------------
> SA 3 SA 4
>
>
> Is this perhaps a "Security Association Bundle"? Anyone got a better name?
We use the term "Security Scheme" which is nice because it is relatively
simple, accurately portrays it's own contents, and doesn't sound like a
stilted computer geek term.
Of course, if the IETF needs to acronym-ize the term (as it seems to do
with everything in the whole world), you might end up with a bit of a
negative connotation.
ben
From owner-ipsec Fri Mar 7 13:33:45 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA04720 for ipsec-outgoing; Fri, 7 Mar 1997 13:30:49 -0500 (EST)
Message-Id: <199703071835.AA275259711@relay.hp.com>
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Cc: ipsec@tis.com
Subject: Re: Grouping SAs (was Re: How many algorithms per SA/Transform?)
In-Reply-To: mcr's message of Fri, 07 Mar 1997 09:55:35 +0200.
<199703070756.JAA04190@morden.ssh.fi>
Date: Fri, 07 Mar 1997 13:35:10 -0500
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> Norman> How about just "Security Bundle" or "Security Package"?
>
> Uh... "policy" ??
Too high level; in my mind, "policy" would cover things like "I need
to encrypt all packets sent outside the LAN and authenticated all
packets inbound from outside the LAN..".
'SA bundle' sounds good to me since "security association" has been
defined to be something more low level..
- Bill
From owner-ipsec Fri Mar 7 14:00:48 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA04915 for ipsec-outgoing; Fri, 7 Mar 1997 13:58:58 -0500 (EST)
Date: Fri, 7 Mar 1997 13:59:58 -0500
From: John Lowry <jlowry@bbn.com>
Message-Id: <199703071859.NAA06697@dave.bbn.com>
To: mcr@sandelman.ottawa.on.ca, sommerfeld@apollo.hp.com
Subject: Re: Grouping SAs (was Re: How many algorithms per SA/Transform?)
Cc: ipsec@tis.com
X-Sun-Charset: US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Microsoft has frequently been using the word BLOB go cover an
aggregation of "stuff" that mere mortals shouldn't play with.
How about SA BLOB ?
:-)
> From owner-ipsec@portal.ex.tis.com Fri Mar 7 13:50:29 1997
> To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
> Cc: ipsec@tis.com
> Subject: Re: Grouping SAs (was Re: How many algorithms per SA/Transform?)
> Date: Fri, 07 Mar 1997 13:35:10 -0500
> From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
>
> > Norman> How about just "Security Bundle" or "Security Package"?
> >
> > Uh... "policy" ??
>
> Too high level; in my mind, "policy" would cover things like "I need
> to encrypt all packets sent outside the LAN and authenticated all
> packets inbound from outside the LAN..".
>
> 'SA bundle' sounds good to me since "security association" has been
> defined to be something more low level..
>
> - Bill
>
From owner-ipsec Fri Mar 7 15:00:30 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA05298 for ipsec-outgoing; Fri, 7 Mar 1997 14:56:31 -0500 (EST)
Date: Fri, 7 Mar 1997 21:02:30 +0100
From: saiz@gc.ssr.upm.es ("LUIS SAIZ GIMENO")
Message-Id: <199703072002.AA04809@orfeo.gc.ssr.upm.es>
To: ipsec@tis.com
Subject: Re: Grouping SAs (was Re: How many algorithms per SA/Transform?)
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> From owner-ipsec@portal.ex.tis.com Fri Mar 7 20:51:56 1997
> Date: Fri, 7 Mar 1997 13:59:58 -0500
> From: John Lowry <jlowry@bbn.com>
> To: mcr@sandelman.ottawa.on.ca, sommerfeld@apollo.hp.com
> Subject: Re: Grouping SAs (was Re: How many algorithms per SA/Transform?)
> Cc: ipsec@tis.com
> X-Sun-Charset: US-ASCII
> Sender: owner-ipsec@ex.tis.com
> Content-Length: 881
>
> Microsoft has frequently been using the word BLOB go cover an
> aggregation of "stuff" that mere mortals shouldn't play with.
> How about SA BLOB ?
I'm not an english native but *BLOB* is used in crypto too, can this confuse people??
Luis Saiz
From owner-ipsec Fri Mar 7 15:18:10 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA05434 for ipsec-outgoing; Fri, 7 Mar 1997 15:15:09 -0500 (EST)
From: bmanning@isi.edu
Posted-Date: Fri, 7 Mar 1997 12:19:15 -0800 (PST)
Message-Id: <199703072019.AA08777@zed.isi.edu>
Subject: Re: Grouping SAs (was Re: How many algorithms per SA/Transform?)
To: saiz@gc.ssr.upm.es (LUIS SAIZ GIMENO)
Date: Fri, 7 Mar 1997 12:19:15 -0800 (PST)
Cc: ipsec@tis.com
In-Reply-To: <199703072002.AA04809@orfeo.gc.ssr.upm.es> from "LUIS SAIZ GIMENO" at Mar 7, 97 09:02:30 pm
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> > Microsoft has frequently been using the word BLOB go cover an
> > aggregation of "stuff" that mere mortals shouldn't play with.
> > How about SA BLOB ?
>
> I'm not an english native but *BLOB* is used in crypto too, can this confuse people??
>
> Luis Saiz
Its also used in database work for very large, undifferentiated datasets.
--
--bill
From owner-ipsec Sat Mar 8 09:58:56 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA10221 for ipsec-outgoing; Sat, 8 Mar 1997 09:51:14 -0500 (EST)
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <v03007803af45f2683494@[128.33.229.242]>
In-Reply-To: <199703062036.PAA27656@portal.ex.tis.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 7 Mar 1997 11:29:57 -0500
To: owner-ipsec@ex.tis.com
From: Stephen Kent <kent@bbn.com>
Subject: Re: question about draft semantics
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Bengt,
I'm sorry that the text is not clear. It was contributed by me and
I'll make sure the ambiguity is removed in the next draft. The intent is
that each AH or ESP use require a separate SA, as has been the case for
some time. Each combination of AH and ESP applied to a class of traffic
might be called an "SA bundle" as suggested in a recent message, but there
is no codified nomenclature for such aggregates yet.
Steve
From owner-ipsec Sat Mar 8 12:28:25 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA10905 for ipsec-outgoing; Sat, 8 Mar 1997 12:25:51 -0500 (EST)
Date: Sat, 8 Mar 97 17:17:15 GMT Standard Time
From: Ran Atkinson <rja@inet.org>
Subject: Re: transport vs network and ipsec syn
To: Arthur Parkos <parkosar@pb.com>, ipsec@tis.com
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <9701288571.AA857165346@smtppc.ct.pb.com>
Message-ID: <Chameleon.857841962.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
--- On Fri, 28 Feb 97 13:15:23 EST Arthur Parkos <parkosar@pb.com> wrote:
> one question (multipart), i was not sure how ipsec addresses the syn attack:
>
> - it's not guaranteed that all connections will be attempted with ipsec
> authentication instantiated. therefore a host will still need to respond to the
> request for a connection. or will a host refuse all connect attempts from
> non-ipsec host.
The NRL IPsec code that I wrote actually permits the system administrator
to configure the node such that connection requests arriving without
IPsec are simply dropped and not passed up to TCP.
In such a configuration, the node is fully protected against TCP session
stealing attacks.
The node is also protected from hosts that it has no IPSEC Security
Association with.
Since the IPSEC Security Association creation requires at least one new
round-trip, the current form of TCP SYN flooding attacks (which
use a bogus source IP address in the SYN packets) are precluded.
If the attacker uses a real source IP address to attack another node, then
the attacker's identity is known and provable -- in which case one can
add packet filters to one's router/node and/or call the Police.
> - if ipsec is implemented, the host will still need to perform an
> authentication on the potential partner which would eat cpu cycles.
Experience with the cisco ISAKMP/Oakley daemon and NRL IPsec code on
a BSD Pentium/90 box with 16 MB of RAM indicates this is not a significant
operational issue.
> - if ipsec is there, the host receives the connect attempt and retrieves the
> address, so what if it was signed. couldn't a bad entity sign fake ip addresses
> and then send them on to a potential host to be attacked?
I can't parse the above.
> - when will the infrastructure be in place so that a host can authenticate
> a connection attempt from the myriad potential connectees where
> certificates may have been issued by different certificate authorities
Not clear how you are defining "infrastructure". If one considers
the potential use of DNSSEC to distribute signed public key values,
deployment could happen fairly quickly after the next version of BIND
(which reportedly will include DNSSEC extensions) is released. TIS
has already obtained US Export Licensing for BIND with DNSSEC, so
that shouldn't be an obstacle.
Ran
rja@Inet.org
From owner-ipsec Sat Mar 8 12:38:41 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA10967 for ipsec-outgoing; Sat, 8 Mar 1997 12:37:22 -0500 (EST)
Date: Sat, 8 Mar 97 17:32:11 GMT Standard Time
From: Ran Atkinson <rja@inet.org>
Subject: Re: How many algorithms per SA/Transform?
To: Ben Rogers <ben@Ascend.COM>, Naganand Doraswamy <naganand@ftp.com>
Cc: Dan McDonald <Dan.McDonald@Eng.sun.com>, ipsec@tis.com
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <199703061758.MAA09960@carp.morningstar.com>
Message-ID: <Chameleon.857842667.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
--- On Thu, 6 Mar 1997 12:58:25 -0500 (EST) Ben Rogers <ben@Ascend.COM> wrote:
> >From the latest draft (draft-ietf-ipsec-arch-sec-01.txt), I understand
> that that you should never have more than one transform per SA:
>
> 1.5 Security Association Management
>
> ...
>
> A single IPsec Security Association is a simplex (unidirectional)
> connection with which either AH or ESP (but not both) is employed. If both
> AH and ESP protection is to be applied to a traffic stream, then two (or
> more) security associations are created to control processing of the
> traffic stream.
>
> To me, this seems to be a clarifcation of RFC1825, and not a change in
> intent. Is this not the case?
What you say makes sense to me, as the editor of RFC-1825.
I will note, however, that with the Combined ESP transform one somewhat
obviates the need for end-to-end AH+ESP that existed when RFC-1828/RFC-1829
were the only standards-track transforms.
There might be legitimate situations where ESP were used from H1 to H2
and a tunnel-mode AH were in use from R1 to R2, where H1,H2 are IPsec-
capable hosts and R1,R2 are IPsec-capable encrypting routers (aka
security gateways), and the topology were loosely described as:
H1----R1---[IP cloud]---R2---H2
This situation would cause the packets on the wire between R1 and R2 to look
something like this:
[IP, R1->R2][AH][IP, H1->H2][ESP[user data]]
Ran
rja@inet.org
From owner-ipsec Sat Mar 8 12:47:46 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA11024 for ipsec-outgoing; Sat, 8 Mar 1997 12:45:53 -0500 (EST)
Date: Sat, 8 Mar 97 17:41:51 GMT Standard Time
From: Ran Atkinson <rja@inet.org>
Subject: Re: question about draft semantics
To: ipsec@tis.com, owner-ipsec@ex.tis.com
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <199703062036.PAA27656@portal.ex.tis.com>
Message-ID: <Chameleon.857843182.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
--- On Thu, 6 Mar 1997 22:18:27 +0200 (EET) owner-ipsec@ex.tis.com wrote:
> To me, this part of the text seems a bit unclear.
Mea culpa. I'm sure it will become more clear after Steve Kent
edits the text. :-)
The correct interpretation is thus:
AH and ESP have separate and distinct SPI spaces.
When processing a packet, one always knows whether the
header being processed is AH or ESP -- hence one knows
whether it is an AH SPI or an ESP SPI.
Correspondingly, a single Security Association includes
only either ESP or AH. No single Security Association
contains both ESP and AH. If ESP and AH are used together,
there are two distinct SAs -- one for ESP and another for AH.
If I'm still not being clear, please post a followup question and
I'll try again. :-)
Ran
rja@inet.org
From owner-ipsec Sun Mar 9 20:24:43 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA18157 for ipsec-outgoing; Sun, 9 Mar 1997 20:16:33 -0500 (EST)
Date: Sun, 9 Mar 1997 20:19:15 -0500
From: ho@earth.hpc.org (Hilarie Orman)
Message-Id: <199703100119.UAA10857@earth.hpc.org>
To: rrglenn@erols.com
Cc: ipsec@tis.com
In-reply-to: Yourmessage <199703062049.NAA10706@baskerville.CS.Arizona.EDU>
Subject: Re: truncation
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> Yes, the HMAC hash's will be truncated to 96 bits. I hope to have the
> "new" AH-HMAC drafts out sometime next week. I can't speak for
> Jim Hughes draft.
> Rob G.
> Rob Adams wrote:
> >
> > Did we ever decide definitively on truncating MD5 and SHA hash's to 96 bits?
> > I think we did but I just want to be clear.
> >
> > Also, how does this apply to the Hughes Combined transform? Do we truncate
> > the MD5 hash there also? I hope so for uniformity's sake.
> >
> > -Rob
The MD5 truncation is not recommended.
Hilarie
From owner-ipsec Sun Mar 9 23:39:46 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA19111 for ipsec-outgoing; Sun, 9 Mar 1997 23:37:46 -0500 (EST)
From: HUGO@watson.ibm.com
Message-Id: <199703100442.XAA33606@mailhub1.watson.ibm.com>
Date: Sun, 9 Mar 97 23:42:06 EST
To: ho@earth.hpc.org, rrglenn@erols.com
cc: ipsec@tis.com
Subject: truncation
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Ref: Your note of Sun, 9 Mar 1997 20:19:15 -0500
Hilarie,
you say: > The MD5 truncation is not recommended.
we are talking here about truncating HMAC-MD5.
Is there any reason why is that "not recommended"?
we're finally close to settling this issue so any
recommendation against needs to be clearly justified.
Hugo
From owner-ipsec Mon Mar 10 08:01:19 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA21527 for ipsec-outgoing; Mon, 10 Mar 1997 07:57:51 -0500 (EST)
Message-Id: <3.0.16.19970310075404.1e477788@pop3.pn.com>
X-Pgp-Key: <http://www.shore.net/~sable/info/rltkey.htm>
X-Sender: rodney@pop3.pn.com
X-Mailer: Windows Eudora Pro Version 3.0 (16)
Date: Mon, 10 Mar 1997 08:02:58 -0500
To: ipsec@tis.com
From: Rodney Thayer <rodney@sabletech.com>
Subject: Re: truncation
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Could someone remind us where the justification is for truncation? I
remember in San Jose, Hugo stood up and said it was a good idea. I don't
remember where it got discussed or what papers were referenced/etc. I
realize this probably went by sometime in the past two months but I don't
recall when.
At 08:19 PM 3/9/97 -0500, you wrote:
>> Yes, the HMAC hash's will be truncated to 96 bits. I hope to have the
>> "new" AH-HMAC drafts out sometime next week. I can't speak for
>> Jim Hughes draft.
>
>> Rob G.
>
>> Rob Adams wrote:
>> >
>> > Did we ever decide definitively on truncating MD5 and SHA hash's to
96 bits?
>> > I think we did but I just want to be clear.
>> >
>> > Also, how does this apply to the Hughes Combined transform? Do we
truncate
>> > the MD5 hash there also? I hope so for uniformity's sake.
>> >
>> > -Rob
>
>The MD5 truncation is not recommended.
>
>Hilarie
>
>
>
--------
Rodney Thayer <rodney@sabletech.com>
PGP Fingerprint: BB1B6428 409129AC 076B9DE1 4C250DD8
From owner-ipsec Mon Mar 10 10:12:59 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA22220 for ipsec-outgoing; Mon, 10 Mar 1997 10:07:58 -0500 (EST)
Date: Mon, 10 Mar 1997 10:10:07 -0500
From: ho@earth.hpc.org (Hilarie Orman)
Message-Id: <199703101510.KAA05281@earth.hpc.org>
To: HUGO@watson.ibm.com
Cc: rrglenn@erols.com, ipsec@tis.com
In-reply-to: Yourmessage <199703100442.XAA33606@mailhub1.watson.ibm.com>
Subject: Re: truncation
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
MD5 is already borderline, and the removal of that much of the output
seems way too risky, an invitation to doom. If you only have to match
96 bits, the possibility of taking one message+HMAC and turning it
into a legal message'+HMAC, even without knowing the key, seems not
impossible, given that only 96 bits have to match. In fact, it seems
to me that you might be able to use such a technique to test for
individual key bits, using the receiver as a verifier.
Hilarie
From owner-ipsec Mon Mar 10 12:41:37 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA23491 for ipsec-outgoing; Mon, 10 Mar 1997 12:37:28 -0500 (EST)
Organization: ESAT, K.U.Leuven, Belgium
Date: Mon, 10 Mar 1997 18:41:37 +0100 (MET)
From: Bart Preneel <Bart.Preneel@esat.kuleuven.ac.be>
To: Hilarie Orman <ho@earth.hpc.org>
cc: HUGO@watson.ibm.com, rrglenn@erols.com, ipsec@tis.com
Subject: Re: truncation
In-Reply-To: <199703101510.KAA05281@earth.hpc.org>
Message-ID: <Pine.HPP.3.95.970310183807.25583E-100000@domein.esat.kuleuven.ac.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I repeat briefly the main points of my post of February 16th:
- MD5 is probably not a strong cryptographic primitive.
- The most dangerous attacks on HMAC constructions based on MD5
seem to be the _key recovery_ attacks.
These attacks become more difficult if truncation is applied.
(just as DES in 16-bit CFB is harder to break than DES).
Forgery attacks seem to be less realistic, and also not as
dangerous as key recovery attacks.
Bart Preneel
-------------------------------------------------------------------------------
On Mon, 10 Mar 1997, Hilarie Orman wrote:
> MD5 is already borderline, and the removal of that much of the output
> seems way too risky, an invitation to doom. If you only have to match
> 96 bits, the possibility of taking one message+HMAC and turning it
> into a legal message'+HMAC, even without knowing the key, seems not
> impossible, given that only 96 bits have to match. In fact, it seems
> to me that you might be able to use such a technique to test for
> individual key bits, using the receiver as a verifier.
>
> Hilarie
>
From owner-ipsec Mon Mar 10 13:37:28 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA23884 for ipsec-outgoing; Mon, 10 Mar 1997 13:35:58 -0500 (EST)
Date: Mon, 10 Mar 1997 13:38:19 -0500
From: ho@earth.hpc.org (Hilarie Orman)
Message-Id: <199703101838.NAA11494@earth.hpc.org>
To: Bart.Preneel@esat.kuleuven.ac.be
Cc: ipsec@tis.com, rrglenn@erols.com, HUGO@watson.ibm.com
In-reply-to: Yourmessage <Pine.HPP.3.95.970310183807.25583E-100000@domein.esat.kuleuven.ac.be>
Subject: Re: truncation
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Oh, OK, make it 96 bits. Sorry for the diversion.
Hilarie
From owner-ipsec Tue Mar 11 03:22:12 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA27928 for ipsec-outgoing; Tue, 11 Mar 1997 03:16:38 -0500 (EST)
Message-Id: <9703110820.AA03690@elgamal.radguard.com>
Comments: Authenticated sender is <yael@radguard.com>
From: "Yael Dayan" <yael@radguard.com>
To: rgm3@chrysler.com
Date: Tue, 11 Mar 1997 10:23:14 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: IPSec Interoperability
Cc: ipsec@tis.com
X-Mailer: Pegasus Mail for Windows (v2.23)
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Dear Mr. Moskowitz,
Our company (Radguard) would like to join the IPSec +
ISAKMP/Oakley interoperability effort.
If this is possible, we would like some information about the
testing schedule and the implementation requirements.
Thank You,
Yael Dayan
Radguard
From owner-ipsec Wed Mar 12 13:21:47 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA11398 for ipsec-outgoing; Wed, 12 Mar 1997 13:10:07 -0500 (EST)
Date: Wed, 12 Mar 1997 13:12:43 -0500
From: ho@earth.hpc.org (Hilarie Orman)
Message-Id: <199703121812.NAA05496@earth.hpc.org>
To: ipsec@tis.com
Subject: DIMACS Workshop on Cryptographic Protocol Design and Verification, Sept. 3-5, 1997
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
The following workshop might be of interest to some of you; it's a chance
to tell the formalists what the real problems in crypto protocol correctness
are, or to find out what tools are available for determining correctness.
Hilarie
=====================================================================
From: Barbara Quigley <bquigley@iyar.rutgers.edu>
Subject: DIMACS Workshop on Cryptographic Protocol Design and
Verification, Sept. 3-5, 1997
--------------------------------------------------------------------------
| DIMACS: Center for Discrete Mathematics & Theoretical Computer Science
|
| A National Science Foundation Science and Technology Center
|
--------------------------------------------------------------------------
DIMACS Special Year on Networks
Workshop on Cryptographic Protocol Design and Verification
September 3-5, 1997
DIMACS Center, CoRE Building, Rutgers University
ORGANIZERS:
Hilarie Orman, orman@darpa.mil
Catherine Meadows, meadows@itd.nrl.navy.mil
The purpose of the workshop is to bring together those who design and
implement cryptographic protocols with those who formally analyze
them, in order to develop a community that can routinely produce
secure protocols for use in protecting organizational data and
facilitating commerce. The two groups will have opportunities to share
ideas about the current state of the art, directions to pursue, and
the motivation for their work.
Participants will be encouraged to bring demonstration software with
them, and part of the workshop organization will involve determining
the needs for Internetwork access and local networking. The
demonstrations will be of secure protocols in action and of
interactive specification and verification techniques.
In addition to examining the current state, participants will attempt
to quantify the factors that they expect to be significant
contributors to scaling the current techniques for future
problems. For example, the ability to perform proofs new protocols
within a day might be significant. What are the prospects for doing
this for a mobile internetwork protocol, for example.
Ideally the conclusion of the workshop would be a set of published
guidelines for how to design and verify secure cryptographic
protocols in reasonable time.
---------------------------------------------------------------------
The Special Year program is made possible by long term funding from the
National Science Foundation, the New Jersey Commission on Science and
Technology and DIMACS university and industry partners.
DIMACS Center; Rutgers University; P.O. Box 1179; Piscataway, NJ 08855-1179
TEL: 908-445-5928 FAX: 908-445-5932
** EMAIL: center@dimacs.rutgers.edu
WWW: http://dimacs.rutgers.edu ** TELNET: telnet info.rutgers.edu
DIMACS is a partnership of Rutgers University, Princeton University,
AT&T Labs, Bellcore, and Bell Laboratories.
From owner-ipsec Wed Mar 12 14:08:52 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA11967 for ipsec-outgoing; Wed, 12 Mar 1997 14:04:44 -0500 (EST)
Message-Id: <3.0.1.32.19970312140629.00a14470@dilbert.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@dilbert.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 12 Mar 1997 14:06:29 -0500
To: ipsec@tis.com
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Round 2, IPsec - Oakley/ISAKMP interop testing
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
The AIAG (Automotive Industry Action Group) will again be hosting an
interop test session.
Thanks to the kind offer of FTP/Software for a facility, we will be in
Andover MA March 24-27th.
I am finishing roughing out a interop check list based on the Glenn AH,
Hughes Combined, Oakley v6, ISAKMP v2, and X.509v3 documents. I will be
posting some details by tomorrow evening.
We are interested in both gateway and workstation implementations. Vendors
that are ready to test in this time frame, please contact me directly.
We are also planning for activities at Interop in May. The AIAG's
Automotive Network eXchange (ANX) will be in pilot this summer with
controled rollout in the fall. IPsec technology will be required for ANX
subscribers.
We will give a status report at the wg session, and are working with the
IPsec chairs for an implementors session at Memphis.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
From owner-ipsec Wed Mar 12 14:12:38 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA11986 for ipsec-outgoing; Wed, 12 Mar 1997 14:08:48 -0500 (EST)
Date: Wed, 12 Mar 1997 14:11:04 -0500
From: ho@earth.hpc.org (Hilarie Orman)
Message-Id: <199703121911.OAA07282@earth.hpc.org>
To: ipsec@tis.com
Subject: DIMACS Workshop on Cryptographic Protocol Design and Verification, Sept. 3-5, 1997
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Here's a more complete announcement for the workshop.
Hilarie
=============================================================================
DIMACS Workshop on Formal Verification of Security Protocols
Sept. 3-5, 1997
Organizers: Hilarie Orman, DARPA and Catherine Meadows, Naval Research
Laboratory
As we come to rely more and more upon computer networks to perform vital
functions, the need for cryptographic protocols that can enforce
a variety of security properties has become more and more important.
Thus it is no surprise that in recent years a number of new
protocols have been proposed for such applications as electronic
credit card transactions, Web browsing, and so forth.
Since it is notoriously difficult to design cryptographic protocols
correctly, this increased reliance on them to provide security has
become cause for some concern. This is especially the case since
many of the new protocols are extremely complex.
In answer to these needs, research has been intensifying in the application
of formal methods to cryptographic protocol verification. Recently
this work has matured enough so that it is starting to see application
to real-life protocols. The goal of this workshop is to facilitate
this process by bringing together those were are involved in the design
and standardization of cryptographic protocols, and those who are developing
and using formal methods techniques for the verification of such protocols.
To this end we plan to alternate papers with panels soliciting new
paths for research. We are particularly interested in paper
and panel proposals addressing new protocols with respect to their
formal and informal analysis.
Other topics of interest include, but are not limited to
- Progress in belief logics
- Use of theorem provers and model checkers in verifying crypto protocols
- Interaction between protocols and cryptographic modes of operation
- Methods for unifying documentation and formal, verifiable specification
- Methods for incorporating formal methods into crypto protocol design
- Verification of cryptographic API systems
- Formal definition of correctness of a cryptographic protocol
- Arithmetic capability required for proofs of security for
number theoretic systems
- Formal definitions of cryptographic protocol requirements
- Design methodologies
- Emerging needs and new uses for cryptographic protocols
- Multiparty protocols, in particular design and verification methods
We encourage attendees to bring tools for demonstration. Information
about availability of facilities for demonstration will be posted later.
To submit a paper to the workshop, submit a one or two page abstract,
in Postscript or ASCII to both organizers at the email addresses given below
by June 16, 1997. Authors will be notified of acceptance or rejection of
abstracts by July 1. Full papers will be due by August 1.
Copies of papers will be distributed at the workshop. We also plan
to publish a proceedings.
Participation in the workshop is *not* limited to those giving presentations.
If you would like to attend the workshop, a registration form is available
at http://dimacs.rutgers.edu/Workshops/Cryptographic/reg_form.html.
Information on accommodations and travel arrangements is available at
http://dimacs.rutgers.edu/Workshops/general/accommodations.html and
http://dimacs.rutgers.edu/Workshops/general/travel.html.
Information on the workshop in general is at
http://dimacs.rutgers.edu/Workshops/Cryptographic.
Organizers
Hilarie Orman Catherine Meadows
DARPA ITO Naval Research Laboratory
3701 N. Fairfax Drive Code 5543
Arlington VA 22203-1714 Washington, DC 20375
phone: (703)696-2234 phone: (202)-767-3490
email: horman@darpa.mil email:meadows@itd.nrl.navy.mil
From owner-ipsec Wed Mar 12 21:21:41 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA14775 for ipsec-outgoing; Wed, 12 Mar 1997 21:16:36 -0500 (EST)
Message-Id: <199703130221.SAA14356@dharkins-ss20>
X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol
To: ipsec@tis.com
Cc: anx-sec@dot.netrex.net, isakmp-oakley@cisco.com, rlfs@cisco.com
Subject: free ISAKMP reference implementation
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 12 Mar 1997 18:21:05 -0800
From: Daniel Harkins <dharkins@cisco.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Cisco Systems is pleased to announce the availability of their free
ISAKMP+Oakley reference implementation. This is based on ISAKMP version 6
and the ISAKMP+Oakley Resolution document version 2.
New features from the previous release include all mandatory and optional
authentication methods. Authentication with RSA signatures and RSA encryption
is accomplished by compiling the ISAKMP distribution with RSAREF. (Note:
RSAREF is *not* included in the distribution).
This ISAKMP+Oakley implementation has successfully interoperated with
other independent implementations at the ANX IPsec bake-off and in
independent testing. And it is fully compliant with the relevant drafts.
This distribution uses the PF_KEY Key Management API to register security
associations with a PF_KEY aware kernel. The NRL IPsec software distribution
contains an implementation of PF_KEY for 4.4-BSD systems.
As with all cryptographic utilites this code is export controlled and all
applicable (U.S) laws will be obeyed in its distribution. Apologies to
all who cannot obtain it.
To obtain a copy of the ISAKMP+Oakley distribution (and also a copy of
the NRL IPsec distribution) point your favorite browser to:
http://www.cisco.com/public/library/isakmp
scroll down to "Cisco Systems Implementation" and follow the hot links.
Please send all comments, opinions, bug reports and suggestions to
the isakmp-oakley mailing list (isakmp-oakley@cisco.com). To join this list
send a message to majordomo@cisco.com with "subscribe isakmp-oakley" in
the *body* of the message.
regards,
Dan Harkins
From owner-ipsec Thu Mar 13 11:06:44 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA21122 for ipsec-outgoing; Thu, 13 Mar 1997 11:00:47 -0500 (EST)
From: svakil@usr.com
Mime-Version: 1.0
Date: Thu, 13 Mar 1997 10:00:42 -0600
Message-ID: <32823C30.3000@usr.com>
Subject: Questions on the Security Arch. draft
To: ipsec@tis.com
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Hi. I had a question on section 1.4 of the Security Architecture
draft (draft-ietf-ipsec-arch-sec-01.txt). Specifically, the draft
says :
"A security gateway which receives a datagram containing a
recognised sensitivity label, for example IPSO [Ken91], from a trusted
host MUST take that label's value into consideration when
creating/selecting an Security Association for use with AH between the
gateway and the external destination. In such an environment, a
gateway which receives a IP packet containing the IP Encapsulating
Security Payload (ESP) should add appropriate authentication,
including implicit (i.e. contained in the Security Association used)
or explicit label information (e.g. IPSO), for the decrypted packet
that it forwards to the trusted host that is the ultimate
destination."
I don't get the last part about the gateway adding authentication
information for the decrypted packet. Does this mean that the gateway
uses the SA that it used to decrypt the packet, to generate the
authentication info? That really doesn't make sense to me since AH
and ESP have separate SAs and also since any given security
association is for use with one peer only. Or, is it that the gateway
has a security association with the trusted host and tunnels all the
packets for that host using this SA?
Thanks,
Sumit A. Vakil
Software Engineer
US Robotics, Access Corp.
From owner-ipsec Thu Mar 13 14:23:22 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA22761 for ipsec-outgoing; Thu, 13 Mar 1997 14:14:43 -0500 (EST)
Message-Id: <3.0.16.19970313141636.297f94d8@pop3.pn.com>
X-Pgp-Key: <http://www.shore.net/~sable/info/rltkey.htm>
X-Sender: rodney@pop3.pn.com
X-Mailer: Windows Eudora Pro Version 3.0 (16)
Date: Thu, 13 Mar 1997 14:19:43 -0500
To: ipsec@tis.com
From: Rodney Thayer <rodney@sabletech.com>
Subject: PKI Signature format in ISAKMP -- proposal
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
In preparing for the ANX bakeoff there has been some discussion
of exactly what a "signature" should look like for ISAKMP. Some
people have interpreted this to mean the signature output was in
PKCS#1 format. Others have not.
In this message I have described what I interpreted this to
mean. Note this DOES NOT use PKCS#1. At the end I have listed my
reasons for not using PKCS#1 and what I think would have to
change to use it.
The Oakley resolution draft, in section 5.1, describes the use
of "signatures" for authentication. The signature consists of
data formed by applying the signature algorithm to a hash and
transmitting the signature. In the case of RSA signatures, this
means you create a hash and encrypt the hash with the RSA
private key. At the receiving end, the process is reversed --
the encrypted data is decrypted using the RSA public key, then
the result is compared to the locally calculated hash. [someone
else can augment this with proper prose for DSA...]
In ISAKMP, this hash which is used in the signature process has
specific meaning related to ISAKMP. The draft specifies it to
be the HMAC form, and the hash algorithms that may be used are
specified explicitly.
The procedure used to produce the signature is described here for the
RSA signature algorithm case. Note the terms are from
draft-ietf-ipsec-isakmp-oakley-03.txt.
- ISAKMP produces HASH_I/HASH_R however it wishes
- the hash is used as input data for encryption with the RSA private
key, with
padding as required by the RSA algorithm (see PKCS#1 or the BSAFE
documentation)
- the (key bits) of encryption output is passed over the wire as the
signature
- the other side calculates the hash value HASH_I/HASH_R independantly
- the other side decrypts the signature data using the public key
retrieved
from the cert we are sending over the wire
- the other side compares the decrypted signature against it's locally
calculated hash and if they match you're all set.
Note that the 'signature' data passed over the wire is the
<key bits> of data as generated by the RSA algorithm. The
normal ISAKMP payload processing allows the receiving side to
determine how much data is present. The 'signature', that is,
the encoded hash, must be padded as required by the RSA
algorithm, so when the data is encrypted it consists of:
one byte of zero
hash bytes
padding of zero bytes up to <key length>
DIFFERENCE FROM PKCS#1.
In PKCS#1 an ASN.1 structure encoded in BER would be transmitted
over the wire. I don't think this can be used because:
a. PKCS#1 can't be referenced in IETF documents
b. PKCS#1 does not define hmac-md5 or hmac-sha1 or Tiger
Note also this would add an implementation burden in that the
ISAKMP code would be responsible for generating BER encoded
information.
In my opinion, we should use the 'raw' signature for now.
If we could obtain an IETF-compliant defininition of an enhanced
PKCS#1 format I would be willing to convert. The fact the
PKCS#1 format contains the length and the algorithm is
appealing.
-----BEGIN PGP SIGNATURE-----
Version: 4.0 Business Edition
Comment: PGP by ViaCrypt
iQCVAgUBMyhSfsKmlvJNktGxAQHJagP/WgKnRWF4IVX92kPlJU9juPacB0fwYNEO
slRCKLQcUatueyuSTvar+I23X6tOO/aNGndGsZfwrAss0cPI271TkCwVd4cOkRnY
EKRxZEVWS9ieAj9Oh7IwqDAeM2Lun9sDzuUUOJxGXZjuj+rVUaXqa9Gt9GljI2cW
SPxfHdkakKI=
=22vj
-----END PGP SIGNATURE-----
Rodney Thayer <rodney@sabletech.com> +1 617 332 7292
Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA
Fax: +1 617 332 7970 http://www.shore.net/~sable
"Developers of communications software"
From owner-ipsec Thu Mar 13 16:48:10 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24035 for ipsec-outgoing; Thu, 13 Mar 1997 16:42:15 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03007803af4e246bab0b@[128.89.0.110]>
In-Reply-To: <32823C30.3000@usr.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 13 Mar 1997 16:43:21 -0500
To: svakil@usr.com
From: Stephen Kent <kent@bbn.com>
Subject: Re: Questions on the Security Arch. draft
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Sumit,
We are in the process of re-writing the architecture document and
will address this question in the revised version. If one is using
security labels and these labels are implicitly bound to an SA, then it
might be appropriate for a gateway terminating a (tunnel mode) SA to
introduce such labels into the decapsulated IP header. However, this could
backfire if this header were covered by transport mode AH! So, we need to
be careful in describing under what circumstances this intermediate system
processing is appropriate. I'm not sure that there is other authentication
data that ought to be addressed here, in a general fashion, and so we may
tighen this part of the spec to focus only on security labels, to the
extent appropriate.
Ran, as the author of this version of the architecture document, is
there anything else you'd like to add to this reply?
Steve
From owner-ipsec Thu Mar 13 20:21:48 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA25382 for ipsec-outgoing; Thu, 13 Mar 1997 20:18:39 -0500 (EST)
Date: Fri, 14 Mar 97 01:11:19 GMT Standard Time
From: Ran Atkinson <rja@inet.org>
Subject: Re: Questions on the Security Arch. draft
To: ipsec@tis.com, svakil@usr.com
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <32823C30.3000@usr.com>
Message-ID: <Chameleon.858302345.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
--- On Thu, 13 Mar 1997 10:00:42 -0600 svakil@usr.com wrote:
> Hi. I had a question on section 1.4 of the Security Architecture
> draft (draft-ietf-ipsec-arch-sec-01.txt). Specifically, the draft
> says :
>
> "A security gateway which receives a datagram containing a
> recognised sensitivity label, for example IPSO [Ken91], from a trusted
> host MUST take that label's value into consideration when
> creating/selecting an Security Association for use with AH between the
> gateway and the external destination. In such an environment, a
> gateway which receives a IP packet containing the IP Encapsulating
> Security Payload (ESP) should add appropriate authentication,
> including implicit (i.e. contained in the Security Association used)
> or explicit label information (e.g. IPSO), for the decrypted packet
> that it forwards to the trusted host that is the ultimate
> destination."
>
> I don't get the last part about the gateway adding authentication
> information for the decrypted packet. Does this mean that the gateway
> uses the SA that it used to decrypt the packet, to generate the
> authentication info? That really doesn't make sense to me since AH
> and ESP have separate SAs and also since any given security
> association is for use with one peer only. Or, is it that the gateway
> has a security association with the trusted host and tunnels all the
> packets for that host using this SA?
If your system does not implement CIPSO and does not implement RFC-1038
or RFC-1108, then the above doesn't apply since those are just about
the only known sensitivity labels used with IPv4.
If your gateway implements one of those label systems (or is B1 or higher),
then the gateway SHOULD use AH (or ESP) when transmitting the packet along
to its final destination. The IPsec SA used for transmitting the packet
along to its final destination MUST have a sensitivity label value
consistent with the sensitivity label associated with that packet when
it was received.
The goal here is to accurately maintain end-to-end integrity on the
sensitivity label of the data.
If this is still confusing, send private email. This is not a general
interest topic...
Ran
rja@inet.org
From owner-ipsec Fri Mar 14 02:37:28 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA27133 for ipsec-outgoing; Fri, 14 Mar 1997 02:33:45 -0500 (EST)
Message-Id: <199703140707.XAA15976@dharkins-ss20>
X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol
To: Rodney Thayer <rodney@sabletech.com>
Cc: ipsec@tis.com
Subject: Re: PKI Signature format in ISAKMP -- proposal
In-Reply-To: Your message of "Thu, 13 Mar 1997 14:19:43 EST."
<3.0.16.19970313141636.297f94d8@pop3.pn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 13 Mar 1997 23:07:08 -0800
From: Daniel Harkins <dharkins@cisco.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> In preparing for the ANX bakeoff there has been some discussion
> of exactly what a "signature" should look like for ISAKMP. Some
> people have interpreted this to mean the signature output was in
> PKCS#1 format. Others have not.
The fact that it is open to interpretation means it needs clarification.
But, regardless of people's interpretation, the intent of the draft
is to not do "PKCS#1 Signatures" for RSA-SIG authentication. The intent
was to do "PKCS#1 Encryption" of the result of the hmac.
> The procedure used to produce the signature is described here for the
> RSA signature algorithm case. Note the terms are from
> draft-ietf-ipsec-isakmp-oakley-03.txt.
>
> - ISAKMP produces HASH_I/HASH_R however it wishes
>
> - the hash is used as input data for encryption with the RSA private
> key, with
> padding as required by the RSA algorithm (see PKCS#1 or the BSAFE
> documentation)
>
> - the (key bits) of encryption output is passed over the wire as the
> signature
>
> - the other side calculates the hash value HASH_I/HASH_R independantly
>
> - the other side decrypts the signature data using the public key
> retrieved
> from the cert we are sending over the wire
This is fine for the bake-off but there is no requirement to pass certs
over the wire and signature verification should not be dependent upon it.
> - the other side compares the decrypted signature against it's locally
> calculated hash and if they match you're all set.
>
> Note that the 'signature' data passed over the wire is the
> <key bits> of data as generated by the RSA algorithm. The
> normal ISAKMP payload processing allows the receiving side to
> determine how much data is present. The 'signature', that is,
> the encoded hash, must be padded as required by the RSA
> algorithm, so when the data is encrypted it consists of:
>
> one byte of zero
> hash bytes
> padding of zero bytes up to <key length>
Actually, it should be (from PKCS#1):
00 | BT | PS | 00 | hmac
where BT in this case would be a 1 (because it's encrypting with the private
key), PS is a string of 0xff which is modulus-length minus 3 minus hmac
length in length.
> DIFFERENCE FROM PKCS#1.
>
> In PKCS#1 an ASN.1 structure encoded in BER would be transmitted
> over the wire. I don't think this can be used because:
>
> a. PKCS#1 can't be referenced in IETF documents
> b. PKCS#1 does not define hmac-md5 or hmac-sha1 or Tiger
>
> Note also this would add an implementation burden in that the
> ISAKMP code would be responsible for generating BER encoded
> information.
But is is PKCS#1, it's just "PKCS#1 encryption". To do an RSA signatures
you do a PKCS#1-defined RSA private key encryption of the output from the
hmac function instead of a PKCS#1-defined "RSA signature" (which includes
encoding a magic number that is outside the control of the IETF).
> In my opinion, we should use the 'raw' signature for now.
>
> If we could obtain an IETF-compliant defininition of an enhanced
> PKCS#1 format I would be willing to convert. The fact the
> PKCS#1 format contains the length and the algorithm is
> appealing.
The fact that it contains the length is extremely important. Given a
key modulus length payload how do you know the true length of the hash
is without the above-mentioned encoding? The fact that it contains an
algorithm identifier is problematic.
The intent of the draft was to do authentication with RSA signatures by
encrypting the hmac with a private key and verifying it with the
corresponding public key. I've failed quite spectacularly in conveying this.
I'm open to suggested text on how to properly convey the intent.
regards,
Dan.
-------------------------------------------------------------------------------
Dan Harkins | E-mail: dharkins@cisco.com
Network Protocol Security, cisco Systems | phone: +1 (408) 526-5905
170 W. Tasman Drive | fax: +1 (408) 526-4952
San Jose, CA 95134-1706, U.S.A. | ICBM: 37.45N, 122.03W
-------------------------------------------------------------------------------
For your safety and the safety of others: concealed carry, and strong crypto
-------------------------------------------------------------------------------
From owner-ipsec Fri Mar 14 15:29:15 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA02650 for ipsec-outgoing; Fri, 14 Mar 1997 15:21:34 -0500 (EST)
Message-Id: <2.2.32.19970314203324.00b4a220@mailserv-H.ftp.com>
X-Sender: naganand@mailserv-H.ftp.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 14 Mar 1997 15:33:24 -0500
To: ipsec@tis.com
From: Naganand Doraswamy <naganand@ftp.com>
Subject: Clarification on 3des draft
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Is there any need to support optional IV for the 3des transform. I would
remove it is there is not going to be any hardware that implements 3des and
needs to generate its own IV.
Thanks,
--Naganand
----------------------------------------------------------------
naganand@ftp.com
Tel #: (508)684-6743 (O)
From owner-ipsec Fri Mar 14 15:37:10 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA02751 for ipsec-outgoing; Fri, 14 Mar 1997 15:35:47 -0500 (EST)
Message-ID: <c=CA%a=_%p=NorTel_Secure_Ne%l=GRANNY-970314201527Z-22658@bwdldb.ott.bnr.ca>
From: Greg Carter <carterg@entrust.com>
To: "'rodney@sabletech.com'" <rodney@sabletech.com>,
"'dharkins@cisco.com'" <dharkins@cisco.com>
Cc: "'ipsec@tis.com'" <ipsec@tis.com>
Subject: RE: PKI Signature format in ISAKMP - DSS
Date: Fri, 14 Mar 1997 15:15:27 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
This refers to DSS signatures...
Could we clarify the format of DSS signatures, all that's in the
isakmp-oakley draft is 'encoded', to us that means the DSS signature
defined in ANSI X9.30 part 3: "Certificate management for DSA". That is
the ASN.1 encoding of r followed by s.
ie DER encoding of type:
SEQUENCE {
r INTEGER,
s INTEGER }
Bye.
From owner-ipsec Fri Mar 14 16:45:01 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA03239 for ipsec-outgoing; Fri, 14 Mar 1997 16:41:53 -0500 (EST)
To: IETF-Announce:
cc: ipsec@tis.com
From: The IESG <iesg-secretary@ietf.org>
Subject: Last Call: The resolution of ISAKMP with Oakley to Proposed
Standard
Reply-to: iesg@ietf.org
Date: Fri, 14 Mar 1997 16:17:42 -0500
Message-ID: <9703141617.aa22907@ietf.org>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
The IESG has received a request from the IP Security Protocol Working
Group to consider the following Internet-Drafts for the status of
Proposed Standard:
o The resolution of ISAKMP with Oakley
<draft-ietf-ipsec-isakmp-oakley-03.txt>
o Internet Security Association and Key Management Protocol (ISAKMP)
<draft-ietf-ipsec-isakmp-07.txt>
o The Internet IP Security Domain of Interpretation for ISAKMP
<draft-ietf-ipsec-ipsec-doi-02.txt>
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by March 28, 1997
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
From owner-ipsec Fri Mar 14 17:03:30 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA03360 for ipsec-outgoing; Fri, 14 Mar 1997 17:03:00 -0500 (EST)
Message-Id: <3.0.16.19970314170013.2e9fff5e@pop3.pn.com>
X-Pgp-Key: <http://www.shore.net/~sable/info/rltkey.htm>
X-Sender: rodney@pop3.pn.com
X-Mailer: Windows Eudora Pro Version 3.0 (16)
Date: Fri, 14 Mar 1997 17:07:46 -0500
To: ipsec@tis.com
From: Rodney Thayer <rodney@sabletech.com>
Subject: IPsec in Memphis - when?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I don't see any IPsec sessions on the agenda at <http://www.ietf.org>.
When is it?
--------
Rodney Thayer <rodney@sabletech.com>
PGP Fingerprint: BB1B6428 409129AC 076B9DE1 4C250DD8
From owner-ipsec Mon Mar 17 00:44:04 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA16889 for ipsec-outgoing; Mon, 17 Mar 1997 00:34:00 -0500 (EST)
Message-Id: <3.0.32.19970316213807.00930100@earthlink.net>
X-Sender: rmonsour@earthlink.net
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Sun, 16 Mar 1997 21:38:10 -0800
To: ipsec@tis.com
From: Bob Monsour <rmonsour@earthlink.net>
Subject: Closing out the COMPRESSION discussion
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
All,
First, thanks to all who participated in the compression discussion. The
debate has been lively and useful. I wanted to make sure that the straw
ballot results were available to the list prior to the 3/26 cutoff for
drafts to be released in time for Memphis.
The results of the straw poll indicated: (1) a significant majority of
those who participated in the discussion (there were around 30 total
participants) believe that adding compression as an optional feature to ESP
is a good idea, and (2) of those in that majority, most felt that using the
most-significant bit of the pad length byte as a compressed/not-compressed
indicator was an appropriate technique.
There were a number of concerns raised on the list and I would like to
close out the discussion with some additional insights on these points.
1. Compression belongs at a higher layer than IP
There are a handful of people who feel this way. Some responded to this (as
I did) by stating that there was no universally appropriate higher layer in
which to do the compression. This is indeed true. However, it is certainly
true that if compression was added to a higher layer protocol, say TCP, one
would have the potential advantage of reducing the number of IP packets as
well maintaining compression state across segments. The result would be a
higher compression ratio for the same type of data. While adding
compression to such a higher layer protocol has its advatnages for some
environments, there is *NO* need for it to preclude the OPTIONAL use of
compression in IPSec, where there *IS* gain to be had (leading to the next
point).
2. There's not enough to gain when compressing packet-by-packet
As most of you know (hopefully all of you), the amount of compression you
get depends on the type of data being compressed. I first responded to this
by providing some compression results based on using the LZS algorithm on
some publically available test data. The response to this was "that's not
*real* network data". Since that time, I have had a number of discussions
with people in the networking industry regarding what *real* network data
is. The reality is that one person's *real* network data is another
person's meaningless data. You cannot simply sniff someone's T1 connection
to the internet to get *real* network data. In the context of IPSec, I
would imagine that network data that will be encrypted will look more like
today's LAN traffic (currently privately held data that will now, under
IPSec, be exposed to the internet). Also, as pointed out by Terry Davis
from Boeing, "CAD, GIFs, or other barely compressable objects" will not
compress well, but "email or a few thousand pages of maintenance manual"
can achieve significant gains by compressing.
A second response on this point came from Jim Hughes, who recently stated
that "We also have numbers on the compression ratios in real world, long
run time situations, and even clearing the dictionary on every packet, we
average 2:1 compression of data. Even on most small packets, the overhead
of the encapsulationis removed by what compression there is."
Similarly, a Q&A doc from VPNet states "VPNet's data compression technology
is oriented around a per-packet compensation for security-induced packet
expansion. In current network tests, the performance improvement for very
small packets is small, but for larger packets, network performance gains
are substantial. Improvements between 10 and 40 percent are typical, though
for packets containing highly compressible data, improvements of up to 70
percent are possible."
3. Using the most significant bit (msb) of the pad length will cause
compatibility problems
The proposal involves using the msb of the pad length field to indicate
whether or not a packet is compressed. Note that the use of compression is
intended to be negotiated on a per SA basis at by the key management
protocol. Any current implementation of ESP that does not wish to support
the OPTIONAL compression feature is free not to and will suffer no
compatibility problems when interoperating with those implementations that
support the compression feature. Current implementations will NEVER
negotiate to turn on the compression feature. As a result, compressed data
will NEVER be sent to them. As such, the msb can continue to be interpreted
to mean that there are 128 additional bytes of padding. Implementations
that DO support the compression feature will use a maximum of 127 bytes of
padding, leaving the msb to indicate compressed/not-compressed.
With that said, the working group should expect the next draft of the ESP
specification to include compression as an optional feature of ESP
(negotiated by the KMP) with the msb of the pad length field used as the
packet compressed/not-compressed indicator.
-Bob
From owner-ipsec Mon Mar 17 11:29:23 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA21108 for ipsec-outgoing; Mon, 17 Mar 1997 11:25:50 -0500 (EST)
Message-Id: <199703171625.LAA21108@portal.ex.tis.com>
Date: Mon, 17 Mar 1997 11:21:47 -0500
From: smamros@newoak.com (Shawn Mamros)
X-Mailer: Mozilla 4.0b2 (WinNT; I)
MIME-Version: 1.0
To: ipsec@tis.com
CC: iesg@ietf.org, smamros@newoak.com
Subject: Comment on the ISAKMP/Oakley resolution draft
X-Priority: 3 (Normal)
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I have a concern regarding the latest version of the ISAKMP/Oakley
resolution draft (draft-ietf-ipsec-isakmp-oakley-03.txt).
The previous version of the draft (-02) allowed a mode of operation
which is no longer possible under the new draft. When using pre-
shared keys for authentication (in section 5.3), one can now use
Oakley Main Mode only if the pre-shared keys are identified by the
IP addresses of the peers. One cannot use keys associated with
some other identifier supplied by the initiator (denoted as IDii
in the draft), because that payload is encrypted with SKEYID_e,
which is derived in part from the pre-shared key in question (as
described at the beginning of section 5 - the pre-shared key is
used to derive SKEYID, which in turn is used to derive SKEYID_e).
The -02 version of the draft did allow Main Mode to be used for
any initiator identifier, because SKEYID was derived in a different
manner which did not include the pre-shared key.
While the -03 draft does state that one can use Oakley Aggressive
Mode instead for pre-shared keys, Agressive Mode does not provide
identity protection (i.e., encryption of IDii) as Main Mode does.
The root cause of the problem seems to be that the -03 draft
introduces a new common algorithm for deriving HASH_I and HASH_R
which uses SKEYID (beginning of section 5). In the -02 draft,
HASH_I and HASH_R were derived differently, depending on which
authentication method (signatures, public keys, or pre-shared keys)
was used. When using pre-shared keys, the key clearly must be used
to derive the hash in order to authenticate the peers to one another.
In order to allow for this, the use of the pre-shared key was moved
into the derivation for SKEYID. However, doing so introduces a
dependency on the pre-shared key for SKEYID_a and SKEYID_e, which
did not exist in the -02 draft.
While I certainly believe that having common algorithms across
different authentication methods wherever possible is a Good Thing
in terms of reducing complexity, I do not feel that that justifies
eliminating a useful mode of operation which was previously allowed.
That being said, I do believe there exists a method by which the
new common HASH_I and HASH_R derivation can remain. Just as HASH_I
and HASH_R require additional processing to derive SIG_I and SIG_R
when using signatures for authentication (section 5.1), one could
require an additional step which combines HASH_I and the key into
a HASH_I1 (likewise for HASH_R and HASH_R1). This would allow
the pre-shared key to be removed from the derivation of SKEYID
without losing authentication capability.
Of course, I am open to other possible solutions to this problem.
My goal here is to allow for a useful mode of operation (pre-shared
keys identified by IDii with identity protection provided by Oakley
Main Mode) to continue as it did in the prior version of the draft.
-Shawn Mamros
E-mail to: smamros@newoak.com
From owner-ipsec Mon Mar 17 11:55:50 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA21385 for ipsec-outgoing; Mon, 17 Mar 1997 11:54:33 -0500 (EST)
From: pau@watson.ibm.com
Date: Mon, 17 Mar 1997 12:04:34 -0500
Message-Id: <9703171704.AA24466@secpwr.watson.ibm.com>
To: smamros@newoak.com
Subject: Re: Comment on the ISAKMP/Oakley resolution draft
Cc: ipsec@tis.com, hugo@watson.ibm.com, pau@watson.ibm.com
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Md5: eZpwI3MlSYwhgkfKKoBwKg==
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id LAA21382
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Shawn, Hugo and I discovered this too. One solution Hugo has
is to give the shared key an ID (like an SPI). This ID could
be sent in ID payload together with KE and NONCE. Another
possibility I could see is to augment the DOI a little bit
and send the key ID in "situation".
Pau-Chen
>
> I have a concern regarding the latest version of the ISAKMP/Oakley
> resolution draft (draft-ietf-ipsec-isakmp-oakley-03.txt).
>
> The previous version of the draft (-02) allowed a mode of operation
> which is no longer possible under the new draft. When using pre-
> shared keys for authentication (in section 5.3), one can now use
> Oakley Main Mode only if the pre-shared keys are identified by the
> IP addresses of the peers. One cannot use keys associated with
> some other identifier supplied by the initiator (denoted as IDii
> in the draft), because that payload is encrypted with SKEYID_e,
> which is derived in part from the pre-shared key in question (as
> described at the beginning of section 5 - the pre-shared key is
> used to derive SKEYID, which in turn is used to derive SKEYID_e).
> The -02 version of the draft did allow Main Mode to be used for
> any initiator identifier, because SKEYID was derived in a different
> manner which did not include the pre-shared key.
>
> While the -03 draft does state that one can use Oakley Aggressive
> Mode instead for pre-shared keys, Agressive Mode does not provide
> identity protection (i.e., encryption of IDii) as Main Mode does.
>
> The root cause of the problem seems to be that the -03 draft
> introduces a new common algorithm for deriving HASH_I and HASH_R
> which uses SKEYID (beginning of section 5). In the -02 draft,
> HASH_I and HASH_R were derived differently, depending on which
> authentication method (signatures, public keys, or pre-shared keys)
> was used. When using pre-shared keys, the key clearly must be used
> to derive the hash in order to authenticate the peers to one another.
> In order to allow for this, the use of the pre-shared key was moved
> into the derivation for SKEYID. However, doing so introduces a
> dependency on the pre-shared key for SKEYID_a and SKEYID_e, which
> did not exist in the -02 draft.
>
> While I certainly believe that having common algorithms across
> different authentication methods wherever possible is a Good Thing
> in terms of reducing complexity, I do not feel that that justifies
> eliminating a useful mode of operation which was previously allowed.
> That being said, I do believe there exists a method by which the
> new common HASH_I and HASH_R derivation can remain. Just as HASH_I
> and HASH_R require additional processing to derive SIG_I and SIG_R
> when using signatures for authentication (section 5.1), one could
> require an additional step which combines HASH_I and the key into
> a HASH_I1 (likewise for HASH_R and HASH_R1). This would allow
> the pre-shared key to be removed from the derivation of SKEYID
> without losing authentication capability.
>
> Of course, I am open to other possible solutions to this problem.
> My goal here is to allow for a useful mode of operation (pre-shared
> keys identified by IDii with identity protection provided by Oakley
> Main Mode) to continue as it did in the prior version of the draft.
>
> -Shawn Mamros
> E-mail to: smamros@newoak.com
>
>
>
From owner-ipsec Mon Mar 17 14:18:57 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA22336 for ipsec-outgoing; Mon, 17 Mar 1997 14:17:25 -0500 (EST)
Message-Id: <3.0.16.19970317141440.357f70a0@pop3.pn.com>
X-PGP-Key: <http://www.shore.net/~sable/info/rltkey.htm>
X-Sender: rodney@pop3.pn.com
X-Mailer: Windows Eudora Pro Version 3.0 (16)
Date: Mon, 17 Mar 1997 14:22:27 -0500
To: ipsec@tis.com
From: Rodney Thayer <rodney@sabletech.com>
Subject: IPsec Implementation Survey
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_858644547==_"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
--=====================_858644547==_
Content-Type: text/plain; charset="us-ascii"
Attached is a revision of the IPsec Implementation Survey form. If you
have an IPsec implementation and you would like to be listed in the survey,
please fill this out and send it back to me, Rodney Thayer, at
<rodney@sabletech.com>. I will collect this and publish them to the list
before the meeting in Memphis.
--=====================_858644547==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="SURVEY2.TXT"
Name of Implementation : (name of your implementation/product)
Version Described :
Organization : (name of your organization)
Which IP versions are
supported : (IPv4, IPv6, or IPv4 and IPv6)
Implements RFC-1828
AH MD5 : (YES, NO, In Progress, Planned, Partial)
Implements RFC-1829
ESP DES-CBC : (YES, NO, In Progress, Planned, Partial)
Implements AH HMAC MD5 : (YES, NO, In Progress, Planned, Partial; draft rev.)
Implements AH HMAC SHA-1: (YES, NO, In Progress, Planned, Partial; draft rev.)
Implements Combined ESP
(DES+MD5+Replay, etc) : Please list combinations you support, and for
each combination indicate
(YES, NO, In Progress, Planned, Partial; draft rev.)
Examples include MD5+DES+Replay, SHA-1+3DES, etc.
Other AH Implemented
Transforms : (YES, NO, In Progress, Planned, Partial; draft rev.)
Other ESP Implemented
Transforms : (YES, NO, In Progress, Planned, Partial; draft rev.)
Transport mode : (YES, NO, In Progress, Planned, Partial)
Tunnel mode : (YES, NO, In Progress, Planned, Partial)
Key Management : (Manual, ISAKMP+Oakley, SKIP, Photuris, other,
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)
POINTS of Contact : (email address, optionally also phone/fax/name)
Claimed Interoperability: (list of systems that your implementation fully
interoperates with)
--=====================_858644547==_
Content-Type: text/plain; charset="us-ascii"
Rodney Thayer <rodney@sabletech.com> +1 617 332 7292
Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA
Fax: +1 617 332 7970 http://www.shore.net/~sable
"Developers of communications software"
--=====================_858644547==_--
From owner-ipsec Mon Mar 17 15:09:37 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA22787 for ipsec-outgoing; Mon, 17 Mar 1997 15:09:12 -0500 (EST)
Message-Id: <199703172013.MAA17906@dharkins-ss20>
X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol
To: pau@watson.ibm.com
Cc: smamros@newoak.com, ipsec@tis.com, hugo@watson.ibm.com
Subject: Re: Comment on the ISAKMP/Oakley resolution draft
In-Reply-To: Your message of "Mon, 17 Mar 1997 12:04:34 EST."
<9703171704.AA24466@secpwr.watson.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 17 Mar 1997 12:13:36 -0800
From: Daniel Harkins <dharkins@cisco.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Shawn, Pau-Chen,
> Shawn, Hugo and I discovered this too. One solution Hugo has
> is to give the shared key an ID (like an SPI). This ID could
> be sent in ID payload together with KE and NONCE. Another
> possibility I could see is to augment the DOI a little bit
> and send the key ID in "situation".
If you pass an ID payload with the KE and NONCE payloads then why
do Main Mode? That sounds like an Aggressive Mode to me. And if the
ID payload is only some opaque blob of data that has meaning only
to the parties involved then there's no loss of "ID protection" in
Aggressive Mode. An ID of dharkins@cisco.com means something to a
passive evesdropper; an ID of 7a8927c5478 (like a SPI) means nothing
so why not just pass it in the clear and do an Aggressive Mode?
The problem is that IDs of type FQDN or user@FQDN (the only two that
convey any real meaning that the two parties might want to hide)
cannot be used to identifiy pre-shared keys to be used with Main Mode.
I'm not sure how big a problem this is.
The two parties must somehow agree to a pre-shared key in some out-of-band
manner, and presumably they'll also agree to some identifier for that key
(which right now can't be FQDN or user@FQDN). The IPSec DOI reserves 6 ID
types for private use. The two parties could agree that the identifier will
be some opaque blob (like a SPI) and it's ID type will be from the private
use range. Then you do Aggressive Mode with out conveying your identities
to any evesdroppers; you retain "ID protection".
Why isn't this acceptable?
The pre-shared key was put into SKEYID, and SKEYID is used as the key to the
HMAC (as opposed to part of the data to hash) on the recommendation of a
cryptographer (it's a security issue). I'm hesitant to remove it to allow
a case that I don't see as overwhelmingly compelling.
Comments?
Dan.
From owner-ipsec Mon Mar 17 18:22:05 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA23983 for ipsec-outgoing; Mon, 17 Mar 1997 18:19:16 -0500 (EST)
From: HUGO@watson.ibm.com
Message-Id: <199703172324.SAA50747@mailhub1.watson.ibm.com>
Date: Mon, 17 Mar 97 17:48:17 EST
To: dharkins@cisco.com, PAU@watson.ibm.com, piper@cisco.com
cc: smamros@newoak.com, ipsec@tis.com
Subject: Comment on the ISAKMP/Oakley resolution draft (pre-shared)
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Shawn and other intersted parties:
Having the pre-shared key in SKEYID and the derived keys increases security.
It was my recommendation to do so. As just one example consider two
parties that use DH with a public prime p. If at some point enough
cryptanalysis and pre-computation is done on p then every exchange using that
prime may be compromised. This is a not-impossible scenario where you
lose (in a hard way) all the advantages of perfect forward secrecy
(your traffic of the last few years may be compromised!).
If, however, you derived your key depending
on both g^xy and your pre-shared key the attacker will need to find the
value of that pre-shared key (which will probably not exist at that point
of time) to find the actual keys used to protect the session traffic.
I agree with you that having to tie the pre-shared key only to IP addresses
is too much of a loss of flexibility and functionality of the protocol.
However, there is the simple solution suggested in Pau-Chen and Dan's messages.
That is, use a key identifier for the pre-shared key: such a key identifier
would be meaningful only to the specific parties sharing that key.
As Dan pointed out you can then dispense of non-aggressive mode and
just do aggressive, thus saving communication. (You may still want
non-aggressive mode for the sake of negotiation). Bottom line: we achieved
more security, a more modular protocol, less communication and full
functionality.
In order to accomodate this key identifier one needs an
"Identifiction Type Value" as defined in the Ipsec DOI
(draft-ietf-ipsec-ipsec-doi-02.txt).
This can be one of the "private" values to be agrred upon by the
communicating parties, or we could have a type value (say 7) added in
that draft for "ID_KEY".
If there is no opposition to do so I would suggest this mininal editorial
change to the DOI draft.
Hugo
From owner-ipsec Mon Mar 17 19:05:50 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA24219 for ipsec-outgoing; Mon, 17 Mar 1997 19:04:13 -0500 (EST)
From: HUGO@watson.ibm.com
Message-Id: <199703180009.TAA29672@mailhub1.watson.ibm.com>
Date: Mon, 17 Mar 97 18:53:17 EST
To: smamros@newoak.com
cc: dharkins@cisco.com, PAU@watson.ibm.com, piper@cisco.com, ipsec@tis.com,
smamros@newoak.com
Subject: Comment on the ISAKMP/Oakley resolution draft (pre-shared)
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
See response below.
> HUGO@watson.ibm.com wrote:
> > Having the pre-shared key in SKEYID and the derived keys increases security.
> > It was my recommendation to do so. As just one example consider two
> > parties that use DH with a public prime p. If at some point enough
> > cryptanalysis and pre-computation is done on p then every exchange using that
> > prime may be compromised. This is a not-impossible scenario where you
> > lose (in a hard way) all the advantages of perfect forward secrecy
> > (your traffic of the last few years may be compromised!).
> > If, however, you derived your key depending
> > on both g^xy and your pre-shared key the attacker will need to find the
> > value of that pre-shared key (which will probably not exist at that point
> > of time) to find the actual keys used to protect the session traffic.
>
> OK, but if that's the case, is there then a problem with the
> derivation of SKEYID in the case where signatures are used for
> authentication, where only the nonces (passeed across the wire in
> plaintext) and g^xy are used?
You are right.
In this sense the signature mode is the weakest of all three modes.
In particular, in the case the public key encryption mode of authentication
the attacker needs to break the TWO private keys of the parties AND
the DH prime to find the keys (i.e. you get the MAXIMAL security of both
DH and RSA). This is one of the important reasons why I have been
"promoting" this mode for long time.
BTW, this not only protects against a broken DH, but also against
a partner to the communciation that implements poorly the DH exchange,
e.g. by choosing short exponents or by not destroying the exponents
immediately after use.
In addition, the signature mode has several privacy weaknesses: it
provides proofs of communication between the communicating parties,
does not protects identities against active attacker (on the other
hand it protects idenities with PFS), and does not provide identity-protection
at all in aggressive mode.
>
> Regarding the other comments and suggestions that have been made,
> I may have more to say in the next day or two - need to do some
> more thinking on the subject...
Hope it will be ok with you and others. Using pre-shared key in this way
(with a key identifier) seems to be the best solution in many cases,
e.g. for mobile users and dynamic IP addrsses.
Hugo
>
> -Shawn Mamros
> E-mail to: smamros@newoak.com
From owner-ipsec Tue Mar 18 07:42:20 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA28129 for ipsec-outgoing; Tue, 18 Mar 1997 07:36:43 -0500 (EST)
Message-Id: <199703181236.HAA28129@portal.ex.tis.com>
Date: Mon, 17 Mar 1997 18:45:51 -0500
From: smamros@newoak.com (Shawn Mamros)
X-Mailer: Mozilla 4.0b2 (WinNT; I)
MIME-Version: 1.0
To: HUGO@watson.ibm.com
CC: dharkins@cisco.com, PAU@watson.ibm.com, piper@cisco.com, ipsec@tis.com,
smamros@newoak.com
Subject: Re: Comment on the ISAKMP/Oakley resolution draft (pre-shared)
X-Priority: 3 (Normal)
References: <199703172324.SAA50747@mailhub1.watson.ibm.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
HUGO@watson.ibm.com wrote:
> Having the pre-shared key in SKEYID and the derived keys increases security.
> It was my recommendation to do so. As just one example consider two
> parties that use DH with a public prime p. If at some point enough
> cryptanalysis and pre-computation is done on p then every exchange using
that
> prime may be compromised. This is a not-impossible scenario where you
> lose (in a hard way) all the advantages of perfect forward secrecy
> (your traffic of the last few years may be compromised!).
> If, however, you derived your key depending
> on both g^xy and your pre-shared key the attacker will need to find the
> value of that pre-shared key (which will probably not exist at that point
> of time) to find the actual keys used to protect the session traffic.
OK, but if that's the case, is there then a problem with the
derivation of SKEYID in the case where signatures are used for
authentication, where only the nonces (passeed across the wire in
plaintext) and g^xy are used?
Regarding the other comments and suggestions that have been made,
I may have more to say in the next day or two - need to do some
more thinking on the subject...
-Shawn Mamros
E-mail to: smamros@newoak.com
From owner-ipsec Tue Mar 18 08:53:49 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA28821 for ipsec-outgoing; Tue, 18 Mar 1997 08:53:01 -0500 (EST)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce
cc: ipsec@tis.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-vpn-00.txt
Date: Tue, 18 Mar 1997 08:49:48 -0500
Message-ID: <9703180849.aa18842@ietf.org>
Sender: owner-ipsec@ex.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 : Implementation of Virtual Private Network (VPNs) with IP
Security
Author(s) : N. Doraswamy
Filename : draft-ietf-ipsec-vpn-00.txt
Pages : 5
Date : 03/14/1997
This document discusses methods for implementing Virtural Private Networks
(VPN) with IP Security (IPSec). We discuss different scenarios in which VPN
is implemented and the security implications for each of these scenarios.
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-vpn-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-vpn-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
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-vpn-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.
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: <19970317162735.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-vpn-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-vpn-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970317162735.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ipsec Tue Mar 18 11:19:47 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00056 for ipsec-outgoing; Tue, 18 Mar 1997 11:17:46 -0500 (EST)
Date: Tue, 18 Mar 97 16:15:01 GMT Standard Time
From: Ran Atkinson <rja@inet.org>
Subject: Re: Closing out the COMPRESSION discussion
To: Bob Monsour <rmonsour@earthlink.net>, ipsec@tis.com
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <3.0.32.19970316213807.00930100@earthlink.net>
Message-ID: <Chameleon.858701872.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
All,
The WG chairs do not see any clear consensus on compression within the IPsec
WG at this time. As such, the discussion on compression is NOT "closed".
In fact additional discussion on this topic is encouraged.
We hope to have further discussions in Memphis on the topic of compression.
People desiring to make technical presentations on this (or other IPsec)
topic(s) should send email to me and Paul Lambert <palamber@us.oracle.com>
with the topic and time requested.
Ran
rja@inet.org
From owner-ipsec Tue Mar 18 11:41:20 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00239 for ipsec-outgoing; Tue, 18 Mar 1997 11:40:04 -0500 (EST)
Date: Tue, 18 Mar 97 16:37:36 GMT Standard Time
From: Ran Atkinson <rja@inet.org>
Subject: [Admin] 38th IETF: IPSEC slots
To: ipsec@tis.com
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <2.2.32.19970318162210.0070912c@ietf.org>
Message-ID: <Chameleon.858703209.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
There are two sessions for IPSEC in Memphis as follows:
Wednesday, April 9 at 0900-1115 (opposite stdguide, rmonmib, pktway,
run, ids, rps, ftpext, qosr, otsv)
Thursday, April 10 at 1300-1500 (opposite fax, mpls, lsma, ipngwg)
One of these meetings will be focused on implementation discussions,
including reports from the AIAG interoperability testing, etc.
The other will focus more on standards issues.
Ran
rja@inet.org
From owner-ipsec Tue Mar 18 12:18:37 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA00506 for ipsec-outgoing; Tue, 18 Mar 1997 12:06:00 -0500 (EST)
Message-Id: <3.0.16.19970318120243.2957b404@pop3.pn.com>
X-Pgp-Key: <http://www.shore.net/~sable/info/rltkey.htm>
X-Sender: rodney@pop3.pn.com
X-Mailer: Windows Eudora Pro Version 3.0 (16)
Date: Tue, 18 Mar 1997 12:10:55 -0500
To: ipsec@tis.com
From: Rodney Thayer <rodney@sabletech.com>
Subject: survey results
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
If you have previously responded to a survey and you don't have any
changes, you don't have to respond again. I will post the existing survey
results along with the new ones I'm receiving. Sorry about the confusion.
Rodney Thayer <rodney@sabletech.com> +1 617 332 7292
Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA
Fax: +1 617 332 7970 http://www.shore.net/~sable
"Developers of communications software"
From owner-ipsec Tue Mar 18 15:04:24 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA00939 for ipsec-outgoing; Tue, 18 Mar 1997 15:01:06 -0500 (EST)
Message-ID: <332EF66B.7701@newoak.com>
Date: Tue, 18 Mar 1997 15:09:15 -0500
From: smamros@newoak.com (Shawn Mamros)
X-Mailer: Mozilla 4.0b2 (WinNT; I)
MIME-Version: 1.0
To: HUGO@watson.ibm.com
CC: dharkins@cisco.com, PAU@watson.ibm.com, piper@cisco.com, ipsec@tis.com,
smamros@newoak.com
Subject: Re: Comment on the ISAKMP/Oakley resolution draft (pre-shared)
X-Priority: 3 (Normal)
References: <199703172324.SAA50747@mailhub1.watson.ibm.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
After thinking about the issue some more and discussing it with
my coworkers, we're willing to go with the workaround proposed
by Pau-Chen, Dan and Hugo (i.e., using an opaque identifier in
Oakley Aggressive Mode to find the correct pre-shared key).
Thanks for the suggestion, guys...
One possibility that Hugo mentioned in one of his messages:
> In order to accomodate this key identifier one needs an
> "Identifiction Type Value" as defined in the Ipsec DOI
> (draft-ietf-ipsec-ipsec-doi-02.txt).
> This can be one of the "private" values to be agrred upon by the
> communicating parties, or we could have a type value (say 7) added in
> that draft for "ID_KEY".
> If there is no opposition to do so I would suggest this mininal editorial
> change to the DOI draft.
Ideally, I too would like to see an "official" value designated in
the DOI draft, if it's possible. But I'm willing to live with a
private value if we have to...
-Shawn Mamros
E-mail to: smamros@newoak.com
From owner-ipsec Tue Mar 18 15:06:11 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA00987 for ipsec-outgoing; Tue, 18 Mar 1997 15:06:03 -0500 (EST)
Message-Id: <199703182009.MAA03622@mailsun3-fddi.us.oracle.com>
Date: 18 Mar 97 11:09:43 -0800
From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>
To: ipsec@tis.com
Subject: IPSEC Agenda
Cc: rodney@sabletech.com, rja@inet.org
MIME-Version: 1.0
X-Mailer: Oracle InterOffice (version 4.0.4.0.25)
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
There will be two IPSEC sessions in Memphis:
Wednesday, April 9 at 0900-1115 (opposite stdguide, rmonmib, pktway,
run, ids, rps, ftpext, qosr, otsv)
Thursday, April 10 at 1300-1500 (opposite fax, mpls, lsma, ipngwg)
The first session will cover the IPSEC specifications in progress and ongoing
or new IPSEC work items.
The second session will be an implementation session that only covers
implementation issues, interoperability testing, interoperability profiles,
etc.
Please send requests for agenda slots asap to the co-chairs (rja@inet.org,
palamber@us.oracle.com). Please be sure to have "IPSEC Agenda" in your
subject line or your message may be ignored. Preference is always given to
editors of IPSEC I-Ds. If you are interested in presenting during the
implementation session please also copy to Rodney Thayer
(rodney@sabletech.com). Rodney is helping coordinate the IPSEC implementation
session in Memphis (thanks Rodney!).
Regards,
Paul
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Paul Lambert Director of Security Products
Oracle Corporation Phone: (415) 506-0370
500 Oracle Parkway, Box 659410 Fax: (415) 633-2963
Redwood Shores, CA 94065 E-Mail: palamber@us.oracle.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Secure jobs for software developers 6+ years experience.
Send resumes to palamber@us.oracle.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From owner-ipsec Tue Mar 18 15:57:20 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA01310 for ipsec-outgoing; Tue, 18 Mar 1997 15:56:57 -0500 (EST)
Message-Id: <199703182022.MAA09677@fluffy.cisco.com>
To: smamros@newoak.com (Shawn Mamros)
cc: HUGO@watson.ibm.com, dharkins@cisco.com, PAU@watson.ibm.com,
piper@cisco.com, ipsec@tis.com
Subject: Re: Comment on the ISAKMP/Oakley resolution draft (pre-shared)
In-reply-to: Your message of "Tue, 18 Mar 1997 15:09:15 EST."
<332EF66B.7701@newoak.com>
Date: Tue, 18 Mar 1997 12:22:16 -0800
From: Derrell Piper <piper@cisco.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
This seems like a worthwhile addition. I'll post an updated IPSEC DOI
before the Memphis deadline. I have one other attribute that needs to
be added ("Key Length" for variable length ciphers like RC5).
Derrell
From owner-ipsec Tue Mar 18 17:32:33 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA01887 for ipsec-outgoing; Tue, 18 Mar 1997 17:27:56 -0500 (EST)
Date: 18 Mar 97 16:32:27 -0600
Subject: Re: [Admin] 38th IETF: IPSEC slots
From: "James Hughes" <hughes@nsco.network.com>
To: ipsec@tis.com, "Ran Atkinson" <rja@inet.org>
X-Mailer: Cyberdog/2.0b1
Mime-Version: 1.0
Message-Id: <AF547430-35366@129.191.63.3>
Content-Type: multipart/mixed; boundary="Cyberdog-MixedBoundary-00034EB0"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
--Cyberdog-MixedBoundary-00034EB0
X-Fontfamily: Palatino
X-Fontsize: 12
Content-Type: text/enriched; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Should I plan on presenting?
jim
On Tue, Mar 18, 1997 10:37 AM,
--Cyberdog-MixedBoundary-00034EB0
Content-Type: application/X-url
Content-Transfer-Encoding: base64
Content-Description: Ran Atkinson
bWFpbHRvOnJqYUBpbmV0Lm9yZw==
--Cyberdog-MixedBoundary-00034EB0
X-Fontfamily: Palatino
X-Fontsize: 12
Content-Type: text/enriched; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
wrote:
>
>
> There are two sessions for IPSEC in Memphis as follows:
>
> Wednesday, April 9 at 0900-1115 (opposite stdguide, rmonmib,
pktway,
> run, ids, rps, ftpext, qosr,
otsv)
> Thursday, April 10 at 1300-1500 (opposite fax, mpls, lsma, ipngwg)
>
> One of these meetings will be focused on implementation discussions,
> including reports from the AIAG interoperability testing, etc.
>
> The other will focus more on standards issues.
>
> Ran
> rja@inet.org
--Cyberdog-MixedBoundary-00034EB0--
From owner-ipsec Tue Mar 18 18:41:46 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA02261 for ipsec-outgoing; Tue, 18 Mar 1997 18:39:58 -0500 (EST)
Message-Id: <2.2.32.19970318235202.00b0e704@mailserv-H.ftp.com>
X-Sender: naganand@mailserv-H.ftp.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 18 Mar 1997 18:52:02 -0500
To: ipsec@tis.com
From: Naganand Doraswamy <naganand@ftp.com>
Subject: Issues with generating IV's in combined transforms
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Both DES and 3DES combined transform specify the way to generate IV's.
However, we dont maintain a running IV. In this case, isint it better to
just send an IV in the packet always and not make it optional?
--Naganand
----------------------------------------------------------------
naganand@ftp.com
Tel #: (508)684-6743 (O)
From owner-ipsec Tue Mar 18 20:38:00 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA02940 for ipsec-outgoing; Tue, 18 Mar 1997 20:36:58 -0500 (EST)
Message-Id: <199703190141.RAA19484@dharkins-ss20>
X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol
To: ipsec@tis.com
Cc: anx-sec@dot.netrex.net
Subject: cisco's free ISAKMP reference implementation
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 18 Mar 1997 17:41:27 -0800
From: Daniel Harkins <dharkins@cisco.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
A bug has been found in the latest ISAKMP release from cisco. If any of
you obtained a copy (and want to do signature authentication) please
get a fresh copy.
Sorry for the inconvienence.
Dan.
From owner-ipsec Wed Mar 19 09:59:00 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA07232 for ipsec-outgoing; Wed, 19 Mar 1997 09:56:36 -0500 (EST)
Message-Id: <3.0.32.19970319065713.00949100@earthlink.net>
X-Sender: rmonsour@earthlink.net
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 19 Mar 1997 06:57:20 -0800
To: Ran Atkinson <rja@inet.org>
From: Bob Monsour <rmonsour@earthlink.net>
Subject: Re: Closing out the COMPRESSION discussion
Cc: Bob Monsour <rmonsour@earthlink.net>, ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Would someone like to suggest where to take the discussion from here?
-Bob
At 04:15 PM 3/18/97 Time, Ran Atkinson wrote:
>All,
>
>The WG chairs do not see any clear consensus on compression within the IPsec
>WG at this time. As such, the discussion on compression is NOT "closed".
>In fact additional discussion on this topic is encouraged.
>
>We hope to have further discussions in Memphis on the topic of compression.
>
>People desiring to make technical presentations on this (or other IPsec)
>topic(s) should send email to me and Paul Lambert <palamber@us.oracle.com>
>with the topic and time requested.
>
>Ran
>rja@inet.org
>
>
>
From owner-ipsec Wed Mar 19 11:02:18 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA07734 for ipsec-outgoing; Wed, 19 Mar 1997 11:00:03 -0500 (EST)
Message-Id: <3.0.1.32.19970319110315.00b4ad70@dilbert.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@dilbert.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 19 Mar 1997 11:03:15 -0500
To: Bob Monsour <rmonsour@earthlink.net>, Ran Atkinson <rja@inet.org>
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: Closing out the COMPRESSION discussion
Cc: Bob Monsour <rmonsour@earthlink.net>, ipsec@tis.com
In-Reply-To: <3.0.32.19970319065713.00949100@earthlink.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 06:57 AM 3/19/97 -0800, Bob Monsour wrote:
>Would someone like to suggest where to take the discussion from here?
>
Unfortunately, this straw vote occured over a time where my mail was hosed
from multiple sources (maybe someone was out to get me ;).
Compression is a must deliver for remote, dialup users. These will number
in their thousands in the corporate arena. In fact, until IPsec is deployed
internally in corporations, remote systems will represent the lion share of
the market and the dollar volume (even with gateways costing more than ws
code).
If this group does not address compression head-on, someone(s) will do it
and publish, at best, an informational RFC of how they did it and vendors
will move down that road to compete in the market. ie the market decides.
Get off the dime, people. Chrysler alone currently fields 6000 notebooks
with another 1000 on order. We plan on putting IPsec into all of them
4Q97. The vendor that delivers compression will get our attention. Ford,
GM, UTA, TRW, PACCAR, John Deere, etc have similar needs. We will work as
a consolidated group (to an extent of course :) to get product that meets
our needs.
I welcome Bob's efforts. It is a careful balance of functionality and
interoperability. I invite him to bring his approach to round 3 or 4 of
our testing/piloting of IPsec. I'd rather it be an IPsec wg methodology.
I can dance around no compression for a little while, but I've been
chartered by the AIAG to deliver the goods, securely.....
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
From owner-ipsec Wed Mar 19 11:48:35 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA08121 for ipsec-outgoing; Wed, 19 Mar 1997 11:48:25 -0500 (EST)
Date: Wed, 19 Mar 1997 11:50:40 -0500
From: ho@earth.hpc.org (Hilarie Orman)
Message-Id: <199703191650.LAA28195@earth.hpc.org>
To: rgm3@chrysler.com
Cc: ipsec@tis.com
In-reply-to: Yourmessage <199703191615.JAA20358@baskerville.CS.Arizona.EDU>
Subject: Re: Closing out the COMPRESSION discussion
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> Compression is a must deliver for remote, dialup users.
Wonderful, just have the compression WG publish their RFC describing the
protocol; I assume they'll define one for TCP streams and another that
can sit over any datagram protocol.
The dime that this group should rise from is inline rekeying using DH
medium-term secrets.
Hilarie
From owner-ipsec Wed Mar 19 12:22:12 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA08339 for ipsec-outgoing; Wed, 19 Mar 1997 12:20:41 -0500 (EST)
From: Dan.McDonald@Eng.sun.com (Dan McDonald)
Message-Id: <199703191725.JAA00587@kebe.eng.sun.com>
Subject: All this tweaking is nice, but...
To: ipsec@tis.com
Date: Wed, 19 Mar 1997 09:25:39 -0800 (PST)
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Hello folks in IPsec-land!
I've been seeing a lot of last-minute tweaks lately on the list. As someone
who Writes Code (TM), and as someone who's helped build some of the earliest
versions of IPsec, I just have one question: WHY?
Most of the ones I've seen recently seem extraneous (we can argue until we're
blue in the face about if truncation is stronger, but the critical question
is if non-truncated is BROKEN?), and others are made for reasons that don't
take into account the big picture (code needed to parse variable-sized replay
counters is lost in the noise compared with the HMAC calculations, so don't
go whining about performance).
I'll bet small sums that some of what's been popping up on IPsec is the
result of some of the AIAG stuff. It's good that stuff like AIAG happens,
but you guys can't forget that some of us aren't doing (or can't do) AIAG yet
for _varying_ reasons.
A few things to remember folks:
1.) The IP Security Architecture is EXTENSIBLE. This means if
something's really broke, you can obsolete the current draft
with a new one. Apart from changes derived from Bellovin's
summer USENIX paper (some of which, mind you, merely involved
following the spec), I haven't seen anything after those changes
(Combined ESP, replay) that fixes honest-to-God BREAKAGE.
Let's go with what's there, and create NEW drafts for some of
these new approaches.
2.) The KISS principle. Yes, we can't leave gaping holes, but if
there are no gaping holes, let's not go changing for change's
sake! I'd suggest to everyone on this list a re-reading of _The
Mythical Man-Month_ by Fred Brooks. And if you've never read
this seminal work, for crying out loud find a copy.
3.) Let's not create a separate implementors list the way IPng did.
I don't get AIAG-type mail, because I'm unable to show up for
now. I'm sure I'm not the only one, though. Spec writers need
to hear about implementation experience, and implementors need to
hear the writers' rationale(s).
4.) We're in the risk reduction business. The only perfect security
is the good ole-fashioned airgap firewall, or something else that
keeps you from moving bits. (If anyone calls your network
"truly secure" be afraid, be very afraid.) If we reduce the
vulnerability, we're doing well.
Alright alright, I'll climb down off my soapbox now.
ObPlug: My updated internet drafts are in the I-D queue currently.
Watch for them.
--
Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT
Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S!
Phone: (415) 786-6815 |"rising falling at force ten
WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush
From owner-ipsec Wed Mar 19 13:01:15 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08737 for ipsec-outgoing; Wed, 19 Mar 1997 13:00:55 -0500 (EST)
Message-Id: <3.0.1.32.19970319130501.00a79450@dilbert.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@dilbert.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 19 Mar 1997 13:05:01 -0500
To: ipsec@tis.com
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Purpose of AIAG discussion list....
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
For those of you not interested in what is going on the AIAG list, but want
to know why it exists, here is a note that I posted on it a week ago to
clear this up, I hope.
>Reply-To: rgm3@is.chrysler.com
>X-Sender: rgm3@dilbert.is.chrysler.com
>Date: Wed, 12 Mar 1997 16:57:22 -0500
>To: anx-sec@dot.netrex.net, anx-sec@dot.netrex.net,
> Naganand Doraswamy <naganand@ftp.com>
>From: Robert Moskowitz <rgm3@is.chrysler.com>
>Subject: Re: developers list
>Sender: owner-anx-sec@dot.netrex.net
>Reply-To: anx-sec@dot.netrex.net
>
>At 05:02 PM 3/8/97 Time, Ran Atkinson wrote:
>>
>>Paul Lambert and I would like to suggest that the implementer discussions
>>occur on the main IPsec list rather than on some sidebar list. This
>>helps keep everyone in sync. Also, the IPsec list is not so noisy these
>>days that it is an issue to have implementer discussions on the main
>>list.
>
>The purpose of this list is to allow vendors and AIAG members to move IPsec
>forward to implementation in step with the ANX schedule. To this extent,
>defining what will be needed in terms of the protocols, and what is not
>clear can definitely be handled on this list.
>
>However, when things are unclear in understanding the specs, or when
>particular insights are learned here, these really have to go to the main
>IPsec list.
>
>I also plan on keeping the main IPsec list abreast of what our requirements
>- expectations - experiences are.
>
>As an ADMIN note, Ran has been on this list since I started it. I was very
>appreciative of Steve Kent to be willing to add this list to his traffic to
>gain his insights. But to all non-coders or non-auto-implementors, I ask
>you to understand our purpose (get product out that interoperates) and our
>schedule.
>
>
>Robert Moskowitz
>Chrysler Corporation
>(810) 758-8212
>
>
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
From owner-ipsec Wed Mar 19 13:18:17 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08842 for ipsec-outgoing; Wed, 19 Mar 1997 13:18:01 -0500 (EST)
Message-ID: <61CDD2C9A961CF11B6A000805FD40AA9031C76EA@RED-84-MSG.dns.microsoft.com>
From: Glen Zorn <glennz@microsoft.com>
To: rgm3@chrysler.com, Bob Monsour <rmonsour@earthlink.net>,
Ran Atkinson
<rja@inet.org>
Cc: ipsec@tis.com
Subject: RE: Closing out the COMPRESSION discussion
Date: Wed, 19 Mar 1997 10:03:23 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I'm not sure I understand your point, Bob. Surely most (if not all)
dial-up users will be using PPP, which already offers compression. What
am I missing?
-----Original Message-----
From: Robert Moskowitz [SMTP:rgm3@chrysler.com]
Sent: Wednesday, March 19, 1997 8:03 AM
To: Bob Monsour; Ran Atkinson
Cc: Bob Monsour; ipsec@tis.com
Subject: Re: Closing out the COMPRESSION discussion
At 06:57 AM 3/19/97 -0800, Bob Monsour wrote:
>Would someone like to suggest where to take the discussion from
here?
>
Unfortunately, this straw vote occured over a time where my mail
was hosed
from multiple sources (maybe someone was out to get me ;).
Compression is a must deliver for remote, dialup users. These
will number
in their thousands in the corporate arena. In fact, until IPsec
is deployed
internally in corporations, remote systems will represent the
lion share of
the market and the dollar volume (even with gateways costing
more than ws
code).
If this group does not address compression head-on, someone(s)
will do it
and publish, at best, an informational RFC of how they did it
and vendors
will move down that road to compete in the market. ie the market
decides.
Get off the dime, people. Chrysler alone currently fields 6000
notebooks
with another 1000 on order. We plan on putting IPsec into all
of them
4Q97. The vendor that delivers compression will get our
attention. Ford,
GM, UTA, TRW, PACCAR, John Deere, etc have similar needs. We
will work as
a consolidated group (to an extent of course :) to get product
that meets
our needs.
I welcome Bob's efforts. It is a careful balance of
functionality and
interoperability. I invite him to bring his approach to round 3
or 4 of
our testing/piloting of IPsec. I'd rather it be an IPsec wg
methodology.
I can dance around no compression for a little while, but I've
been
chartered by the AIAG to deliver the goods, securely.....
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
From owner-ipsec Wed Mar 19 14:05:03 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA09269 for ipsec-outgoing; Wed, 19 Mar 1997 14:02:17 -0500 (EST)
Message-Id: <3.0.1.32.19970319140514.00ab68f0@dilbert.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@dilbert.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 19 Mar 1997 14:05:14 -0500
To: Glen Zorn <glennz@microsoft.com>, Bob Monsour <rmonsour@earthlink.net>,
Ran Atkinson <rja@inet.org>
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: RE: Closing out the COMPRESSION discussion
Cc: ipsec@tis.com
In-Reply-To: <61CDD2C9A961CF11B6A000805FD40AA9031C76EA@RED-84-MSG.dns.mi
crosoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 10:03 AM 3/19/97 -0800, Glen Zorn wrote:
>I'm not sure I understand your point, Bob. Surely most (if not all)
>dial-up users will be using PPP, which already offers compression. What
>am I missing?
Once you encrypt you cannot compress, or else there is something wrong with
your crypto, as I understand it. Thus PPP compression would only act on
the PPP and IP header stuff.
No offense, Glen, but this question tends to indicate that you have missed
a big part of the compression discussion.
Another reason given for IPsec compression is to get a packet to fit into
an IP tunnel payload. The argument against this is that MTU discovery
should handle this problem.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
From owner-ipsec Wed Mar 19 17:13:34 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA10541 for ipsec-outgoing; Wed, 19 Mar 1997 17:11:06 -0500 (EST)
Message-ID: <01BC3470.1AC91AE0@Tastid.cisco.com>
From: adams@cisco.com (Rob Adams)
To: ipsec@tis.com ('ipsec@tis.com')
Subject: RE: All this tweaking is nice, but...
Date: Wed, 19 Mar 1997 14:16:02 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I don't know but I think we wouldn't be doing all this tweeking if the original drafts
had been well thought out and the NRL "reference" pile of... code... made sense
for more than just the base transforms which, lets face it, made no sense.
You must agree that less than six months ago when we had a base transform
that depended on changing the behaviour of MD5 and sets of documents that
said "oh and key management will handle that" when key management didn't
exist really, and we had drafts with material changes being introduced AFTER
last call and etc. etc. etc. we were in pretty bad shape.
I would argue that this process is broken and that the tweaks are necessary to
produce something that is secure and that does make sense and is extensible.
The drafts/RFC we have now are not really any of the above.
64 bit replay? great for alignment, bad for security/stupid to implement.
key hashing by transforms based on ISAKMP attributes? what? secure maybe, extensible? what?
documents to resolve documents? When is that ever right?
variable length optional fields in the middle of fixed headers?? WHAT! -10. I can hear my compsci
120 prof laughing now..
I would call all of the above "honest to God BREAKAGE."
A lot of us "Write Code (TM)". A lot of us write for a market that cares
about quality and security. A lot of us write code that has to be maintained
and costs money if it is broken. A lot of us will have to live with this pile of ..
code .. for a long time in the future. We want this to work, to be secure, to
be really extensible and we don't want to support broken, ill-conceived trash
that we'll have to maintain forever because some customer will not upgrade.
That's the difference between the NRL hack ah oh sorry, code and what
we are doing. I don't think we require perfection, we just require that it
makes sense and will actually achieve the goals we have for our products
and our customers.
Rob Adams
Cisco Systems
----------
From: Dan McDonald[SMTP:Dan.McDonald@Eng.sun.com]
Sent: Wednesday, March 19, 1997 9:25 AM
To: ipsec@tis.com
Subject: All this tweaking is nice, but...
Hello folks in IPsec-land!
I've been seeing a lot of last-minute tweaks lately on the list. As someone
who Writes Code (TM), and as someone who's helped build some of the earliest
versions of IPsec, I just have one question: WHY?
Most of the ones I've seen recently seem extraneous (we can argue until we're
blue in the face about if truncation is stronger, but the critical question
is if non-truncated is BROKEN?), and others are made for reasons that don't
take into account the big picture (code needed to parse variable-sized replay
counters is lost in the noise compared with the HMAC calculations, so don't
go whining about performance).
I'll bet small sums that some of what's been popping up on IPsec is the
result of some of the AIAG stuff. It's good that stuff like AIAG happens,
but you guys can't forget that some of us aren't doing (or can't do) AIAG yet
for _varying_ reasons.
A few things to remember folks:
1.) The IP Security Architecture is EXTENSIBLE. This means if
something's really broke, you can obsolete the current draft
with a new one. Apart from changes derived from Bellovin's
summer USENIX paper (some of which, mind you, merely involved
following the spec), I haven't seen anything after those changes
(Combined ESP, replay) that fixes honest-to-God BREAKAGE.
Let's go with what's there, and create NEW drafts for some of
these new approaches.
2.) The KISS principle. Yes, we can't leave gaping holes, but if
there are no gaping holes, let's not go changing for change's
sake! I'd suggest to everyone on this list a re-reading of _The
Mythical Man-Month_ by Fred Brooks. And if you've never read
this seminal work, for crying out loud find a copy.
3.) Let's not create a separate implementors list the way IPng did.
I don't get AIAG-type mail, because I'm unable to show up for
now. I'm sure I'm not the only one, though. Spec writers need
to hear about implementation experience, and implementors need to
hear the writers' rationale(s).
4.) We're in the risk reduction business. The only perfect security
is the good ole-fashioned airgap firewall, or something else that
keeps you from moving bits. (If anyone calls your network
"truly secure" be afraid, be very afraid.) If we reduce the
vulnerability, we're doing well.
Alright alright, I'll climb down off my soapbox now.
ObPlug: My updated internet drafts are in the I-D queue currently.
Watch for them.
--
Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT
Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S!
Phone: (415) 786-6815 |"rising falling at force ten
WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush
From owner-ipsec Wed Mar 19 18:28:56 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA11248 for ipsec-outgoing; Wed, 19 Mar 1997 18:26:34 -0500 (EST)
Message-Id: <61CDD2C9A961CF11B6A000805FD40AA9031DB71B@RED-84-MSG.dns.microsoft.com>
From: Glen Zorn <glennz@microsoft.com>
To: rgm3@chrysler.com, Bob Monsour <rmonsour@earthlink.net>
Cc: ipsec@tis.com
Subject: RE: Closing out the COMPRESSION discussion
Date: Wed, 19 Mar 1997 15:29:57 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 10:03 AM 3/19/97 -0800, Glen Zorn wrote:
>I'm not sure I understand your point, Bob. Surely most (if not
all)
>dial-up users will be using PPP, which already offers
compression. What
>am I missing?
Once you encrypt you cannot compress, or else there is something
wrong with
your crypto, as I understand it. Thus PPP compression would
only act on
the PPP and IP header stuff.
Yes, you wouldn't get a very good compression factor at least.
No offense, Glen,
None taken!
but this question tends to indicate that you have missed
a big part of the compression discussion.
That answers one question; I'll shut up an d listen for awhile.
Perhaps it was just that I dropped in on the middle of the conversation,
but I was puzzled as to what compression had to do w/security.
Another reason given for IPsec compression is to get a packet to
fit into
an IP tunnel payload. The argument against this is that MTU
discovery
should handle this problem.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
From owner-ipsec Wed Mar 19 21:04:18 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA12032 for ipsec-outgoing; Wed, 19 Mar 1997 21:03:30 -0500 (EST)
Date: Thu, 20 Mar 97 01:57:18 GMT Standard Time
From: Ran Atkinson <rja@inet.org>
Subject: Re: the COMPRESSION discussion
To: ipsec@tis.com
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <3.0.1.32.19970319110315.00b4ad70@dilbert.is.chrysler.com>
Message-ID: <Chameleon.858823442.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Just to be clear, I _personally_ am indifferent about compression.
As co-chair, I'm very religious about following the standards process.
Before we can move forward there MUST be rough consensus within the WG
on how to proceed. Right now this just is not present. Sigh.
The items that the IPsec WG needs to sort out are:
1) Is compression "must implement" or "optional to implement" or
"outside our scope" ?
If its inside our scope, then these next items also need to
be sorted out:
2) What compression mechanism (not algorithm, but how to implement
and at what processing layer) should be used ?
3) How to ensure that the compression mechanism can support arbitrary
compression algorithms so that a new gee-whiz compression
algorithm can be added modularly without changing everything.
Reasonable steps towards progress might include:
- Various people writing up various approaches as I-Ds and
presenting these in Memphis (warning: time is short)
- Discussing specifics on the IPsec list, noting which items
are most important.
- A clear agreement on the scope of the problem that should
be addressed.
- Deciding whether compression is just an ESP issue or
whether it might be good to have a more generalised scheme
for IP-layer compression of any IP packet (not just those
packets with IPsec)
Ran
rja@inet.org
From owner-ipsec Wed Mar 19 21:05:36 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA12076 for ipsec-outgoing; Wed, 19 Mar 1997 21:05:33 -0500 (EST)
Date: Thu, 20 Mar 97 02:04:42 GMT Standard Time
From: Ran Atkinson <rja@inet.org>
Subject: Re: Closing out the COMPRESSION discussion
To: Hilarie Orman <ho@earth.hpc.org>, rgm3@chrysler.com
Cc: ipsec@tis.com
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <199703191650.LAA28195@earth.hpc.org>
Message-ID: <Chameleon.858823553.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
--- On Wed, 19 Mar 1997 11:50:40 -0500 Hilarie Orman <ho@earth.hpc.org> wrote:
> The dime that this group should rise from is inline rekeying using DH
> medium-term secrets.
>
> Hilarie
---------------End of Original Message-----------------
Hilarie,
I expect that Bill Sommerfeld will be publishing a revised version
of inline keying with ISAKMP in the near future and I hope it will
be discussed in Memphis. Bill is the document editor for that work
item.
Best wishes,
Ran
rja@inet.org
From owner-ipsec Thu Mar 20 02:42:12 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA13657 for ipsec-outgoing; Thu, 20 Mar 1997 02:41:13 -0500 (EST)
Message-Id: <3.0.32.19970319234159.009c34e0@earthlink.net>
X-Sender: rmonsour@earthlink.net
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 19 Mar 1997 23:42:06 -0800
To: Ran Atkinson <rja@inet.org>
From: Bob Monsour <rmonsour@earthlink.net>
Subject: Re: the COMPRESSION discussion
Cc: PALAMBER@us.oracle.com, ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 01:57 AM 3/20/97 Time, Ran Atkinson wrote:
>
>Just to be clear, I _personally_ am indifferent about compression.
>As co-chair, I'm very religious about following the standards process.
>Before we can move forward there MUST be rough consensus within the WG
>on how to proceed. Right now this just is not present. Sigh.
>The items that the IPsec WG needs to sort out are:
>
>1) Is compression "must implement" or "optional to implement" or
> "outside our scope" ?
>
Ran, please forgive my frustration here (and perhaps I'm miss-reading the
process) but I distinctly recall Paul Lambert getting up to summarize the
activity of the WG meeting (in San Jose) and saying that there appeared to
be consensus that the WG should take up compression as a work item. What I
find frustrating is that the recently issued minutes (I understand that
they "have not been edited") state "A straw pole indicated there is no
current consensus on how to proceed". Am I the only one with this
recollection? I read Paul's comment as calling compression within the scope
of the WG.
>If its inside our scope, then these next items also need to
>be sorted out:
>
>
>2) What compression mechanism (not algorithm, but how to implement
> and at what processing layer) should be used ?
>3) How to ensure that the compression mechanism can support arbitrary
> compression algorithms so that a new gee-whiz compression
> algorithm can be added modularly without changing everything.
I appreciate your desire to be "very religious about following the
standards process", but what I also find frustrating is the lack of
presence of the co-chairs, in a moderating role, during the lengthy
discussions that have been conducted on the list; items 2 and 3 that you
list above are topics that have been discussed somewhat vigorously over the
last few months. Where were you? The working group guidelines call for the
co-chairs to "attempt to ensure that the discussions on the list are
relevant and that they converge to consensus agreements". If there was an
issue of whether or not compression was "inside our scope", then I would've
expected to have the question of relevance raised early in the discussion
for us to carry out that debate prior to spending an awful lot of WG time
and energy on the topic. Specifically, in an email I wrote on Jan 23, I said:
At the December IETF meeting, the IPSEC working group consensus was to
undertake compression as a work item.
In the rest of that email, I recapped the San Jose discussion, reviewed the
proposals made in San Jose, and requested input on some of the issues
raised at the WG meeting. I understand that the decisions in the meeting
are not final (nothing is), but again, I would've expected some co-chair
moderation to raise the question to the WG to avoid wasting everyone's
valuable time.
>Reasonable steps towards progress might include:
> - Various people writing up various approaches as I-Ds and
> presenting these in Memphis (warning: time is short)
> - Discussing specifics on the IPsec list, noting which items
> are most important.
> - A clear agreement on the scope of the problem that should
> be addressed.
> - Deciding whether compression is just an ESP issue or
> whether it might be good to have a more generalised scheme
> for IP-layer compression of any IP packet (not just those
> packets with IPsec)
In an earlier email I made a formal request for agenda time in Memphis.
There will be a draft submitted by the 3/26 cutoff date. As promised
earlier, I will not refer to any consensus or straw poll info during my
presentation. I will defer to you to make the necessary process calls at
the meeting.
In closing, the reality I am seeing in the vendor community is that there
WILL be a number of companies in the market with compressing IPSec
implementations. In the interest of the user community, it is important
that the WG strive for the goal of interoperable implementations of this
capability.
I hope you understand my concerns.
Regards (really),
-Bob
From owner-ipsec Thu Mar 20 09:44:54 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA16496 for ipsec-outgoing; Thu, 20 Mar 1997 09:42:34 -0500 (EST)
Date: Thu, 20 Mar 1997 09:45:10 -0500
From: ho@earth.hpc.org (Hilarie Orman)
Message-Id: <199703201445.JAA06780@earth.hpc.org>
To: rja@inet.org
Cc: rgm3@chrysler.com, ipsec@tis.com
In-reply-to: Yourmessage <Chameleon.858823553.rja@c8-a.snvl1.sfba.home.com>
Subject: Re: Closing out the COMPRESSION discussion
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
As I mentioned in San Jose, Bill Sommerfeld's version of inline keying
is not at all what I mean. What I mean is carrying an identifier in
the ESP header that can be hashed with a pre-established secret to
produce the unique key for the packet payload. This can be done many
times to achieve uni-directional rekeying before security would demand
that the pre-established secret be changed.
I think the distinction is inline keys vs. inline key exchanges.
Hilarie
From owner-ipsec Thu Mar 20 10:44:13 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA17060 for ipsec-outgoing; Thu, 20 Mar 1997 10:43:23 -0500 (EST)
Date: Thu, 20 Mar 97 15:30:53 GMT Standard Time
From: Ran Atkinson <rja@inet.org>
Subject: Re: the COMPRESSION discussion
To: ipsec@tis.com
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <3.0.32.19970319234159.009c34e0@earthlink.net>
Message-ID: <Chameleon.858872555.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
--- On Wed, 19 Mar 1997 23:42:06 -0800 Bob Monsour <rmonsour@earthlink.net> wrote:
> At 01:57 AM 3/20/97 Time, Ran Atkinson wrote:
> >
> >Just to be clear, I _personally_ am indifferent about compression.
> >As co-chair, I'm very religious about following the standards process.
> >Before we can move forward there MUST be rough consensus within the WG
> >on how to proceed. Right now this just is not present. Sigh.
> >The items that the IPsec WG needs to sort out are:
> >
> >1) Is compression "must implement" or "optional to implement" or
> > "outside our scope" ?
> >
>
> Ran, please forgive my frustration here (and perhaps I'm miss-reading the
> process) but I distinctly recall Paul Lambert getting up to summarize the
> activity of the WG meeting (in San Jose) and saying that there appeared to
> be consensus that the WG should take up compression as a work item.
> ... the recently issued minutes (I understand that
> they "have not been edited") state "A straw pole indicated there is no
> current consensus on how to proceed". Am I the only one with this
> recollection? I read Paul's comment as calling compression within the scope
> of the WG.
Those statements are not mutually exclusive. The fact that we are
discussing compression is consistent with it being a Work Item. Not
all work items lead to specifications, though most do.
"How to proceed" is a broader question that encompasses the items
I mentioned in my email note:
mandatory or optional to implement
what mechanism to use
etc. (see original note)
Further, frustrating though it might be, the consensus of this WG
seems to be fairly fluid on several topics, including compression.
I have received recent email from several different people asserting
that they now believe compression to be important but out of scope
for IPsec in that they believe it should be done at a higher protocol
processing layer. I might or might not personally agree, but its not
my personal call -- its up to the group as a whole to reach some conclusions.
Those who really want to make progress on this should write up some
concrete protocol specifications in the form of an I-D, put it online,
present it to the WG in Memphis, and see whether the WG as a whole
is comfortable with that approach. Such an I-D should try to answer
the questions I've posed.
Its entirely possible for this WG to reach consensus on this in Memphis
if people will write some concrete things up and present them in a
way that convinces most people in the WG...
Ran
rja@inet.org
From owner-ipsec Thu Mar 20 10:53:40 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA17135 for ipsec-outgoing; Thu, 20 Mar 1997 10:53:29 -0500 (EST)
Message-Id: <97Mar20.105913est.11651@elgreco.rnd.border.com>
To: Ran Atkinson <rja@inet.org>
cc: ipsec@tis.com
Subject: Re: the COMPRESSION discussion
References: <3.0.1.32.19970319110315.00b4ad70@dilbert.is.chrysler.com>
<Chameleon.858823442.rja@c8-a.snvl1.sfba.home.com>
In-reply-to: Your message of "Wed, 19 Mar 1997 20:57:18 -0500".
<Chameleon.858823442.rja@c8-a.snvl1.sfba.home.com>
From: "C. Harald Koch" <chk@utcc.utoronto.ca>
X-uri: <URL:http://chk.home.ml.org/>
X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw
z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ)
did@Pr9
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <19029.858873477.1@rafael.rnd.border.com>
Date: Thu, 20 Mar 1997 10:57:58 -0500
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
In message <Chameleon.858823442.rja@c8-a.snvl1.sfba.home.com>, Ran Atkinson writes:
>
> Just to be clear, I _personally_ am indifferent about compression.
> As co-chair, I'm very religious about following the standards process.
> Before we can move forward there MUST be rough consensus within the WG
> on how to proceed. Right now this just is not present. Sigh.
And this is where I'm wary of compression as part of the IPsec WG.
Compression is extremely difficult to standardize, due to the number of
patents on compression algorithms. Witness the PPP WG, which ran around and
around on the discussion of compression for years, and where there is
*still* no useful interoperable compression.
It's already taken us far too long to get standards out; adding compression
will only make this worse.
--
Harald Koch <chk@utcc.utoronto.ca>
From owner-ipsec Thu Mar 20 11:02:45 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA17189 for ipsec-outgoing; Thu, 20 Mar 1997 11:02:02 -0500 (EST)
Date: Thu, 20 Mar 1997 10:59:15 -0500
From: "Ferdinand N. Ahlberg" <ahlberg@ctron.com>
Message-Id: <199703201559.KAA19229@olympus.ctron.com>
To: rgm3@chrysler.com, rmonsour@earthlink.net, rja@inet.org,
glennz@microsoft.com
Subject: RE: Closing out the COMPRESSION discussion
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Hey now!
>
> I'm not sure I understand your point, Bob. Surely most (if not all)
> dial-up users will be using PPP, which already offers compression. What
> am I missing?
>
IPSec, among other things, defines encrypting packets at the network
layer. PPP compression is performed at the data link layer.
Compression algorithms search the data stream for patterns and then
replace those patterns with smaller representations. Encryption algorithms
generate outputs which are free of repetitive patterns. Therefore,
compression of encryted data will have no effect.
So, use of compression deserves to be defined in IPSec, because, if you
encrypt at the network layer, your PPP compression will not compress the
packets.
In order to harmonize the two technologies, you must compress before
encrypting.
Ferd
///////////////////////////////////////
// //
// Ferdinand N. Ahlberg //
// WAN Development //
// Cabletron Systems, Inc. //
// //
// ahlberg@ctron.com //
// //
///////////////////////////////////////
From owner-ipsec Thu Mar 20 11:23:50 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA17288 for ipsec-outgoing; Thu, 20 Mar 1997 11:23:39 -0500 (EST)
Date: Thu, 20 Mar 1997 08:28:44 -0800
Message-Id: <199703201628.IAA25182@gump.eng.ascend.com>
From: Karl Fox <karl@Ascend.COM>
To: "C. Harald Koch" <chk@utcc.utoronto.ca>
Cc: Ran Atkinson <rja@inet.org>, ipsec@tis.com
Subject: Re: the COMPRESSION discussion
In-Reply-To: <97Mar20.105913est.11651@elgreco.rnd.border.com>
References: <3.0.1.32.19970319110315.00b4ad70@dilbert.is.chrysler.com>
<Chameleon.858823442.rja@c8-a.snvl1.sfba.home.com>
<97Mar20.105913est.11651@elgreco.rnd.border.com>
Reply-To: Karl Fox <karl@Ascend.COM>
Organization: Ascend Communications
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
C. Harald Koch writes:
> Compression is extremely difficult to standardize, due to the number of
> patents on compression algorithms. Witness the PPP WG, which ran around and
> around on the discussion of compression for years,
This is true.
> and where there is *still* no useful interoperable compression.
This is not true. CCP is standardized, and at least two compression
methods are in widespread use, being available on the majority of all
PPP-speaking devices.
--
Karl Fox, servant of God, employee of Ascend Communications
3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841
From owner-ipsec Thu Mar 20 12:12:33 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA17580 for ipsec-outgoing; Thu, 20 Mar 1997 12:11:27 -0500 (EST)
Message-Id: <199703201715.MAA00500@thunk.ch.apollo.hp.com>
X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs
To: ho@earth.hpc.org (Hilarie Orman)
Cc: rja@inet.org, rgm3@chrysler.com, ipsec@tis.com
Subject: Re: inline keying
In-Reply-To: ho's message of Thu, 20 Mar 1997 09:45:10 -0500.
<199703201445.JAA06780@earth.hpc.org>
Date: Thu, 20 Mar 1997 12:15:14 -0500
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I've received relatively little feedback on the inline keying
proposal; as i'm in the process of revising it (hopefully in time for
the deadline next Wednesday), I'd very much like to hear what you, or
anyone else, has to say.
> As I mentioned in San Jose, Bill Sommerfeld's version of inline keying
> is not at all what I mean. What I mean is carrying an identifier in
> the ESP header that can be hashed with a pre-established secret to
> produce the unique key for the packet payload. This can be done many
> times to achieve uni-directional rekeying before security would demand
> that the pre-established secret be changed.
What you're suggesting is rekeying every packet. Putting my
efficiency hat on, this could get quite expensive (potentially
doubling the crypto overhead vs. fixed keys for short packets..).
My proposal was (essentially) rekeying every "connection" or "flow",
so that the second and subsequent packets in each direction can run at
the same speed as a vanilla fixed-key SA.
> I think the distinction is inline keys vs. inline key exchanges.
Fair enough.. Anyone else have any comments?
- Bill
From owner-ipsec Thu Mar 20 12:55:23 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA17855 for ipsec-outgoing; Thu, 20 Mar 1997 12:54:36 -0500 (EST)
Message-Id: <3.0.32.19970320095113.009c6680@earthlink.net>
X-Sender: rmonsour@earthlink.net
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 20 Mar 1997 09:51:27 -0800
To: "C. Harald Koch" <chk@utcc.utoronto.ca>
From: Bob Monsour <rmonsour@earthlink.net>
Subject: Re: the COMPRESSION discussion
Cc: Ran Atkinson <rja@inet.org>, ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 10:57 AM 3/20/97 -0500, C. Harald Koch wrote:
>Compression is extremely difficult to standardize, due to the number of
>patents on compression algorithms. Witness the PPP WG, which ran around and
>around on the discussion of compression for years, and where there is
>*still* no useful interoperable compression.
The issue that surrounded and delayed the PPP WG had to do with 2 Motorola
patents, neither of which involved compression algorithms per se. One has
to do with the idea of maintaining multiple compression contexts/histories
over a communication link and the second had to do with a way to handle
out-of-order packets and resetting the compression contexts/histores
appropriately. Neither of these come into play in the proposed IPSec method
for compressing. This is because no context/history is maintained from one
packet to the next (unlike PPP).
Perhaps someone else from the PPP world could respond with their knowledge
on the subject as well.
-Bob
Disclaimer: I'm not a lawyer.
From owner-ipsec Thu Mar 20 12:58:12 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA17887 for ipsec-outgoing; Thu, 20 Mar 1997 12:58:08 -0500 (EST)
Message-Id: <199703201803.KAA00704@imo.plaintalk.bellevue.wa.us>
Content-Type: text/plain
MIME-Version: 1.0 (NeXT Mail 3.3 v118.2)
From: Dennis Glatting <dennis.glatting@plaintalk.bellevue.wa.us>
Date: Thu, 20 Mar 97 10:03:08 -0800
To: Ran Atkinson <rja@inet.org>
Subject: Re: the COMPRESSION discussion
cc: ipsec@tis.com
Reply-To: dennis.glatting@plaintalk.bellevue.wa.us
References: <3.0.32.19970319234159.009c34e0@earthlink.net>
<Chameleon.858872555.rja@c8-a.snvl1.sfba.home.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> Those who really want to make progress on this should write up
> some concrete protocol specifications in the form of an I-D,
> put it online, present it to the WG in Memphis, and see whether
> the WG as a whole is comfortable with that approach. Such an I-D
> should try to answer the questions I've posed.
>
I'm confused, don't we already have such documents?
(draft-sabin-esp-des3-lzs-md5-00.txt and
draft-sabin-lzs-payload-00.txt)
-dpg
From owner-ipsec Thu Mar 20 13:09:29 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA18000 for ipsec-outgoing; Thu, 20 Mar 1997 13:09:10 -0500 (EST)
Message-Id: <199703201813.KAA00712@imo.plaintalk.bellevue.wa.us>
Content-Type: text/plain
MIME-Version: 1.0 (NeXT Mail 3.3 v118.2)
From: Dennis Glatting <dennis.glatting@plaintalk.bellevue.wa.us>
Date: Thu, 20 Mar 97 10:13:58 -0800
To: ipsec@tis.com
Subject: How about a DESX transform?
Reply-To: dennis.glatting@plaintalk.bellevue.wa.us
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Is there interest for a DESX transform? Would the introduction
of such a transform be counter productive at this time?
-dpg
From owner-ipsec Thu Mar 20 15:59:23 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA19234 for ipsec-outgoing; Thu, 20 Mar 1997 15:55:24 -0500 (EST)
Date: Thu, 20 Mar 1997 16:00:17 -0500 (EST)
From: Robert Glenn <glenn@snad.ncsl.nist.gov>
Message-Id: <199703202100.QAA26863@snad.ncsl.nist.gov>
To: ipsec@tis.com
Subject: New AH Transform Drafts submitted
Cc: rob.glenn@nist.gov
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I've submitted the new AH transform drafts today. They should show
up at your favorite I-D place in a few days. Until then, I've
made them available at:
ftp://ftp.antd.nist.gov/pub/ipsec/draft-ietf-ipsec-ah-hmac-md5-96-00.txt and
ftp://ftp.antd.nist.gov/pub/ipsec/draft-ietf-ipsec-ah-hmac-sha-1-96-00.txt.
These are to replace RFC2085 and draft-ietf-ipsec-ah-hmac-sha-04.txt.
Here are some quick diffs & potential open issues. Before commenting on this
message, please first read the drafts.
1. The HMAC digest is truncated to 96 bits.
2. The Replay Prevention field is a fixed 32-bits.
3. Replay Prevention is still optional BUT, if not implemented or
not in use (as specified by the SA) the field remains in the packet
header but is zeroed and ignored - read the spec for more details.
4. The Replay Prevention field is an up counter that starts at 1. Actually
this is kept from the previous specs. The reason I mention it, is that
it differs from the ESP-DES-MD5 spec. I avoided using a negotiated
counter because of the complexity it adds and I'm not convinced
that starting at a fixed number weakens security. I'm open to be
convinced.
5. There is a pointer to a HMAC test vectors draft (forth coming with
in the next day or so) that will hopefully eliminate some of the
interoperability problems seen recently.
There are additional changes where we tried to make things a bit more
clear.
Please read the drafts and provide comments. I'll re-iterate the above
in Memphis and bring up additional issues that may arise between now
and then.
Rob G.
rob.glenn@nist.gov
From owner-ipsec Thu Mar 20 16:47:07 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA00284 for ipsec-outgoing; Thu, 20 Mar 1997 16:35:09 -0500 (EST)
Message-Id: <199703202130.QAA17141@raptor.research.att.com>
To: Robert Glenn <glenn@snad.ncsl.nist.gov>
cc: ipsec@tis.com, rob.glenn@nist.gov
Subject: Re: New AH Transform Drafts submitted
Date: Thu, 20 Mar 1997 16:30:38 -0500
From: Steven Bellovin <smb@research.att.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
4. The Replay Prevention field is an up counter that starts at 1. Act
ually
this is kept from the previous specs. The reason I mention it, is
that
it differs from the ESP-DES-MD5 spec. I avoided using a negotiated
counter because of the complexity it adds and I'm not convinced
that starting at a fixed number weakens security. I'm open to be
convinced.
My issue with the replay counter applies to ESP, not AH. I know of no
weaknesses here. The only possible issue is whether or not MD5 or SHA
are weaker if handed large numbers of 0-bits; I suspect not with this
few.
From owner-ipsec Thu Mar 20 16:47:06 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA00275 for ipsec-outgoing; Thu, 20 Mar 1997 16:35:01 -0500 (EST)
Date: Thu, 20 Mar 97 21:15:26 GMT Standard Time
From: Ran Atkinson <rja@inet.org>
Subject: RE: the COMPRESSION discussion
To: "Ferdinand N. Ahlberg" <ahlberg@ctron.com>
Cc: ipsec@tis.com
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <199703201559.KAA19229@olympus.ctron.com>
Message-ID: <Chameleon.858892707.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
--- On Thu, 20 Mar 1997 10:59:15 -0500 "Ferdinand N. Ahlberg" <ahlberg@ctron.com> wrote:
> So, use of compression deserves to be defined in IPSec, because, if you
> encrypt at the network layer, your PPP compression will not compress the
> packets.
Some have argued that it is better to define a separate per-packet
compression method that can be used by IPsec but is not tied directly
inside the ESP packet format. Others argue that compression should
be within ESP. Either approach eliminates the issue that link-layer
compression is ineffective on encrypted data.
> In order to harmonize the two technologies, you must compress before
> encrypting.
That is an argument for optional compression but it doesn't argue for
or against either of the approaches that have been proposed on this list.
Ran
rja@inet.org
From owner-ipsec Fri Mar 21 06:59:05 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA04382 for ipsec-outgoing; Fri, 21 Mar 1997 06:57:41 -0500 (EST)
Message-Id: <2.2.32.19970321013202.006df08c@trix.cisco.com>
X-Sender: sned@trix.cisco.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 20 Mar 1997 17:32:02 -0800
To: rmonsour@earthlink.net
From: Steve Sneddon <sned@cisco.com>
Subject: "Pillage first, then burn" - Attila the Hun
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
"Compress first, then encrypt" - Bob Monsure
Bob,
I have watched the IPSec mailing list debates pretty much from the sidelines
so far. I am heartened by the lively debate, but disappointed by closure on
key aspects of the standards effort (no slam intended against anyone). I
agree with Ran - there isn't a consensus at this point.
Email to the IPSec list has its place, and formal presentations have their
place, but I believe you (HiFn) and I (Cisco) need to host an informal
BOF-like discussion in Memphis around this topic in the hope that it can
help move opinion forward. Maybe Tuesday evening would work.
At that session, I propose that we discuss Cisco's results with compression
in an IPSec-type environment. We have tied LZS into our client stack and are
now accumulating data on what it can do for you. We should present that data
to the community, even if it's in pretty raw form (which it will be!) at
that time. Who knows, we may even be ready to demo a compression-enabled
IPSec implementation by then (watch as five Cisco engineers slaughter me in
Email for saying this...). I will also be prepared to discuss ways that
Cisco can assist others with their implementations.
One final point. Some people worry that working on compression now will slow
down IPSec standards work. While I understand that concern, it is more than
outweighed in my mind by how seriously a lack of compression would impede
actual customer adoption of this technology. In fact, Cisco does not plan to
release an IPSec implementation until there is a plan, which we can
communicate clearly to customers, about how and when we will be doing
compression in that environment. This is the result of significant customer
backlash to lack of compression in our now-shipping but non-standard
encryption offering.
In closing, let me emphatically state my support for proper process in the
IETF, and my strong desire for a standard in this important area. Thanks,
Bob, for your help with this. Anybody on the IPSec list who wants to discuss
this more in private is encouraged to send me private Email.
\|||/
(. .)
------ooO-(_)-Ooo------------------------------------------------------------
^^ ^^ Cisco Systems, Inc. STEVE SNEDDON
.||. .||. IOS Development Director, IOS Client Tech
.||||. .||||. 170 West Tasman Drive Phone: 408-527-1035
..:||||||||:..:|||||||:.. SJ-F2 Pager: 800-365-4578
Cisco Systems Inc. San Jose, CA 95134-1706 EMAIL: sned@cisco.com
-----------------------------------------------------------------------------
From owner-ipsec Fri Mar 21 07:48:36 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA04803 for ipsec-outgoing; Fri, 21 Mar 1997 07:48:22 -0500 (EST)
Message-Id: <3.0.1.32.19970321075102.0093ee10@dilbert.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@dilbert.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 21 Mar 1997 07:51:02 -0500
To: Steve Sneddon <sned@cisco.com>, rmonsour@earthlink.net
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: "Pillage first, then burn" - Attila the Hun
Cc: ipsec@tis.com
In-Reply-To: <2.2.32.19970321013202.006df08c@trix.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 05:32 PM 3/20/97 -0800, Steve Sneddon wrote:
>Email to the IPSec list has its place, and formal presentations have their
>place, but I believe you (HiFn) and I (Cisco) need to host an informal
>BOF-like discussion in Memphis around this topic in the hope that it can
>help move opinion forward. Maybe Tuesday evening would work.
I hope we can fit this into the main IPsec session. I seem to think I have
some IAB meeting tues night.
>At that session, I propose that we discuss Cisco's results with compression
>in an IPSec-type environment. We have tied LZS into our client stack and are
>now accumulating data on what it can do for you. We should present that data
>to the community, even if it's in pretty raw form (which it will be!) at
>that time. Who knows, we may even be ready to demo a compression-enabled
>IPSec implementation by then (watch as five Cisco engineers slaughter me in
>Email for saying this...). I will also be prepared to discuss ways that
>Cisco can assist others with their implementations.
Gee do I know those 5 engineers? Aren't they already very busy next week?
>One final point. Some people worry that working on compression now will slow
>down IPSec standards work. While I understand that concern, it is more than
>outweighed in my mind by how seriously a lack of compression would impede
>actual customer adoption of this technology. In fact, Cisco does not plan to
>release an IPSec implementation until there is a plan, which we can
>communicate clearly to customers, about how and when we will be doing
>compression in that environment. This is the result of significant customer
>backlash to lack of compression in our now-shipping but non-standard
>encryption offering.
I can do my boarder to boarder without compression, but workstation to
boarder I need it or I will get slaughtered by the whole auto community.
And they use heavy wheeled methods over here...
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
From owner-ipsec Fri Mar 21 13:51:28 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA07322 for ipsec-outgoing; Fri, 21 Mar 1997 13:48:28 -0500 (EST)
Date: 21 Mar 97 12:50:52 -0600
Subject: Re: "Pillage first, then burn" - Attila the Hun
From: "James Hughes" <hughes@nsco.network.com>
To: rmonsour@earthlink.net, "Steve Sneddon" <sned@cisco.com>
Cc: ipsec@tis.com, ken@anubis.network.com, varnis@winternet.com
X-Mailer: Cyberdog/2.0b1
Mime-Version: 1.0
Message-Id: <AF5834BB-4DC0DA@129.191.63.3>
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
"Press release first, then develop" - (Name withheld by request)
Again, I hesitate to answer this.
I seem to see that there are people that again claim that their intentions
and experiments are more valuable than product experience in a compression
with encryption product. The NSC product won the Best of Show at INTEROP
'95. It had compression then, and it has it now.
On Thu, Mar 20, 1997 7:32 PM, Steve Sneddon <mailto:sned@cisco.com> wrote:
> Email to the IPSec list has its place, and formal presentations have
their
> place, but I believe you (HiFn) and I (Cisco) need to host an informal
> BOF-like discussion in Memphis around this topic in the hope that it can
> help move opinion forward. Maybe Tuesday evening would work.
In my heart, I know that cisco -is- the pre-eminent vendor of eveything
important and we are not. NSC does have 2+ years of experience with
implementing, deploying and real traffic with products that have packet
level compression and encryption. This is actual experience, not
conjecture. This is also true from the legal, commercial as well as the
technical areas.
I find that Cisco claiming the right to lead the discussions and host such
a BOF to be incredulous.
> This is the result of significant customer
> backlash to lack of compression in our now-shipping but non-standard
> encryption offering.
> In fact, Cisco does not plan to
> release an IPSec implementation until there is a plan
I personally find this kind of grandstanding abhorrent. To claim the high
ground in the compression discussion because their customers see this as
cisco problem is (in my mind) the same kind of paper tiger announcements
that their encryption program did 2 years ago when several vendors were
trying to make a living with existing products built on forethough, cisco
was trying to freeze the market with press releases so they could play
catch up.
I will (again) be happy to supply real results in providing a combined
compressed, replay prevented, authentic, integrity and privacy transform
(as I did to the IPSEC working group in 1994 in San Jose).
jim
http://www.network.com/~hughes
From owner-ipsec Fri Mar 21 14:04:57 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA07444 for ipsec-outgoing; Fri, 21 Mar 1997 14:03:32 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v0300780eaf5886498ba8@[128.89.0.110]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 21 Mar 1997 14:10:11 -0500
To: ipsec@tis.com
From: Stephen Kent <kent@bbn.com>
Subject: Proposed changes to ESP (andf a little AH too)
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Folks,
In working on revisions to the AH and ESP specs, we've noticed that
there is an opportunity to make a change to the ESP format and processing
that would simplify implementations, introduce greater consistency between
AH and ESP, and offer greater protection against denial of servioce
attacks. However, in setting out to revise the ESP spec, the intent was
NOT to make any changes to the format (for backward compatability) and
hence I am somewhat reluctant to prose such changes at this point in time.
Nonetheless, I ask the WG to consider these proposed changes relative to
the benefits noted above, and balance them against the cost to implementors.
ESP transforms that include an anti-replay counter place this
counter at the begining of the encrypted portion of the ESP payload. This
motivates negotiating a random starting value for the counter (to minimize
known plaintext attacks) and it creates the requirement for the AR window
mechanism to deal with modular arithmetic, since the counter may wrap
around the 32 bit space legitimately. Note that for AH, recent I-Ds defin
ethe counter value to begin at 1, which makes life much easier. I propose
to move the counter value out of the encrypted portion of the payload (it
would appear immediately after the SPI), and to define it to begin at 1.
This would simplify counter and counter window management and make it
uniform with AH in this regard. It also allows for very fast rejection of
replays by a receiver. After matching an inbound packet to an SA (using
the SPI) the counter value can be checked, prior to any crypto processing.
Moving the counter to this location causes the IV (if present) to
appear immediately before the encrypted portion of the payload, and to be
aligned on an 8-byte boundary. This offers potential (though probably
minor) performance improvements for receivers, since crypto that uses
explicit IVs tend to view it as an immdeiate prefix for the ciphertext.
Now for a bigger change! I suggest that we reverse the order of
encryption and authentication processing, when both are employed. Now,
authentication processing occurs first, then encryption. This means that a
receiver must decrypt then autehnticate. While most systems I have seen in
the past have adopted this strategy, we are now more concerned with denial
of service attacks. A likely common use of ESP is to create VPNs thorugh
IPSEC implementations in security gateways. If we reverse the order of
processing, then a secruity gateway can validate the integrity and
authenticity of a packet befor edecrypting it, thus rejecting bogus packets
faster (about twice as fast, in many instances), than if we had to decrypt
then authenticate. Combined with the psoposed positional change for the
counter (suggested above), we now have an ability to reject duplicate or
spurious packets very quickly, providing better defense against DoS attacks.
One final note re ESP formats and processing: I-Ds discussing
anti-replay require support of a window size of 1, which implies strict
sequencing of packets. I'd like to remove this requirement. In fact, I'd
like to suggest that supporting a window size of 1 is inappropriate. The
IP layer does NOT guarantee ordered delivery and by imposing strict
sequencing via IPSEC we are violating a fundamental characteristic of the
IP layer. Note that such sequencing could have adverse affects on TCP
connections (ofrcing unnecessary retransmission), merely because of packets
arrived at a security gateway out of order, due to no malicious actions.
The motivation for the counter and window mechanaims was to protect against
replays, not to enforce strict sequencing at the IP layer.
Please respond to these proposed changes. We're submitting
revised versions of AH and ESP, designed to reduce the proliferation of
distinct transform documents, to meet the 3/36 cutoff. We'll put the
changes I noted above in these I-Ds, but if the WG does not endorse some or
all of these changes, we will quickly revise the documents and re-issue
them. Presentations on these changes, and on other issues that we've
encountered in the course of revising the architecture document, will be
made in Memphis. I also will be sending out a message on the architecture
issues next week, providing fodder for discussion prior to Memphis. The
revised architecture I-D will not be ready for Memphis, because of the many
issues that we want to get Wg feedback on, and because we are re-writing
the document from scratch to better articulate these and other issues.
Thanks in advance for your carefuyl reading and feedback,
Steve
From owner-ipsec Fri Mar 21 15:20:23 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA08035 for ipsec-outgoing; Fri, 21 Mar 1997 15:17:56 -0500 (EST)
Message-Id: <3.0.32.19970321122157.00919680@earthlink.net>
X-Sender: rmonsour@earthlink.net
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 21 Mar 1997 12:21:59 -0800
To: Stephen Kent <kent@bbn.com>
From: Bob Monsour <rmonsour@earthlink.net>
Subject: Re: Proposed changes to ESP (andf a little AH too)
Cc: ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 02:10 PM 3/21/97 -0500, Stephen Kent wrote:
> Now for a bigger change! I suggest that we reverse the order of
>encryption and authentication processing, when both are employed. Now,
>authentication processing occurs first, then encryption. This means that a
>receiver must decrypt then autehnticate.
Steve,
I understand the rationale, but want to make sure I understand exactly what
you are proposing. Are you saying that in ESP, the sender would encrypt the
payload and then calculate the MAC over the encrypted payload?
-Bob
From owner-ipsec Fri Mar 21 16:05:48 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA08304 for ipsec-outgoing; Fri, 21 Mar 1997 16:04:19 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03007816af58a8fab463@[128.89.0.110]>
In-Reply-To: <3.0.32.19970321122157.00919680@earthlink.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 21 Mar 1997 16:08:36 -0500
To: Bob Monsour <rmonsour@earthlink.net>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Proposed changes to ESP (andf a little AH too)
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Bob,
Yes, that is exactly what I am saying. If both encryption and
authentication/integrity are selected as services, apply the encryption
algorithm first, then the auth/integrity algorithm (to the ciphertext).
Steve
From owner-ipsec Fri Mar 21 16:05:55 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA08303 for ipsec-outgoing; Fri, 21 Mar 1997 16:04:19 -0500 (EST)
Message-Id: <199703212108.QAA01317@thunk.ch.apollo.hp.com>
X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs
To: Bob Monsour <rmonsour@earthlink.net>
Cc: Stephen Kent <kent@bbn.com>, ipsec@tis.com
Subject: Re: Proposed changes to ESP (andf a little AH too)
In-Reply-To: rmonsour's message of Fri, 21 Mar 1997 12:21:59 -0800.
<3.0.32.19970321122157.00919680@earthlink.net>
Date: Fri, 21 Mar 1997 16:08:22 -0500
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> I understand the rationale, but want to make sure I understand exactly what
> you are proposing. Are you saying that in ESP, the sender would encrypt the
> payload and then calculate the MAC over the encrypted payload?
Normally I tend to like things which improve performance, but I don't
really like this proposal, for robustness reasons; it allows errors in
encryption or decryption to go undetected, while doing the MAC over
the plaintext provides better assurance that the data was decrypted
correctly.
Consider the case where the encryption key gets smashed but the
authentication key is intact .. you get authentic gibberish out of
the transform instead of a hard indication that something's out of
synch between the endpoints.
- Bill
From owner-ipsec Fri Mar 21 16:09:15 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA08339 for ipsec-outgoing; Fri, 21 Mar 1997 16:07:50 -0500 (EST)
Date: Fri, 21 Mar 1997 16:12:11 -0500
Message-Id: <9703212112.AA20804@dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Stephen Kent <kent@bbn.com>
Cc: ipsec@tis.com
In-Reply-To: Stephen Kent's message of Fri, 21 Mar 1997 14:10:11 -0500,
<v0300780eaf5886498ba8@[128.89.0.110]>
Subject: Re: Proposed changes to ESP (andf a little AH too)
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Date: Fri, 21 Mar 1997 14:10:11 -0500
From: Stephen Kent <kent@bbn.com>
Now for a bigger change! I suggest that we reverse the order of
encryption and authentication processing, when both are employed. Now,
authentication processing occurs first, then encryption. This means that a
receiver must decrypt then autehnticate. While most systems I have seen in
the past have adopted this strategy, we are now more concerned with denial
of service attacks.
Hmm... there's a definite tradeoff here between the trying to prevent
denial of service attacks, versus the potential traffic analysis that
this allows, at least in some cases.
In the case of using ESP to create VPN's through security gateways, the
threat of traffic analysis doesn't really apply, since the authenticated
destination will always be the other security gateway. Indeed, the
traffic analysis threat isn't important if we're doing host keying for
the same reason --- the low level, unauthenticated address allows for
traffic analysis anyway.
The only place where traffic analysis would matter would be if we did
user-based keying, and we have multiple users using the same host, in a
time-sharing fashion.
I believe this is not going to be a likely use of IPSEC, and so I agree
with Steve's recommendation. If there is any disagreement on this
point, it's likely going to be because people believe that there will be
a large amount of usage of both (a) user-based keying, and (b)
time-sharing machines. While I could believe (a), I have trouble
believing (b).
- Ted
From owner-ipsec Fri Mar 21 16:34:58 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA08518 for ipsec-outgoing; Fri, 21 Mar 1997 16:30:58 -0500 (EST)
Date: Fri, 21 Mar 1997 16:33:15 -0500
From: ho@earth.hpc.org (Hilarie Orman)
Message-Id: <199703212133.QAA01890@earth.hpc.org>
To: sommerfeld@apollo.hp.com
Cc: ipsec@tis.com
In-reply-to: Yourmessage <199703201733.KAA02818@baskerville.CS.Arizona.EDU>
Subject: Re: inline keying
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> What you're suggesting is rekeying every packet.
Not at all. If the "key hash index" doesn't change, then the key doesn't
change. You can keep a small (2 or 3) table of most recently used
derived keys to avoid having to recompute.
Hilarie
From owner-ipsec Fri Mar 21 16:55:59 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA08646 for ipsec-outgoing; Fri, 21 Mar 1997 16:50:07 -0500 (EST)
Message-Id: <199703212154.QAA01422@thunk.ch.apollo.hp.com>
X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: Stephen Kent <kent@bbn.com>, ipsec@tis.com
Subject: Re: Proposed changes to ESP (andf a little AH too)
In-Reply-To: tytso's message of Fri, 21 Mar 1997 16:12:11 -0500.
<9703212112.AA20804@dcl.MIT.EDU>
Date: Fri, 21 Mar 1997 16:54:09 -0500
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> If there is any disagreement on this point, it's likely going to be
> because people believe that there will be a large amount of usage of
> both (a) user-based keying, and (b) time-sharing machines. While I
> could believe (a), I have trouble believing (b).
traditional time-sharing is indeed fading, but I think there are a
number of important services with similar characteristics:
- "virtual web hosting" (many web sites from different companies on
one server).
- application gateways/proxies (going outbound through a firewall).
- multiple-layer applications (with a client, a frontend server, and
a backend database).
- Bill
From owner-ipsec Fri Mar 21 16:56:31 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA08629 for ipsec-outgoing; Fri, 21 Mar 1997 16:48:34 -0500 (EST)
Hops: 0
Host: tis.com.
Posted-Date: Fri, 21 Mar 1997 23:49:47 -0200 (GMT)
Message-Id: <199703212153.XAA26081@del.tla.org>
X-Mailer: exmh version 1.6.2 7/18/95
To: ipsec@tis.com
Subject: Re: Proposed changes to ESP (andf a little AH too)
In-reply-to: Your message of "Fri, 21 Mar 1997 14:10:11 EST."
<v0300780eaf5886498ba8@[128.89.0.110]>
Reply-To: ji@hol.gr
Organization: La maison qui rend fou.
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 21 Mar 1997 23:52:56 +0200
From: John Ioannidis <ji@hol.gr>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I'm all in favour of doing the encryption first and the authentication after,
so that on receipt we can authenticate before we receive, but wasn't there
some cryptographic argument against that sort of thing? Or was it decided back
when we only had the RFC 182* transforms that in the case of cascaded
transforms, we should encapsulate first with AH-MD5 and then with DES-ESP, and
that carried over into the combined ESP transform? Or could it even be a
carry-over back from the swIPe days (which also encrypted the authenticated
packet)?
/ji
From owner-ipsec Fri Mar 21 17:12:52 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA08785 for ipsec-outgoing; Fri, 21 Mar 1997 17:10:13 -0500 (EST)
From: Dan.McDonald@Eng.sun.com (Dan McDonald)
Message-Id: <199703212215.OAA22300@kebe.eng.sun.com>
Subject: Re: Proposed changes to ESP (andf a little AH too)
To: kent@bbn.com (Stephen Kent)
Date: Fri, 21 Mar 1997 14:15:23 -0800 (PST)
Cc: ipsec@tis.com
In-Reply-To: <v0300780eaf5886498ba8@[128.89.0.110]> from "Stephen Kent" at Mar 21, 97 02:10:11 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> In working on revisions to the AH and ESP specs, we've noticed that
Ummm, I've a quick question. Who are, "we"? I thought you (singular) were
rewhacking these drafts. Are there others we (the good folks in IPsec-land)
do not currently know?
> there is an opportunity to make a change to the ESP format and processing
> that would simplify implementations, introduce greater consistency between
> AH and ESP, and offer greater protection against denial of servioce
> attacks. However, in setting out to revise the ESP spec, the intent was
> NOT to make any changes to the format (for backward compatability) and
> hence I am somewhat reluctant to prose such changes at this point in time.
Good points on the cleanup, the backward compatibility, and the implication
that there is a tradeoff between the two.
> Nonetheless, I ask the WG to consider these proposed changes relative to
> the benefits noted above, and balance them against the cost to
> implementors.
My first and foremost concern is that we don't hold up this IPsec
specification train any longer. We need to stop the target from moving as
much as it is. Some of us have enough implementation headaches w/o changing
specs.
After that urgent concern, the question becomes:
Is improvement <foo> worth the time <t> and pain <p> that it'll take
to implement said improvement?
Is: <foo> >> <t> X <p>
It seems we have quite a few working systems already. So while time might be
relatively small, pain might be high because things might be deployed
already.
Enough philosophy, I got shredded for that once already. ;)
<SNIP!>
> I propose to move the counter value out of the encrypted portion of the
> payload (it would appear immediately after the SPI), and to define it to
> begin at 1. This would simplify counter and counter window management and
> make it uniform with AH in this regard. It also allows for very fast
> rejection of replays by a receiver. After matching an inbound packet to an
> SA (using the SPI) the counter value can be checked, prior to any crypto
> processing.
It _seems_ very rational. How much replay-enabled code do we have out there?
I personally haven't approached replay protection yet, and this seems easy
enough to build. OTOH, I can't speak for my fellow implementors. Also,
consider this potential attack when taking your "It also allows for very fast
rejection..." sentence into account:
I'm receiving ESP packets. I get packets #1, #2, and #3 from the
actual source. Now assume active attacker Mallory injects an ESP
packet with #4 into the flow. My "quick reject" algorithm accepts
Mallory's #4, while rejecting the geniune #4 that arrives while I'm
attempting to decrypt Mallory's #4. (Remember folks, some of us
live in a multi-threaded, multi-processing world.)
Granted, this is a denial-of-service attack, and as your paper with Voidoc
(sp.?) points out, you can't shut down all denial-of-service attacks. My
question is, does this attack exist with the previous method of implementing
replay counters?
<SNIP!>
> Now for a bigger change! I suggest that we reverse the order of
> encryption and authentication processing, when both are employed. This
> means that a receiver must decrypt then autehnticate. While most systems I
> have seen in the past have adopted this strategy, we are now more concerned
> with denial of service attacks. A likely common use of ESP is to create
> VPNs thorugh IPSEC implementations in security gateways. If we reverse the
> order of processing, then a secruity gateway can validate the integrity and
> authenticity of a packet befor edecrypting it, thus rejecting bogus packets
> faster (about twice as fast, in many instances), than if we had to decrypt
> then authenticate. Combined with the psoposed positional change for the
> counter (suggested above), we now have an ability to reject duplicate or
> spurious packets very quickly, providing better defense against DoS
> attacks.
Ahhhhh, so _THAT's_ how you solve my problem mentioned above. My "quick
reject" algorithm doesn't reject until auth passes/fails.
Let me reiterate that this seems rational, and that as a fresh-from-scratch
implementor I can build this. Let me also reiterate that there is running
code out there now (I'd like to know how widely deployed, actually. It could
be useful data.), and it may be not operationally painless.
> One final note re ESP formats and processing: I-Ds discussing
> anti-replay require support of a window size of 1, which implies strict
> sequencing of packets. I'd like to remove this requirement.
<SNIP!>
At the risk of sounding like a parrot, it's a nice idea, but will it break
anyone's back too much? In this case, however, it really seems like it's not
difficult to achieve. Replay window size is negotiated in Key mgmt., so you
can just have key mgmt. reject such window replay window sizes.
<SNIP!>
> We're submitting revised versions of AH and ESP, designed to reduce
> the proliferation of distinct transform documents, to meet the 3/36 cutoff.
That's 3/26, and while it may reduce the number of transform documents, will
it reduce the number of transforms?
> Presentations on these changes, and on other issues that we've encountered
> in the course of revising the architecture document, will be made in
> Memphis. I also will be sending out a message on the architecture issues
> next week, providing fodder for discussion prior to Memphis. The revised
> architecture I-D will not be ready for Memphis, because of the many issues
> that we want to get Wg feedback on, and because we are re-writing the
> document from scratch to better articulate these and other issues.
Again, the issue of transforms vs. algorithm vectors is foremost in my head.
I've envisioned an IPsec module (AH or ESP) doing as much common work as
possible and only farming out the algorithm-specific stuff. With
"transforms" it's not clear to me that you can farm out as little. Hard to
say, and I do live in a different kernel-internals world than other
implementors.
I'd like resolution on that issue. Is my unit of difference a transform, or
(algorithm + option) combinations?
> Thanks in advance for your carefuyl reading and feedback,
Hope this helps!
--
Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT
Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S!
Phone: (415) 786-6815 |"rising falling at force ten
WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush
From owner-ipsec Fri Mar 21 17:19:50 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA08847 for ipsec-outgoing; Fri, 21 Mar 1997 17:18:19 -0500 (EST)
Message-Id: <199703212221.RAA03006@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol
To: ji@hol.gr
cc: ipsec@tis.com
Subject: Re: Proposed changes to ESP (andf a little AH too)
In-reply-to: Your message of "Fri, 21 Mar 1997 23:52:56 +0200."
<199703212153.XAA26081@del.tla.org>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Fri, 21 Mar 1997 17:21:52 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
John Ioannidis writes:
> I'm all in favour of doing the encryption first and the
> authentication after, so that on receipt we can authenticate before
> we receive, but wasn't there some cryptographic argument against
> that sort of thing? Or was it decided back when we only had the RFC
> 182* transforms that in the case of cascaded transforms, we should
> encapsulate first with AH-MD5 and then with DES-ESP, and that
> carried over into the combined ESP transform?
Back when I was still involved in the drafting of these things (long
ago) I kept asking for input on the cryptographic and other desiderata
for picking one or the other. I got very little feedback. I don't
think the decisions was made consciously. The topic deserves a full
scale discussion...
Perry
From owner-ipsec Fri Mar 21 18:31:50 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA09367 for ipsec-outgoing; Fri, 21 Mar 1997 18:29:36 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v0300781daf58c83a0dca@[128.89.0.110]>
In-Reply-To: <9703212112.AA20804@dcl.MIT.EDU>
References: Stephen Kent's message of Fri, 21 Mar 1997 14:10:11 -0500,
<v0300780eaf5886498ba8@[128.89.0.110]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 21 Mar 1997 18:23:44 -0500
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Proposed changes to ESP (andf a little AH too)
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Ted,
Even for transport mode ESP, the proposed swap of fields only
exposes the packet counters, nothing else that was not expose before. The
SPIs are equally visible in both cases, as are the soure and destination
addresses and the IP packet IDs. Together, these pieces of data provide me
with enough info to do a good job of TA, exclusive of the counter info.
So, I'm not sure that I understand why you feel that the exposure of the
packet counters represents much of an aid to traffic analysis.
Steve
From owner-ipsec Fri Mar 21 18:32:29 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA09387 for ipsec-outgoing; Fri, 21 Mar 1997 18:31:06 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v0300781faf58c9945f25@[128.89.0.110]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 21 Mar 1997 18:26:41 -0500
To: Bill Sommerfeld <sommerfeld@apollo.hp.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Proposed changes to ESP (andf a little AH too)
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Bill,
You are right that an error that occurs during decryption will not
be detected by this reversed ordering of the operations. However, the
purpose of the authentication/integrity service in IPSEC is to detect
malicious modification of the data, not to protect against errors that
might occur during protocol processing within IPSEC. Such errors copuld
also occur after both operations were completed, irrespective of the order
of processing, and thus would be undetected by the IPSEC module.
Yes, an encryption key mismatch would not be detected under the
proposed processing order, but I expect the encryption and authentication
keys for ESP will be derrived algorithmically from a common source, e.g.,
as described in Jim Hughes I-D. In such cases, it would be unlikely for
the sort of error you describe to occur. I admit there is a greater chance
of this for manually configured keys, but since this would trash all
incoming traffic over the Sa in question, this should be an easy error to
track down.
Steve
From owner-ipsec Fri Mar 21 18:51:15 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA09476 for ipsec-outgoing; Fri, 21 Mar 1997 18:49:43 -0500 (EST)
Message-ID: <33331FCD.2781@cs.umass.edu>
Date: Fri, 21 Mar 1997 18:54:53 -0500
From: Lewis McCarthy <lmccarth@cs.umass.edu>
Organization: Theoretical Computer Science Group, UMass-Amherst, <URL:http://www.cs.umass.edu/~thtml/>
X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha)
MIME-Version: 1.0
To: IPsec Mailing List <ipsec@tis.com>
Subject: Re: Proposed changes to ESP (andf a little AH too)
References: <199703212108.QAA01317@thunk.ch.apollo.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Bill Sommerfeld writes:
[re: ciphertext = MAC(encrypt(plaintext))]
> Normally I tend to like things which improve performance, but I don't
> really like this proposal, for robustness reasons; it allows errors in
> encryption or decryption to go undetected, while doing the MAC over
> the plaintext provides better assurance that the data was decrypted
> correctly.
The optional preliminary "sanity check" of the decrypted replay counter
value (in e.g. draft-...-esp-3des-md5-00) still could be used to detect
most encryption/decryption errors, provided the counter remains inside
the encrypted portion and randomly initialized. This would represent an
intermediate approach between the current method and the revised one
proposed by Steve K. (et al. ?). Fake packets could be detected
relatively quickly, as per Steve, but replays would still take longer to
notice, as per the status quo. Presumably the sanity check would change
from optional to required or recommended.
-Lewis
From owner-ipsec Fri Mar 21 18:55:03 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA09521 for ipsec-outgoing; Fri, 21 Mar 1997 18:53:44 -0500 (EST)
Date: Fri, 21 Mar 1997 18:58:55 -0500
Message-Id: <9703212358.AA20912@dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Stephen Kent <kent@bbn.com>
Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, ipsec@tis.com
In-Reply-To: Stephen Kent's message of Fri, 21 Mar 1997 18:23:44 -0500,
<v0300781daf58c83a0dca@[128.89.0.110]>
Subject: Re: Proposed changes to ESP (andf a little AH too)
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Steve,
My mistake. I had assumed that the AH SPI was encrypted, and
was therefore not visible. It sounds like I was mistaken.
- Ted
From owner-ipsec Fri Mar 21 19:12:36 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA09598 for ipsec-outgoing; Fri, 21 Mar 1997 19:10:48 -0500 (EST)
Message-ID: <333324BE.794B@cs.umass.edu>
Date: Fri, 21 Mar 1997 19:15:58 -0500
From: Lewis McCarthy <lmccarth@cs.umass.edu>
Organization: Theoretical Computer Science Group, UMass-Amherst, <URL:http://www.cs.umass.edu/~thtml/>
X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha)
MIME-Version: 1.0
To: IPsec Mailing List <ipsec@tis.com>
Subject: Re: replay window size (Re: Proposed changes to ESP (andf a little AH too))
References: <v0300780eaf5886498ba8@[128.89.0.110]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Stephen Kent writes:
> One final note re ESP formats and processing: I-Ds discussing
> anti-replay require support of a window size of 1, which implies strict
> sequencing of packets. I'd like to remove this requirement. In fact, I'd
> like to suggest that supporting a window size of 1 is inappropriate.
Do you have a recommendation for the replacement mandatory-to-implement
window size, instead of 1? To minimize disruption, we might upgrade
size=32 from recommended to mandatory-to-implement.
-Lewis
From owner-ipsec Fri Mar 21 21:44:18 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA10289 for ipsec-outgoing; Fri, 21 Mar 1997 21:42:09 -0500 (EST)
Date: Sat, 22 Mar 97 02:38:59 GMT Standard Time
From: Ran Atkinson <rja@inet.org>
Subject: Re: "Pillage first, then burn" - Attila the Hun
To: Steve Sneddon <sned@cisco.com>
Cc: ipsec@tis.com
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <2.2.32.19970321013202.006df08c@trix.cisco.com>
Message-ID: <Chameleon.858998544.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Steve,
If you are interested in working within the process, constructive
steps towards consensus would include:
-- NOT holding a separate meeting.
-- writing up cisco's proposal for compression with IPsec as an
I-D and submitting it before the I-D cutoff before
Memphis.
-- presenting that specific proposal to the IPsec WG in the
usual IPsec meeting so that everyone can consider it
openly (I also anticipate other compression proposals
to be presented in the IPsec WG meetings).
For item 3, you'd need to send email to Paul Lambert (copy to me)
asking for agenda time, providing a topic, and giving a presentation
estimate so Paul can schedule accordingly (Paul mostly takes care
of the meetings :-).
Best wishes,
Ran
rja@inet.org
From owner-ipsec Sat Mar 22 10:17:31 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13406 for ipsec-outgoing; Sat, 22 Mar 1997 10:13:22 -0500 (EST)
Message-Id: <199703221517.KAA26648@amaterasu.sandelman.ottawa.on.ca>
To: ipsec@tis.com
Subject: Re: Proposed changes to ESP (andf a little AH too)
In-reply-to: Your message of "Fri, 21 Mar 1997 14:10:11 EST."
<v0300780eaf5886498ba8@[128.89.0.110]>
Date: Sat, 22 Mar 1997 10:17:41 -0500
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Stephen" == Stephen Kent <kent@bbn.com> writes:
Stephen> ESP transforms that include an anti-replay counter
Stephen> place this counter at the begining of the encrypted
Stephen> portion of the ESP payload. This motivates negotiating a
Stephen> random starting value for the counter (to minimize known
Stephen> plaintext attacks) and it creates the requirement for the
Stephen> AR window mechanism to deal with modular arithmetic,
Stephen> since the counter may wrap around the 32 bit space
Stephen> legitimately. Note that for AH, recent I-Ds defin ethe
Stephen> counter value to begin at 1, which makes life much
Stephen> easier. I propose to move the counter value out of the
Stephen> encrypted portion of the payload (it would appear
Stephen> immediately after the SPI), and to define it to begin at
Forgive me for not being a cryptographer: but isn't the SHA+AH+reply draft
flawed in not including the replay counter in the authenticated data?
It seems that the ESP anti-reply counter is properly placed to me.
:!mcr!: | Network security consulting and
Michael Richardson | contract programming
WWW: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQB1AwUBMzP4DqZpLyXYhL+BAQGyzQL/XLrmjbQWECxOeIeA0E81zfr3qYXLPPhF
A78qwqBgXeX69huwMqmYnGQORe1riuP1sw6X5mVhzjf3qMxKNDeZtLXboB+R+jj3
SBcnVWMQpXVCaEKzbcZ15nG2+7WDEyI5
=WS+q
-----END PGP SIGNATURE-----
From owner-ipsec Sat Mar 22 11:40:29 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA13740 for ipsec-outgoing; Sat, 22 Mar 1997 11:38:23 -0500 (EST)
Message-Id: <2.2.32.19970322165101.00b92a24@mailserv-H.ftp.com>
X-Sender: naganand@mailserv-H.ftp.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 22 Mar 1997 11:51:01 -0500
To: Stephen Kent <kent@bbn.com>
From: Naganand Doraswamy <naganand@ftp.com>
Subject: Re: Proposed changes to ESP (andf a little AH too)
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Steve,
I like your idea of starting the replay counter with 1. I think we should
adopt it.
With respect to doing authentication first and then encryption, in terms of
implementation it is not a very big change. I am not a cryptographer but it
looks like the processing involed with bad packets is lesser in the scheme
you are proposing. I dont know of vendor who has a product out in the market
supporting the combined transform. So if we decide to do this, this HAS to
be decided at Memphis. Many of us are almost ready to release products in
the next 3-4 months timeframe and once we have products out there, it
becomes a real pain if there is a fundamental change in the transform. I
will support this provided we can reach a decision in Memphis.
Regarding the window size, I think it is upto the implementation. I have
always seen window size as something that should not be negoatiated and is
entirely upto the receiver to decide the size. If the receiver chooses a
window size of 1, they in all probability they may drop quite a few packets.
--Naganand
----------------------------------------------------------------
naganand@ftp.com
Tel #: (508)684-6743 (O)
From owner-ipsec Sat Mar 22 14:44:30 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA14480 for ipsec-outgoing; Sat, 22 Mar 1997 14:41:28 -0500 (EST)
Message-Id: <3.0.16.19970322144254.1d1721aa@pop3.pn.com>
X-PGP-Key: <http://www.shore.net/~sable/info/rltkey.htm>
X-Sender: rodney@pop3.pn.com
X-Mailer: Windows Eudora Pro Version 3.0 (16)
Date: Sat, 22 Mar 1997 14:46:55 -0500
To: ipsec@tis.com
From: Rodney Thayer <rodney@sabletech.com>
Subject: Who is ELVIS?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
This is not a joke.
Sorry but I couldn't resist that subject line, as I stare at my Memphis
IETF Hotel reservation, where the price goes UP for Saturday night (to
$219) apparently due to tourists who come into town to see Graceland.
On the IPsec survey I see two implementations I don't have new or old
entries for. These are listed in the section where people report what
other implementations they have interoperated with. One is "Elvis" and one
is "SOS".
What are these?
--------
Rodney Thayer <rodney@sabletech.com>
PGP Fingerprint: BB1B6428 409129AC 076B9DE1 4C250DD8
From owner-ipsec Sat Mar 22 14:53:33 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA14507 for ipsec-outgoing; Sat, 22 Mar 1997 14:50:59 -0500 (EST)
Message-Id: <1.5.4.16.19970322195558.0bf7ea44@world.std.com>
X-Sender: dpj@world.std.com
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 22 Mar 1997 14:55:58 -0500
To: wdmaugh@tycho.ncsc.mil, mss@tycho.ncsc.mil, sjt@epoch.ncsc.mil,
mjs@terisa.com
From: "David P. Jablon" <dpj@world.std.com>
Subject: Re: Last Call: The resolution of ISAKMP with Oakley to
Proposed Standard
Cc: ipsec@tis.com, iesg@ietf.org
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Douglas, Mark, Jeff, and Mark,
In draft-ietf-ipsec-isakmp-07.txt, there is some some seriously
misleading information in the initial discussion of strong and weak
authentication. I've included a reworded paragraph that corrects
this problem. Here's the offending paragraph:
| 1.5 Authentication
|
| A very important step in establishing secure network communications is au-
| thentication of the entity at the other end of the communication. Many
| authentication mechanisms are available. Authentication mechanisms fall
| into two catagories of strength - weak and strong.
| [So far so good, except for "categories"] Passwords are an ex-
| ample of a mechanism that provides weak authentication. ...
This is wrong. Passwords are not a mechanism. They're just
a factor in establishing identity, like stored secret keys, private
keys, fingerprints, or faces. Strong password protocols
exist, and passwords are important for strong network authentication.
Yes, many bad ways to use passwords have been implemented and deployed.
Yes, there's a lot of misinformation about passwords out there.
But let's not propagate more of it.
| ... The reason pass-
| words are considered weak is the fact that most users pick passwords that
| are easy to guess and when used over an unprotected network are easily
| read by network sniffers. ...
This is poorly worded. If you're talking about off-line dictionary
attack on the sniffed messages, strong password methods are immune
to this. There are also good ways to generate large-enough
(for strong methods) passwords with deterministic entropy
that are easily memorized, and for preventing on-line guessing
attacks.
Sending clear-text passwords or keys is a weak mechanism.
Sending passwords or keys in easily decrypted form is weak.
Sending small passwords in a one-way hashed form that permits
eavesdropper dictionary attack is weak.
Password-authenticated key exchange is strong, and
there are at least three ways to do this.
They are all as strong as the more commonly known digital
signature approaches, when properly used, and can provide
added benefits in many applications, due to decreased need
for stored keys or certificates.
As I understand ISAKMP, passwords aren't suitable here
mainly because users are not actively involved in the
authentication process. So the keys have to be stored anyway,
and thus there is no good reason not to use *large* keys.
This makes your condemnation of password-based mechanisms even
more inappropriate.
Here's a suggested rewording of the paragraph:
| 1.5 Authentication
|
| A very important step in establishing secure network communications is au-
| thentication of the entity at the other end of the communication. Many
| authentication mechanisms are available. Authentication mechanisms fall
| into two categories of strength - weak and strong.
| Sending clear-text keys over a network is weak,
| due to the threat of reading them with a network sniffer.
| Sending one-way hashed poorly-chosen keys with low-entropy is
| also weak, due to the added threat of brute-force guessing
| attack on the sniffed messages. Digital signatures [... etc.]
Thanks.
-- David
> The IESG has received a request from the IP Security Protocol Working
> Group to consider the following Internet-Drafts for the status of
> Proposed Standard:
>
> o The resolution of ISAKMP with Oakley
> <draft-ietf-ipsec-isakmp-oakley-03.txt>
> o Internet Security Association and Key Management Protocol (ISAKMP)
> <draft-ietf-ipsec-isakmp-07.txt>
> o The Internet IP Security Domain of Interpretation for ISAKMP
> <draft-ietf-ipsec-ipsec-doi-02.txt>
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by March 28, 1997
>
>Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
------------------------------------
David P. Jablon
Integrity Sciences, Inc.
Tel: +1 508 898 9024
http://world.std.com/~dpj/
E-mail: dpj@world.std.com
From owner-ipsec Sat Mar 22 15:12:40 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA14609 for ipsec-outgoing; Sat, 22 Mar 1997 15:10:00 -0500 (EST)
Message-Id: <199703222014.MAA24591@dharkins-ss20>
X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol
To: Rodney Thayer <rodney@sabletech.com>
Cc: ipsec@tis.com
Subject: Re: Who is ELVIS?
In-Reply-To: Your message of "Sat, 22 Mar 1997 14:46:55 EST."
<3.0.16.19970322144254.1d1721aa@pop3.pn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 22 Mar 1997 12:14:52 -0800
From: Daniel Harkins <dharkins@cisco.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Elvis not only left the building, he left the country. You can visit
him at http://www.elvis.ru (it helps if you have KOI-8).
> On the IPsec survey I see two implementations I don't have new or old
> entries for. These are listed in the section where people report what
> other implementations they have interoperated with. One is "Elvis" and one
> is "SOS".
>
> What are these?
Elvis is a SKIP implementation from Russia.
Dan.
From owner-ipsec Sat Mar 22 15:24:02 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA14661 for ipsec-outgoing; Sat, 22 Mar 1997 15:20:02 -0500 (EST)
Message-Id: <3.0.16.19970322152445.2a07148e@pop3.pn.com>
X-PGP-Key: <http://www.shore.net/~sable/info/rltkey.htm>
X-Sender: rodney@pop3.pn.com
X-Mailer: Windows Eudora Pro Version 3.0 (16)
Date: Sat, 22 Mar 1997 15:25:16 -0500
To: ipsec@tis.com
From: Rodney Thayer <rodney@sabletech.com>
Subject: IPsec Survey Results, March 1997 [rev 1]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I have gathered the survey results at this URL:
<ftp://research.ftp.com/pub/ipsec/results.htm>.
Thanks to FTP Software for hosting this.
Please check for errors.
There are 28 implementations listed.
I'll update this periodically as I get more responses.
--------
Rodney Thayer <rodney@sabletech.com>
PGP Fingerprint: BB1B6428 409129AC 076B9DE1 4C250DD8
From owner-ipsec Sat Mar 22 18:11:40 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15417 for ipsec-outgoing; Sat, 22 Mar 1997 18:02:44 -0500 (EST)
Message-Id: <199703222307.PAA24653@dharkins-ss20>
X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol
To: Rodney Thayer <rodney@sabletech.com>
Cc: ipsec@tis.com
Subject: Re: IPsec Survey Results, March 1997 [rev 1]
In-Reply-To: Your message of "Sat, 22 Mar 1997 15:25:16 EST."
<3.0.16.19970322152445.2a07148e@pop3.pn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 22 Mar 1997 15:07:54 -0800
From: Daniel Harkins <dharkins@cisco.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Rodney,
Please update ftp://research.ftp.com/pub/ipsec/results.htm for the
cisco IOS entry to the following:
Name of Implementation: cisco IOS (TM)
Organisation: cisco Systems
Which IP versions are supported: IPv4 & IPv6 in progress
Implemented Features:
AH (RFC-1825,1826): yes
ESP (RFC-1825,1827): yes
AH MD5 (RFC-1828): yes
ESP DES (RFC-1829): yes
Other implemented AH transforms: AH-HMAC-MD5 & AH-HMAC-SHA
Other implemented ESP transforms: ESP-DES-MD5-Replay
Key Management: ISAKMP+Oakley (v6 and v2, v7 and v3 in progress)
Platforms: cisco
Lineage of IPsec Code: cisco Systems
Lineage of Key Mgmt Code: cisco Systems
Location of Source Code: proprietary
Point of Contact: Cheryl Madson
> Thanks to FTP Software for hosting this.
Yes, thanks!
Dan.
From owner-ipsec Sat Mar 22 19:08:17 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA15660 for ipsec-outgoing; Sat, 22 Mar 1997 19:03:52 -0500 (EST)
Hops: 0
Host: sabletech.com.
Posted-Date: Sun, 23 Mar 1997 02:05:13 -0200 (GMT)
Message-Id: <199703230008.CAA08137@del.tla.org>
X-Mailer: exmh version 1.6.2 7/18/95
To: Rodney Thayer <rodney@sabletech.com>
Cc: ipsec@tis.com
Subject: Re: Who is ELVIS?
In-reply-to: Your message of "Sat, 22 Mar 1997 14:46:55 EST."
<3.0.16.19970322144254.1d1721aa@pop3.pn.com>
Reply-To: ji@hol.gr
Organization: La maison qui rend fou.
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 23 Mar 1997 02:08:20 +0200
From: John Ioannidis <ji@hol.gr>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
[[ intentionally Cc'ed to the whole list ]]
> On the IPsec survey I see two implementations I don't have new or old
> entries for. These are listed in the section where people report what
> other implementations they have interoperated with. One is "Elvis" and one
> is "SOS".
>
> What are these?
>
I don't know about Elvis, but SOS refers to my (JI) implementation for BSDI,
presented at the December '95 IETF in Dallas.
/ji
From owner-ipsec Sun Mar 23 13:24:03 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA19988 for ipsec-outgoing; Sun, 23 Mar 1997 13:16:59 -0500 (EST)
From: Uri Blumenthal <uri@watson.ibm.com>
Message-Id: <9703231820.AA24783@hawpub.watson.ibm.com>
Subject: Re: Proposed changes to ESP (andf a little AH too)
To: ji@hol.gr
Date: Sun, 23 Mar 1997 13:20:53 -0500 (EST)
Cc: ipsec@tis.com
In-Reply-To: <199703212153.XAA26081@del.tla.org> from "John Ioannidis" at Mar 21, 97 11:52:56 pm
Reply-To: uri@watson.ibm.com
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
John Ioannidis says:
> I'm all in favour of doing the encryption first and the authentication
> after, so that on receipt we can authenticate before we receive, but
> wasn't there some cryptographic argument against that sort of thing?
The main argument against doing encryption first and auth second would
be - generally speaking there is no guarantee even if you verified the
CIPHERTEXT correctly, that the PLAINTEXT finally obtained is the same
as was sent.
--
Regards,
Uri uri@watson.ibm.com
-=-=-=-=-=-=-
<Disclaimer>
From owner-ipsec Sun Mar 23 15:04:56 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA20357 for ipsec-outgoing; Sun, 23 Mar 1997 14:59:37 -0500 (EST)
Message-Id: <3.0.16.19970323150234.2987aab4@pop3.pn.com>
X-PGP-Key: <http://www.shore.net/~sable/info/rltkey.htm>
X-Sender: rodney@pop3.pn.com
X-Mailer: Windows Eudora Pro Version 3.0 (16)
Date: Sun, 23 Mar 1997 15:04:42 -0500
To: uri@watson.ibm.com
From: Rodney Thayer <rodney@sabletech.com>
Subject: Re: Proposed changes to ESP (andf a little AH too)
Cc: ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Would that mean that a transform combination of (outer AH, ESP, and inner
AH) be useful? Or, of course, AH and ESP-with-authentication.
At 01:20 PM 3/23/97 -0500, you wrote:
>John Ioannidis says:
>> I'm all in favour of doing the encryption first and the authentication
>> after, so that on receipt we can authenticate before we receive, but
>> wasn't there some cryptographic argument against that sort of thing?
>
>The main argument against doing encryption first and auth second would
>be - generally speaking there is no guarantee even if you verified the
>CIPHERTEXT correctly, that the PLAINTEXT finally obtained is the same
>as was sent.
>--
>Regards,
>Uri uri@watson.ibm.com
>-=-=-=-=-=-=-
><Disclaimer>
>
>
--------
Rodney Thayer <rodney@sabletech.com>
PGP: BB1B6428 409129AC 076B9DE1 4C250DD8
From owner-ipsec Sun Mar 23 16:59:08 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA20848 for ipsec-outgoing; Sun, 23 Mar 1997 16:53:17 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03007803af59e9b12802@[128.33.229.246]>
In-Reply-To: <199703221517.KAA26648@amaterasu.sandelman.ottawa.on.ca>
References: Your message of "Fri, 21 Mar 1997 14:10:11 EST."
<v0300780eaf5886498ba8@[128.89.0.110]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 22 Mar 1997 14:56:05 -0500
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Proposed changes to ESP (andf a little AH too)
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Mike,
Both AH and ESP encompass the anti-replay counter within the scope
of the authentication/integrity calculation.
Steve
From owner-ipsec Sun Mar 23 18:12:47 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA21175 for ipsec-outgoing; Sun, 23 Mar 1997 18:06:20 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03007805af5b60eb7139@[128.33.229.243]>
In-Reply-To: <9703231820.AA24783@hawpub.watson.ibm.com>
References: <199703212153.XAA26081@del.tla.org> from "John Ioannidis" at
Mar 21, 97 11:52:56 pm
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 23 Mar 1997 18:02:25 -0500
To: uri@watson.ibm.com
From: Stephen Kent <kent@bbn.com>
Subject: Re: Proposed changes to ESP (andf a little AH too)
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Uri,
Just an observation about the encrypt-then-authentication
(outbound) approach. When AH and ESP were initially defined, ESP provided
only encryption. To achieve the combined authentication and encrypt
function that was later added to ESP transforms, one would have to employ
both AH and ESP. The architecture document does not recommend against
applying ESP first and then adding AH, and I have seen many examples based
on this ordering of these transforms. Thus, in reversing the order of the
algorithm processing as I have suggested, one has a function analogous
(though not exactly equivalent) to what has been proposed and advertized as
a reasonable application of AH and ESP in the IPSEC context.
You are right, of course, that the "outer" authentication
computation verifies the ciphertext, not the underlying plaintext.
However, the recipient has negotiated both the key and the encryption
algorithm used to transform the ciphertext into plaintext, and we are
requiring PFS for the key management algorithms. So, a number of tricks
that one might attempt to undermine the binding between the ciphertext and
plaintext should be thwarted. Also, we are talking about authentication
and integrity, not non-repudiation, here, so some other forms of attacks
that might be of concern in the NR context don't apply either.
Given these caveats, do you feel that the proposed re-ordering of
the processing steps (and associated syntax changes) poses a concern? If
so, could you provide an example of the sort of attack that we would be
subject to under this proposed re-ordering?
Thanks,
Steve
From owner-ipsec Sun Mar 23 18:12:47 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA21176 for ipsec-outgoing; Sun, 23 Mar 1997 18:06:21 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03007804af5b5c27529d@[128.33.229.243]>
In-Reply-To: <199703212215.OAA22300@kebe.eng.sun.com>
References: <v0300780eaf5886498ba8@[128.89.0.110]> from "Stephen Kent" at
Mar 21, 97 02:10:11 pm
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 23 Mar 1997 17:36:13 -0500
To: Dan.McDonald@Eng.sun.com (Dan McDonald)
From: Stephen Kent <kent@bbn.com>
Subject: Re: Proposed changes to ESP (andf a little AH too)
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Dan,
The "we" working on the revisions include two folks from my network
security departement at BBN (Karen Seo and Nina Yuan), plus Charlie Lynn, a
protocol expert who has been involved in Nimrod, IPv6, host requirements
and many other TCP/IP activities at BBN for over 15 years. Nina will be at
Memphis (I have a prior engagement in Singapore) to brief the AH and ESP
I-Ds, plus to go over some of the architecture document open issues.
I agree with your observation that we have to look at every
proposed change to AH and ESP with an eye toward the percieved benefit and
to the cost (including time to market) for vendors. However, in working on
the architecture document, we have uncovered a lot of issues that have not
been well addressed to date, and I suspect that resolving these issues will
actually cause more potential delays than the format changes we're looking
at for AH and ESP. For example, the list had a brief discussion of PMTU
and DF bit conventions, but our analysis has come up with a pretty good
rationale for what various implementations should do, and when. Also, the
currently posted architectuire I-D calls for being able to use a variety of
IP header fields (and TCP/UDP port fields) as selectors for defining SAs or
nested sets of SAs (I like the term "SA bundle" as suggested earlier).
Yet, I have not seen any implementations that support these features, so
far, even though the I-D has been out for over 6 months.
As for the window size issue, I agree that one can simply decline
to negotiate a size of 1, as a means of addressing this issue. However, I
really believe that a size of 1 is so awful that it ought not be allowed.
Moreover, only a size of 1 is proposed as required so far, and if we say
dom't do 1, then we cannot rely on anyone doing 32 (and multiples thereof)
instead. So, that's why I'd like to change to make 32 a MUST support, and
multiples of 32 be recommemded optional window sizes.
Your question about tranform document vs. transforms deserves a
thoughtful reply. The revised specs (its more of an issue for ESP, but it
applies to AH as well) will contain the details for (optional) anti-replay
counter management. They also will describe how to do (optional) HMAC
computation, with appropriate references to base spec by Hugo. There will
be a definition of the required padding technique for ESP. Default
algorithms will be cited and referred to via base algorithm specs. The
goal is to no longer have "transform" documents, but only these specs and
algorithm documents. In that sense, the number of transforms will
diminish, since we will have made the combinations of algorithms and
processing morr modular. However, one will still need to negotiate
"transforms" as part of SA management, and it's up to the Wg to decide how
many of these MUST be supported, vs. ones that MAY be supported, etc. So,
I do think my goal is consistent with yours, in that I hope to have
algorithms plus options within each protocol. One selects the combinations
of algorithms and options via SA management, and we have chosen to label
the bundled combinations "transforms."
Steve
P.S.
I hope this explanation lays to rest any rumors about the demise of AH. I
do see a diminished role for AH once we have ESP implementations that
support encryptionless SAs, but there will still be uses for AH.
From owner-ipsec Sun Mar 23 18:26:45 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA21241 for ipsec-outgoing; Sun, 23 Mar 1997 18:21:51 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03007825af58d1763a0f@[128.89.0.110]>
In-Reply-To: <Chameleon.858823442.rja@c8-a.snvl1.sfba.home.com>
References: <3.0.1.32.19970319110315.00b4ad70@dilbert.is.chrysler.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 23 Mar 1997 18:22:09 -0500
To: Ran Atkinson <rja@inet.org>
From: Stephen Kent <kent@bbn.com>
Subject: Re: the COMPRESSION discussion
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Ran,
I think that we can make provision for compression in ESP, while
deferring some of the issues you raised. For example, we already allow the
definition of additional encryption and authentication algorithms, in
addition to having define defaults that must be implemented. For
compression, we could hold off on defining a MUST implement default, and
thus rely on specific choices that are defined later. I admit that this is
not the preferred approach, and it certainly does not promote
interoperability as well as the tack we have taken with encryption and
authentication algorithms so far, but it is a start.
We have debated the question of at what processing layer to
implement compression and there is agreement that one cabn do it at various
layers, with differing benefits. But, the issue for us is not that more
general one, but rather do we wish to provide for optional compression in
the context of ESP. I agree with Bob and others that the responses on the
list suggest that there is asubstantial support for this as an optional
feature, to be negotiated on a per-SA basis.
Support for arbitrary algorithms is a good goal, but operating in
the IP layer, we have to limit ourselves to algorithms that do not rely on
ordered delivery. I think that we understand the limitations on the
methods that will work in our context, and those become constraints on
applicable algorithms. It does not seem appropriate to require than any
compression algortihm be a candiadte for IPSEC ESP use. Only ones that are
fairly stateless should be candidates, given the out-of-order arrival and
packet loss that are characteristics of IP layer traffic.
I agree with most of your proposed process for dealing with this
issue, and hope that we will receive submissions on specific, detailed
proposals. However, I also believe that Bob has provided the necessary
details that are sufficient for mods to the ESP spec, to accommodate a
range of compression options and that we can add this to a later version of
the ESP I-D with little or no effort. I do not agree with the suggestion
to explore whether this is a generic IP layer issue vs. just an ESP issue.
If we really want to make progerss on this, and meet the well-articulated
needs of folks like Bob Moskowitz, I think we must plan on putting
compression into IPSEC, since it is the use of ESP that especially
motivates the need for compression as a compensating factor.
So, I'd like to see us proceed as follows to add compression to our
specs, if the WG agrees:
- have the architecture document describe the optional use of
compression within ESP, to be negotiated on a per-SA basis
- define in the relevant ISAKMP documents how to negotiate compression
- set aside the high order bit from the ESP padding field to
indicate if compression has been applied to an individual packet
- define in ESP the scope of compression and any alignment
considerations applicable to the use of compression
- define compression algorithms for ESP use in separate base
documents, which can have backpointers to the architecture, ESP, and ISAKMP
docs
Steve
From owner-ipsec Sun Mar 23 22:15:00 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA22243 for ipsec-outgoing; Sun, 23 Mar 1997 22:10:10 -0500 (EST)
From: Uri Blumenthal <uri@watson.ibm.com>
Message-Id: <9703240315.AA280941@hawpub.watson.ibm.com>
Subject: Re: Proposed changes to ESP (andf a little AH too)
To: kent@bbn.com (Stephen Kent)
Date: Sun, 23 Mar 1997 22:15:13 -0500 (EST)
Cc: ipsec@tis.com
In-Reply-To: <v03007805af5b60eb7139@[128.33.229.243]> from "Stephen Kent" at Mar 23, 97 06:02:25 pm
Reply-To: uri@watson.ibm.com
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Stephen Kent says:
> You are right, of course, that the "outer" authentication
> computation verifies the ciphertext, not the underlying plaintext.
Of course. (:-)
> However, the recipient has negotiated both the key and the encryption
> algorithm used to transform the ciphertext into plaintext, and we are
> requiring PFS for the key management algorithms....Also, we are talking
> about authentication and integrity, not non-repudiation, here.......
Yes, I understand that.
> Given these caveats, do you feel that the proposed re-ordering of
> the processing steps (and associated syntax changes) poses a concern? If
> so, could you provide an example of the sort of attack that we would be
> subject to under this proposed re-ordering?
1. I'm not sure. As you might have noticed, that same approach is adopted
by SNMP Security (encrypt the body first, then authenticate the whole
package), and similar arguments were made (wrt. who cares about non-
repudiation etc.). Of course it's a reasonable assumption, that if
both sides have the same encryption algorithm/key and the ciphertext
is authentic, then the plaintext will also match. And *if* you can
guarantee that the keys are indeed intact on both ends, *probably*
the approach will work OK.
2. I don't have [at this moment] an example of how to break this
encrypt-first-auth-second scheme. But I haven't really thought
about it, and there are others more clever than me wrt. crypto
attacks on the algorithms and protocols.
3. I basically tried to simply answer the question posted: what's the
difference wrt. the order of the operations.
Crypto people, am I the only one who is not 100% comfortable with
this order of the operations? Can *you* think of an attack? What
would be the assumptions for such an attack to succeed?
--
Regards,
Uri uri@watson.ibm.com
-=-=-=-=-=-=-
<Disclaimer>
From owner-ipsec Sun Mar 23 22:46:44 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA22414 for ipsec-outgoing; Sun, 23 Mar 1997 22:42:43 -0500 (EST)
Message-Id: <199703240346.WAA15658@raptor.research.att.com>
To: uri@watson.ibm.com
cc: kent@bbn.com (Stephen Kent), ipsec@tis.com
Subject: Re: Proposed changes to ESP (andf a little AH too)
Date: Sun, 23 Mar 1997 22:46:32 -0500
From: Steven Bellovin <smb@research.att.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Crypto people, am I the only one who is not 100% comfortable with
this order of the operations? Can *you* think of an attack? What
would be the assumptions for such an attack to succeed?
Kent's approach defeats Wagner's short-block guessing attack (described
in my paper ftp://ftp.research.att.com/dist/smb/badesp.ps). This is
precisely because it does protect the ciphertext.
My discomfort is due solely to the fact that I want these transforms
standardized *now*. Anything that delays them is no good.
From owner-ipsec Mon Mar 24 01:03:15 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA23092 for ipsec-outgoing; Mon, 24 Mar 1997 00:57:27 -0500 (EST)
From: Dan.McDonald@Eng.sun.com (Dan McDonald)
Message-Id: <199703240602.WAA06987@kebe.eng.sun.com>
Subject: Re: Proposed changes to ESP (andf a little AH too)
To: kent@bbn.com (Stephen Kent)
Date: Sun, 23 Mar 1997 22:02:36 -0800 (PST)
Cc: Dan.McDonald@Eng.sun.com, ipsec@tis.com
In-Reply-To: <v03007804af5b5c27529d@[128.33.229.243]> from "Stephen Kent" at Mar 23, 97 05:36:13 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
<mucho snippage>
> For example, the list had a brief discussion of PMTU and DF bit
> conventions, but our analysis has come up with a pretty good rationale for
> what various implementations should do, and when.
I remember this discussion. I'm looking forward to seeing what you have to
say on this topic. (IMHO, the only big issue I see on this front is that
transport sessions (i.e. TCP) should be informed to ratchet down their MSS
when/if using IPsec. This passing of information can be difficult in certain
circumstances.)
> Also, the currently posted architectuire I-D calls for being able to use a
> variety of IP header fields (and TCP/UDP port fields) as selectors for
> defining SAs or nested sets of SAs (I like the term "SA bundle" as
> suggested earlier). Yet, I have not seen any implementations that support
> these features, so far, even though the I-D has been out for over 6 months.
Previous work has suggested that for outbound packets and their SAs, the
"per-endpoint" abstraction works well. This same previous work, however,
does not cover tying inbound SAs to an endpoint. I have some ideas, but I
look forward to learning other approaches to the problem.
<SNIP!>
> So, that's why I'd like to change to make 32 a MUST support, and multiples
> of 32 be recommemded optional window sizes.
My current experience with replay is limited, hence I do not feel qualified
to comment on this just now. I look at it as something new to learn. :)
> Your question about tranform document vs. transforms deserves a
> thoughtful reply.
It's a tricky question that affects:
1.) Key management
* What do I negotiate?
* What allows better policy definitions?
2.) AH and ESP code
* What abstraction to my kernel-loadable modules implement?
* What allows better policy definitions?
3.) APIs for both key management and endpoint security
* What do I offer to the user or key management programs?
* How do I manually administer such things?
> However, one will still need to negotiate "transforms" as part of SA
> management, and it's up to the Wg to decide how many of these MUST be
> supported, vs. ones that MAY be supported, etc.
<SNIP!>
> One selects the combinations of algorithms and options via SA management,
> and we have chosen to label the bundled combinations "transforms."
Okay.
> I hope this explanation lays to rest any rumors about the demise of AH. I
> do see a diminished role for AH once we have ESP implementations that
> support encryptionless SAs, but there will still be uses for AH.
There are plenty of uses for AH, even with encryptionless ESP. These
include (in order of importance):
1.) Use of certain IP/IPv6 options w/o having to encapsulate them.
Source routing is the foremost example that comes to my mind.
These options, while used hop-by-hop, only need to be really
authenticated end-to-end.
2.) AH has been sucessfully exported. I'm under the impression
that ESP is "encryption-enabling" as per dain-bramaged U.S.
export control law.
3.) Given the way IPv6 handles its payloads and options in discrete
next-header units, AH fits in better (IMHO) with IPv6
processing.
Thanks for the reply, and see you in Memphis!
Dan
From owner-ipsec Mon Mar 24 01:04:30 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA23103 for ipsec-outgoing; Mon, 24 Mar 1997 00:59:26 -0500 (EST)
Message-ID: <3336197C.2847@cs.umass.edu>
Date: Mon, 24 Mar 1997 01:04:44 -0500
From: Lewis McCarthy <lmccarth@cs.umass.edu>
Organization: Theoretical Computer Science Group, UMass-Amherst, <URL:http://www.cs.umass.edu/~thtml/>
X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha)
MIME-Version: 1.0
To: IPsec Mailing List <ipsec@tis.com>
Subject: Re: Proposed changes to ESP (andf a little AH too)
References: <9703240315.AA280941@hawpub.watson.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Uri Blumenthal writes:
> 2. I don't have [at this moment] an example of how to break this
> encrypt-first-auth-second scheme.
Let me just toss in another observation on this operation ordering.
Compared to auth-then-encrypt, I think this order technically makes it
easier to compile a set of plaintext/ciphertext pairs, because it moves
a potential entropy source outside the encryption. Suppose the
replay counter is shifted outside the encryption as suggested. If an
attacker can choose payload data & type values that require no padding,
then all the plaintext input to the encryption transform is known, and
of course the resulting ciphertext can be observed.
On the other hand, with the auth-then-encrypt ordering, the HMAC digest
forms part of the plaintext input to the encryption transform. The
attacker presumably can't choose the HMAC digest value, and _may_ be
unable to verify it at the receiver. Thus the complete plaintext
corresponding to an observed ciphertext may not be as readily available
to the attacker.
(It also may be easier under some circumstances for the attacker to
verify unpadded payload data & type values than HMAC digest values,
at the receiver, even when nothing is chosen. The HMAC digest is much
less interesting to higher protocol layers than is the payload, after
the receiver performs its authentication check.)
-Lewis
From owner-ipsec Mon Mar 24 08:26:52 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA25427 for ipsec-outgoing; Mon, 24 Mar 1997 08:23:32 -0500 (EST)
Date: Mon, 24 Mar 1997 08:23:32 -0500 (EST)
Message-Id: <199703241323.IAA25427@portal.ex.tis.com>
To: "James Hughes" <hughes@nsco.network.com>
From: Steve Sneddon <sned@cisco.com>
Subject: Re: "Pillage first, then burn" - Attila the Hun
Cc: rmonsour@earthlink.net, ipsec@tis.com, ken@anubis.network.com,
varnis@winternet.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 12:50 PM 3/21/97 -0600, James Hughes wrote:
>"Press release first, then develop" - (Name withheld by request)
OK, I admit, you made me :=).
>
>Again, I hesitate to answer this.
>
>I seem to see that there are people that again claim that their intentions
>and experiments are more valuable than product experience in a compression
>with encryption product. The NSC product won the Best of Show at INTEROP
>'95. It had compression then, and it has it now.
Then I hope we can figure out a way to work together toward the goal of
getting standards in this area. Let's discuss any commercial issues outside
of the IETF list.
>
>On Thu, Mar 20, 1997 7:32 PM, Steve Sneddon <mailto:sned@cisco.com> wrote:
>> Email to the IPSec list has its place, and formal presentations have
>their
>> place, but I believe you (HiFn) and I (Cisco) need to host an informal
>> BOF-like discussion in Memphis around this topic in the hope that it can
>> help move opinion forward. Maybe Tuesday evening would work.
>
>In my heart, I know that cisco -is- the pre-eminent vendor of eveything
>important and we are not. NSC does have 2+ years of experience with
>implementing, deploying and real traffic with products that have packet
>level compression and encryption. This is actual experience, not
>conjecture. This is also true from the legal, commercial as well as the
>technical areas.
>
>I find that Cisco claiming the right to lead the discussions and host such
>a BOF to be incredulous.
I said an "informal BOF-like discussion". I have something very informal and
totally unofficial and off the record in mind. We'll have plenty of occasion
for real sessions at the official meeting. If you want to help lead it,
great. I'll find the hall, and you can bring the pizza. :=)
[The rest of this message is best answered off the mailing list. I'll send
you private mail.]
From owner-ipsec Mon Mar 24 08:30:59 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA25497 for ipsec-outgoing; Mon, 24 Mar 1997 08:29:34 -0500 (EST)
Date: Mon, 24 Mar 1997 08:29:34 -0500 (EST)
From: owner-ipsec@ex.tis.com
Message-Id: <199703241329.IAA25497@portal.ex.tis.com>
To: lmccarth@cs.umass.edu (Lewis McCarthy)
cc: ipsec@tis.com (IPsec Mailing List)
Subject: Re: replay window size (Re: Proposed changes to ESP (andf a little
AH too))
Date: Sun, 23 Mar 1997 11:14:46 -0800
From: Derrell Piper <piper@cisco.com>
Sender: owner-ipsec@portal.ex.tis.com
Precedence: bulk
The size of the replay window should be implementation defined. There's
nothing you can do in the protocol to force the other end to honor any
particular window size, so you might as well let him choose one that's
efficient for his particular kernel/architecture. On 32-bit systems, this
will probably be 32, and on Alpha, 64.
Steve Kent suggested in Montreal that the size might want to be negotiated
so that the initiator has some way to indicate to the receiver the
anti-replay size that he believes might be most appropriate. I think this
adds unnecessary complexity, but I could support this if it's worded
appropriately. In the past, it has been worded as if increasing the size
of the replay detection window somehow weakens the anti-replay protection.
Derrell
> Do you have a recommendation for the replacement mandatory-to-implement
> window size, instead of 1? To minimize disruption, we might upgrade
> size=32 from recommended to mandatory-to-implement.
>
>-Lewis
From owner-ipsec Mon Mar 24 10:16:38 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27000 for ipsec-outgoing; Mon, 24 Mar 1997 10:16:00 -0500 (EST)
Message-Id: <97Mar24.102209est.11650@elgreco.rnd.border.com>
To: "James Hughes" <hughes@nsco.network.com>
cc: "Steve Sneddon" <sned@cisco.com>, ipsec@tis.com
Subject: Vendor Interests (was Re: "Pillage first, then burn" - Attila the Hun)
References: <AF5834BB-4DC0DA@129.191.63.3>
In-reply-to: hughes's message of "Fri, 21 Mar 1997 13:50:52 -0500".
<AF5834BB-4DC0DA@129.191.63.3>
From: "C. Harald Koch" <chk@utcc.utoronto.ca>
Date: Mon, 24 Mar 1997 10:20:45 -0500
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
In message <AF5834BB-4DC0DA@129.191.63.3>, "James Hughes" writes:
>
> I find that Cisco claiming the right to lead the discussions and host such
> a BOF to be incredulous.
I assume that everyone participating in this discussion is an individual,
and not a mindless slave to their employer's desires. It's certainly the
case that at each IETF meeting, the participants remain the same while the
"company names" on people's badges keep changing; this would support my
assumption.
--
Harald Koch <chk@utcc.utoronto.ca>
From owner-ipsec Mon Mar 24 10:45:43 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27210 for ipsec-outgoing; Mon, 24 Mar 1997 10:45:20 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03007803af5c5178c8cf@[128.89.0.110]>
In-Reply-To: <3336197C.2847@cs.umass.edu>
References: <9703240315.AA280941@hawpub.watson.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 24 Mar 1997 10:46:42 -0500
To: Lewis McCarthy <lmccarth@cs.umass.edu>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Proposed changes to ESP (andf a little AH too)
Cc: IPsec Mailing List <ipsec@tis.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Lewis,
It is true that moving the counter and the HMAC outside of the
encryption boundary does remove a source of unpredictable plaintext from
the message. However, the HMAC is at the end of the message, and the use
of an IV in feedback modes is designed to provide an unpredictable starting
point for the encryption process. If the contents of the message are
predictable, as suggested, then there typically will be enough plaintext to
support a known plaintext attack irresepctive of the posotioning of the
counter value. See Steve Bellovin's recent paper (in the Proceedings of
the Symposium on Network and Distributed System Security, Feb 97) analyzing
such attacks in a typical IP/TCP context.
Steve
From owner-ipsec Mon Mar 24 11:16:32 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27210 for ipsec-outgoing; Mon, 24 Mar 1997 10:45:20 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03007803af5c5178c8cf@[128.89.0.110]>
In-Reply-To: <3336197C.2847@cs.umass.edu>
References: <9703240315.AA280941@hawpub.watson.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 24 Mar 1997 10:46:42 -0500
To: Lewis McCarthy <lmccarth@cs.umass.edu>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Proposed changes to ESP (andf a little AH too)
Cc: IPsec Mailing List <ipsec@tis.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Lewis,
It is true that moving the counter and the HMAC outside of the
encryption boundary does remove a source of unpredictable plaintext from
the message. However, the HMAC is at the end of the message, and the use
of an IV in feedback modes is designed to provide an unpredictable starting
point for the encryption process. If the contents of the message are
predictable, as suggested, then there typically will be enough plaintext to
support a known plaintext attack irresepctive of the posotioning of the
counter value. See Steve Bellovin's recent paper (in the Proceedings of
the Symposium on Network and Distributed System Security, Feb 97) analyzing
such attacks in a typical IP/TCP context.
Steve
From owner-ipsec Mon Mar 24 11:22:13 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00405 for ipsec-outgoing; Mon, 24 Mar 1997 11:20:44 -0500 (EST)
From: Hsin Fang <fang@snad.ncsl.nist.gov>
Date: Mon, 24 Mar 1997 11:23:26 -0500 (EST)
Message-Id: <199703241623.LAA06124@emu.ncsl.nist.gov>
To: kent@bbn.com
Subject: Re: Proposed changes to ESP (andf a little AH too)
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Steve,
In your 23 Mar 1997 note, you wrote:
> As for the window size issue, I agree that one can simply decline
> to negotiate a size of 1, as a means of addressing this issue. However, I
> really believe that a size of 1 is so awful that it ought not be allowed.
> Moreover, only a size of 1 is proposed as required so far, and if we say
> dom't do 1, then we cannot rely on anyone doing 32 (and multiples thereof)
> instead. So, that's why I'd like to change to make 32 a MUST support, and
> multiples of 32 be recommemded optional window sizes.
I can understand that mandatory window size of 1 is not a good idea: it force
to drop every single out-of-order packet. But I don't see any good reason to
force the window size to be 32*X (X >= 1). Shouldn't people be allowed to pick
up any smaller number, let us say 8 or 16, as best fit their application?
Window size of 32*X when X>=2 is quite big to me considering that it is a per
destination/per security association figure.
Regards,
Hsin
From owner-ipsec Mon Mar 24 11:22:13 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00391 for ipsec-outgoing; Mon, 24 Mar 1997 11:19:14 -0500 (EST)
To: IETF-Announce:;
cc: ipsec@tis.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-ah-hmac-md5-96-00.txt
Date: Mon, 24 Mar 1997 09:58:17 -0500
Message-ID: <9703240958.aa24177@ietf.org>
Sender: owner-ipsec@ex.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-96 IP Authentication with Replay Prevention
Author(s) : M. Oehler, R. Glenn
Filename : draft-ietf-ipsec-ah-hmac-md5-96-00.txt
Pages : 8
Date : 03/21/1997
This document describes a keyed-MD5 transform to be used in conjunction
with the IP Authentication Header [RFC-1826]. The particular transform is
based on [RFC-2104]. A replay prevention field is also specified.
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-ah-hmac-md5-96-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ah-hmac-md5-96-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
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-ah-hmac-md5-96-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.
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: <19970321095813.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-md5-96-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-ah-hmac-md5-96-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970321095813.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ipsec Mon Mar 24 11:22:16 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00283 for ipsec-outgoing; Mon, 24 Mar 1997 11:13:51 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03007804af5c528908eb@[128.89.0.110]>
In-Reply-To: <199703241329.IAA25497@portal.ex.tis.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 24 Mar 1997 10:59:48 -0500
To: ipsec@tis.com
From: Stephen Kent <kent@bbn.com>
Subject: Re: replay window size
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Derrell,
The revised specs will make sure that there is no confusion re the
relative secruity afforded by different replay windo sizes. As you
observe, a large window, if proparly implemented, does just as good a job
of preventing replays as a smaller window. The difference is that larger
windows have a greater tolerance for out of order packet arrival than
smaller windows, but IP assumes out of order arrival, and is silent on the
extent to which such behavior may be benign (vs. malicious).
I'm concvrened about having the window size be solely
implementation defined, since that can lead to unopredictable behavior that
may be hard to track down. Also, there seems to be general agreement that
a wiondow size of 32, or multiples thereof, is relatively easy to
implement. I don't want to have implementors feel that they must implement
arbitrary size windows, since that is potentially hard (or inefficient),
yet some have sent me private mail expressing concerns abotu exactly that.
So, we need to clarify this. Also, I don't want to see a window size of 1
since that conflcits with the IP layer model for delivery.
I like to think in terms of "consumer protection" when writing a
spec. If certain requirements are levied, then the purchasers of
IPSEC-compliant devices will be assured of a certain level of functionality
(though not assurance), and interoperability will be fostered. If we are
silent on important issues, such as what size window is supported for
anti-replay, then I worry about what the products will do. Hence my desire
to stipulate reasonable requirements for window sizes. However, I am
sensitive to your concern re negotiation and if we could settle on a window
size of 32 as a mandatory to implement default, and have negotiation of
larger sizes optional, that might address both concerns.
Steve
From owner-ipsec Mon Mar 24 13:59:34 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA01739 for ipsec-outgoing; Mon, 24 Mar 1997 13:56:11 -0500 (EST)
From: Robert Glenn <glenn@snad.ncsl.nist.gov>
Date: Mon, 24 Mar 1997 14:00:37 -0500 (EST)
Message-Id: <199703241900.OAA12874@sloth.ncsl.nist.gov>
To: ipsec@tis.com
Subject: HMAC Test case draft submitted
Cc: pau@watson.ibm.com, rob.glenn@nist.gov
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
In hopes of helping eliminate some of the more basic algorithm-specific
interoperability problems, Pau-Chen Cheng and I have put together
and submitted a HMAC Test Cases I-D that covers HMAC-MD5 and HMAC-SHA.
I've put an advanced copy at:
ftp://ftp.antd.nist.gov/pub/ipsec/draft-cheng-hmac-test-cases-00.txt.
Rob G.
rob.glenn@nist.gov
From owner-ipsec Mon Mar 24 16:40:25 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA02892 for ipsec-outgoing; Mon, 24 Mar 1997 16:36:52 -0500 (EST)
Message-Id: <199703242141.QAA01968@thunk.ch.apollo.hp.com>
X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs
To: ipsec@tis.com
Subject: Open issues for inline keying.
Date: Mon, 24 Mar 1997 16:41:25 -0500
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I've gotten several bits of feedback on my inline keying proposal;
unfortunately, there doesn't seem to be any particular consensus in
the comments I've received.
Please read draft-ietf-ipsec-inline-isakmp-00.txt; it's not very long;
a quick summary is that it involves "spawning" new security
associations from old ones by using "reply-SPI-creation" messages
piggybacked on normal network traffic.
I see three major open isues:
Issue 1:
How do we frame the reply-SPI creation message within the packet?
[There are some similarities between this issue and the compression
issue. It would be good to resolve them in a similar way..]
option 1a:
Steal a bit out of the ESP encoding to indicate the presence
of a reply-SPI-creation message. Perhaps the next-to-the-high-order
bit of the pad length? :-)) This bit would only be used if the
endpoints had configured/negotiated inline keying in the parent SA.
option 1b:
use a new IP-level protocol with a "next-protocol" field, and
set the next-protocol field of the containing ESP header to this new
protocol, and the inline-keying protocol's next-protocol to the
payload's protocol. One implementor was significantly opposed to this
idea; another was significantly in favor of it and I haven't heard any
other opinions.
option 1c:
Use the ipv6 "destination options" IP-layer protocol (IP
protocol 60) to contain the reply-SPI-creation message.
For those unfamiliar with ipv6 (which includes myself): ipv6 doesn't
include any space for option information in the base IP header;
instead, it uses a nested protocol approach akin to AH (ip protocol 60
is the "ipv6 destination options" protocol). It appears to me that
there is fundamentally no reason why this protocol could not also be
used inside an ipv4 header, though it may be a little more work in
ipv4-only implementations and it may complicate mixed ipv4/ipv6
implementations.
option 1d:
anyone have any better ideas?
Issue 2:
What goes inside the reply-SPI creation message?
option 2a:
An a message from an ISAKMP quick-mode exchange (which
requires three messages before both new SA's can be brought up).
option 2b:
A simplified quick-mode-like message which creates a reply-SPI
in a single message, allowing both child-SA's to be brought up in a
single message exchange, probably piggybacked on the SYN and SYN-ACK
of a connection establishment.
This is lower overhead, probably higher efficiency, but more
work to implement and analyze since we can't just encapsulate the
isakmp message and send it in line.
Issue 3: Keying the payload which is along for the ride with the
reply-SPI-creation message.
option 3a:
Just use the SPI's encryption as-is [which seems like it might be
cryptographically weaker than options 3b and 3c ]
option 3b:
Include a nonce in the reply-spi-creation message to hash with the
shared secret to generate the key for this packet. [this is
effective, but non-modular]
option 3c:
define a new class of ESP transforms which include a nonce in
each packet (Hilarie Orman called this a "key hash index") which is
combined with the SA's shared secret to generate the key used to
encrypt the packet. This may be easier to do given the new
mix-and-match ESP architecture which Steve Kent has proposed, and I
think this, without the additional reply-SPI-creation protocol, is
what Hilarie is looking for.
---
Does anyone have any commentary? If you have a preference, please
explain why (since I'm easier to convince if there's a rationale
behind it).
I am currently leaning towards 1c, 2b, and 3c, but could be convinced
one way or the other. The -01 draft will likely continue to waffle
about the issues unless I receive *convincing* arguments in favor of
particular options by late tomorrow.
- Bill
From owner-ipsec Mon Mar 24 23:44:43 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA05211 for ipsec-outgoing; Mon, 24 Mar 1997 23:41:45 -0500 (EST)
From: HUGO@watson.ibm.com
Message-Id: <199703250446.XAA49412@mailhub1.watson.ibm.com>
Date: Mon, 24 Mar 97 23:38:20 EST
To: iesg@ietf.org, IPSEC@tis.com
cc: DHARKINS@cisco.com, carrel@ipsec.org, RJA@inet.org, PALAMBER@us.oracle.com,
CANETTI@watson.ibm.com
Subject: oakley-03: last call comments
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
In the last months I have been collaborating with Dan Harkins
on several design issues for the isakmp/oakley protocol.
Dan has been very open and receptive of the changes and design
guidelines that I suggested. There are two issues, however, that were
not resolved in oakley-03. They are significant for security and
functionality reasons so I insist they need to be done.
I am also adding a third simple change that I failed to communicate
to the editors in time before the appearance of oakley-03.
The changes are simple from editorial point of view (full text change
is suggested below). They do impact implementations but do not require
any extensive work to adjust to them. Therefore, now is the right
time to do them before fielded implementations are available.
Notice that I am careful not to suggest any change that could
lead to delays in the standard definition and deployment.
Change No. 1: Quick Mode
************************
The draft says:
> Quick Mode is defined as follows:
>
> Initiator Responder
> ----------- -----------
> HDR*, HASH(1), SA, Ni
> [, KE ] [, IDui, IDur ] -->
> <-- HDR*, HASH(2), SA, Nr
> [, KE ] [, IDui, IDur ]
> HDR*, HASH(3) -->
>
> Where:
> HASH(1) and HASH(2) are the prf over the message id (M-ID) from
> the ISAKMP header concatenated with the entire message that follows
> the hash including payload headers, but excluding any padding added
> for encryption. HASH(3)-- for liveliness-- is the prf over the value
> zero represented as a single octet, followed by a concatenation of
> the message id and the two nonces-- the initiator's followed by the
> responder's. In other words, the hashes for the above exchange are:
>
> HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDui | IDur ])
> HASH(2) = prf(SKEYID_a, M-ID | SA | Nr [ | KE ] [ | IDui | IDur ])
> HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni | Nr)
>
Problem: A basic practice in authentication protocols is to use nonces to
guarantee the freshness of the authentication messages.
In this case there is a nonce Ni sent for I to R in the first message.
That nonce Ni needs to be incorporated into the hash computation of HASH(2)
for such a freshness purpose (to prevent re-play attacks).
This is also consistent with design of HASH_I and HASH_R in all the
other modes of the protocol.
Recommendation: Change
> HASH(2) = prf(SKEYID_a, M-ID | SA | Nr [ | KE ] [ | IDui | IDur ])
to
HASH(2) = prf(SKEYID_a, M-ID | SA | Nr | Ni [ | KE ] [ | IDui | IDur ])
^^
Discussion: Currently, freshness in HASH(2) IS provided
via the field M-ID which ISAKMP specifies to be "randomly chosen by the
Initiator". The problem is that M-ID (message identifier) has
no cryptographic motivation by itself in ISAKMP. It is used by a system
to differentiate parallel (phase 2) exchanges belonging to the same tunnel.
In particular, in many cases implementations could dispense of the randomness
(e.g. when no parallel sessions are run).
Actually, we cannot even guarantee that this definition
of M-ID as a random number will not be changed in the future in arevised ISAKMP
version. Who will then remember that there is a cryptographic use of this
number in Oakley?
Since Ni is there anyway in Oakley let's use it as freshness guarantee, thus
making Oakley more self-contained, more secure, and easier for analysts
and implementers to understand its cryptographic rationale and design.
Change No. 2: Authentication through public key encryption
***********************************************************
Problem: The draft currently provides identity protection in this mode
(page 11) by encrypting the identities under a public key encryption.
As specified now this public key encryption is separated from that
of the nonces Ni and Nr. This means that the protocol requires TWO
encryption and decryption operation for each party. This is unnecessarily
expensive (depending on your processor the extra exponentiation may have
negligible up to significant effect in performance). Indeed it is enough
to encrypt the nonce under the public key
and to derive from it a key for a symmetric encryption (e.g. under DES)
of the identity. This solution adds no significant complexity to the
implementation and saves a costly long (RSA or other) exponentiation.
(It also allows to easily encrypt long certificates if sent from Inititiator
to Responder; currently such an encryption is not specified/possible.)
Recommendation: Change the following text (page 11)
>
> In addition to the nonce, the identities of the parties (IDii and
> IDir) are also encrypted with the other parties public key. If the
> authentication method is public key encryption, the nonce and
> identity payloads MUST be encrypted with the public key of the other
> party. Only the body of the payloads are encrypted, the payload
> headers are left in the clear.
>
> When using encrytion for authentication with Oakley, Main Mode is
> defined as follows.
>
> Initiator Responder
> ----------- -----------
> HDR, SA -->
> <-- HDR, SA
> HDR, KE, [ HASH(1), ]
> <IDii>PubKey_r,
> <Ni>PubKey_r -->
> HDR, KE, <IDir>PubKey_i,
> <-- <Nr>PubKey_i
> HDR*, HASH_I -->
> <-- HDR*, HASH_R
>
> Oakley Aggressive Mode authenticated with encryption is described as
> follows:
>
> Initiator Responder
> ----------- -----------
> HDR, SA, [ HASH(1),] KE,
> <IDii>Pubkey_r,
> <Ni>Pubkey_r -->
> HDR, SA, KE, <IDir>PubKey_i,
> <-- <Nr>PubKey_r, HASH_R
> HDR, HASH_I -->
>
>
>
> Harkins, Carrel [Page 11]
TO:
The nonce is encrypted with the other parties public key.
The identities of the parties (IDii and IDir) are encrypted with
a symmetric cipher (as negotiated by the ISAKMP Security Association,
e.g. DES) using a key derived from the nonce (if a certificate is passed
from Initiator to Responder it is encrypted under the same key as the
identities).
If the authentication method is public key encryption, the nonce payload
MUST be encrypted with the public key of the other party. Only the body
of the payloads are encrypted, the payload headers are left in the clear.
When using encryption for authentication with Oakley, Main Mode is
defined as follows.
Initiator Responder
----------- -----------
HDR, SA -->
<-- HDR, SA
HDR, KE, [ HASH(1), ]
<Ni>PubKey_r -->
<IDii>Ne_i
[<Cert-I>Ne_i]
<-- HDR, KE, <Nr>PubKey_i
<IDir>Ne_r
HDR*, HASH_I -->
<-- HDR*, HASH_R
The keys Ne_i and Ne_r are defined as:
Ne_i = prf(Ni, CKY-I)
Ne_r = prf(Nr, CKY-R)
The notation <...>PubKey refers to public key encryption
(e.g. using the RSA algorithm) while the notation <...>Ne
refers to encryption under a symmetric cipher (e.g DES)
as negotiated for payload encryption by the ISAKMP SA.
The key used for symmetric encryption to protect the third
(resp. fourth) message payloads is derived (and possibly expanded)
from Ne_i (resp. Ne_r) in an algorithm-specific manner (see appendix B).
If CBC mode is used for the encryption then the initialization vector (IV)
is set to 0 (notice that the value Ne_i is ephemeral).
Encrypted payloads are padded up to the nearest block size using bytes
containing 0x00.
Oakley Aggressive Mode authenticated with encryption is described as
follows:
Initiator Responder
----------- -----------
HDR, SA, [ HASH(1),] KE,
<Ni>Pubkey_r,
<IDii>Ne_i -->
[<Cert-I>Ne_i]
HDR, SA, KE, <Nr>PubKey_i,
<-- <IDir>Ne_r, HASH_R
HDR, HASH_I -->
(end of proposed change)
Discussion: A further security measure that can be taken here is to use
Ne_i and Ne_r to encrypt the KE payload. This adds more security to the DH
exchange (against broken modulus p, against short exponents, etc.).
I leave the decision to the editors whether to add this encryption as part
of the specification or not.
Also, notice that I left the HDR* notation in non-aggressive mode although
this encryption (under SKEYID_e) it is not really necessary since
the identities are not there. Whether to remove that encryption
is up to the editors. Leaving it adds to the processing time but may simplify
implementation as it is consistent with other non-aggressive modes.
Change No. 3: Derivation of SKEYID
**********************************
SKEYID derivation is defined as:
>
> For signatures: SKEYID = prf(Ni | Nr, g^xy)
> For public key encryption: SKEYID = hash(Ni | Nr)
> For pre-shared keys: SKEYID = prf(pre-shared-key, Ni | Nr)
In the case of public key encryption I suggest to change the definition to
For public key encryption: SKEYID = prf(Ni | Nr, CKY-I | CKY-R)
This is better compatible with the definition of prf (rather than just hash)
and uniform with all other key derivations in this protocol.
Note: The suggestion SKEYID = hash(Ni | Nr) is my own fault. Pau-Chen Cheng
suggested the above improved prf derivation.
Hugo
From owner-ipsec Tue Mar 25 01:34:53 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA05854 for ipsec-outgoing; Tue, 25 Mar 1997 01:32:17 -0500 (EST)
To: ipsec@ex.tis.com
Path: not-for-mail
From: daw@cs.berkeley.edu (David Wagner)
Newsgroups: isaac.lists.ipsec
Subject: Re: Proposed changes to ESP (andf a little AH too)
Date: 24 Mar 1997 22:33:06 -0800
Organization: ISAAC Group, UC Berkeley
Lines: 39
Message-ID: <5h7rj2$ng6@joseph.cs.berkeley.edu>
References: <199703212153.XAA26081@del.tla.org> <9703231820.AA24783@hawpub.watson.ibm.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
In article <9703231820.AA24783@hawpub.watson.ibm.com>,
Uri Blumenthal <uri@watson.ibm.com> wrote:
> The main argument against doing encryption first and auth second would
> be - generally speaking there is no guarantee even if you verified the
> CIPHERTEXT correctly, that the PLAINTEXT finally obtained is the same
> as was sent.
That's a robustness argument against authenticating the ciphertext,
and a pretty good one if the decryption routine is complicated.
However, if the decryption is simple & easy to analyze, we can (mostly)
put to rest those fears about authenticating ciphertext.
Suppose the decryption routine depends only on the authenticated
ciphertext (and a key). We assume the two endpoints both see the same
view of the key. Furthermore, we assume the MAC is secure, so that
the two endpoints both share the same view of the ciphertext. Because
decryption is a function that depends on no other parameters (by
assumption), then the result of decryption will be the same at both
endpoints. Therefore, you can be sure that the plaintext finally
obtained is the same as was sent.
Some examples where this informal "proof" goes wrong will probably
make the argument clearer. If decryption depended on an IV which
wasn't authenticated (more specifically, wasn't included in the MAC
input for this packet), then the arguments fails -- and indeed, if
an adversary with control over the IV can fake the first block of
plaintext at will without breaking the MAC. If decryption included
a decompression stage which depended on some context (a LZH dictionary,
say), and that context was implicit and un-authenticated, the argument
fails.
So-- how simple is the decryption routine? What parameters does it
depend on? If the decryption routine is simple enough that we can
(with pretty high assurance) isolate all the parameters it depends on
and ensure that they are authenticated, then we have a good argument
saying that authenticating the ciphertext is safe. Otherwise, we
should start to worry that authenticating the ciphertext is not
robust enough.
From owner-ipsec Tue Mar 25 09:12:31 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA09120 for ipsec-outgoing; Tue, 25 Mar 1997 09:10:04 -0500 (EST)
Message-Id: <3.0.1.32.19970325072815.009d8350@dilbert.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@dilbert.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 25 Mar 1997 07:28:15 -0500
To: Stephen Kent <kent@bbn.com>, "Theodore Y. Ts'o" <tytso@MIT.EDU>
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: Proposed changes to ESP (andf a little AH too)
Cc: ipsec@tis.com
In-Reply-To: <v0300781daf58c83a0dca@[128.89.0.110]>
References: <9703212112.AA20804@dcl.MIT.EDU>
<v0300780eaf5886498ba8@[128.89.0.110]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 06:23 PM 3/21/97 -0500, Stephen Kent wrote:
>
> Even for transport mode ESP, the proposed swap of fields only
>exposes the packet counters, nothing else that was not expose before. The
>SPIs are equally visible in both cases, as are the soure and destination
>addresses and the IP packet IDs. Together, these pieces of data provide me
>with enough info to do a good job of TA, exclusive of the counter info.
>So, I'm not sure that I understand why you feel that the exposure of the
>packet counters represents much of an aid to traffic analysis.
Silly rabbit, when you are behind on mail, good thing to read through whole
thread before interjecting :)
This answers my question Steve....
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
From owner-ipsec Tue Mar 25 09:12:34 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA09125 for ipsec-outgoing; Tue, 25 Mar 1997 09:10:06 -0500 (EST)
Message-Id: <3.0.1.32.19970325071745.009d7450@dilbert.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@dilbert.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 25 Mar 1997 07:17:45 -0500
To: Stephen Kent <kent@bbn.com>, ipsec@tis.com
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: Proposed changes to ESP (andf a little AH too)
In-Reply-To: <v0300780eaf5886498ba8@[128.89.0.110]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 02:10 PM 3/21/97 -0500, Stephen Kent wrote:
>
> Now for a bigger change! I suggest that we reverse the order of
>encryption and authentication processing, when both are employed. Now,
>authentication processing occurs first, then encryption. This means that a
>receiver must decrypt then autehnticate. While most systems I have seen in
>the past have adopted this strategy, we are now more concerned with denial
>of service attacks. A likely common use of ESP is to create VPNs thorugh
>IPSEC implementations in security gateways. If we reverse the order of
>processing, then a secruity gateway can validate the integrity and
>authenticity of a packet befor edecrypting it, thus rejecting bogus packets
>faster (about twice as fast, in many instances), than if we had to decrypt
>then authenticate. Combined with the psoposed positional change for the
>counter (suggested above), we now have an ability to reject duplicate or
>spurious packets very quickly, providing better defense against DoS attacks.
Steve, I will admit my limited experience in this matter, but in secure
mail, it makes sense to auth then encrypt to hide identities for traffic
analysis and for gaining identities of protected individuals (like CEOs).
Now does the same argument apply to IPsec? Would exposing the auth
information reveal more than some would want?
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
From owner-ipsec Tue Mar 25 09:12:34 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA09135 for ipsec-outgoing; Tue, 25 Mar 1997 09:10:30 -0500 (EST)
Message-Id: <3.0.1.32.19970325072021.009d7450@dilbert.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@dilbert.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 25 Mar 1997 07:20:21 -0500
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>, Stephen Kent <kent@bbn.com>
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: Proposed changes to ESP (andf a little AH too)
Cc: ipsec@tis.com
In-Reply-To: <9703212112.AA20804@dcl.MIT.EDU>
References: <Stephen Kent's message of Fri, 21 Mar 1997 14:10:11 -0500,<v0300780eaf5886498ba8@[128.89.0.110]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 04:12 PM 3/21/97 -0500, Theodore Y. Ts'o wrote:
>
>In the case of using ESP to create VPN's through security gateways, the
>threat of traffic analysis doesn't really apply, since the authenticated
>destination will always be the other security gateway. Indeed, the
>traffic analysis threat isn't important if we're doing host keying for
>the same reason --- the low level, unauthenticated address allows for
>traffic analysis anyway.
>
>The only place where traffic analysis would matter would be if we did
>user-based keying, and we have multiple users using the same host, in a
>time-sharing fashion.
Ah, but you missed the case where the SA was built from the identity of the
system behind the gateway. This is not user-based keying, but key proxing.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
From owner-ipsec Tue Mar 25 10:27:30 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA09753 for ipsec-outgoing; Tue, 25 Mar 1997 10:24:32 -0500 (EST)
Message-Id: <3.0.16.19970325102428.1b17eeca@pop3.pn.com>
X-PGP-Key: <http://www.shore.net/~sable/info/rltkey.htm>
X-Sender: rodney@pop3.pn.com
X-Mailer: Windows Eudora Pro Version 3.0 (16)
Date: Tue, 25 Mar 1997 10:29:50 -0500
To: ipsec@tis.com
From: Rodney Thayer <rodney@sabletech.com>
Subject: replay mandatory?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Replay is mandatory? As in, replay size of 1 (no replay checking) is
forbidden?
>From: Hsin Fang <fang@snad.ncsl.nist.gov>
>Date: Mon, 24 Mar 1997 11:23:26 -0500 (EST)
>To: kent@bbn.com
>Subject: Re: Proposed changes to ESP (andf a little AH too)
>Cc: ipsec@tis.com
>Sender: owner-ipsec@ex.tis.com
>
>
>Steve,
>
>In your 23 Mar 1997 note, you wrote:
>
>> As for the window size issue, I agree that one can simply decline
>> to negotiate a size of 1, as a means of addressing this issue. However, I
>> really believe that a size of 1 is so awful that it ought not be allowed.
>> Moreover, only a size of 1 is proposed as required so far, and if we say
>> dom't do 1, then we cannot rely on anyone doing 32 (and multiples thereof)
>> instead. So, that's why I'd like to change to make 32 a MUST support, and
>> multiples of 32 be recommemded optional window sizes.
>
>I can understand that mandatory window size of 1 is not a good idea: it
force
>to drop every single out-of-order packet. But I don't see any good reason to
>force the window size to be 32*X (X >= 1). Shouldn't people be allowed to
pick
>up any smaller number, let us say 8 or 16, as best fit their application?
>Window size of 32*X when X>=2 is quite big to me considering that it is a per
>destination/per security association figure.
>
>Regards,
>Hsin
>
>
>
>
--------
Rodney Thayer <rodney@sabletech.com>
PGP: BB1B6428 409129AC 076B9DE1 4C250DD8
From owner-ipsec Tue Mar 25 10:28:31 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA09759 for ipsec-outgoing; Tue, 25 Mar 1997 10:25:52 -0500 (EST)
Date: Tue, 25 Mar 1997 10:30:15 -0500
Message-Id: <199703251530.KAA00625@road-warrior.mit.edu>
From: "Jeffrey I. Schiller" <jis@MIT.EDU>
To: kent@bbn.com
CC: rja@inet.org, ipsec@tis.com
In-reply-to: <v03007825af58d1763a0f@[128.89.0.110]> (message from Stephen Kent
on Sun, 23 Mar 1997 18:22:09 -0500)
Subject: Re: the COMPRESSION discussion
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I have tried to keep my nose out of this debate, but Memphis is approaching
rapidly (must have put it on one of the Fedex jets) and we need to come to
cloture real soon.
From: Stephen Kent <kent@bbn.com>
...
So, I'd like to see us proceed as follows to add compression to our
specs, if the WG agrees:
- have the architecture document describe the optional use of
compression within ESP, to be negotiated on a per-SA basis
- define in the relevant ISAKMP documents how to negotiate compression
- set aside the high order bit from the ESP padding field to
indicate if compression has been applied to an individual packet
- define in ESP the scope of compression and any alignment
considerations applicable to the use of compression
- define compression algorithms for ESP use in separate base
documents, which can have backpointers to the architecture, ESP, and ISAKMP
docs
This looks like a good plan to me.
-Jeff
From owner-ipsec Tue Mar 25 11:00:36 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA10042 for ipsec-outgoing; Tue, 25 Mar 1997 10:57:47 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03007804af5da51497f4@[128.89.0.110]>
In-Reply-To: <199703241623.LAA06124@emu.ncsl.nist.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 25 Mar 1997 10:54:58 -0500
To: Hsin Fang <fang@snad.ncsl.nist.gov>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Proposed changes to ESP (andf a little AH too)
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Hsin,
Arbitrary size windows are potentially expensive to implement,
though conceptually simple. We chose 32 (and multiples thereof) for the
ease with which one can implement the window on a 32 bit (or 64 bit)
machine. This sort of pragmatic recognition of commonly deployed machine
word sizes also shows up in the IPv6 packet alignment requirements, so it
is not out of pace here. Note that there is no security risk associated
with a larger window size, i.e., in all cases all replays are rejected.
The larger window size just provides a greater tolerance for out-of-order
arrival, which is itsefl a feature of IP.
Steve
From owner-ipsec Tue Mar 25 11:00:35 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA10041 for ipsec-outgoing; Tue, 25 Mar 1997 10:57:46 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03007805af5da67decf1@[128.89.0.110]>
In-Reply-To: <3.0.16.19970325102428.1b17eeca@pop3.pn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 25 Mar 1997 10:59:50 -0500
To: Rodney Thayer <rodney@sabletech.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: replay mandatory?
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Rodney,
The window size of 1 does prevent replay, but it also prevents
legitimate, out-of-order arrival of packets at the IP layer. A larger
window size does not allow ANY replays; it just allows packets to arrive at
the IPsec implementation out of order and still be checked and accepted.
Steve
From owner-ipsec Tue Mar 25 11:56:32 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA10498 for ipsec-outgoing; Tue, 25 Mar 1997 11:51:56 -0500 (EST)
Message-Id: <199703251656.LAA02300@thunk.ch.apollo.hp.com>
X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs
To: daw@cs.berkeley.edu (David Wagner)
Cc: ipsec@ex.tis.com
Subject: Re: Proposed changes to ESP (andf a little AH too)
In-Reply-To: daw's message of 24 Mar 1997 22:33:06 -0800.
<5h7rj2$ng6@joseph.cs.berkeley.edu>
Date: Tue, 25 Mar 1997 11:56:26 -0500
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> > The main argument against doing encryption first and auth second would
> > be - generally speaking there is no guarantee even if you verified the
> > CIPHERTEXT correctly, that the PLAINTEXT finally obtained is the same
> > as was sent.
>
> That's a robustness argument against authenticating the ciphertext,
> and a pretty good one if the decryption routine is complicated.
>
> However, if the decryption is simple & easy to analyze, we can (mostly)
> put to rest those fears about authenticating ciphertext.
It's also the case that the bulk of the protocols which will likely be
used inside ESP (IP, UDP, TCP) already use a simple 16-bit checksum,
which will cause most garbled traffic to be dropped.
If we assume that errors where the ciphertext is authenticated but the
decryption is garbled will most likely occur during debugging of new
code or manual keying, then that would seem to be an acceptable risk;
the operator(s) will interpret 99.998% packet loss as 100% packet loss
and start debugging..
We merely need to specify that the IP checksum MUST be supplied on
transmission and verified on receipt for packets nested inside ESP.
- Bill
From owner-ipsec Tue Mar 25 13:43:05 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA11500 for ipsec-outgoing; Tue, 25 Mar 1997 13:40:40 -0500 (EST)
Message-Id: <3.0.16.19970325133743.373f1152@pop3.pn.com>
X-PGP-Key: <http://www.shore.net/~sable/info/rltkey.htm>
X-Sender: rodney@pop3.pn.com
X-Mailer: Windows Eudora Pro Version 3.0 (16)
Date: Tue, 25 Mar 1997 13:45:32 -0500
To: Stephen Kent <kent@bbn.com>
From: Rodney Thayer <rodney@sabletech.com>
Subject: Re: replay mandatory?
Cc: ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I wonder if I am missing something. Today, in an IPsec-less environment,
if I get IP packets for 1000 different TCP circuits, I have to have some
pool of local copies of packets to deal with out-of-order IP packets.
If I implement IPsec, with NO replay, things are the same. I decrypt, I
send it to the next step in the process, and presumably the same pool could
be used.
If I require a replay window of 32 for 1000 different Security
Associations, that means I need to keep 32*1000 copies of IP packets
around. I can't spread the pool cost among the 1000 like I could in the
non-IPsec case.
At 10:59 AM 3/25/97 -0500, you wrote:
>Rodney,
>
> The window size of 1 does prevent replay, but it also prevents
>legitimate, out-of-order arrival of packets at the IP layer. A larger
>window size does not allow ANY replays; it just allows packets to arrive at
>the IPsec implementation out of order and still be checked and accepted.
>
>Steve
>
>
>
>
--------
Rodney Thayer <rodney@sabletech.com>
PGP: BB1B6428 409129AC 076B9DE1 4C250DD8
From owner-ipsec Tue Mar 25 14:22:16 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA11864 for ipsec-outgoing; Tue, 25 Mar 1997 14:20:05 -0500 (EST)
From: Dan.McDonald@Eng.sun.com (Dan McDonald)
Message-Id: <199703251925.LAA07271@kebe.eng.sun.com>
Subject: Re: replay mandatory?
To: rodney@sabletech.com (Rodney Thayer)
Date: Tue, 25 Mar 1997 11:25:06 -0800 (PST)
Cc: ipsec@tis.com
In-Reply-To: <3.0.16.19970325133743.373f1152@pop3.pn.com> from "Rodney Thayer" at Mar 25, 97 01:45:32 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> I wonder if I am missing something.
I think the only thing you're missing is that you CAN have no replay
protection on your SA(s). (There is no window size when you have no replay.)
I see people saying, "If you use replay, the minimum window size MUST be 32
packets." And let's look at your concerns.
> Today, in an IPsec-less environment, if I get IP packets for 1000 different
> TCP circuits, I have to have some pool of local copies of packets to deal
> with out-of-order IP packets.
Basically, each TCP connection has state which will queue up the packets that
arrive out of order, rather than deliver them to the appropriate application.
If a segment arrives out-of-order, it gets queued at the TCP control block
(or whatever you call yours), and that memory is held until such time as the
data is delivered and consumed.
> If I implement IPsec, with NO replay, things are the same. I decrypt, I
> send it to the next step in the process, and presumably the same pool could
> be used.
If the same memory block (mbuf, mblk, whatever you use) ISN'T being used
after you've decrypted (OR AUTHENTICATED, DON'T FORGET AH, FOLKS), I question
your design. :)
You're right, you just deliver as before w/o replay.
> If I require a replay window of 32 for 1000 different Security
> Associations, that means I need to keep 32*1000 copies of IP packets
> around.
Not necessarily. It's POSSIBLE that you'll have 31*1000 copies of IP packets
queued up, assuming a Byzantine failure. Besides, at some point in time, you
just assume that packet <foo> didn't arrive, drop it, then deliver the
<foo+1>.. etc packets. Delivery will free up the resources.
Keep in mind that with larger replay windows, system resources CAN be
consumed at a faster rate. It doesn't, however, mean that they WILL be
consumed at a faster rate.
> I can't spread the pool cost among the 1000 like I could in the non-IPsec
> case.
I understand that you're concerned about system resources. It sounds like,
in your system, you allocate a fixed number of buffers allocated to network
traffic. Yes, a large replay window will perhaps exhaust your finite supply
of buffers quicker than no replay.
If packets are behaving themselves and arrive mostly in-order, even with a
replay window of 256, you won't be burning your buffers very quickly. I
suspect that's the common case.
Finally, if I understand, if you're that concerned about system resources,
you can have a policy of no-replay-protection in your KMd.
Dan
From owner-ipsec Tue Mar 25 14:32:47 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA12015 for ipsec-outgoing; Tue, 25 Mar 1997 14:31:18 -0500 (EST)
Message-Id: <199703251935.OAA02413@thunk.ch.apollo.hp.com>
X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs
To: Rodney Thayer <rodney@sabletech.com>
Cc: Stephen Kent <kent@bbn.com>, ipsec@tis.com
Subject: Re: replay mandatory?
In-Reply-To: rodney's message of Tue, 25 Mar 1997 13:45:32 -0500.
<3.0.16.19970325133743.373f1152@pop3.pn.com>
Date: Tue, 25 Mar 1997 14:35:12 -0500
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> If I require a replay window of 32 for 1000 different Security
> Associations, that means I need to keep 32*1000 copies of IP packets
> around. I can't spread the pool cost among the 1000 like I could in the
> non-IPsec case.
No, you process non-replayed packets out-of-order as they arrive (and
toss replayed or stale packets as they arrive), so, at the ipsec
layer, for 1000 SA's, you need room for 1000 * 64 bits of storage (32
bits of sequence number plus 32 bits of replay-window bitmap); this is
most likely smaller than the encryption state.
You still need buffering in tcp and in ip fragment reassembly.
- Bill
From owner-ipsec Tue Mar 25 14:39:20 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA12156 for ipsec-outgoing; Tue, 25 Mar 1997 14:37:56 -0500 (EST)
From: HUGO@watson.ibm.com
Message-Id: <199703251942.OAA28141@mailhub1.watson.ibm.com>
Date: Tue, 25 Mar 97 14:12:31 EST
To: sommerfeld@apollo.hp.com, daw@cs.berkeley.edu
cc: ipsec@ex.tis.com
Subject: Proposed changes to ESP (andf a little AH too)
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Ref: Your note of Tue, 25 Mar 1997 11:56:26 -0500 (attached)
I agree with both Bill's note attached here,
and Dave Wagner's comments in a recent note.
If the choice would be pure cryptographic I might be inclined for the
current authenticate-the-plaintext (and encrypt the MAC) approach.
It better captures the real objective which is to authenticate the
plaintext rather than the ciphertext.
However, the other approach is not bad enough as to be immediately
disqualified.
If authenticate-the-ciphertext is chosen, it will be important to have
some remarks in the draft in the lines of Dave's note.
The real question to decide in this WG is whether the advantage against
denial of service attacks provided by the authenticate-the-ciphertext
approach is important enough to risk even further delay of ipsec
deployment (which is also a form of denial-of-service attack :)
In other words, if any of these discussion cannot be resolved by Memphis
leave it the way it is now and go forward.
Hugo
----------------------------- Note follows ------------------------------
Received: from mailhub1.watson.ibm.com by yktvmv.watson.ibm.com
(IBM VM SMTP V2R4) with TCP; Tue, 25 Mar 97 12:19:36 EST
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [9.2.250.12]) by mailhub1.watson.ibm.com (8.8.2/01-15-97) with ESMTP id
MAA43726; Tue, 25 Mar 1997 12:19:35 -0500
Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by igw2.watson.ibm.com (8.7.6/8.7.1) with ESMTP id MAA24364;
Tue, 25 Mar 1997 12:18:56 -0500
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA10498 for ipsec-outgoing; Tue, 25 Mar 1997 11:51:56
-0500 (EST)
Message-Id: <199703251656.LAA02300@thunk.ch.apollo.hp.com>
X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs
To: daw@cs.berkeley.edu (David Wagner)
Cc: ipsec@ex.tis.com
Subject: Re: Proposed changes to ESP (andf a little AH too)
In-Reply-To: daw's message of 24 Mar 1997 22:33:06 -0800.
<5h7rj2$ng6@joseph.cs.berkeley.edu>
Date: Tue, 25 Mar 1997 11:56:26 -0500
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> > The main argument against doing encryption first and auth second would
> > be - generally speaking there is no guarantee even if you verified the
> > CIPHERTEXT correctly, that the PLAINTEXT finally obtained is the same
> > as was sent.
>
> That's a robustness argument against authenticating the ciphertext,
> and a pretty good one if the decryption routine is complicated.
>
> However, if the decryption is simple & easy to analyze, we can (mostly)
> put to rest those fears about authenticating ciphertext.
It's also the case that the bulk of the protocols which will likely be
used inside ESP (IP, UDP, TCP) already use a simple 16-bit checksum,
which will cause most garbled traffic to be dropped.
If we assume that errors where the ciphertext is authenticated but the
decryption is garbled will most likely occur during debugging of new
code or manual keying, then that would seem to be an acceptable risk;
the operator(s) will interpret 99.998% packet loss as 100% packet loss
and start debugging..
We merely need to specify that the IP checksum MUST be supplied on
transmission and verified on receipt for packets nested inside ESP.
- Bill
From owner-ipsec Tue Mar 25 14:39:44 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA12164 for ipsec-outgoing; Tue, 25 Mar 1997 14:38:26 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03007809af5dd84da19c@[128.89.0.110]>
In-Reply-To: <3.0.16.19970325133743.373f1152@pop3.pn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 25 Mar 1997 14:44:50 -0500
To: Rodney Thayer <rodney@sabletech.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: replay mandatory?
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Rodney,
I think I see the source of your confusion. Anti-replay is not
designed to ensure that TCP receives packets in order. The ordering of
packets for delivery to an application is a TCP function and we should not
try to usurp that function at the IP layer. Our only goal for anti-replay
in AH and ESP is to detect and reject (authentic) packets that we have
already received.
We use an integrity-protected, monotonically increasing sequence
number in AH or ESP for anti-replay purposes. Thus an IPSEC implementation
can reject a duplacate packet merely by examining the sequence number and
comparing it to the window maintained for the SA via which the packet
arrived. By choosing windows that are 32-bit multiples, one can mainatin a
bit map to easily track pacets that arrive outr of order, but within the
(trailing, sliding) window. See Jim Hughes code in one of his I-Ds for
details.
Thus we can achieve the anti-replay goal without buffering ANY
packets in IPSEC. TCP still needs to buffer packets, to allow for
out-of-order arrival, but the buffer pool arrangemetts should be the same
as before. That's a TCP, not an IP, function, and anti-replay will not
change this buffering and re-oredering task for TCP. However, TCP already
does this just fine and IPsec anti-replay will protect TCP implementations
from having to buffer bogus packets.
Steve
From owner-ipsec Thu Mar 27 15:16:22 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA00687 for ipsec-outgoing; Thu, 27 Mar 1997 15:07:17 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v0300780baf607dcff3dc@[128.89.0.110]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 27 Mar 1997 15:12:55 -0500
To: ipsec@tis.com
From: Stephen Kent <kent@bbn.com>
Subject: new I-Ds, etc.
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Folks,
Extensively revised versions of the AH and ESP specs have been
submitted as I-Ds. I'll send out the formatted versions to the list as
well, to help speed up the distribution process. Please forgive the
receipt of moderately large documents later today. The changes to the
documents represent an attempt to unify the document structure for IPsec
(to do away with the proliferation of "transform" documents), and to make
some substantive changes that promise better efficiency and effectiveness,
and simplier impelmentations.
For example, the new AH spec should suffice, with its reference to
HMAC and the indirect references to MD5 and SHA-1, to encopmass all of the
previously described AH transforms. Any new algorithms that might be added
for AH use can be described in very brief documents that need not reproduce
packet syntax, etc. Similarly, the new ESP spec attempts to capture all of
the essential features of all of the proposed ESP transforms. (No inclusion
of compression for now, but it will be easy to add the necessary
placeholders if the WG elects to do so.) We do need a revised spec for DES
CBC, with explicit and implicit IVs but without reference to all the other
fields, and then the transition to the revised spec format shold be
complete (for the default algorithm sets). New algorithms should be
described in short, focused documents that need not describe the rest of
the packet, other security services, etc. Combinations of services and
algorithms are definbed through the ISAKMP negotiations, thus doing away
with the need for additional documents to describe all the precommended
combinations of services and algorithms. If nothing else, we will save
lots of trees (and electrons?) through this consolidation strategy.
Implementors will have fewer documents to read and there will be fewer
opportunities for inconsistency.
All of the sunstantive changes to the AH and ESP specs have been
discussed on the list, and most were briefed at the last WG meeting, in San
Jose. Although I will not be in Memphis, Nina Yuan has worked with me on
these specs and will be there to provide briefings on the I-Ds and on the
architecture document (see below). We look forward to receiving any
feedback that will further improve the quality of these important specs.
We hope for speed approval by the WG, so that we can move to last call and
issue new RFCs that reflect the nature of the current, evolved AH and ESP
designs and implementations.
I am sorry to say that the architecture document is not among the
newly released I-Ds. I have decided to re-write this document from
scratch: (zero-based budgeting?). This decision was motivated by several
observations:
- the extensive changes in the AH and ESP documents
- descovery of a number of architectural issues that need to be
addressed but were not included in previous versions of the document (and
some of which have not received extensive discussion on the mailing list)
In this latter category are several important issues that we will be
raising on the list (after Memphis). The plan is to propose language for
the architecture document for each major issue, with supporting analysis
for the proposal, and to reach concensus before incorporating the text (or
a revised verison of the text) into the new document. The list of issues
to be addressed in this fashion include:
- proper handling of the DF bit and processing of ICMP PMTU messages
- requirements for selectors (filters) for SA bundles, in
integrated host, bump-in-the-stack, bump-in-the-wire and security gateway
implementations
- header and option copying in tunnel mode, for both inbound and
outbound traffic, in hosts and gateways
- a uniform mechanism for extracting autehntication and/or
encryption keys for use with AH and ESP, based on ISAKMP exchanges
- a mechanism for discovering and verifying the authorization of
security gateways
As you can see, we have a few things to discuss and resolve before
we can calim to have a complete architecture for IPsec, even though we have
made a lot of progress so far and we have nailed down a number of
architectural issues. As noted above, we will begin sedning out messages
(one per topic) for each of these issues, after Memphis, with the intent to
having resolution of the issues and a new architecture I-D well before
Munich.
Steve
From owner-ipsec Thu Mar 27 15:22:08 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA00796 for ipsec-outgoing; Thu, 27 Mar 1997 15:21:58 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v0300780daf60874f2f7a@[128.89.0.110]>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="============_-1352627887==_============"
Date: Thu, 27 Mar 1997 15:22:08 -0500
To: ipsec@tis.com
From: Stephen Kent <kent@bbn.com>
Subject: new AH spec (big message)
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
--============_-1352627887==_============
Content-Type: text/plain; charset="us-ascii"
--============_-1352627887==_============
Content-Type: text/plain; name="AH_Final_(formatted)"; charset="us-ascii"
Content-Disposition: attachment; filename="AH_Final_(formatted)"
Network Working Group Stephen Kent, BBN Corp
Internet Draft Randall Atkinson, @Home Network
draft-ietf-ipsec-auth-04.txt 26 March 1997
IP Authentication Header
Status of This Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of 6 months.
Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet Drafts
as reference material or to cite them other than as a "working draft"
or "work in progress". Please check the I-D abstract listing
contained in each Internet Draft directory to learn the current
status of this or any other Internet Draft.
This particular Internet Draft is a product of the IETF's IPng and
IPsec Working Groups. It is intended that a future version of this
draft will be submitted for consideration as a standards-track
document. Distribution of this document is unlimited.
Kent, Atkinson [Page 1]
Internet Draft IP Authentication Header 26 March 1997
Table of Contents
1. Introduction......................................................3
2. Authentication Header Format......................................4
2.1 Next Header...................................................4
2.2 Payload Length................................................4
2.3 Reserved......................................................4
2.4 Security Parameters Index (SPI)...............................5
2.5 Sequence Number...............................................5
2.6 Authentication Data ..........................................5
3. Authentication Header Processing..................................5
3.1 Authentication Header Location...............................5
3.2 Outbound Packet Processing...................................8
3.2.1 Security Association Lookup.............................8
3.2.2 Sequence Number Field...................................8
3.2.3 Integrity Check Value Calculation.......................8
3.2.3.1 Handling Mutable Fields............................8
3.2.3.1.1 ICV Computation for IPv4......................9
3.2.3.1.2 ICV Computation for IPv6......................9
3.2.3.2 Padding...........................................10
3.2.3.2.1 Authentication Data Padding..................10
3.2.3.2.2 Implicit Packet Padding......................10
3.2.3.3 Authentication Algorithms.........................10
3.2.4 Fragmentation..........................................11
3.3 Inbound Packet Processing...................................11
3.3.1 Reassembly.............................................11
3.3.2 Security Association Lookup............................11
3.3.3 Sequence Number Verification...........................11
3.3.4 Integrity Check Value Verification.....................12
4. Conformance Requirements.........................................13
5. Security Considerations..........................................13
Acknowledgements....................................................13
References..........................................................14
Disclaimer..........................................................15
Author Information..................................................15
Kent, Atkinson [Page 2]
Internet Draft IP Authentication Header 26 March 1997
1. Introduction
The IP Authentication Header (AH) is used to provide connectionless
integrity and data origin authentication for IP datagrams (hereafter
referred to as just "authentication"), and to provide protection
against replays. This latter, optional service may be selected when
a Security Association is established. AH provides authentication
for as much of the IP header as possible, as well as for upper level
protocol data. However, some IP header fields may change in transit
and the value of these fields, when the packet arrives at the
receiver, may not be predictable by the transmitter. The values of
such fields cannot be protected by AH. Thus the protection provided
to the IP header by AH is somewhat piecemeal.
AH may be applied alone, in combination with the IP Encapsulating
Security Payload (ESP) [KA97b], or in a nested fashion through the
use of tunnel mode (see below). Security services can be provided
between a pair of communicating hosts, between a pair of
communicating security gateways, or between a security gateway and a
host. ESP may be used to provide the same security services, and it
also provides an optional confidentiality (encryption) service. The
primary difference between ESP and AH, when used for authentication,
is the extent of the coverage. Specifically, ESP does not protect
any IP header fields unless those fields are encapsulated by ESP.
For more details on how to use AH and ESP in various network
environments, see "Security Architecture for the Internet Protocol"
[KA97a].
It is assumed that the reader is familiar with the terms and concepts
described in the document "Security Architecture for the Internet
Protocol" [KA97a]. In particular, the reader should be familiar with
the definitions of security services offered by AH (and by ESP), the
concept of Security Associations, the different key management
options available for AH (and ESP), and the ways in which AH can be
used in conjunction with ESP.
Kent, Atkinson [Page 3]
Internet Draft IP Authentication Header 26 March 1997
2. Authentication Header Format
+---------------+---------------+---------------+---------------+
| Next Header(8)| Payload Len(8)| RESERVED (16) |
+---------------+---------------+---------------+---------------+
| Security Parameters Index (32) |
+---------------+---------------+---------------+---------------+
| Sequence Number Field (32) |
+---------------+---------------+---------------+---------------+
| |
+ Authentication Data (variable number of 32-bit words) |
| |
+---------------+---------------+---------------+---------------+
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
The following subsections define the fields that comprise the AH
format. "Optional" means that the field is omitted if the option is
not selected, i.e., it is present in neither the packet as
transmitted nor as formatted for computation of the Integrity Check
Value (ICV). Whether or not an option is selected is defined as part
of the Security Association. In contrast, "mandatory" fields are
always present in the AH format.
2.1 Next Header
The Next Header is an 8-bit field that identifies the type of the
next payload after the Authentication Header. The value of this
field is chosen from the set of IP Protocol Numbers defined in the
most recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned
Numbers Authority (IANA). The Next Header field is mandatory.
2.2 Payload Length
This 8-bit field specifies the length of AH, in 32-bit words (4-byte
units), minus "2," i.e., the fixed portion of AH is not counted. The
minimum value is 0, which is used only in the degenerate case of a
"null" authentication algorithm. The Payload Length field is
mandatory.
*** Do we want to retain a null authentication algorithm as part of the
*** spec at this point? What purpose does it serve?
2.3 Reserved
This 16-bit field is reserved for future use. It MUST be set to
"zero." (Note that the value is included in the Authentication Data
calculation, but is otherwise ignored by the recipient.) The
Kent, Atkinson [Page 4]
Internet Draft IP Authentication Header 26 March 1997
Reserved field is mandatory.
2.4 Security Parameters Index (SPI)
The SPI is an arbitrary 32-bit value identifying the Security
Association for this datagram (relative to the destination IP address
contained in the IP header with which this security header is
associated). The set of SPI values in the range 1 through 255 are
reserved by the Internet Assigned Numbers Authority (IANA) for future
use; a reserved SPI value will not normally be assigned by IANA
unless the use of the assigned SPI value is specified in an RFC. A
value of zero indicates that no Security Association exists. The SPI
field is mandatory. It is ordinarily selected by the destination
system upon establishment of an SA (see "Security Architecture for
the Internet Protocol" [KA97a] for more details).
*** Under what circumstances will a zero SPI be employed? Is this
*** still relevant or is it vestigial?
2.5 Sequence Number
This unsigned 32-bit field contains a monotonically increasing
counter value (sequence number). The counter is initialized to 1
when an SA is established. The sequence number must never be allowed
to cycle; thus, it MUST be reset (by establishing a new SA and thus a
new key) prior to the transmission of 2^32-1 packets on an SA. The
Sequence Number field is optional. It is included only if the anti-
replay service (a form of loose sequence integrity) is selected as a
security service for the SA.
2.6 Authentication Data
This is a variable-length field that contains the Integrity Check
Value (ICV) for this packet. The field must be an integral multiple
of 32 bits in length. The details of the ICV computation are
described in Section 3.2.3 below. This field may include explicit
padding. This padding is included to ensure that the length of the
AH header is an integral multiple of 32 bits (IPv4) or 64 bits
(IPv6). All implementations MUST support such padding. Details of
how to compute the required padding length are provided in Section
3.2.3.2.1 below. The Authentication Data field is mandatory.
3. Authentication Header Processing
3.1 Authentication Header Location
Like ESP, AH may be employed in two ways: transport mode or tunnel
mode. The former mode is applicable only to host implementations and
Kent, Atkinson [Page 5]
Internet Draft IP Authentication Header 26 March 1997
provides protection for upper layer protocols, in addition to
selected IP header fields. In this mode, AH is inserted after the IP
header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc.
In the context of IPv4, this calls for placing AH after the IP header
(and any options that it contains), but before the upper layer
protocol. (Note that the term "transport" mode should not be
misconstrued as restricting its use to TCP and UDP. For example, an
ICMP message MAY be sent using either "transport" mode or "tunnel"
mode.) The following diagram illustrates AH transport mode
positioning for a typical IPv4 packet, on a "before and after" basis.
BEFORE APPLYING AH
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING AH
---------------------------------
IPv4 |orig IP hdr | | | |
|(any options)| AH | TCP | Data |
---------------------------------
|<------ authenticated ------->|
except for mutable fields
In the IPv6 context, AH is viewed as an end-to-end payload, and thus
should appear after hop-by-hop, routing, and fragmentation extension
headers. The destination options extension header(s) could appear
either before or after the AH header depending on the semantics
desired. The following diagram illustrates AH transport mode
positioning for a typical IPv6 packet.
Kent, Atkinson [Page 6]
Internet Draft IP Authentication Header 26 March 1997
BEFORE APPLYING AH
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
AFTER APPLYING AH
------------------------------------------------------------
IPv6 | |hxh,rtg,frag| dest | | dest | | |
|orig IP hdr |if present**| opt* | AH | opt* | TCP | Data |
------------------------------------------------------------
|<-------------------- authenticated --------------------->|
except for mutable fields
* = if present, could be before AH, after AH, or both
** = hop by hop, routing, fragmentation headers
Tunnel mode AH may be employed in either hosts or security gateways.
When AH is implemented in a security gateway (to protect subscriber
transit traffic), tunnel mode must be used. In tunnel mode, the
"inner" IP header carries the ultimate source and destination
addresses, while an "outer" IP header may contain distinct IP
addresses, e.g., addresses of security gateways. In tunnel mode, AH
protects the entire inner IP packet, including the entire inner IP
header. The position of AH in tunnel mode, relative to the outer IP
header, is the same as for AH in transport mode. The following
diagram illustrates AH tunnel mode positioning for typical IPv4 and
IPv6 packets.
------------------------------------------------
IPv4 | new IP hdr* | | orig IP hdr* | | |
|(any options)| AH | (any options) |TCP | Data |
------------------------------------------------
|<---------------- authenticated ------------->|
except for mutable fields
--------------------------------------------------------------
IPv6 | | ext hdrs*| | | ext hdrs*| | |
|new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data|
--------------------------------------------------------------
|<---------------------- authenticated --------------------->|
except for mutable fields
* = construction of outer IP hdr/extensions and
modification of inner IP hdr/extensions is
discussed below.
Kent, Atkinson [Page 7]
Internet Draft IP Authentication Header 26 March 1997
3.2 Outbound Packet Processing
In transport mode, the transmitter inserts the AH header after the IP
header and before an upper layer protocol header, as described above.
In tunnel mode, the outer and inner IP header/extensions can be
inter-related in a variety of ways. The construction of the outer IP
header/extensions during the encapsulation process is described in
the document, "Security Architecture for the Internet Protocol".
3.2.1 Security Association Lookup
AH is applied to an outbound packet only after an IPsec
implementation determines that the packet is associated with an SA
that calls for AH processing. The process of determining what, if
any, IPsec processing is applied to outbound traffic is described in
the document, "Security Architecture for the Internet Protocol".
3.2.2 Sequence Number Field
If the anti-replay service has been selected for this SA, the
transmitter increments the sequence number for this SA, checks to
ensure that the counter has not cycled, and inserts the new value
into the Sequence Number Field. A transmitter MUST not send a packet
on an SA if doing so would cause the sequence number to cycle.
3.2.3 Integrity Check Value Calculation
3.2.3.1 Handling Mutable Fields
The AH ICV is computed over IP header fields that are either
immutable in transit or that are predictable in value upon arrival at
the endpoint for the AH SA. The ICV also encompasses the upper level
protocol data, which is assumed to be immutable in transit. If a
field is modified during transit, the value of the field is set to
zero for purposes of the ICV computation. If a field is mutable, but
its value at the (IPsec) receiver is predictable, then that value is
inserted into the field for purposes of the ICV calculation. The
Authentication Data field also is set to zero in preparation for this
computation. (Note that by replacing each field's value with zero,
rather than omitting the field, alignment is preserved for the ICV
calculation.)
DISCUSSION:
For IPv4 (unlike IPv6), there is no mechanism for tagging options
as mutable in transit. Hence the IPv4 options are explicitly
listed here and classified as either mutable or immutable. For
IPv4, the entire option is viewed as a unit; so even though the
Kent, Atkinson [Page 8]
Internet Draft IP Authentication Header 26 March 1997
type and length fields within most options are immutable in
transit, if an option is classified as mutable, the entire option
is zeroed for ICV computation purposes. The mutable IPv4 header
fields also are enumerated below. The ICV calculation is
restricted to the immutable options and (base) header fields.
3.2.3.1.1 ICV Computation for IPv4
The IPv4 base header fields "Time to Live", "Header Checksum",
"Offset", "Flags", and "Type of Service" are zeroed prior to the
computation of the ICV. (The TOS field is included here because some
routers are known to change the value of this field, even though the
IP specification does not consider TOS to be a mutable header field.)
*** What about OFFSET and FLAGS. Since reassembly takes place before
*** AH processing why are these fields omitted from the ICV
*** computation?
The following IPv4 options are mutable: record route, timestamp,
loose source routing, and strict source routing. These options are
treated as zero-filled for purposes of the ICV computation. The IP
Security Options, BSO and ESO (RFC-1038, RFC-1108) and the CIPSO
(option number 134) option are included in the ICV calculation and
are not zeroed.
3.2.3.1.2 ICV Computation for IPv6
In IPv6, the "Hop Limit" field in the IPv6 base header is zeroed
prior to performing the ICV calculation. IPv6 options contain a bit
that indicates whether the option might change during transit. For
any option for which contents may change en-route, the entire "Option
Data" field must be treated as zero-valued octets when computing or
verifying the ICV. The Option Type and Opt Data Len are included in
the ICV calculation. All other options are also included in the ICV
calculation. See the IPv6 specification [DH95] for more information.
Note that the IPv6 Routing Header "Type 0" will rearrange the address
fields within the packet during transit from source to destination.
However, the contents of the packet as it will appear at the receiver
are known to the sender and to all intermediate hops. Hence, the
IPv6 Routing Header "Type 0" is included in the Authentication Data
calculation as an immutable option. The transmitter must order the
field so that it appears as it will at the receiver, prior to
performing the ICV computation.
*** Do we want to make any recommendation for what an AH implementation
*** should do if it encounters an unfamiliar IPv6 extension header,
Kent, Atkinson [Page 9]
Internet Draft IP Authentication Header 26 March 1997
*** e.g., Routing Header "Type 1" (aka Nimrod)?
3.2.3.2 Padding
3.2.3.2.1 Authentication Data Padding
As mentioned in section 2.6, the Authentication Data field explicitly
includes padding to ensure that the AH header is a multiple of 32
bits (IPv4) or 64 bits (IPv6). If padding is required, its length is
determined by three factors:
- the presence or absence of the Sequence Number field
- the length of the ICV
- the IP protocol context (v4 or v6)
For example, if the Sequence Number field is present and a default,
96-bit truncated HMAC algorithm is selected, no padding is required
for either IPv4 nor IPv6. In contrast, if the anti-replay service is
not selected, and a default 96-bit truncated HMAC algorithm is
selected, no padding is required for IPv4, but 4 bytes of padding are
required for IPv6. The content of the padding field is arbitrarily
selected by the sender. (The padding is arbitrary, but need not be
random to achieve security.) These bytes are included in the
Authentication Data calculation, counted as part of the Payload
Length, and transmitted at the end of the Authentication Data field
to enable the receiver to perform the ICV calculation.
3.2.3.2.2 Implicit Packet Padding
For some authentication algorithms, the byte string over which the
ICV computation is performed must be a multiple of a blocksize
specified by the algorithm. If the IP packet length (including AH)
does not match the blocksize requirements for the algorithm, implicit
padding MUST be appended to the end of the packet, prior to ICV
computation. The padding octets MUST have a value of zero. The
blocksize (and hence the length of the padding) is specified by the
algorithm specification. This padding is not transmitted with the
packet.
3.2.3.3 Authentication Algorithms
The authentication algorithm employed for the ICV computation is
specified by the SA. For point-to-point communication, suitable
authentication algorithms include keyed Message Authentication Codes
(MACs) based on symmetric encryption algorithms (e.g., DES) or on
one-way hash functions (e.g., MD5 or SHA-1). For multicast
communication, one-way hash algorithms combined with asymmetric
signature algorithms are suitable. As of this writing, the
mandatory-to-implement authentication algorithms are based on the
Kent, Atkinson [Page 10]
Internet Draft IP Authentication Header 26 March 1997
former class, i.e., HMAC [KBC97] with SHA-1 [SHA] or HMAC with MD5
[Riv92]. The output of the HMAC computation is truncated to (the
leftmost) 96 bits. Other algorithms, possibly with different ICV
lengths, MAY be supported.
3.2.4 Fragmentation
If required, IP fragmentation occurs after AH processing within an
IPsec implementation. However, an IP packet to which AH has been
applied may itself be fragmented by routers en route, including
security gateways that may apply AH or ESP (tunnel mode) to the
already-protected packet or fragments.
3.3 Inbound Packet Processing
3.3.1 Reassembly
If required, reassembly is performed prior to AH processing.
3.3.2 Security Association Lookup
Upon receipt of a packet containing an IP Authentication Header, the
receiver determines the appropriate (unidirectional) SA, based on the
destination IP address and the SPI. (This process is described in
more detail in the document, "Security Architecture for the Internet
Protocol".) The SA will indicate whether the Sequence Number field
should be present, will specify the algorithm(s) employed for ICV
computation, and will indicate the key(s) required to validate the
ICV.
If no valid Security Association exists for this session (e.g., the
receiver has no key), the receiver MUST discard the packet and the
failure MUST be recorded in an audit log. The log entry SHOULD
include the SPI value, date/time, Source Address, Destination
Address, and (in IPv6) the Flow ID. The log entry MAY also include
other identifying data. There is no requirement for the receiver to
transmit any message to the purported transmitter in response to
receipt of such packets (because of the potential to induce denial of
service via such actions).
3.3.3 Sequence Number Verification
If the anti-replay service has been selected for this SA, the
receiver MUST verify that the packet contains a Sequence Number that
does not duplicate the Sequence Number of any other packets received
during the life of this SA. This SHOULD be the first AH check
applied to a packet after it has been matched to an SA, to speed
rejection of duplicate packets.
Kent, Atkinson [Page 11]
Internet Draft IP Authentication Header 26 March 1997
Duplicates are rejected through the use of a sliding receive window.
(How the window is implemented is a local matter, but the following
text describes the functionality that the implementation must
exhibit.) The default window size is 32 and all AH implementations
MUST support this window size. A larger window size MAY be
established during SA negotiation. If a larger window size is
negotiated it MUST be a multiple of 32.
The "right" edge of the window represents the highest, validated
Sequence Number value received on this SA. Packets that contain
Sequence Number values lower than the "left" edge of the window are
rejected. Packets falling within the window are checked against a
list of received packets within the window. An efficient means for
performing this check, based on the use of a bit mask, is described
in [KA97a].
If the received packet falls within the window, then the receiver
proceeds to ICV verification. If the ICV validation fails, the
receiver MUST discard the received IP datagram as invalid and MUST
record the authentication failure in an audit log. If such a failure
occurs, the log entry MUST include the SPI value, date/time received,
Sending Address, Destination Address, and (in IPv6) Flow ID. The log
data MAY also include other information about the failed packet. The
window is updated only if the ICV verification succeeds.
DISCUSSION:
Note that if the packet is either inside the window and new, or
outside the window on the "right" side, the receiver MUST
authenticate the Sequence Number field before updating the bit
mask (either turning on a bit or updating the "right" side of the
window).
3.3.4 Integrity Check Value Verification
The receiver computes the ICV over the appropriate fields of the
packet, using the specified authentication algorithm, and verifies
that it is the same as the ICV included in the Authentication Data
field of the packet. Details of the computation are provided below.
If the computed and received ICV's match, then the datagram is valid,
and it is accepted. If the test fails, then the receiver MUST
discard the received IP datagram as invalid and MUST record the
authentication failure in an audit log. The log data MUST include the
SPI value, date/time received, Source Address, Destination Address,
and (in IPv6) the Flow ID. The log data also MAY include other
information about the failed packet.
Kent, Atkinson [Page 12]
Internet Draft IP Authentication Header 26 March 1997
DISCUSSION:
Begin by saving the ICV value and replacing it (but not any
Authentication Data padding) with zero. Zero all other fields
that may have been modified during transit. (See section 3.2.3.1
for a discussion of which fields are zeroed before performing the
ICV calculation.) Check the overall length of the packet, and if
it requires implicit padding based on the requirements of the
authentication algorithm, append zero-filled bytes to the end of
the packet as required. Now perform the ICV computation and
compare the result with the received value. (If a digital
signature and one-way hash are used for the ICV computation, the
matching process is more complex and will be described in the
algorithm specification.)
4. Conformance Requirements
Implementations that claim conformance or compliance with this
specification MUST fully implement the AH syntax and processing
described here and MUST comply with all requirements of the "Security
Architecture for the Internet Protocol." Note that support for
manual key distribution is required, but its use is inconsistent with
the anti-replay service, and thus a compliant implementation must not
negotiate this service in conjunction with SAs that are manually
keyed. A compliant AH implementation MUST support the following
mandatory-to-implement algorithms (specified in [KBC97]):
- HMAC with MD5
- HMAC with SHA-1
5. Security Considerations
Security is central to the design of this protocol, and this security
considerations permeate the specification. Additional security-
relevant aspects of using IPsec protocol are discussed in the
document, "Security Architecture for the Internet Protocol".
Acknowledgements
For over 2 years, this document has evolved through multiple versions
and iterations. During this time, many people have contributed
significant ideas and energy to the process and the documents
themselves. The authors would like to thank the members of the IPsec
and IPng working groups, with special mention of the efforts of (in
alphabetic order): Steve Bellovin, Steve Deering, Francis Dupont,
Phil Karn, Frank Kastenholz, Perry Metzger, David Mihelcic, Hilarie
Kent, Atkinson [Page 13]
Internet Draft IP Authentication Header 26 March 1997
Orman, and William Simpson. In addition, Charlie Lynn, Karen Seo,
and Nina Yuan provided extensive help in the review and editing of
this version of the specification.
References
[BCCH94] R. Braden, D. Clark, S. Crocker, & C.Huitema, "Report of IAB
Workshop on Security in the Internet Architecture", RFC-
1636, 9 June 1994, pp. 21-34.
[Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP
Protocol Suite", ACM Computer Communications Review, Vol.
19, No. 2, March 1989.
[CER95] Computer Emergency Response Team (CERT), "IP Spoofing
Attacks and Hijacked Terminal Connections", CA-95:01,
January 1995. Available via anonymous ftp from
info.cert.org in /pub/cert_advisories.
[DH95] Steve Deering & Bob Hinden, "Internet Protocol version 6
(IPv6) Specification", RFC-1883, December 1995.
[GM93] James Galvin & Keith McCloghrie, Security Protocols for
version 2 of the Simple Network Management Protocol
(SNMPv2), RFC-1446, April 1993.
[KBC97] Hugo Krawczyk, Mihir Bellare, and Ran Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC-2104,
February 1997.
[Ken91] Steve Kent, "US DoD Security Options for the Internet
Protocol", RFC-1108, November 1991.
[KA96a] Steve Kent, Randall Atkinson, "Security Architecture for
the Internet Protocol", Internet Draft, ?? 1997.
[KA96b] Steve Kent, Randall Atkinson, "IP Encapsulating Security
Payload (ESP)", Internet Draft, March 1997.
[KA96c] Steve Kent, Randall Atkinson, "IP Authentication Header",
Internet Draft, March 1997.
[Riv92] Ronald Rivest, MD5 Digest Algorithm, RFC-1321, April 1992.
[SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995
[STD-1] J. Postel, "Internet Official Protocol Standards", STD-1,
Kent, Atkinson [Page 14]
Internet Draft IP Authentication Header 26 March 1997
March 1996.
[STD-2] J. Reynolds & J. Postel, "Assigned Numbers", STD-2, 20
October 1994.
Disclaimer
The views and specification here are those of the authors and are not
necessarily those of their employers. The authors and their
employers specifically disclaim responsibility for any problems
arising from correct or incorrect implementation or use of this
specification.
Author Information
Stephen Kent
BBN Corporation
70 Fawcett Street
Cambridge, MA 02140
USA
Telephone: +1 (617) 873-3988
Randall Atkinson <rja@inet.org>
@Home Network
385 Ravendale Drive
Mountain View, CA 94043
USA
Kent, Atkinson [Page 15]
--============_-1352627887==_============--
From owner-ipsec Thu Mar 27 15:26:44 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA00835 for ipsec-outgoing; Thu, 27 Mar 1997 15:26:33 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v0300780eaf6087753872@[128.89.0.110]>
Mime-Version: 1.0
Date: Thu, 27 Mar 1997 15:22:38 -0500
To: ipsec@tis.com
From: Stephen Kent <kent@bbn.com>
Subject: new ESP spec (bigger message)
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
--============_-1352627881==_============
Content-Type: text/plain; charset="us-ascii"
--============_-1352627881==_============
Content-Type: text/plain; name="ESP_final_(formatted)"; charset="us-ascii"
Content-Disposition: attachment; filename="ESP_final_(formatted)"
Network Working Group Stephen Kent, BBN Corp
Internet Draft Randall Atkinson, @Home Network
draft-ietf-ipsec-esp-03.txt 26 March 1997
IP Encapsulating Security Payload (ESP)
Status of This Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its working groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of 6 months.
Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet Drafts
as reference material or to cite them other than as "work in
progress".
This particular Internet Draft is a product of the IETF's IPng and
IPsec working groups. It is intended that a future version of this
draft be submitted to the IPng Area Directors and the IESG for
possible publication as a standards-track protocol.
Kent, Atkinson [Page 1]
Internet Draft IP Encapsulating 26 March 1997
Security Payload (ESP)
Table of Contents
1. Introduction......................................................3
2. Encapsulating Security Payload Packet Format......................4
2.1 Security Parameters Index....................................4
2.2 Sequence Number .............................................5
2.3 Initialization Vector........................................5
2.4 Payload Data.................................................5
2.5 Padding (for encryption).....................................6
2.6 Pad Length...................................................6
2.7 Next Header..................................................6
2.8 Authentication Data..........................................6
3. Encapsulating Security Protocol Processing........................7
3.1 ESP Header Location..........................................7
3.2 Outbound Packet Processing...................................9
3.2.1 Security Association Lookup.............................9
3.2.2 Anti-replay Service.....................................9
3.2.3 Packet Encryption.......................................9
3.2.3.1 Scope of Encryption.................................9
3.2.3.2 Encryption Algorithms..............................10
3.2.4 Integrity Check Value Calculation......................10
3.2.4.1 Scope of Authentication Protection................10
3.2.4.2 Authentication Padding............................10
3.2.4.3 Authentication Algorithms.........................11
3.2.5 Fragmentation..........................................11
3.3 Inbound Packet Processing...................................11
3.3.1 Pre-ESP Processing Overview............................11
3.3.2 Security Association Lookup............................11
3.3.3 Anti-replay Service....................................12
3.3.4 Integrity Check Value Verification.....................13
3.3.5 Packet Decryption......................................13
4. Conformance Requirements.........................................14
5. Security Considerations..........................................14
Acknowledgements....................................................14
References..........................................................15
Disclaimer..........................................................17
Author Information..................................................17
Kent, Atkinson [Page 2]
Internet Draft IP Encapsulating 26 March 1997
Security Payload (ESP)
1. Introduction
The Encapsulating Security Payload (ESP) header is designed to
provide a mix of optional security services in IPv4 and IPv6. ESP
may be applied alone, in combination with the IP Authentication
Header (AH) [KA97b], or in a nested fashion, e.g., through the use of
tunnel mode (see below). Security services can be provided between a
pair of communicating hosts, between a pair of communicating security
gateways, or between a security gateway and a host. For more details
on how to use ESP and AH in various network environments, see
"Security Architecture for the Internet Protocol" [KA97a].
The ESP header is inserted after the IP header and before the upper
layer protocol header (transport mode) or the encapsulated IP header
(tunnel mode). These modes are described in more detail below.
ESP is used to provide confidentiality, data origin authentication,
connectionless integrity, anti-replay service (a form of sequence
integrity), and limited traffic flow confidentiality. The set of
services provided depends on options selected at the time of Security
Association establishment and the implementation placement.
Confidentiality may be selected independent of all other services.
Data origin authentication and connectionless integrity are joint
services (hereafter referred to jointly as "authentication),
independent of confidentiality. An anti-replay service may be
selected only if data origin authentication is selected, but it is
independent of confidentiality. Traffic flow confidentiality depends
on confidentiality, and requires selection of tunnel mode.
It is assumed that the reader is familiar with the terms and concepts
described in the document "Security Architecture for the Internet
Protocol" [KA97a]. In particular, the reader should be familiar with
the definitions of security services offered by ESP (and by AH), the
concept of Security Associations, the different key management
options available for ESP (and AH), and the ways in which ESP can be
used in conjunction with the Authentication Header (AH).
Kent, Atkinson [Page 3]
Internet Draft IP Encapsulating 26 March 1997
Security Payload (ESP)
2. Encapsulating Security Payload Packet Format
+---------------+---------------+---------------+---------------+ ----
| Security Parameters Index (SPI), (32 bits) | ^
+---------------+---------------+---------------+---------------+ |
| Sequence Number (32 bits) | |
+---------------+---------------+---------------+---------------+ Auth/
| Initialization Vector (variable) | Integrity
+ + Coverage
| | |
+---------------+---------------+---------------+---------------+ | -----
| Payload Data (variable) | | ^
- - | |
| | | |
+ +---------------+---------------+---------------+ | Confid.
| | Padding (0-255 bytes) | |
Coverage
+---------------+ +---------------+---------------+ | |
| | Pad Length(8) | Next Header(8)| v v
+---------------+---------------+---------------+---------------+ --------
| Authentication Data (variable) |
- -
| |
+---------------+---------------+---------------+---------------+
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
The following subsections define the fields in the header format.
"Optional" means that the field is omitted if the option is not
selected, i.e., it is present in neither the packet as transmitted nor
as formatted for computation of an ICV. Whether or not an option is
selected is defined as part of Security Association (SA)
establishment. Thus the format of ESP packets for a given SA is
fixed, for the duration of the SA. In contrast, "mandatory"
fields are always present in the ESP packet format, for all SAs.
2.1 Security Parameters Index
The SPI is an arbitrary 32-bit value identifying the Security
Association for this datagram (relative to the destination IP address
contained in the IP header with which this security header is
associated). The set of SPI values in the range 1 through 255 are
reserved by the Internet Assigned Numbers Authority (IANA) for future
use; a reserved SPI value will not normally be assigned by IANA
unless the use of the assigned SPI value is specified in an RFC. A
value of zero indicates that no Security Association exists. (Note
that the SPI is similar to the SAID used in other security protocols.
The name has been changed because the semantics used here are not
exactly the same as those used in other security protocols.)
Kent, Atkinson [Page 4]
Internet Draft IP Encapsulating 26 March 1997
Security Payload (ESP)
***Under what circumstances will a zero SPI be employed? Is this
***vestigial, or is there still a use for a zero SPI? Is it a SKIP
***support feature of some sort?
The SPI field is mandatory, and its value is ordinarily selected by
the destination system upon establishment of an SA (see "Security
Architecture for the Internet Protocol" for more details.)
2.2 Sequence Number
This unsigned 32-bit field contains a monotonically increasing
counter value (sequence number). The counter is initialized to 1
when an SA is established. The Sequence Number must never be allowed
to cycle; thus, it MUST be reset (by establishing a new SA and thus a
new key) prior to the transmission of 2^32-1 packets on an SA.
The Sequence Number is optional. It is only included if the anti-
replay service is selected as a security service for the SA. Since
the anti-replay service requires selection of the authentication
service as well, the Sequence Number MUST not be present in the
absence of the Authentication Data field (described below.)
2.3 Initialization Vector
This is a variable-length field used only when an explicit IV is
required by the selected encryption algorithm, mode or device. The
length of the IV is dependent upon the choice of encryption
algorithm, and is established during SA negotiation. The IV field is
optional, but all implementations must be capable of generating and
processing this field if they support algorithms or devices that
require an explicit IV.
2.4 Payload Data
Payload Data is a variable-length field containing data described by
the Next Header field. This field is an integral number of bytes in
length. The Payload Data field is mandatory.
***We have a potential IPv6 alignment problem here, that may have
***been present for some time. Ignoring the presence or absence of an
***iv, the payload data will not be aligned on an 8-byte boundary if
***the Sequence Number is omitted. This may cause a problem for
***efficient crypto data transfer. If the IV is present, and the
***Sequence Number is omitted, the same problem arises, starting with
***the IV, unless the IV is of a compensating size. The decryption
***process can fix the problem for higher layer protocols, because the
***output buffer from decryption is usually distinct from the input
Kent, Atkinson [Page 5]
Internet Draft IP Encapsulating 26 March 1997
Security Payload (ESP)
***buffer, but that still causes potential problems for transfer of
***data to the crypto module. Also, if encryption is not employed,
***this becomes a potential problem for authentication data being
***passed up. We could solve this by adding an optional alignment
***field to the ESP header, when required for IPv6. What do people think?
2.5 Padding (for Encryption)
If the confidentiality service has been selected, the Padding field
is used to fill the Payload Data to a multiple of the blocksize
required by the encryption algorithm. This blocksize requirement is
a parameter of the algorithm negotiated during SA establishment.
If encryption has not been selected, the Padding field is used to
align the Next Header field so that the last bit of that field ends
on a 32-bit boundary.
The Padding bytes SHOULD be initialized with random data and they are
transmitted. The transmitter can add 0-255 bytes of padding. Padding
beyond that required for encryption algorithm blocksize alignment may
be used to conceal the actual length of the payload, in support of
traffic flow confidentiality. However, inclusion of such additional
padding has adverse bandwidth implications and thus its use should be
undertaken with care. The Padding field is optional, but all
implementations MUST support generation and consumption of padding.
2.6 Pad Length
The Pad Length field indicates the number of pad bytes immediately
preceding it. The range of valid values is 0-255, where a value of
zero indicates that the byte immediately preceding the pad length
field is the last byte of the payload. The Pad Length field is
mandatory.
2.7 Next Header
The Next Header is an 8-bit field that identifies the type of data
contained in the Payload Data field, e.g., an extension header in
IPv6 or an upper layer protocol identifier. The value of this field
is chosen from the set of IP Protocol Numbers defined in the most
recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned
Numbers Authority (IANA). The Next Header field is mandatory.
2.8 Authentication Data
The Authentication Data is a variable-length field containing an
Integrity Check Value (ICV) computed over the ESP packet minus the
Kent, Atkinson [Page 6]
Internet Draft IP Encapsulating 26 March 1997
Security Payload (ESP)
Authentication Data. The length of the field depends upon the
authentication function selected. The mandatory-to-implement
authentication algorithms, HMAC with MD5 or SHA-1, both yield 96-bit
ICVs because of the truncation convention adopted for use in IPsec.
The Authentication Data field is optional.
3. Encapsulating Security Protocol Processing
3.1 ESP Header Location
Like AH, ESP may be employed in two ways: transport mode or tunnel
mode. The former mode is applicable only to host implementations and
provides protection for upper layer protocols, but not the IP header.
In this mode, ESP is inserted after the IP header and before an upper
layer protocol, e.g., TCP, UDP, ICMP, etc. In the context of IPv4,
this translates to placing ESP after the IP header (and any options
that it contains), but before the upper layer protocol. (Note that
the term "transport" mode should not be misconstrued as restricting
its use to TCP and UDP. For example, an ICMP message MAY be sent
using either "transport" mode or "tunnel" mode.) The following
diagram illustrates ESP transport mode positioning for a typical IPv4
packet, on a "before and after" basis. (The "ESP trailer" encompasses
any Padding, plus the Pad Length, and Next Header fields.)
BEFORE APPLYING ESP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING ESP
-------------------------------------------------
IPv4 |orig IP hdr | | | | ESP | ESP|
|(any options)| ESP | TCP | Data | Trailer |Auth|
-------------------------------------------------
|<----- encrypted ---->|
|<------ authenticated ----->|
In the IPv6 context, ESP is viewed as an end-to-end payload, and thus
should appear after hop-by-hop, routing, and fragmentation extension
headers. The destination options extension header(s) could appear
either before or after the ESP header depending on the semantics
desired. However, since ESP protects only fields after the ESP
header, it generally may be desirable to place the destination
options header(s) after the ESP header. The following diagram
illustrates ESP transport mode positioning for a typical IPv6 packet.
Kent, Atkinson [Page 7]
Internet Draft IP Encapsulating 26 March 1997
Security Payload (ESP)
BEFORE APPLYING ESP
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
AFTER APPLYING ESP
---------------------------------------------------------
IPv6 | orig |hxh,rtg,frag|dest| |dest| | | ESP | ESP|
|IP hdr|if present**|opt*|ESP|opt*|TCP|Data|Trailer|Auth|
---------------------------------------------------------
|<---- encrypted ---->|
|<---- authenticated ---->|
* = if present, could be before AH, after AH, or both
** = hop by hop, routing, fragmentation headers
Tunnel mode ESP may be employed in either hosts or security gateways.
When ESP is implemented in a security gateway (to protect subscriber
transit traffic), tunnel mode must be used. In tunnel mode, the
"inner" IP header carries the ultimate source and destination
addresses, while an "outer" IP header may contain distinct IP
addresses, e.g., addresses of security gateways. In tunnel mode, ESP
protects the entire inner IP packet, including the entire inner IP
header. The position of ESP in tunnel mode, relative to the outer IP
header, is the same as for ESP in transport mode. The following
diagram illustrates ESP tunnel mode positioning for typical IPv4 and
IPv6 packets.
-----------------------------------------------------------
IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP|
|(any options)| ESP | (any options) |TCP|Data|Trailer|Auth|
-----------------------------------------------------------
|<--------- encrypted ---------->|
|<----------- authenticated ---------->|
---------------------------------------------------------------
IPv6 | new* | ext hdrs*| | orig*| ext hdrs*| | | ESP | ESP|
|IP hdr|if present|ESP|IP hdr|if present|TCP|Data|Trailer|Auth|
---------------------------------------------------------------
|<---------- encrypted ----------->|
|<----------- authenticated ---------->|
* = construction of outer IP hdr/extensions and modification
of inner IP hdr/extensions is discussed below.
Kent, Atkinson [Page 8]
Internet Draft IP Encapsulating 26 March 1997
Security Payload (ESP)
3.2 Outbound Packet Processing
In transport mode, the transmitter encapsulates the upper layer
protocol information in the ESP header/trailer, and retains the
specified IP header (and any IP extension headers in the IPv6
context). In tunnel mode, the outer and inner IP header/extensions
can be inter-related in a variety of ways. The construction of the
outer IP header/extensions during the encapsulation process is
described in the document, "Security Architecture for the Internet
Protocol".
3.2.1 Security Association Lookup
ESP is applied to an outbound packet only after an IPsec
implementation determines that the packet is associated with an SA
that calls for ESP processing. The process of determining what, if
any, IPsec processing is applied to outbound traffic is described in
the document, "Security Architecture for the Internet Protocol".
3.2.2 Anti-replay Service
If the anti-replay service has been selected for this SA, the
transmitter increments the Sequence Number for this SA, checks to
ensure that the counter has not cycled, and inserts the new value
into the Sequence Number field. A transmitter MUST NOT send a packet
on an SA if doing so would cause the Sequence Number to cycle.
As mentioned in section 2.2, the anti-replay service requires the
selection of the authentication services thus the Sequence Number
field MUST NOT be present in the absence of the Authentication Data
field (described below.)
3.2.3 Packet Encryption
3.2.3.1 Scope of Encryption
In transport mode, if encryption has been selected, the transmitter
encapsulates the original upper layer protocol information into the
ESP payload field, adds any necessary padding, and encrypts the
result (Payload Data, Padding, Pad Length, and Next Header) using the
key, encryption algorithm, and algorithm mode indicated by the SA.
In tunnel mode, the transmitter encapsulates and encrypts the the
entire original IP datagram (plus the Padding, Pad Length, and Next
Header).
If both encryption and authentication have been selected, encryption
is performed first, before the authentication and the encryption does
Kent, Atkinson [Page 9]
Internet Draft IP Encapsulating 26 March 1997
Security Payload (ESP)
not encompass the Authentication Data field. This order of
processing facilitates rapid detection and rejection of replayed or
bogus packets by the receiver, prior to decrypting the packet, hence
potentially reducing the impact of denial of service attacks. It
also allows for the possibility of parallel processing of packets at
the receiver, i.e., decryption can take place in parallel with
authentication. Note that since the Authentication Data is not
protected by encryption, a keyed authentication algorithm must be
employed to compute the ICV.
3.2.3.2 Encryption Algorithms
If confidentiality is selected, the encryption algorithm employed is
specified by the SA. ESP is designed for use with symmetric
encryption algorithms. Because IP packets may arrive out of order,
each packet must carry either an explicit Initialization Vector (IV)
that allows the receiver to establish cryptographic synchronization
for decryption, or data derived from the packet header must suffice
to generate an IV at the receiver. Since ESP makes provision for
padding of the plaintext, encryption algorithms employed with ESP may
exhibit either block or stream mode characteristics.
At the time of writing, one mandatory-to-implement encryption
algorithm and mode has been defined for ESP. It is based on the Data
Encryption Standard (DES) [NIST77] in Cipher Block Chaining Mode
[NIST80]. Details of use of this mode are contained in [need a new
I-D with DES-CBC and implicit IV generation, but no overlap with this
document].
3.2.4 Integrity Check Value Calculation
3.2.4.1 Scope of Authentication Protection
If authentication is selected for the SA, the transmitter computes
the ICV over the ESP packet minus the Authentication Data. Thus the
SPI, Sequence Number (if present), Initialization Vector (if
present), Payload Data, Padding (if present), Pad Length, and Next
Header are all encompassed by the ICV computation. If encryption has
been selected, the last 4 fields will be in ciphertext form.
3.2.4.2 Authentication Padding
For some authentication algorithms, the byte string over which the
ICV computation is performed must be a multiple of a blocksize
specified by the algorithm. If the length of this byte string does
not match the blocksize requirements for the algorithm, implicit
padding MUST be appended to the end of the ESP packet, prior to ICV
Kent, Atkinson [Page 10]
Internet Draft IP Encapsulating 26 March 1997
Security Payload (ESP)
computation. The padding octets MUST have a value of zero. The
blocksize (and hence the length of the padding) is specified by the
algorithm specification. This padding is not transmitted with the
packet.
3.2.4.3 Authentication Algorithms
The authentication algorithm employed for the ICV computation is
specified by the SA. For point-to-point communication, suitable
authentication algorithms include keyed Message Authentication Codes
(MACs) based on symmetric encryption algorithms (e.g., DES) or on
one-way hash functions (e.g., MD5 or SHA-1). For multicast
communication, one-way hash algorithms combined with asymmetric
signature algorithms are suitable. As of this writing, the
mandatory-to-implement authentication algorithms are based on the
former class, i.e., HMAC [KBC97] with SHA-1 [SHA] or HMAC with MD5
[Riv92]. The output of the HMAC computation is truncated to (the
leftmost) 96 bits. Other algorithms, possibly with different ICV
lengths, MAY be supported.
3.2.5 Fragmentation
If necessary, fragmentation is performed after ESP processing within
an IPsec implementation. However, an IP packet to which ESP has been
applied may itself be fragmented by routers en route, including
security gateways that may apply AH or ESP (tunnel mode) to the
already-protected packet or fragments.
3.3 Inbound Packet Processing
3.3.1 Pre-ESP Processing Overview
If required, reassembly is performed prior to ESP processing.
3.3.2 Security Association Lookup
Upon receipt of a (reassembled) packet containing an ESP Header, the
receiver determines the appropriate (unidirectional) SA, based on the
destination IP address and the SPI. (This process is described in
more detail in the document, "Security Architecture for the Internet
Protocol".) The SA indicates whether the Sequence Number,
Initialization Vector, and Authentication Data fields should be
present, and it will specify the algorithms and keys to be employed
for decryption and ICV computations (if applicable).
If no valid Security Association exists for this session (for
example, the receiver has no key), the receiver MUST discard the
Kent, Atkinson [Page 11]
Internet Draft IP Encapsulating 26 March 1997
Security Payload (ESP)
packet and the failure MUST be recorded in an audit log. The log
entry MUST include the SPI value, date/time, Source Address,
Destination Address, and (in IPv6) the cleartext Flow ID. The log
entry MAY also include other identifying data. There is no
requirement for the receiver to transmit any message to the purported
transmitter in response to receipt of such packets (because of the
potential to induce denial of service via such actions).
3.3.3 Anti-replay Service
If the anti-replay service has been selected for this SA, the
receiver MUST verify that the packet contains a Sequence Number value
that does not duplicate the Sequence Number of any other packet
received during the life of this SA. This SHOULD be the first AH
check applied to a packet after it has been matched to an SA, to
speed rejection of duplicate packets.
Duplicates are rejected through the use of a sliding receive window.
(How the window is implemented is a local matter, but the following
text describes the functionality that the implementation must
exhibit.) The default window size is 32 and all AH implementations
MUST support this window size. A larger window size MAY be
established during SA negotiation. If a larger window size is
negotiated it MUST be a multiple of 32.
The "right" edge of the window represents the highest, validated
Reply Protection value received on this SA. Packets that contain
Sequence Numbers lower than the "left" edge of the window are
rejected. Packets falling within the window are checked against a
list of received packets within the window. An efficient means for
performing this check, based on the use of a bit mask, is described
in [KA97a].
If the received packet falls within the window, then the receiver
proceeds to ICV verification. If the ICV validation fails, the
receiver MUST discard the received IP datagram as invalid and MUST
record the authentication failure in an audit log. If such a failure
occurs, the log entry MUST include the SPI value, date/time received,
Sending Address, Destination Address, and (in IPv6) Flow ID. The log
data MAY also include other information about the failed packet. The
window is updated only if the ICV verification succeeds.
DISCUSSION:
Note that if the packet is either inside the window and new, or
outside the window on the "right" side, the receiver MUST
authenticate the Sequence Number before updating the Sequence
Kent, Atkinson [Page 12]
Internet Draft IP Encapsulating 26 March 1997
Security Payload (ESP)
Number window data.
3.3.4 Integrity Check Value Verification
If authentication has been selected, the receiver computes the ICV
over the ESP packet minus the Authentication Data using the specified
authentication algorithm and verifies that it is the same as the ICV
included in the Authentication Data field of the packet. Details of
the computation are provided below.
If the computed and received ICV's match, then the datagram is valid,
and it is accepted. If the test fails, then the receiver MUST
discard the received IP datagram as invalid and MUST record the
authentication failure in an audit log. The log data MUST include the
SPI value, date/time received, Source Address, Destination Address,
and (in IPv6) the clear-text Flow ID. The log data MAY also include
other information about the failed packet.
DISCUSSION:
Begin by removing and saving the ICV value (Authentication Data
field). Next check the overall length of the ESP packet minus the
Authentication Data. If implicit padding is required, based on
the blocksize of the authentication algorithm, append zero-filled
bytes to the end of the ESP packet directly after the Next Header
field. Perform the ICV computation and compare the result with
the received value. (If a digital signature and one-way hash are
used for the ICV computation, the matching process is more complex
and will be described in the algorithm specification.)
3.3.5 Packet Decryption
If data confidentiality was selected, the receiver decrypts the ESP
Payload Data, Padding, Pad Length, and Next Header using the session
key that has been established for this traffic. If an explicit IV is
present, it is input to the decryption algorithm as per the algorithm
specification. If an implicit IV is employed, a local version of the
IV is constructed and input to the decryption algorithm as per the
algorithm specification. (Decryption may take place in parallel with
authentication, but care must be taken to avoid possible race
conditions with regard to packet access and reconstruction of the
decrypted packet.)
After decryption, the original IP datagram is reconstructed and
processed per the normal IP protocol specification. The exact steps
for reconstructing the original datagram depend on the mode (tunnel
Kent, Atkinson [Page 13]
Internet Draft IP Encapsulating 26 March 1997
Security Payload (ESP)
vs transport) and are described in the document, "Security
Architecture for the Internet Protocol."
Note that there are two ways in which the decryption can "fail". The
selected SA may not be correct or the encrypted ESP packet could be
corrupted. (The latter case would be detected if authentication is
selected for the SA, as would tampering with the SPI. However, an SA
mismatch might still occur due to tampering with the IP Destination
Address.) In either case, the erroneous result of the decryption
operation (an invalid IP datagram or transport-layer frame) will not
necessarily be detected by IPsec, and is the responsibility of later
protocol processing.
4. Conformance Requirements
Implementations that claim conformance or compliance with this
specification MUST implement the ESP syntax and processing described
here and MUST comply with all requirements of the "Security
Architecture for the Internet Protocol." Note that support for
manual key distribution is required, but its use is inconsistent with
anti-replay service, and thus a compliant implementation must not
negotiate this service in conjunction with SAs that are manually
keyed. A compliant ESP implementation MUST support the following
mandatory-to-implement algorithms (specified in [KBC97] and in [need
a new I-D with DES-CBC and implicit IV generation, but no overlap
with this document].
- DES in CBC mode
- HMAC with MD5
- HMAC with SHA-1
5. Security Considerations
Security is central to the design of this protocol, and this security
considerations permeate the specification. Additional security-
relevant aspects of using IPsec protocol are discussed in the
document, "Security Architecture for the Internet Protocol".
Acknowledgements
Many of the concepts embodied in this specification were derived from
or influenced by the US Government's SP3 security protocol, ISO/IEC's
NLSP, or from the proposed swIPe security protocol. [SDNS89, ISO92
IB93].
For over 2 years, this document has evolved through multiple versions
Kent, Atkinson [Page 14]
Internet Draft IP Encapsulating 26 March 1997
Security Payload (ESP)
and iterations. During this time, many people have contributed
significant ideas and energy to the process and the documents
themselves. The authors would like to thank the members of the IPSEC
and IPng working groups, with special mention of the efforts of (in
alphabetic order): Steve Bellovin, Steve Deering, Phil Karn, Perry
Metzger, David Mihelcic, Hilarie Orman, and William Simpson. In
addition, Charlie Lynn, Karen Seo, and Nina Yuan provided extensive
help in the review and editing of this version of the specification.
References
[Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP
Protocol Suite", ACM Computer Communications Review, Vol.
19, No. 2, March 1989.
[CERT95] Computer Emergency Response Team (CERT), "IP Spoofing
Attacks and Hijacked Terminal Connections", CA-95:01,
January 1995. Available via anonymous ftp from
info.cert.org.
[DH95] Steve Deering & Robert Hinden, Internet Protocol Version 6
(Ipv6) Specification, RFC 1883, December 1995.
[IB93] John Ioannidis & Matt Blaze, "Architecture and
Implementation of Network-layer Security Under Unix",
Proceedings of the USENIX Security Symposium, Santa Clara,
CA, October 1993.
[ISO92] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC
DIS 11577, International Standards Organisation, Geneva,
Switzerland, 29 November 1992.
[KBC97] Hugo Krawczyk, Mihir Bellare, and Ran Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC-2104,
February 1997.
[Ken91] Steve Kent, "US DoD Security Options for the Internet
Protocol (IPSO)", RFC-1108, November 1991.
[KA97a] Steve Kent, Randall Atkinson, "Security Architecture for
the Internet Protocol", Internet Draft, ?? 1997.
[KA97b] Steve Kent, Randall Atkinson, "IP Authentication Header",
Internet Draft, March 1997.
[MS95] Perry Metzger & W.A. Simpson, "The ESP DES-CBC Transform",
RFC-1829, August 1995.
Kent, Atkinson [Page 15]
Internet Draft IP Encapsulating 26 March 1997
Security Payload (ESP)
[NIST77] US National Bureau of Standards, "Data Encryption
Standard", Federal Information Processing Standard (FIPS)
Publication 46, January 1977.
[NIST80] US National Bureau of Standards, "DES Modes of Operation"
Federal Information Processing Standard (FIPS) Publication
81, December 1980.
[NIST81] US National Bureau of Standards, "Guidelines for
Implementing and Using the Data Encryption Standard",
Federal Information Processing Standard (FIPS) Publication
74, April 1981.
[NIST88] US National Bureau of Standards, "Data Encryption
Standard", Federal Information Processing Standard (FIPS)
Publication 46-1, January 1988.
[Riv92] Ronald Rivest, MD5 Digest Algorithm, RFC-1321, April 1992.
[SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995
[STD-2] J. Reynolds and J. Postel, "Assigned Numbers", STD-2, 20
October 1994.
[Sch94] Bruce Schneier, Applied Cryptography, John Wiley & Sons,
New York, NY, 1994. ISBN 0-471-59756-2
[SDNS89] SDNS Secure Data Network System, Security Protocol 3, SP3,
Document SDN.301, Revision 1.5, 15 May 1989, as published
in NIST Publication NIST-IR-90-4250, February 1990.
Kent, Atkinson [Page 16]
Internet Draft IP Encapsulating 26 March 1997
Security Payload (ESP)
Disclaimer
The views and specification here are those of the authors and are not
necessarily those of their employers. The authors and their
employers specifically disclaim responsibility for any problems
arising from correct or incorrect implementation or use of this
specification.
Author Information
Stephen Kent
BBN Corporation
70 Fawcett Street
Cambridge, MA 02140
USA
Telephone: +1 (617) 873-3988
Randall Atkinson <rja@inet.org>
@Home Network
385 Ravendale Drive
Mountain View, CA 94043
USA
Kent, Atkinson [Page 17]
--============_-1352627881==_============--
From owner-ipsec Thu Mar 27 17:43:03 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA01775 for ipsec-outgoing; Thu, 27 Mar 1997 17:41:49 -0500 (EST)
From: Dan.McDonald@Eng.sun.com (Dan McDonald)
Message-Id: <199703272247.OAA00326@kebe.eng.sun.com>
Subject: Re: new AH spec
To: kent@bbn.com (Stephen Kent)
Date: Thu, 27 Mar 1997 14:47:11 -0800 (PST)
Cc: ipsec@tis.com
In-Reply-To: <v0300780daf60874f2f7a@[128.89.0.110]> from "Stephen Kent" at Mar 27, 97 03:22:08 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I guess someone has to toss out the first feedback.
> IP Authentication Header
<SNIP!>
> 1. Introduction
<SNIP!>
Looks good so far. The bit about "piecemeal" might be a bit strong, but
that's really hairsplitting.
> 2. Authentication Header Format
<SNIP!>
> *** Do we want to retain a null authentication algorithm as part of the
> *** spec at this point? What purpose does it serve?
Mostly, the NULL authentication algorithm is used for testing of protocol
plumbing. I don't expect any shipping product to have a null authentication
algorithm. I do expect AH implementations that are in their nascent stages
to have a null authentication algorithm. Interpret this data as you will
w.r.t. how the spec should read.
> 2.4 Security Parameters Index (SPI)
<SNIP!>
> A value of zero indicates that no Security Association exists. The SPI
> field is mandatory. It is ordinarily selected by the destination
> system upon establishment of an SA (see "Security Architecture for
> the Internet Protocol" [KA97a] for more details).
>
> *** Under what circumstances will a zero SPI be employed? Is this
> *** still relevant or is it vestigial?
A zero SPI is useful for any number of implementation-specific aids. An
example I can think of off the top of my head is that if my
getassocybyendpoint() call for an outgoing datagram returns an association
with a zero SPI, I can interpret this as any number of results (including, "I
just kicked key management in the rear, I'll get back to you.")
> 2.5 Sequence Number
>
> This unsigned 32-bit field contains a monotonically increasing
> counter value (sequence number). The counter is initialized to 1
> when an SA is established. The sequence number must never be allowed
> to cycle; thus, it MUST be reset (by establishing a new SA and thus a
> new key) prior to the transmission of 2^32-1 packets on an SA. The
> Sequence Number field is optional. It is included only if the anti-
> replay service (a form of loose sequence integrity) is selected as a
> security service for the SA.
I know certain people who have issues about having this field NOT being
present. I don't have a problem with this, but I suspect the people who have
these issues will speak up.
See the newly issued HMAC-96 drafts for details.
> 3. Authentication Header Processing
>
> 3.1 Authentication Header Location
>
> Like ESP, AH may be employed in two ways: transport mode or tunnel
> mode. The former mode is applicable only to host implementations and
> provides protection for upper layer protocols, in addition to
> selected IP header fields. In this mode, AH is inserted after the IP
> header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc.
BTW, ESP is one of these upper-layer protocol fields. In fact, lemme return
to this upper-layer protocol idea in a bit.
<SNIP!>
> In the IPv6 context, AH is viewed as an end-to-end payload, and thus
> should appear after hop-by-hop, routing, and fragmentation extension
> headers. The destination options extension header(s) could appear
> either before or after the AH header depending on the semantics
> desired. The following diagram illustrates AH transport mode
> positioning for a typical IPv6 packet.
>
> BEFORE APPLYING AH
> ---------------------------------------
> IPv6 | | ext hdrs | | |
> | orig IP hdr |if present| TCP | Data |
> ---------------------------------------
>
> AFTER APPLYING AH
> ------------------------------------------------------------
> IPv6 | |hxh,rtg,frag| dest | | dest | | |
> |orig IP hdr |if present**| opt* | AH | opt* | TCP | Data |
> ------------------------------------------------------------
> |<-------------------- authenticated --------------------->|
> except for mutable fields
>
> * = if present, could be before AH, after AH, or both
> ** = hop by hop, routing, fragmentation headers
This isn't _quite_ accurate.
Destination options CAN appear before or after AH. But the semantic of
destination options is very precise. From RFC 1883...
IPv6 | Hop-by-Hop | Destination | Routing | Fragment....
If Destination options appear before AH, they appear before the routing
header. The semantics being that the destination options are parsed on each
hop specified in the routing header. This might be hairsplitting, but others
who are IPv6/IPsec implementors might get confused.
<SNIP!>
> The position of AH in tunnel mode, relative to the outer IP
> header, is the same as for AH in transport mode.
This sentence is more important than is apparent at first. An implementation
can look at the inner IP header as JUST ANOTHER UPPER LAYER. This helps
reduce some of the special-casing for IP as the inner payload. It doesn't
_ELIMINATE_ it, but it can reduce it.
(For example, if you have A->B with the inner IP saying A->B, you can make
stronger assertions than if the inner packet says something else.)
<SNIP!>
> 3.2 Outbound Packet Processing
>
> In transport mode, the transmitter inserts the AH header after the IP
> header and before an upper layer protocol header, as described above.
> In tunnel mode, the outer and inner IP header/extensions can be
> inter-related in a variety of ways. The construction of the outer IP
> header/extensions during the encapsulation process is described in
> the document, "Security Architecture for the Internet Protocol".
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Hmmm. I'm looking forward to this.
> 3.2.1 Security Association Lookup
>
> AH is applied to an outbound packet only after an IPsec
> implementation determines that the packet is associated with an SA
> that calls for AH processing. The process of determining what, if
> any, IPsec processing is applied to outbound traffic is described in
> the document, "Security Architecture for the Internet Protocol".
Once again, I'm looking forward to this.
As an aside, I'd strongly encourage to look at the current implementations
out there, as well as some of the analysis literature. I suspect you've
already done your homework on this front and will be drawing on their
experience when you finish rewhacking the architecture document.
> 3.2.2 Sequence Number Field
>
> If the anti-replay service has been selected for this SA, the
> transmitter increments the sequence number for this SA, checks to
> ensure that the counter has not cycled, and inserts the new value
> into the Sequence Number Field. A transmitter MUST not send a packet
> on an SA if doing so would cause the sequence number to cycle.
Do you have any recommendations for when the sequence number cycles? (Kick
key mgmt. in the pants, logging, tuning future SAs to expire sooner, etc.)
> 3.2.3 Integrity Check Value Calculation
>
> 3.2.3.1 Handling Mutable Fields
<SNIP!>
> 3.2.3.1.1 ICV Computation for IPv4
> *** What about OFFSET and FLAGS. Since reassembly takes place before
> *** AH processing why are these fields omitted from the ICV
> *** computation?
Except for perhaps DF, these FLAGS and OFFSET SHOULD be zero anyway after
reassembly! The question of DF is perhaps why the decision was made to just
zero out that bit too.
<SNIP!>
> 3.2.3.1.2 ICV Computation for IPv6
<SNIP!>
> *** Do we want to make any recommendation for what an AH implementation
> *** should do if it encounters an unfamiliar IPv6 extension header,
> *** e.g., Routing Header "Type 1" (aka Nimrod)?
IMHO, new IPv6 extensions should document their own AH properties. Keep in
mind this is IMHO only.
> 3.2.3.2 Padding
>
> 3.2.3.2.1 Authentication Data Padding
>
> As mentioned in section 2.6, the Authentication Data field explicitly
> includes padding to ensure that the AH header is a multiple of 32
> bits (IPv4) or 64 bits (IPv6). If padding is required, its length is
> determined by three factors:
> - the presence or absence of the Sequence Number field
> - the length of the ICV
> - the IP protocol context (v4 or v6)
>
> For example, if the Sequence Number field is present and a default,
> 96-bit truncated HMAC algorithm is selected, no padding is required
> for either IPv4 nor IPv6. In contrast, if the anti-replay service is
> not selected, and a default 96-bit truncated HMAC algorithm is
> selected, no padding is required for IPv4, but 4 bytes of padding are
> required for IPv6. The content of the padding field is arbitrarily
> selected by the sender. (The padding is arbitrary, but need not be
> random to achieve security.) These bytes are included in the
> Authentication Data calculation, counted as part of the Payload
> Length, and transmitted at the end of the Authentication Data field
> to enable the receiver to perform the ICV calculation.
Thank you! We in IPv6-land appreciate this.
<SNIP!>
> 3.2.3.3 Authentication Algorithms
>
> The authentication algorithm employed for the ICV computation is
> specified by the SA. For point-to-point communication, suitable
> authentication algorithms include keyed Message Authentication Codes
> (MACs) based on symmetric encryption algorithms (e.g., DES) or on
> one-way hash functions (e.g., MD5 or SHA-1). For multicast
> communication, one-way hash algorithms combined with asymmetric
> signature algorithms are suitable.
As an aside, has anyone tackled this? A lightweight digital signature
algorithm would be perfect in a multicast environment with a small number of
senders compared with an arbitrary number of receivers.
LARGE number of senders, however, requires Real Work (TM).
> As of this writing, the mandatory-to-implement authentication algorithms
> are based on the former class, i.e., HMAC [KBC97] with SHA-1 [SHA] or
> HMAC with MD5 [Riv92]. The output of the HMAC computation is truncated
> to (the leftmost) 96 bits. Other algorithms, possibly with different
> ICV lengths, MAY be supported.
Like I mentioned before, as currently written, these I-Ds _always_ include
the replay counter. The replay counter is set to 0 for associations that
don't use replay.
<SNIP!>
> 3.3 Inbound Packet Processing
<SNIP!>
> 3.3.3 Sequence Number Verification
>
> If the anti-replay service has been selected for this SA, the
> receiver MUST verify that the packet contains a Sequence Number that
> does not duplicate the Sequence Number of any other packets received
> during the life of this SA. This SHOULD be the first AH check
> applied to a packet after it has been matched to an SA, to speed
> rejection of duplicate packets.
Ummm, what if I live in a multithreaded world? I can theoretically get two
packets near-concurrently with the same sequence number. If the bogus one
arrives first, do I trash the good one just because one with the same replay
number arrived first? Or do I not count a sequence number as "good" until
I've authenticated? Or is this just an implementation detail? Or is this
why it says SHOULD rather than MUST?
<SNIP!>
> DISCUSSION:
>
> Note that if the packet is either inside the window and new, or
> outside the window on the "right" side, the receiver MUST
> authenticate the Sequence Number field before updating the bit
> mask (either turning on a bit or updating the "right" side of the
> window).
Ahhhh, I get it now. I left the questions in because this is how some might
think as they read it.
<SNIP!>
I guess that's it for pass one. As I see more things, I'll report them.
Dan
From owner-ipsec Thu Mar 27 17:52:28 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA01881 for ipsec-outgoing; Thu, 27 Mar 1997 17:52:23 -0500 (EST)
From: touch@isi.edu
Date: Thu, 27 Mar 1997 14:57:40 -0800
Posted-Date: Thu, 27 Mar 1997 14:57:40 -0800
Message-Id: <199703272257.AA18146@ash.isi.edu>
To: kent@bbn.com, Dan.McDonald@Eng.sun.com
Subject: Re: new AH spec
Cc: ipsec@tis.com
X-Auto-Sig-Adder-By: faber@isi.edu
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> From: Dan.McDonald@eng.sun.com (Dan McDonald)
> > 2.4 Security Parameters Index (SPI)
>
> > A value of zero indicates that no Security Association exists. The SPI
> > field is mandatory. It is ordinarily selected by the destination
> > system upon establishment of an SA (see "Security Architecture for
> > the Internet Protocol" [KA97a] for more details).
> >
> > *** Under what circumstances will a zero SPI be employed? Is this
> > *** still relevant or is it vestigial?
>
> A zero SPI is useful for any number of implementation-specific aids. An
> example I can think of off the top of my head is that if my
> getassocybyendpoint() call for an outgoing datagram returns an association
> with a zero SPI, I can interpret this as any number of results (including, "I
> just kicked key management in the rear, I'll get back to you.")
But under what circumstances would you set the SPI in the outgoing datagram
to zero - wouldn't you wait??
(I can't send it and hope to resolve it later - what if I have several
pending key mgt requests, then I can't distinguish which packets use
which associations later)
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/
From owner-ipsec Thu Mar 27 17:54:02 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA01896 for ipsec-outgoing; Thu, 27 Mar 1997 17:53:54 -0500 (EST)
From: Dan.McDonald@Eng.sun.com (Dan McDonald)
Message-Id: <199703272259.OAA00476@kebe.eng.sun.com>
Subject: Re: new AH spec
To: touch@isi.edu
Date: Thu, 27 Mar 1997 14:59:11 -0800 (PST)
Cc: kent@bbn.com, Dan.McDonald@Eng.sun.com, ipsec@tis.com
In-Reply-To: <199703272257.AA18146@ash.isi.edu> from "touch@ISI.EDU" at Mar 27, 97 02:57:40 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> But under what circumstances would you set the SPI in the outgoing datagram
> to zero - wouldn't you wait??
Oops, my bad. On the WIRE you'll NEVER see a zero SPI.
I was arguing that the value 0 should continue to be reserved.
Pardon the confusion, folks!
Dan
From owner-ipsec Thu Mar 27 18:29:52 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA02041 for ipsec-outgoing; Thu, 27 Mar 1997 18:29:07 -0500 (EST)
From: Dan.McDonald@Eng.sun.com (Dan McDonald)
Message-Id: <199703272334.PAA00564@kebe.eng.sun.com>
Subject: Re: new ESP spec (bigger message)
To: kent@bbn.com (Stephen Kent)
Date: Thu, 27 Mar 1997 15:34:28 -0800 (PST)
Cc: ipsec@tis.com
In-Reply-To: <v0300780eaf6087753872@[128.89.0.110]> from "Stephen Kent" at Mar 27, 97 03:22:38 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Note that many of my questions were covered in AH already.
> IP Encapsulating Security Payload (ESP)
<SNIP!>
> 2. Encapsulating Security Payload Packet Format
<SNIP!>
> 2.1 Security Parameters Index
> 2.4 Payload Data
>
> Payload Data is a variable-length field containing data described by
> the Next Header field. This field is an integral number of bytes in
> length. The Payload Data field is mandatory.
>
> ***We have a potential IPv6 alignment problem here, that may have
> ***been present for some time. Ignoring the presence or absence of an
> ***iv, the payload data will not be aligned on an 8-byte boundary if
> ***the Sequence Number is omitted. This may cause a problem for
> ***efficient crypto data transfer. If the IV is present, and the
> ***Sequence Number is omitted, the same problem arises, starting with
> ***the IV, unless the IV is of a compensating size. The decryption
> ***process can fix the problem for higher layer protocols, because the
> ***output buffer from decryption is usually distinct from the input
> ***buffer, but that still causes potential problems for transfer of
> ***data to the crypto module. Also, if encryption is not employed,
> ***this becomes a potential problem for authentication data being
> ***passed up. We could solve this by adding an optional alignment
> ***field to the ESP header, when required for IPv6. What do people think?
This isn't a real problem for IPv6. The reason for the 8-byte alignment
drive in IPv6 was to make fast-path processing faster. (Those of us with
UltraSPARC appreciate this.) Since ESP is already beating down the slow
path, this isn't as huge of a deal as one might think at first. Also, a
properly formed IPv6 datagram will be 8-byte aligned once you strip out the
ESP cruft after decryption.
There's always crypto-algorithm alignment issues, but I leave those to the
crypto wizards.
> 3. Encapsulating Security Protocol Processing
See my previous note about IPv6 destination option semantics, tunnel-mode
not being all that different, and outbound SA selection.
<SNIP!>
> 3.2.3 Packet Encryption
>
> 3.2.3.1 Scope of Encryption
>
> In transport mode, if encryption has been selected, the transmitter
> encapsulates the original upper layer protocol information into the
> ESP payload field, adds any necessary padding, and encrypts the
> result (Payload Data, Padding, Pad Length, and Next Header) using the
> key, encryption algorithm, and algorithm mode indicated by the SA.
> In tunnel mode, the transmitter encapsulates and encrypts the the
> entire original IP datagram (plus the Padding, Pad Length, and Next
> Header).
>
> If both encryption and authentication have been selected, encryption
> is performed first, before the authentication and the encryption does
> not encompass the Authentication Data field. This order of
> processing facilitates rapid detection and rejection of replayed or
> bogus packets by the receiver, prior to decrypting the packet, hence
> potentially reducing the impact of denial of service attacks. It
> also allows for the possibility of parallel processing of packets at
> the receiver, i.e., decryption can take place in parallel with
> authentication. Note that since the Authentication Data is not
> protected by encryption, a keyed authentication algorithm must be
> employed to compute the ICV.
You've seen my comments on this (reversing the order of authentication and
encryption) already.
<SNIP!>
> 3.2.4.3 Authentication Algorithms
>
> The authentication algorithm employed for the ICV computation is
> specified by the SA. For point-to-point communication, suitable
> authentication algorithms include keyed Message Authentication Codes
> (MACs) based on symmetric encryption algorithms (e.g., DES) or on
> one-way hash functions (e.g., MD5 or SHA-1). For multicast
> communication, one-way hash algorithms combined with asymmetric
> signature algorithms are suitable. As of this writing, the
> mandatory-to-implement authentication algorithms are based on the
> former class, i.e., HMAC [KBC97] with SHA-1 [SHA] or HMAC with MD5
> [Riv92]. The output of the HMAC computation is truncated to (the
> leftmost) 96 bits. Other algorithms, possibly with different ICV
> lengths, MAY be supported.
Is the HMAC trunctated for use in ESP?!? I hadn't heard any movement to do
so, but I sometimes miss these things.
<SNIP!>
> 3.3 Inbound Packet Processing
<SNIP!>
You've seen some comments about things in here in the AH comments.
> 3.3.5 Packet Decryption
>
> If data confidentiality was selected, the receiver decrypts the ESP
> Payload Data, Padding, Pad Length, and Next Header using the session
> key that has been established for this traffic. If an explicit IV is
> present, it is input to the decryption algorithm as per the algorithm
> specification. If an implicit IV is employed, a local version of the
> IV is constructed and input to the decryption algorithm as per the
> algorithm specification. (Decryption may take place in parallel with
> authentication, but care must be taken to avoid possible race
> conditions with regard to packet access and reconstruction of the
> decrypted packet.)
>
> After decryption, the original IP datagram is reconstructed and
> processed per the normal IP protocol specification. The exact steps
> for reconstructing the original datagram depend on the mode (tunnel
> vs transport) and are described in the document, "Security
> Architecture for the Internet Protocol."
Ahh, the stripping of the ESP cruft I was talking about before... :)
That's it for this one,
Dan
From owner-ipsec Thu Mar 27 22:19:23 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA03208 for ipsec-outgoing; Thu, 27 Mar 1997 22:18:12 -0500 (EST)
Message-Id: <199703280320.WAA04052@relay.hq.tis.com>
Date: Thu, 27 Mar 97 22:21:16 EST
From: Charles Lynn <clynn@bbn.com>
To: ipsec@tis.com
cc: Dan McDonald <Dan.McDonald@Eng.sun.com>
Subject: Re: new AH spec
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Dan,
> This isn't _quite_ accurate.
>
> Destination options CAN appear before or after AH. But the semantic of
> destination options is very precise. From RFC 1883...
>
> IPv6 | Hop-by-Hop | Destination | Routing | Fragment....
>
> If Destination options appear before AH, they appear before the routing
> header. The semantics being that the destination options are parsed on each
> hop specified in the routing header. This might be hairsplitting, but others
> who are IPv6/IPsec implementors might get confused.
>From RFC 1883:
< IPv6|Hop-by-Hop|Destination|Routing|Fragment|AH|ESP|Destination|ULP
When Destination options appear before the Routing Header, they are
processed at each cluster contained in the Routing Header (including
the final destination), as described. When they appear after any AH
or ESP, they are only processed by the final destination after the AH
and/or ESP processing.
The text in the draft is pointing out an extensibility issue. It is
often hard to foresee what evolution may happen in the future. Some
option, which may be defined in the future, may have an effect that
alters how the AH or ESP is to be processed by the final destination.
Such an option could not appear before the Routing Header (as it
should not be processed at each cluster), and could not appear after
the AH and/or ESP as that would be too late to have the intended
effect.
For example, there is a Destination option that effectively alters the
"source" and "destination" "addresses" which are to be use further up
the protocol stack, e.g., as used in TCP or UDP "pseudo headers". As
currently defined, the SPI is relative to the "destination address".
There is no restriction on how an implementor must manage the SPI
number space. I.e., an implementor may have a single SPI space per
box, or may have one per interface, or even separate spaces for link
addresses and global addresses, etc., and then there is multihoming,
and the idea of having border routers rewriting addresses of packets
that pass through them. There are many issues to be worked out
(hopefully we can get the spec out before they are all resolved :-).
Lets not write extra code to eliminate flexibility that we might find
we want further down the road.
Charlie
From owner-ipsec Thu Mar 27 22:58:34 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA03379 for ipsec-outgoing; Thu, 27 Mar 1997 22:58:18 -0500 (EST)
Message-Id: <199703280400.XAA04513@relay.hq.tis.com>
Date: Thu, 27 Mar 97 23:01:11 EST
From: Charles Lynn <clynn@bbn.com>
To: ipsec@tis.com
cc: Dan McDonald <Dan.McDonald@Eng.sun.com>
Subject: Re: new ESP spec (bigger message)
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Dan,
+=========+ > > ***We have a potential IPv6 alignment problem
| ver ... | > > here, that may have
| ESP | ...
| src ... | >
| | > This isn't a real problem for IPv6. The reason
| | > for the 8-byte alignment drive in IPv6 was to make
| | > fast-path processing faster. (Those of us with
| dst ... | > UltraSPARC appreciate this.) Since ESP is already
| | > beating down the slow path, this isn't as huge of
| | > a deal as one might think at first. Also, a
| | > properly formed IPv6 datagram will be 8-byte
+=========+ > aligned once you strip out the ESP cruft after
| SPI | > decryption.
| IV ... |
| | I was under the impression that the 8-byte alignment
+---------+ drive was to make processing not incur a lot of
| ver ... | address alignment faults when processing IPv6
| TCP | packets. I also heard a desire that IPsec be
| src ... | "friendly" to both hardware and software based
| | algorithms. If one uses a software algorithm that
| | decrypts in place, and have an IPv6 packet that
| | begins as shown to the left, then the tunneled IPv6
| dst ... | header, etc., is not aligned, relative to the outer
| | one.
| |
| | One argument for not needing alignment is that
+---------+ decryption in place won't be common, as a hardware
| TCP Hdr | decryption will "copy" the packet and can be made to
| Data | do realignment in the process.
| +----+
| |n|IP| Another is that IPv6 header alignment on 64-bit
+----+----+ boundaries is not a "requirement", just a "guide
line".
I do not see any justification why AH and ESP should differ in their
requirements to preserve alignment across their headers.
Comments anyone?
Charlie
From owner-ipsec Fri Mar 28 13:03:18 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA07923 for ipsec-outgoing; Fri, 28 Mar 1997 13:00:35 -0500 (EST)
Message-Id: <3.0.32.19970328100436.00925300@earthlink.net>
X-Sender: rmonsour@earthlink.net
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 28 Mar 1997 10:04:37 -0800
To: ipsec@tis.com
From: Bob Monsour <rmonsour@earthlink.net>
Subject: Internet Draft on compression
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
All,
The attached draft was submitted on Wednesday. Since there is a delay
between draft submission and draft annoucement, I wanted to get this in
front of the group so you would have enough time to review it. Please feel
free to provide comments prior to Memphis.
Regards,
-Bob
Internet Draft March 1997 (Expires September 1997)
R. Monsour, Hi/fn Inc.
M. Sabin, Consultant
A. Shacham, Cisco Systems
S. Anand, Microsoft Corporation
R. Thayer, Sable Technology
Compression in IP Security
<draft-monsour-compr-ipsec-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
This draft is intended provide input to the IP Security working
group as it sorts through the debate regarding the incorporation of
lossless data compression into the IP Security architecture.
Comments about this draft should be submitted to the authors or to
the IPSEC mailing list (ipsec@tis.com).
Abstract
This memo discusses the application of lossless compression
technology to the IP Security Architecture [IPSecArch].
Over the last few several months, a number of lively debates
on this topic have been held on IPSec mailing list. This memo
discusses the issues raised, the alternatives available to
resolve them and provides a set of recommendations to bring
resolution to the issue.
The goals of the draft are to: (1) define the problem solved by the
use of compression in the context of IPSec, (2) review the use of
compression and security technologies as they have been applied
in other layers of the protocol stack, (3) outline a set of
Monsour, et al [Page 1]
INTERNET DRAFT Compression in IP Security March 1996
requirements for applying compression to IPSec, (4) discuss
alternative methods which can be implemented to meet the
requirements, and (4) propose a set of recommendations for
consideration by the working group.
Acknowledgments
The authors wish to acknowledge the many contributors to the
compression debate on the IPSec mailing list. In addition, the
concept of compressing prior to encrypting data is drawn from
several prior sources, including Rodney Thayer's draft
[Thayer], the ECP/CCP protocols under PPP and the TLS protocol
(better known as SSL).
Table of Contents
1. Introduction
2. Compression in IPSec - Problem Definition
3. Review of Other Protocols Using Compression and/or Security
3.1 Overview
3.2 The Encryption Control Protocol (ECP)
3.3 Transport Layer Security (TLS)
3.4 Application Layer Security
4. Does Compression Fall Within the Scope of the Working Group?
5. Requirements for Applying Compression to IPSec
5.1 Negotiated Algorithm
5.2 Stateless AND Stateful Compression
5.3 Compressed Packet Indicator
5.4 Compatibility with Existing and Emerging Implementations
5.5 Optional Use of Compression
5.6 Ability to Optimize Compression Across Protocol Layers
5.7 Anti-Expansion of Payload Data
6. Alternative Approaches to the Use of Compression in IPSec
6.1 Layered Architecture Using a Separate Compression Header
6.2 Optional Feature of ESP
6.3 Comparison of the Two Approaches
7. Which Approach Meets the Proposed Requirements?
7.1 Negotiated Algorithm
7.2 Stateless AND Stateful Compression
7.3 Compressed Packet Indicator
7.4 Compatibility with Existing and Emerging Implementations
7.5 Optional Use of Compression
7.6 Ability to Optimize Compression Across Protocol Layers
7.7 Anti-Expansion of Payload Data
8. Conclusions
9. Recommendations
10. Security Considerations
11. References
12. Authors' Addresses
Monsour, et al [Page 2]
INTERNET DRAFT Compression in IP Security March 1996
1. Introduction
Encrypted data is random in nature and not compressible. When an IP
datagram is encrypted, compression methods used at lower protocol
layers -- e.g., the PPP Compression Control Protocol [RFC1962] --
no longer work. If both compression and encryption are desired,
compression must be performed first.
The IPSec working group of the IETF has been debating the topic
of incorporating lossless data compression into the IPSec
architecture for the past several months. In fact, the initial
introduction of the topic goes as far back as 1994, when Jim
Hughes of Network Systems presented the idea at the San Jose
meeting of the IPSec working group [Dec96WG].
Following that initial presentation, Network Systems, as well
as a handful of other companies have implemented proprietary
methods for compressing IP datagrams prior to encrypting them.
This memo takes that work, and analyzes similar work done in other
security protocols, and proposes a negotiable, interoperable
method for applying lossless data compression to the IPSec
protocol.
The first compression-related drafts were developed in 1996 and
three of those drafts were discussed at the December 1996 IPSec
working group meeting in San Jose [Thayer][Sabin1][Sabin2].
2. Compression in IPSec - Problem Definition
The widespread use of the internet has resulted in equally
widespread use of point-to-point (PPP) connections between hosts as
well as between routers. Lossless compression technology has
been deployed in the PPP environment in the form of a sub-protocol
known as the Compression Control Protocol (CCP). PPP is a
connection-oriented protocol. Many lossless compression technologies
have the capability to retain state across each "packet" of data
that is compressed. Hence, in a connection-oriented protocol such as
PPP, compression can be applied to the continuing stream of
"packets". The principal advantage to such a stateful mechanism is
a higher compression ratio.
Another important aspect of the CCP is the negotiability of the
compression algorithm for each PPP connection.
Today, PPP is the predominant method for end-user hosts to connect
to the internet. Compression in CCP provides end users with
significant improvements in bandwidth utilization.
In a different environment, today's routers that support connections
in the T1 range AND use lossless compression technology, provide
great economic value to their users. For example, a corporate user
Monsour, et al [Page 3]
INTERNET DRAFT Compression in IP Security March 1996
employing a leased T1 line can save thousands of dollars per
month in line charges through the use of compression technology.
The use of encryption technologies at protocol layers higher than
the data-link/PPP layer, renders PPP compression ineffective. With
the strong demand for secure communications, encryption is
actively being deployed at various layers in the protocol stack to
meet the security requirements of various environments. The is the
core problem which has driven the compression debate in the IPSec
working group.
3. Review of Other Protocols Using Compression and/or Security
This section provides an overview of several examples of other
protocols and applications involving the use of lossless compression
technology. Some of the protocols described use compression in
conjunction with encryption.
3.1 Overview
The diagram below depicts the OSI reference model for data
communications protocol layers along with various internet
protocols and/or products which incorporate the use of
compression and/or security capabilities.
These are just a few examples of the technologies being
deployed to meet the security and bandwidth requirements of
various classes of users and systems.
Protocols
and/or
Protocol Layers Products Compression Security
------------------ ----------- ------------- ------------
+----------------+
| Application | PGPmail yes yes
|----------------|
| Presentation | HTTPv1.1* yes no
|----------------|
| Session | TLS/SSL yes yes
|----------------|
| Transport | TCP** no no
|----------------|
| Network | IPSec no yes
|----------------|
| Data Link | PPP/CCP/ECP yes yes
|----------------|
| Physical | link encryptors no yes
+----------------+ link compressors yes no
*[RFC2068]
Monsour, et al [Page 4]
INTERNET DRAFT Compression in IP Security March 1996
**Note: There is discussion within the IETF of taking up work
in this area.
3.2 The Encryption Control Protocol (ECP)
At the same time that the Compression Control Protocol was defined, a
sister protocol, the Encryption Control Protocol (ECP) [RFC1968], was
defined. In the ECP protocol, it is clearly noted that if
compression has been negotiated for a connection, compression must be
performed prior to encryption. As far as the authors can tell at
this time, the ECP has not been widely deployed. However, it should
also be noted that the PPP Extensions working group [PPPEXT] is
currently working on additional security protocols in the areas of
authentication and public key technologies.
3.3 Transport Layer Security (TLS)
TLS [TLS] (formerly/better known as SSL, the Secure Socket Layer)
is a security protocol originally defined and implemented by
Netscape Communications Corporation. In the initial draft of
TLS 1.0, the use of compression is defined as an optional data
transformation which can be used prior to encryption for each
packet.
In TLS, the selection of compression algorithm is a negotiated
property of the session. Since TLS is a connection-oriented
protocol, compression state can be maintained from one packet
to the next, thereby improving compression ratio.
3.4 Application Layer Security
There are several examples of application layer security. Clearly,
any application which has requirements for confidentiality in its
data flow can implement encryption technology to meet such a
security requirement. One example of this is an email application.
A secure email client is capable of encrypting messages sent from
one host to another. PGPmail [PGPMan], a security add-on to many
popular email client products, is one such example. PGPmail
provides the capability to compress mail prior to encrypting it.
No doubt, this is due to the realization of its developers that
subsequent attempts to compress the data at lower layers in the
protocol stack will be rendered ineffective.
4. Does Compression Fall Within the Scope of the Working Group?
There are several issues which surround the question of whether
the IPSec working group should directly consider the issue of
applying compression to the IPSec protocols.
The IPSec working group charter specifically states:
Monsour, et al [Page 5]
INTERNET DRAFT Compression in IP Security March 1996
A security protocol in the network layer will be developed to
provide cryptographic security services that will flexibly
support combinations of authentication, integrity, access
control, and confidentiality.
The protocol formats for the IP Authentication Header (AH)
and IP Encapsulating Security Payload (ESP) will be independent
of the cryptographic algorithm. The preliminary goals will
specifically pursue host-to-host security followed by subnet-to-
subnet and host-to-subnet topologies.
Protocol and cryptographic techniques will also be developed
to support the key management requirements of the network
layer security. The Internet Key Management Protocol (IKMP)
will be specified as an application layer protocol that is
independent of the lower layer security protocol.
The problem definition in section 2 describes the "problem"
in terms of the affect of IPSec on a lower-layer protocol. While
this is indeed true, it is unclear whether the obligation to
provide the detailed protocol "fix" to correct the problem lies
within the scope of the IPSec working group.
While progress is being made, it is also true that the IPSec
specifications have been not been stable and available in a
manner to support widespread interoperable implementations
(as has been noted by various members of the working group).
The user community has indicated their requirement that
compression capabilities be "supported" by IPSec implementations.
The specific methods used to provide such support are clearly
in the scope of the working group to decide.
There is currently discussion underway (within the IETF) to
explore the application of compression in TCP. This raises a
question regarding the potential to provide a consistent
mechanism for supporting compression across these two closely-
related protocols (TCP & IP).
5. Requirements for Applying Compression to IPSec
As noted earlier, the use of encryption at any protocol layer above
the data link layer renders PPP compression ineffective. This leads
to the need to support the use of compression in the context of
IPSec. The question then becomes one of how to provide this
support.
An understanding of the problem, the approaches taken in other
protocol environments, the emerging discussion of compression
support in TCP, and the discussions on the mailing list lead to
the definition of the following requirements for the technical
Monsour, et al [Page 6]
INTERNET DRAFT Compression in IP Security March 1996
approaches to support compression in IPSec.
5.1 Negotiated Algorithm
Regardless of the protocol for which compression support is
provided, a method is required for the two communicating
parties to negotiate both the use and the type of compression
to be applied to the packets.
5.2 Stateless AND Stateful Compression
Since IP is a connectionless/stateless protocol, it is important
that each compressed packet be capable of being decompressed
independently of any other packet; i.e., the successful
decompression of a packet must not depend on the contents of any
other packet(s), nor should it depend on order of receipt of any
other packet(s).
The development of a consistent approach to providing compression
capabilities to both IPSec and TCP should support the use
of stateful compression in the TCP context. TCP's connection
orientation can guarantee packet ordering and thus achieve
higher compression ratios.
5.3 Compressed Packet Indicator
Once the use of compression is negotiated between two
communicating parties, the sender must have the flexibility
to determine whether or not to compress each packet. Such
flexibility requires a per-packet indication of whether or
not the packet is compressed.
5.4 Compatibility with Existing and Emerging Implementations
Changes to the IPSec protocol definitions to support compression
must not not break any existing implementation. This means
that for an implementation to be compression-capable, it will
have to be modified, but it will remain compliant with the IPSec
protocols without the addition of compression support. This
requirement becomes more desirable with the passage of time, as
more and more implementations are developed and deployed.
5.5 Optional Use of Compression
This requirement derives from the previous requirement. If
an existing implementation is to be considered compliant
with the IPSec protocol, then it MUST NOT be required to
provide support for compression.
Monsour, et al [Page 7]
INTERNET DRAFT Compression in IP Security March 1996
5.6 Ability to Optimize Compression Across Protocol Layers
The use of compression at several layers in the protocol stack
can cause inefficiencies in the processing by sending systems.
For example, in an environment where application layer
compression is in use, it is desirable to communicate to the
lower layer protocols that the data is already compressed and
that the lower layers need not attempt to compress (read as
"waste cycles"). Thus, support for compression in IPSec shall
be provide the capability for "turning compression on or off"
through some mechanism of inter-layer communication.
5.7 Anti-Expansion of Payload Data
It is not possible in all instances to pre-determine if a payload
has already been compressed at a higher layer. Future protocol
changes could support such a pre-determination. Until then,
a mechanism for detecting the expansion of data and optionally
sending the original uncompressed payload is required.
6. Alternative Approaches to the Use of Compression in IPSec
Two general technical approaches to meet the requirements
outlined in previous section have been presented to the working
group and subsequently debated on the mailing list. These two
approaches are described below along with their relative
advantages and disadvantages.
6.1 Layered Architecture Using a Separate Compression Header
This approach involves the use of a separate compression header
which would follow the IP header and precede the AH and/or ESP
header(s). The header would provide all the fields necessary
to support compression of either AH and/or ESP payloads as
well as support for compression in TCP.
6.2 Optional Feature of ESP
This approach is based on the fact that it is the encryption
of ESP payloads which renders downstream compression techniques
ineffective. This approach is limited to only compressing
ESP payloads and does not extend naturally to any upper layer
protocols.
6.3 Comparison of the Two Approaches
Below is a comparison of the advantages and disadvantages of the
two approaches.
Monsour, et al [Page 8]
INTERNET DRAFT Compression in IP Security March 1996
Advantages Disadvantages
-----------------------------------------------------------------
Layered not tied to use some delay in getting
Architecture of encryption; i.e., to a standard
works with AH payloads
as well
can be applied to
upper layer protocols
such as TCP in addition
to IPSec
routers can more easily
determine if a packet
is compressed without
knowledge of IPSec
protocol details
Optional Easily defined due to doesn't map well for
Feature its limited scope use in upper layer protocols
of ESP
tied to use of security
protocols
requires routers to know
IPSec to avoid compression
processing overhead
7. Which Approach Meets the Proposed Requirements?
This section describes how the two approaches described in
the previous section meet each of the requirements defined
in section 5.
7.1 Negotiated Algorithm
Both approaches meet this requirement. ISAKMP provides a
method for algorithm negotiation which can easily be extended
to support the negotiation of the use and type of compression.
In the TCP context, TCP negotiation would be extended to
negotiate the use and type of compression.
7.2 Stateless AND Stateful Compression
IPSec compression MUST be stateless. Both approaches support
this concept.
TCP, as a connection-oriented protocol, can support stateful
compression and achieve higher compression ratios as a result.
The use of the layered architecture approach makes stateful
TCP compression possible.
Monsour, et al [Page 9]
INTERNET DRAFT Compression in IP Security March 1996
7.3 Compressed Packet Indicator
In the layered architecture approach, the compression header
would contain a field to indicate whether or not the packet
is compressed.
In the ESP option approach, the most-significant bit of the
pad length field has been proposed to serve this function.
7.4 Compatibility with Existing and Emerging Implementations
Since compression is a negotiated option in both approaches,
they both meet this requirement. Existing implementations
will not negotiate to use compression and will continue to
interoperate with new and existing IPSec compliant implementations.
7.6 Ability to Optimize Compression Across Protocol Layers
The layered architecture approach meets this requirement.
The ESP option approach sacrifices the opportunity to develop
a single method for compressing across IP and TCP layer protocol.
7.7 Anti-Expansion of Payload Data
Both approaches can meet this requirement.
8. Conclusions
The authors have drawn the following conclusions based on
discussions with user community members, analysis of the
proposed technical approaches, and the emerging need to
broaden the use of compression beyond the IPSec context.
- The need for compression in the IPSec context exists.
The effect of IPSec encryption on downstream compression
and the demands by members of the user community demonstrate
a clear need for supporting compression in an IPSec context.
- The compression topic does not distinctly fall in the
charter of the IPSec working group.
- A layered architecture approach is a superior approach when
compared to the ESP option approach to problem of providing
compression capabilities in the IPSec context.
9. Recommendations
The authors recommend the following course of action.
Monsour, et al [Page 10]
INTERNET DRAFT Compression in IP Security March 1996
- Document the IPSec Architecture to Support Optional Compression
It is important that the IPSec architecture specification
include the notion that payload data of IPSec payloads may
optionally be compressed. The draft should note that the
specification for providing such compression capabilities
will be developed outside of the IPSec working group.
- Develop a Layered Architecture Approach to Compression
A layered architecture approach, when considered against
the ESP option approach has significant advantages which
outweigh any potential delays in specification development
and subsequent deployment.
- Establish a compression working group
This group would take on the responsibility for defining
a the layered architecture and the separate compression
header for use in IPSec as well as other candidate upper
layer protocols.
The rationale for this recommendation is based on several
factors, including (1) the user community as well as the
vendor community are under pressure to finalize the IPSec
specifications, complete development and begin deployment
of IPSec-compliant products. As Hugo put in a recent post
to the list, "...further delay of ipsec deployment (which
is also a form of denial-of-service attack :)", (2) the
desire to support compression in a context broader than
IPSec alone (i.e., TCP or other candidate protocols), and
10. Security Considerations
This memo discusses the use of lossless compression technology
in a security protocol, specifically IPSec. The proposed use
of compression within this protocol is not believed to have an
effect on the underlying security functionality provide by the
protocol; i.e., the use of compression is not known to degrade
or alter the nature of the underlying security architecture or
the encryption technologies used to implement it.
The use of compression does change the length of ESP payloads, in a
manner that depends on the data prior to encryption. Thus, the use
of compression may have an effect on the ability of an eavesdropper
to glean information by analyzing the length of transmitted packets.
11. References
[IPSecArch] Atkinson, R., "Security Architecture for the Internet
Protocol," November 1996.
Monsour, et al [Page 11]
INTERNET DRAFT Compression in IP Security March 1996
[Dec96WG] Lambert, P., Minutes of the IPSec Working Group, San Jose
December 1994.
[Thayer] Thayer, R., "Compression Header for IPSec",
draft-thayer-seccomp-00.txt, May, 1996.
[Sabin1] Sabin, M., Monsour R., "
[Sabin2] Sabin, M., Monsour R., "
[RFC1962] Rand, D., "The PPP Compression Control Protocol (CCP),"
RFC-1962, June 1996.
[RFC2068] ????, "Hypertext Transport Protocol version 1.1",
January, 1997.
[RFC1968] ????, "The PPP Encryption Control Protocol (ECP)",
June 1996.
[PPPEXT] Point-to-Point Protocol Extensions Working Group Charter.
[TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0",
draft-ietf-tls-protocol-01.txt, March 1997.
[PGPMan] ????, "PGPmail Reference Manual"
[AH] Atkinson, R., "IP Authentication Header"
[ESP] Atkinson, R., "IP Encapsulating Security Payload,"
June 1996.
[DOI] Piper, D., "IPSec Domain of Interpretation", March 1997.
[Calgary] Text Compression Corpus, University of Calgary, available
at
ftp://ftp.cpsc.ucalgary.ca/pub/projects/text.compression.corpus.
8. Authors' Addresses
Robert Monsour
Hi/fn Inc.
12636 High Bluff Drive
San Diego, CA 92130
Email: rmonsour@hifn.com
Michael Sabin
883 Mango Avenue
Sunnyvale, CA 94087
Email: mike.sabin@worldnet.att.net
Monsour, et al [Page 12]
INTERNET DRAFT Compression in IP Security March 1996
Abraham Shacham
Cisco Systems
101 Cooper Street
Santa Cruz, CA 95060
Email: shacham@cisco.com
Sanjay Anand
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
Email: sanjayan@microsoft.com
Rodney Thayer
Sable Technology
246 Walnut Street
Newton, MA 02160
Email: rodney@sabletech.com
Monsour, et al [Page 13]
From owner-ipsec Fri Mar 28 13:42:38 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08361 for ipsec-outgoing; Fri, 28 Mar 1997 13:42:19 -0500 (EST)
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <v03007805af61bfa67d0b@[128.89.30.17]>
In-Reply-To: <199703272334.PAA00564@kebe.eng.sun.com>
References: <v0300780eaf6087753872@[128.89.0.110]> from "Stephen Kent" at
Mar 27, 97 03:22:38 pm
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 28 Mar 1997 13:47:06 -0500
To: Dan.McDonald@Eng.sun.com (Dan McDonald)
From: Stephen Kent <kent@bbn.com>
Subject: Re: new ESP spec (bigger message)
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Dan,
>> 2.4 Payload Data
<SNIP! SNIP!>
>This isn't a real problem for IPv6. The reason for the 8-byte alignment
>drive in IPv6 was to make fast-path processing faster. (Those of us with
>UltraSPARC appreciate this.) Since ESP is already beating down the slow
>path, this isn't as huge of a deal as one might think at first. Also, a
>properly formed IPv6 datagram will be 8-byte aligned once you strip out the
>ESP cruft after decryption.
>
>There's always crypto-algorithm alignment issues, but I leave those to the
>crypto wizards.
Good to hear that view from an IPv6 perspective, but we are crypto people too!
>> 3.2.4.3 Authentication Algorithms
<SNIP! SNIP!>
>Is the HMAC trunctated for use in ESP?!? I hadn't heard any movement to do
>so, but I sometimes miss these things.
We were going for consistency here. There's no reason to believe that if
96 bits is good enough for authentication/integrity in AH that it isn't
good enough for the same services in ESP.
Steve
From owner-ipsec Fri Mar 28 13:44:54 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08381 for ipsec-outgoing; Fri, 28 Mar 1997 13:44:50 -0500 (EST)
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <v03007803af61b93c1578@[128.89.30.17]>
In-Reply-To: <199703272247.OAA00326@kebe.eng.sun.com>
References: <v0300780daf60874f2f7a@[128.89.0.110]> from "Stephen Kent" at
Mar 27, 97 03:22:08 pm
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 28 Mar 1997 13:47:45 -0500
To: Dan.McDonald@Eng.sun.com (Dan McDonald)
From: Stephen Kent <kent@bbn.com>
Subject: Re: new AH spec
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Dan,
<SNIP! SNIP!>
>Looks good so far. The bit about "piecemeal" might be a bit strong, but
>that's really hairsplitting.
I'm not trying to be negative, just accurate in my description of the way
in which Ah is computed over portions of the IP header, zero-filling
others, etc.
<SNIP! SNIP!>
>Mostly, the NULL authentication algorithm is used for testing of protocol
>plumbing. I don't expect any shipping product to have a null authentication
>algorithm. I do expect AH implementations that are in their nascent stages
>to have a null authentication algorithm. Interpret this data as you will
>w.r.t. how the spec should read.
I think if NULL is used only for testing, it would be better not to have it
as a cited transform/algorithm.
<SNIP! SNIP!>
>A zero SPI is useful for any number of implementation-specific aids. An
>example I can think of off the top of my head is that if my
>getassocybyendpoint() call for an outgoing datagram returns an association
>with a zero SPI, I can interpret this as any number of results (including, "I
>just kicked key management in the rear, I'll get back to you.")
As above, if a zero SPI will never appear on the wire (fiber?), I'd rather
not specify it here. What you describe is a local interface matter.
<SNIP! SNIP!>
>I know certain people who have issues about having this field NOT being
>present. I don't have a problem with this, but I suspect the people who have
>these issues will speak up.
Yes, documents have clearly diverged re the presence or absence of this
field and I'm going with the interpretation we adopted for ESP, i.e., if
the servuce is not negotiated, the field is absent.
<SNIP! SNIP!>
>BTW, ESP is one of these upper-layer protocol fields. In fact, lemme return
>to this upper-layer protocol idea in a bit.
Yep! We'll add ESP as an obvious additional example.
<SNIP! SNIP!>
I'll leave the resolution of IPv6 header element ordering to those more
knowledgable in the intricacies of that protocol.
<SNIP! SNIP!>
>This sentence is more important than is apparent at first. An implementation
>can look at the inner IP header as JUST ANOTHER UPPER LAYER. This helps
>reduce some of the special-casing for IP as the inner payload. It doesn't
>_ELIMINATE_ it, but it can reduce it.
>
>(For example, if you have A->B with the inner IP saying A->B, you can make
>stronger assertions than if the inner packet says something else.)
We can emphasize this point if you think it's important and does not
receive enough attention here.
<SNIP! SNIP!>
>As an aside, I'd strongly encourage to look at the current implementations
>out there, as well as some of the analysis literature. I suspect you've
>already done your homework on this front and will be drawing on their
>experience when you finish rewhacking the architecture document.
The implementations I have seen so far do not seem to provide the sort of
granularity that Ran's previous architecture I-D called for, and that I
called for in my talk at the last IETF WG, etc. But I am going on what
I've seen at the trade shows, not the bakeoffs, so I hope we are closer
than I fear.
<SNIP! SNIP!>
>Do you have any recommendations for when the sequence number cycles? (Kick
>key mgmt. in the pants, logging, tuning future SAs to expire sooner, etc.)
I'm tempted to say that cycling is an error, and that key managememtn
should have been kicked sooner. The architecture document can address this
in more detail, or we can say something more definite here is there is
concensus.
<SNIP! SNIP!>
>Except for perhaps DF, these FLAGS and OFFSET SHOULD be zero anyway after
>reassembly! The question of DF is perhaps why the decision was made to just
>zero out that bit too.
I think we agree on the basic premise. Note that if a security gateway
fragments a packet with AH applied already, it will be using tunnel mode,
so the DF bit covered by the inner AH is not an issue here. We will be
sending out a message iscussion DF and PMTU after Memphis.
<SNIP! SNIP!>
>IMHO, new IPv6 extensions should document their own AH properties. Keep in
>mind this is IMHO only.
I like this as an answer; it allows it to reach closure on this document.
<SNIP! SNIP!>
>Thank you! We in IPv6-land appreciate this.
You're welcome.
<SNIP! SNIP!>
>As an aside, has anyone tackled this? A lightweight digital signature
>algorithm would be perfect in a multicast environment with a small number of
>senders compared with an arbitrary number of receivers.
This is a hard problem is we look for digital signature solutions, but
maybe we'll get lucky. ECC signatures are faster and smaller, but ... Are
you suggesting solutions that are not digital signature based? I ask only
because of your comment re the number of possible senders, which would seem
not to be an issue if we use a real signature algorithm.
<SNIP! SNIP!>
>Like I mentioned before, as currently written, these I-Ds _always_ include
>the replay counter. The replay counter is set to 0 for associations that
>don't use replay.
The I-Ds cited are not ones that inlude references to counters, AH, etc.
They are raw algorithms I-Ds, which is just what we want for this style of
specification. The issue of the presence or absence of the replay counter
should be with separately, in this document.
<SNIP! SNIP!>
>Ummm, what if I live in a multithreaded world? I can theoretically get two
>packets near-concurrently with the same sequence number. If the bogus one
>arrives first, do I trash the good one just because one with the same replay
>number arrived first? Or do I not count a sequence number as "good" until
>I've authenticated? Or is this just an implementation detail? Or is this
>why it says SHOULD rather than MUST?
We can make mention earlier of the need to authentciate prior to accepting
a packet, as you observed later.
Steve
From owner-ipsec Fri Mar 28 18:51:14 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA10293 for ipsec-outgoing; Fri, 28 Mar 1997 18:47:09 -0500 (EST)
Message-ID: <01BC3B90.23A3D480@nomad16.nomadix.com>
From: Andrew Everett <aeverett@tticom.com>
To: "'ipsec@tis.com'" <ipsec@tis.com>
Subject: Call for Presentations - SIP & Security for Mobile Users
Date: Fri, 28 Mar 1997 15:53:10 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Speakers are sought for a half-day tutorial on Security for Mobile Users and
and a conference session on Secure IP at the upcoming Nomadic 97 conference.
The theme of the conference is Enabling Mobility on the Internet and Intranets
and will take place August 25-28, 1997 in Santa Clara, California. Interested
parties may inquire about speaking opportunities by sending an e-mail
to Andrew Everett at aeverett@tticom.com.
From owner-ipsec Sun Mar 30 15:19:38 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA20789 for ipsec-outgoing; Sun, 30 Mar 1997 15:18:35 -0500 (EST)
Date: Sun, 30 Mar 97 20:16:52 GMT Daylight Time
From: Ran Atkinson <rja@inet.org>
Subject: Re: new ESP spec (bigger message)
To: Charles Lynn <clynn@bbn.com>, ipsec@tis.com
Cc: Dan McDonald <Dan.McDonald@Eng.sun.com>
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <199703280400.XAA04513@relay.hq.tis.com>
Message-ID: <Chameleon.859749540.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Charlie,
Since the alignment question is one driven by the IPng community,
it seems to me that the right approach to this question includes
at least:
(1) posting a note to both IPsec and IPng lists announcing the
new drafts and raising the alignment question
(2) asking that all followup notes be cross-posted to both lists
so that both communities see all the discussion
(3) understanding that consensus in BOTH WGs on this question
is a prerequisite for considering this matter resolved.
Ran
rja@inet.org
From owner-ipsec Sun Mar 30 15:19:38 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA20782 for ipsec-outgoing; Sun, 30 Mar 1997 15:13:36 -0500 (EST)
Date: Sun, 30 Mar 97 20:10:09 GMT Daylight Time
From: Ran Atkinson <rja@inet.org>
Subject: Re: new AH spec
To: Dan.McDonald@Eng.sun.com, kent@bbn.com, touch@isi.edu
Cc: ipsec@tis.com
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <199703272257.AA18146@ash.isi.edu>
Message-ID: <Chameleon.859749249.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Joe,
"An SPI value of zero indicates no Security Association exists." is a
very useful part of the IPsec specificationS. By definition, this SPI
value is NEVER used in a packet sent on the wire. It is extremely useful,
however, to have a single reserved SPI value that can be optionally
used for implementation-specific purposes inside some implementation.
In practice, changing or removing this sentence will cause existing fully
conforming implementations to become non-conforming (which is something
that the IETF does NOT generally do unless the prior statement has
some fatal operational flaw, which this reserved value does not).
Ran
rja@inet.org
From owner-ipsec Mon Mar 31 09:58:57 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA26068 for ipsec-outgoing; Mon, 31 Mar 1997 09:57:01 -0500 (EST)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce
cc: ipsec@tis.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-new-esp-00.txt
Date: Mon, 31 Mar 1997 09:35:18 -0500
Message-ID: <9703310935.aa04772@ietf.org>
Sender: owner-ipsec@ex.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 : IP Encapsulating Security Payload (ESP)
Author(s) : S. Kent, R. Atkinson
Filename : draft-ietf-ipsec-new-esp-00.txt
Pages : 17
Date : 03/28/1997
The Encapsulating Security Payload (ESP) header is designed to provide a
mix of optional security services in IPv4 and IPv6. ESP may be applied
alone, in combination with the IP Authentication Header (AH) [KA97b], or in
a nested fashion, e.g., through the use of tunnel mode (see below).
Security services can be provided between a pair of communicating hosts,
between a pair of communicating security gateways, or between a security
gateway and a host. For more details on how to use ESP and AH in various
network environments, see "Security Architecture for the Internet Protocol"
[KA97a].
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-new-esp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-new-esp-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
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-new-esp-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.
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: <19970328110738.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-new-esp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-new-esp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970328110738.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ipsec Mon Mar 31 09:58:57 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA26074 for ipsec-outgoing; Mon, 31 Mar 1997 09:57:31 -0500 (EST)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce
cc: ipsec@tis.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-new-auth-00.txt
Date: Mon, 31 Mar 1997 09:35:20 -0500
Message-ID: <9703310935.aa04792@ietf.org>
Sender: owner-ipsec@ex.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 : IP Authentication Header
Author(s) : S. Kent, R. Atkinson
Filename : draft-ietf-ipsec-new-auth-00.txt
Pages : 15
Date : 03/28/1997
The IP Authentication Header (AH) is used to provide connectionless
integrity and data origin authentication for IP datagrams (hereafter
referred to as just "authentication"), and to provide protection against
replays. This latter, optional service may be selected when a Security
Association is established. AH provides authentication for as much of the
IP header as possible, as well as for upper level protocol data. However,
some IP header fields may change in transit and the value of these fields,
when the packet arrives at the receiver, may not be predictable by the
transmitter. The values of such fields cannot be protected by AH. Thus
the protection provided to the IP header by AH is somewhat piecemeal.
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-new-auth-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-new-auth-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
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-new-auth-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.
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: <19970328111608.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-new-auth-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-new-auth-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970328111608.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ipsec Mon Mar 31 12:36:57 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA26978 for ipsec-outgoing; Mon, 31 Mar 1997 12:35:51 -0500 (EST)
From: touch@isi.edu
Date: Mon, 31 Mar 1997 09:41:01 -0800
Posted-Date: Mon, 31 Mar 1997 09:41:01 -0800
Message-Id: <199703311741.AA01725@ash.isi.edu>
To: Dan.McDonald@Eng.sun.com, kent@bbn.com, touch@isi.edu, rja@inet.org
Subject: Re: new AH spec
Cc: ipsec@tis.com
X-Auto-Sig-Adder-By: faber@isi.edu
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> From rja@inet.org Sun Mar 30 12:19:08 1997
> Date: Sun, 30 Mar 97 20:10:09 GMT Daylight Time
> From: Ran Atkinson <rja@inet.org>
> Subject: Re: new AH spec
> To: Dan.McDonald@eng.sun.com, kent@bbn.com, touch@isi.edu
> Cc: ipsec@tis.com
> X-Priority: 3 (Normal)
> References: <199703272257.AA18146@ash.isi.edu>
>
>
> Joe,
>
> "An SPI value of zero indicates no Security Association exists." is a
> very useful part of the IPsec specificationS. By definition, this SPI
> value is NEVER used in a packet sent on the wire. It is extremely useful,
> however, to have a single reserved SPI value that can be optionally
> used for implementation-specific purposes inside some implementation.
Sure - that part is clear. The SPI value of 0 is to the API,
but there is never a case when the value needs to be stored
in the field.
This should be made clear in section 2.4 of the draft.
> In practice, changing or removing this sentence will cause existing fully
> conforming implementations to become non-conforming (which is something
> that the IETF does NOT generally do unless the prior statement has
> some fatal operational flaw, which this reserved value does not).
Given that there's already a revision of the RFC in progress,
this statement is of little significance. Fully conforming
to WHICH - the new or old spec?
PS - in that vein, why does the new draft have
no references to RFC 1826, even though it has the same title?
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/
From owner-ipsec Mon Mar 31 15:51:41 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA28370 for ipsec-outgoing; Mon, 31 Mar 1997 15:50:32 -0500 (EST)
Message-Id: <2.2.32.19970331210326.00bddb34@mailserv-H.ftp.com>
X-Sender: naganand@mailserv-H.ftp.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 31 Mar 1997 16:03:26 -0500
To: Bill Sommerfeld <sommerfeld@apollo.hp.com>
From: Naganand Doraswamy <naganand@ftp.com>
Subject: Re: Proposed changes to ESP (andf a little AH too)
Cc: daw@cs.berkeley.edu (David Wagner), ipsec@ex.tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Bill,
>We merely need to specify that the IP checksum MUST be supplied on
>transmission and verified on receipt for packets nested inside ESP.
>
I think IPv6 does not do any checksum. It depends on the upper layer
protocols to perform checksums.
--Naganand
----------------------------------------------------------------
naganand@ftp.com
Tel #: (508)684-6743 (O)
From owner-ipsec Mon Mar 31 15:51:45 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA28349 for ipsec-outgoing; Mon, 31 Mar 1997 15:45:54 -0500 (EST)
Date: Mon, 31 Mar 97 20:43:15 GMT Daylight Time
From: Ran Atkinson <rja@inet.org>
Subject: Re: new AH spec
To: Dan.McDonald@Eng.sun.com, kent@bbn.com, rja@inner.net, touch@isi.edu
Cc: ipsec@tis.com
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <199703311741.AA01725@ash.isi.edu>
Message-ID: <Chameleon.859837569.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Joe,
The notion is that the _revised_ AH/ESP specifications should be
written such that existing implementations that conform fully to
RFC-1825 through RFC-1827 are NOT made non-conforming except for
very very good reason (e.g. a specific known cryptographic attack).
My understanding from Steve Kent during and since Montreal has always
been that his revisions would have the above property -- except as required
to fix specific publicly-known attacks on the existing RFCs.
Ran
rja@inet.org
From owner-ipsec Mon Mar 31 17:21:54 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA28888 for ipsec-outgoing; Mon, 31 Mar 1997 17:20:54 -0500 (EST)
From: touch@isi.edu
Date: Mon, 31 Mar 1997 14:26:10 -0800
Posted-Date: Mon, 31 Mar 1997 14:26:10 -0800
Message-Id: <199703312226.AA08928@ash.isi.edu>
To: Dan.McDonald@Eng.sun.com, kent@bbn.com, rja@inner.net, touch@isi.edu,
rja@inet.org
Subject: Re: new AH spec
Cc: ipsec@tis.com
X-Auto-Sig-Adder-By: faber@isi.edu
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> From rja@inet.org Mon Mar 31 12:51:22 1997
> Date: Mon, 31 Mar 97 20:43:15 GMT Daylight Time
> From: Ran Atkinson <rja@inet.org>
> Subject: Re: new AH spec
> To: Dan.McDonald@eng.sun.com, kent@bbn.com, rja@inner.net, touch@ISI.EDU
> Cc: ipsec@tis.com
> X-Priority: 3 (Normal)
> References: <199703311741.AA01725@ash.isi.edu>
>
>
> Joe,
>
> The notion is that the _revised_ AH/ESP specifications should be
> written such that existing implementations that conform fully to
> RFC-1825 through RFC-1827 are NOT made non-conforming except for
> very very good reason (e.g. a specific known cryptographic attack).
maybe a paragraph indicating this goal would be appropriate,
and certainly the revised specs should refer directly to the
original specs
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/
From owner-ipsec Mon Mar 31 19:11:56 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA29445 for ipsec-outgoing; Mon, 31 Mar 1997 19:06:16 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03007809af66028a447d@[128.89.30.21]>
In-Reply-To: <199703312226.AA08928@ash.isi.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 31 Mar 1997 19:11:26 -0500
To: touch@isi.edu, rja@inet.org
From: Stephen Kent <kent@bbn.com>
Subject: Re: new AH spec
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Joe + Ran,
It was an oversight on my part that we did not reference the
original AH and ESP specs, and that will be remedied in our next round of
revisions. We also can add a section to provide a brief overview of
format/processing differences between the old and new verisons, to make
reading easier for those already familiar with the current RFCs.
As per Ran's clarifying comments, we will re-wrod the specs to make
clear that an SPI of 0 is for internal use, not for transmission on the
wire.
Steve
From owner-ipsec Mon Mar 31 22:03:55 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA00507 for ipsec-outgoing; Mon, 31 Mar 1997 22:02:45 -0500 (EST)
Message-Id: <199704010307.WAA06277@thunk.ch.apollo.hp.com>
X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs
To: Naganand Doraswamy <naganand@ftp.com>
Cc: daw@cs.berkeley.edu (David Wagner), ipsec@ex.tis.com
Subject: Re: Proposed changes to ESP (andf a little AH too)
In-Reply-To: naganand's message of Mon, 31 Mar 1997 16:03:26 -0500.
<2.2.32.19970331210326.00bddb34@mailserv-H.ftp.com>
Date: Mon, 31 Mar 1997 22:07:13 -0500
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> I think IPv6 does not do any checksum. It depends on the upper layer
> protocols to perform checksums.
Right, but TCP-on-IPv6 and UDP-on-IPv6 still include the
ones-complement checksum, right?
- Bill
From owner-ipsec Mon Mar 31 22:34:30 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA00700 for ipsec-outgoing; Mon, 31 Mar 1997 22:34:05 -0500 (EST)
Message-Id: <199704010338.WAA04898@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol
To: Bill Sommerfeld <sommerfeld@apollo.hp.com>
cc: Naganand Doraswamy <naganand@ftp.com>, daw@cs.berkeley.edu (David Wagner),
ipsec@ex.tis.com
Subject: Re: Proposed changes to ESP (andf a little AH too)
In-reply-to: Your message of "Mon, 31 Mar 1997 22:07:13 EST."
<199704010307.WAA06277@thunk.ch.apollo.hp.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Mon, 31 Mar 1997 22:38:24 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Bill Sommerfeld writes:
> > I think IPv6 does not do any checksum. It depends on the upper layer
> > protocols to perform checksums.
>
> Right, but TCP-on-IPv6 and UDP-on-IPv6 still include the
> ones-complement checksum, right?
Yes.