[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: allocation of key material into keys


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


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: 28 Oct 1996 18:47:04 -0800
Organization: ISAAC Group, UC Berkeley
Lines: 20
Message-ID: <553r78$2vp@joseph.cs.berkeley.edu>
References: <v02130505ae9a8af26d4c@[128.89.30.6]>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

In article <v02130505ae9a8af26d4c@[128.89.30.6]>,
Stephen Kent  <kent@bbn.com> wrote:
>        The document explains the need to support AH and both transport and
> tunnel modes of ESP, based on the context (host vs. security gateway).
> However, what about nested combinations of these protocols?  It probably is
> not reasonable to require an implementation to support all possible
> combinations of these headers, nested to any depth.

While I don't know what the requirements ought to be, I thought I'd throw
in a brief word of implementation experience.

When I was implementing ipsec, I found that handling arbitrarily-nested
combinations was easy.  On inbound processing, just strip off an ipsec
header, and recurse: throw the packet back in the inbound queue.  (You
only have to maintain a bit of state for authentication.)

Certainly support for *sending* packets with arbitrarily-nested headers
is harder to implement.  But that's fine; either way, we ought to

    Be conservative in what you send and liberal in what you'll accept.



Message-Id: <199610291214.HAA01347@smb.research.att.com>
To: Stephen Kent <kent@bbn.com>
cc: ipsec@TIS.COM
Subject: Re: proposed IPSEC changes/extensions 
Date: Tue, 29 Oct 1996 07:14:21 -0500
From: Steve Bellovin <smb@research.att.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

I have a number of other comments I'll try to send out tonight.  For
now, though, I'm very curious why you want management parameters
to retrieve keys.  Why would a management station -- and remember that
we don't have SNMP security yet -- ever need to retrieve a key?  (For
that matter, I thought I'd heard from you that keeping keys inside the
secure box was a primary goal of cryptographic system design.)



Date: Tue, 29 Oct 1996 10:09:37 -0500
Message-Id: <199610291509.KAA13917@csmes.ncsl.nist.gov>
From: Joe Konczal <konczal@csmes.ncsl.nist.gov>
To: rja@cisco.com
CC: ipsec@TIS.COM
In-reply-to: (message from Ran Atkinson on Mon, 28 Oct 1996 11:21:23 PST)
Subject: Re: allocation of key material into keys
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

Sounds like a good idea to me.
Follow-Ups: