[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Suggestion for ESP 3DES MD5 document
Steve,
At 09:44 AM 10/24/96 -0500, you wrote:
> Thanks for the reminder message. Work is underway to revise ESP as
>per the Montreal discussion and resolution, so we ougt not create any new
>transforms per se. Instead, authors of transforms should go back and
>develop I-Ds that specify the algorithms used, independent of the
>combinations of the algorithms. So, we need brief descriptions of DES-CBC,
>3DES-CBC, HMAC-MD5, HMAC-SHA1, etc.
Having just created a "new transform", I thought it best to alert the list
of a new internet draft for 3DES-CBC (see below). Note that it also adds
compression, HMAC and replay prevention. It is based on Hughes DES-CBC draft.
Given the move to define the algorithms separately and provide the
algorithm selection information in the ESP document, I would like to
propose that optional use of compression be added as an integral part of
ESP. The only discussion of compression to date has in brief mention within
some of the key management protocol drafts. Additionally, another draft
(draft-thayer-seccomp-00.txt) has been proposed to provide compression
within an ESP payload.
With the increasingly pervasive use of compression within PPP, all of the
encryption that will be done to implement VPNs (or any other network layer
encryption applications) will end up costing businesses additional line
charges due to the inability to compress encrypted data. When you're
talking about T1 rates and greater, this is not small change. As a result,
I think it is critical for the ipsec framework to support the optional use
of compression. I would also suggest that the additional fields be included
in a revised ESP. I propose that the newly submitted draft (see below)
along with the Thayer draft be examined as starting points for such
discussion.
On the specifics of the 3DES included in the draft below, as someone else
on the list had mentioned earlier (don't recall who), ANSI is currently
nearing completion on a 3DES draft (X9.52). The 3DES in our draft is based
(in part) on that work.
Comments are appreciated.
Bob Monsour
rmonsour@earthlink.net
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> Title : Combined 3DES-CBC, LZS Compression, HMAC, and
> Replay Prevention ESP Transform
> Author(s) : M. Sabin, R. Monsour
> Filename : draft-sabin-esp-des3-lzs-md5-00.txt
> Pages : 18
> Date : 10/23/1996
>
>This document proposes the "3DES-CBC-LZS-HMAC-Replay" security transform
>for the IP Encapsulating Security Payload (ESP). The proposed transform
>combines triple-DES encryption, LZS compression, HMAC authentication, and
>replay prevention into a single packet format. The transform is compatible
>with implementations that do not support compression and with
>implementations that support only single-DES encryption. Compression is
>performed prior to encryption, which has the side benefit of reducing the
>amount of data that must be encrypted.
>
>This document is based on the IPsec Working Group's proposed "Combined
>DES-CBC, HMAC, and Replay Prevention Security Transform," cited later in
>this document.
>
>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-sabin-esp-des3-lzs-md5-00.txt".
>A URL for the Internet-Draft is:
>ftp://ds.internic.net/internet-drafts/draft-sabin-esp-des3-lzs-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.a
>
> 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-sabin-esp-des3-lzs-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.
>
><ftp://ds.internic.net/internet-drafts/draft-sabin-esp-des3-lzs-md5-00.txt>
>