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--