Re: allocation of key material into keys
David Carrel <carrel@cisco.com> Wed, 30 October 1996 23:26 UTC
Received: from relay.hq.tis.com by neptune.TIS.COM id aa15100; 30 Oct 96 18:26 EST
Received: by relay.hq.tis.com; id SAA14569; Wed, 30 Oct 1996 18:31:00 -0500
Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma014566; Wed, 30 Oct 96 18:30:38 -0500
Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id SAA10370 for <ipsec@tis.com>; Wed, 30 Oct 1996 18:32:23 -0500 (EST)
Received: by relay.hq.tis.com; id SAA14550; Wed, 30 Oct 1996 18:30:32 -0500
Received: from stilton.cisco.com(171.69.1.161) by relay.tis.com via smap (V3.1.1) id xma014543; Wed, 30 Oct 96 18:30:14 -0500
Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by stilton.cisco.com (8.6.12/8.6.5) with ESMTP id PAA07726; Wed, 30 Oct 1996 15:30:51 -0800
Message-Id: <199610302330.PAA07726@stilton.cisco.com>
To: Naganand Doraswamy <naganand@ftp.com>
cc: Bill Sommerfeld <sommerfeld@apollo.hp.com>, "C. Harald Koch" <chk@border.com>, Ran Atkinson <rja@cisco.com>, ipsec@TIS.COM
Subject: Re: allocation of key material into keys
In-reply-to: Your message of "Tue, 29 Oct 1996 08:27:25 EST." <2.2.32.19961029132725.00c13120@mailserv-H.ftp.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7723.846718251.1@cisco.com>
Date: Wed, 30 Oct 1996 15:30:51 -0800
From: David Carrel <carrel@cisco.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
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--
- allocation of key material into keys Ran Atkinson
- Re: allocation of key material into keys Bill Sommerfeld
- Re: allocation of key material into keys C. Harald Koch
- Re: allocation of key material into keys Bill Sommerfeld
- Re: allocation of key material into keys Naganand Doraswamy
- Re: allocation of key material into keys David Carrel