[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposed IPSEC changes/extensions
At 04:13 PM 11/4/96 -0500, Stephen Kent wrote:
>...if there is agreement that providing for compression in ESP (vs. a
>separate protocol) is a good idea, I'll put in the hooks for it as
>specified by those of you who have been working the problem.
Steve,
I've done some chatting with others working the problem. We believe that
we've come up with a way to accommodate compression within ESP with minimal
impact and overhead on the ESP draft (smiles erupt here).
What we propose is that the ESP draft simply state that compression is one
of the negotiable security association attributes (which I realize will
ultimately be negotiated by whatever KMP is employed; the ISAKMP draft
already includes support for turning on compression and specifying the
algorithm). In addition, the ESP draft would state that when the optional
compression is implemented, it is performed prior to encryption. I would
suggest that the appropriate language be added to the descriptions of the
"sender" and "receiver" operations in the tunnel-mode and transport-mode
descriptions (sections 4.1 and 4.2 of the June 6 draft).
That simple mechanism would allow for the creation of one or more separate
compression transform descriptions (one for each compression algorithm)
which would include the format for the compressed data, as well as the
description of any compression-specific fields (such as bits for
compressed/uncompressed and history reset). In the case where a particular
SPI specifies NOT using a replay prevention counter, the compression
transform would include a sequence counter (perhaps only 16 bits) to
provide the capability for handling out of order packets.
For example, the resulting ESP syntax, when using 3DES and HMAC and reply
prevention would look as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| Security Parameters Index (SPI) | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
| Initialization Vector (optional) | |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---
| Replay Prevention Field (count) | | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| |HMAC |
| Payload Data (compressed or uncompressed) | | |
| | | |
| +-+-+-+-+-+-+-+-| | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 3DES
| Padding (0-7 bytes) | | CBC
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Payload Type | v |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- |
| | |
| HMAC digest | |
| | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
I am hopeful that this solution provides the group with both the ability to
keep the door open on the compression topic as well as the flexibility for
defining compression transforms which, like encryption, will change over
time to meet differing operational requirements.
We are planning to develop an LZS informational draft in the form suggested
prior to the 11/26 ID cutoff date.
Lastly, while it may appear that compression should be orthogonal to
security considerations, it is important to note that in the absence of the
implementation of encryption, compression is already provided for at the
data link layer (PPP). It is exactly the incorporation of security that
drives the need to also include compression so as to maintain the bandwidth
gains already achieved for today's network user.
Comments are welcome.
Bob Monsour
rmonsour@earthlink.net
To: ipsec@TIS.COM
Path: not-for-mail
From: David Wagner <daw@cs.berkeley.edu>
Newsgroups: isaac.lists.ipsec
Subject: Re: proposed IPSEC changes/extensions
Date: 4 Nov 1996 21:58:00 -0800
Organization: ISAAC Group, UC Berkeley
Lines: 25
Message-ID: <55ml18$9pk@joseph.cs.berkeley.edu>
References: <199611011912.OAA01596@thunk.orchard.medford.ma.us>
<Pine.SUN.3.91.961104122622.11989B-100000@hutcs-2.cs.hut.fi>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
[Apologies if I'm covering old, familiar ground again:]
In article <Pine.SUN.3.91.961104122622.11989B-100000@hutcs-2.cs.hut.fi>,
Santeri Paavolainen <santtu@mail.cs.hut.fi> wrote:
> TCP is inherently safe
> from replay prevention, and no cryptographic security is needed. The
> only item of interest is authentication, eg. tamperproof connections.
I disagree. TCP still needs replay protection.
For one thing, TCP sequence numbers were designed for robustness against
long-lived packets and network errors, not against adversaries. TCP sequence
numbers can easily wrap around (and they do in some applications). Once
they wrap, you're vulnerable to replays.
Also, when host-pair keying is in effect, and one host has mutually
distrustful users, TCP probably needs replay protection, lest one of
Bellovin's attacks compromise confidentiality. (Alice binds to port
1234, receives some traffic, disconnects; Bob then binds to port 1234,
replays the old traffic, and receives the decryption of Alice's data.)
Who knows -- there may be other attacks, too. I say, for robustness,
and for security against known attacks, TCP does need replay protection.
Anyhow, maybe this doesn't change your main point. Just a nitpick.
To: Stephen Kent <kent@bbn.com>
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
Cc: Karl Fox <karl@ascend.com>, Steven Bellovin <smb@research.att.com>,
Hilarie Orman <ho@earth.hpc.org>, ipsec@TIS.COM
Subject: Re: proposed IPSEC changes/extensions
In-Reply-To: <v02130511aea3bd9313c1@[128.89.0.110]>
Date: Mon, 04 Nov 1996 20:15:07 -0800
From: John Gilmore <gnu@toad.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9611050729.aa05541@neptune.TIS.COM>
> Let's just work on
> designing the protocols to work correctly and assume that the crypto will
> be secure under assumptions of known (and chosen) plaintext attacks. This
> is a sufficiently hard task.
Perhaps I'm just reacting to Stephen's wording, but I think that
rather than "assuming" the crypto is secure against known and chosen
plaintext attacks, we should use crypto algorithms that we "strongly
believe" are secure.
I advocate against the use of 1DES because it is often "assumed" to be
secure -- but we know it isn't, and are within months of seeing
demonstration proofs of its insecurity.
John
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-esp-3des-md5-00.txt
Date: Tue, 05 Nov 1996 09:42:11 -0500
Message-ID: <9611050942.aa17948@ietf.org>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Security Protocol Working
Group of the IETF.
Title : Combined 3DES-CBC, HMAC and Replay Prevention Security
Transform
Author(s) : N. Doraswamy
Filename : draft-ietf-ipsec-esp-3des-md5-00.txt
Pages : 13
Date : 11/04/1996
This draft describes a combination of privacy, authentication, integrity
and replay prevention into a single packet format.
This document is the result of significant work by several major
contributors and the IPsec working group as a whole. These contributors,
cited later in this document, provided many of the key technical details
summarized in this document. [IB93] [IBK93]
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-esp-3des-md5-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-3des-md5-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.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-esp-3des-md5-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
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: <19961104110923.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-esp-3des-md5-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-esp-3des-md5-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961104110923.I-D@ietf.org>
--OtherAccess--
--NextPart--