[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: allocation of key material into keys
I think it is very important that we remove the convention that the Hughes
draft uses to bind key generation for both directions of an ESP tunnel to a
single key blob. The key management protocol should be useful for many
services without having to have specific knowledge about those services.
This concept of key derivation becomes IPSEC specific. Instead I believe
the KMP should deliver a key blob for each SA that is negotiated.
Dave
> >Agreed. Each SA/SPI instantiated by the key mgmt protocol needs to
> >get a different, independant, blob of entropy.
> >
>
> Correct me if I am wrong. Jim Hughes draft on esp-des currently specifies
> deriving the the keys for the Initiator and the Responder from the same
> keying materail K. Are we suggesting here that we should be using different
> keying materail or can we still use the same keying materail but change the
> input to the hash algorithm by padding something.
>
> --Naganand
> ----------------------------------------------------------------
> naganand@ftp.com
> Tel #: (508)684-6743 (O)
>
X-Sender: rah@pop.tiac.net
Message-Id: <v03007801ae9d9dc2b321@[206.119.69.46]>
In-Reply-To: <v03007801ae9d5bdf0f34@[206.119.69.46]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 30 Oct 1996 19:07:07 -0500
To: ipsec@neptune.tis.com
From: Robert Hettinga <rah@shipwright.com>
Subject: Re: Financial Cryptography 1997 (FC97): General Announcement
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
At 3:40 pm -0500 10/30/96, Robert Hettinga wrote:
> Financial Cryptography 1997 (FC97):
> The world's first financial cryptography conference, workshop, and
>exhibition!
Ack!
I'm very, very, sorry. I didn't mean to send this here. I have *no* idea
what I was thinking...
Cheers,
Bob Hettinga
-----------------
Robert Hettinga (rah@shipwright.com)
e$, 44 Farquhar Street, Boston, MA 02131 USA
"The cost of anything is the foregone alternative" -- Walter Johnson
The e$ Home Page: http://www.vmeng.com/rah/
Date: Thu, 31 Oct 1996 09:46:34 -0500
From: Hilarie Orman <ho@earth.hpc.org>
Message-Id: <199610311446.JAA02150@earth.hpc.org>
To: ipsec@TIS.COM
Subject: Re: proposed IPSEC changes/extensions
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> > Certainly support for *sending* packets with arbitrarily-nested headers
> > is harder to implement.
> Yep!
I don't see why. Define the SA's, make a list of them, perform some
form of "open" operation with the list. Send. Interpret list, one SA at
a time.
Hilarie
Date: Thu, 31 Oct 1996 09:50:25 -0500
From: Hilarie Orman <ho@earth.hpc.org>
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
Message-Id: <199610311450.JAA02288@earth.hpc.org>
To: msabin@netcom.com
Cc: ipsec@TIS.COM
In-reply-to: Yourmessage <199610300153.SAA16259@baskerville.CS.Arizona.EDU>
Subject: Re: proposed IPSEC changes/extensions
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> 2) Compression is stateful, which means that the transmitter and receiver
> can get out of sync if packets are missed.
Isn't stateful compression is most logically done as a separate
protocol, performed prior to any IPSEC encryption?
Hilarie Orman
Message-ID: <n1365366045.9976@mail.ndhm.gtegsc.com>
Date: 31 Oct 1996 10:02:17 -0400
From: WaterhouseR <WaterhouseR@mail.ndhm.gtegsc.com>
Subject: ISAKMP Questions
To: IPSEC Working Group <ipsec@TIS.COM>
X-Mailer: Mail*Link SMTP-MS 3.0.2
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
The following is based on draft-ietf-ipsec-isakmp-05.
I find myself confused re the following.
3.5.6 says "If the basic exchange types are inadequate to meet the
requirements within a DOI, a designer can define up to thirteen extra exchange
types per DOI."
Now Exchange Type is carried in the Header, but DOI is carried in the SA
Payload. This seems to imply that every Exchange Type must begin with an SA
Payload, something which is probably harmless in Phase 1. But in Phase 2, it
appears to have the further implication that the SA Payload be unencrypted
(since you can't process the Header without accessing the SA Payload). It has
the further implication that if the Payloads are encrypted only one SA can be
negotiated at a time between a pair of Negotiation Servers (since you need
access to the SPIs to interpret Exchange Type if you are trying to negotiate
for more than one association at the same time).
My initial reaction is that DOI is mispositioned to support the more general
capability suggested in 3.5.6. But perhaps I am overlooking something.
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
MMDF-Warning: Parse error in original version of preceding line at
Message-ID: <9610311035.aa17853@neptune.TIS.COM>
neptune.TIS.COM
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-03.txt
Date: Thu, 31 Oct 1996 10:01:43 -0500
Message-ID: <9610311001.aa25654@ietf.org>
Sender: ipsec-approval@neptune.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.
Note: This revision reflects comments received during the last call period.
Title : HMAC-MD5 IP Authentication with Replay Prevention
Author(s) : M. Oehler, R. Glenn
Filename : draft-ietf-ipsec-ah-hmac-md5-03.txt
Pages : 7
Date : 10/30/1996
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 [HMAC-MD5]. An option is also specified to guard against replay
attacks.
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-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ah-hmac-md5-03.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-ah-hmac-md5-03.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: <19961030145250.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-md5-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-ah-hmac-md5-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961030145250.I-D@ietf.org>
--OtherAccess--
--NextPart--
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
MMDF-Warning: Parse error in original version of preceding line at
Message-ID: <9610311036.aa17969@neptune.TIS.COM>
neptune.TIS.COM
cc: ipsec@TIS.COM
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-ah-hmac-sha-03.txt
Date: Thu, 31 Oct 1996 10:01:47 -0500
Message-ID: <9610311001.aa25671@ietf.org>
Sender: ipsec-approval@neptune.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.
Note: This revision reflects comments received during the last call period.
Title : HMAC-SHA IP Authentication with Replay Prevention
Author(s) : S. Chang, R. Glenn
Filename : draft-ietf-ipsec-ah-hmac-sha-03.txt
Pages : 7
Date : 10/30/1996
This document describes a keyed-SHA transform to be used in conjunction
with the IP Authentication Header [RFC-1826]. The particular transform is
based on [HMAC-MD5]. An option is also specified to guard against replay
attacks.
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-sha-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ah-hmac-sha-03.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-ah-hmac-sha-03.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: <19961030150401.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-sha-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-ah-hmac-sha-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961030150401.I-D@ietf.org>
--OtherAccess--
--NextPart--
References: