Re: independence of keying material for multiple transforms

Uri Blumenthal <uri@watson.ibm.com> Tue, 29 October 1996 21:19 UTC

From: Uri Blumenthal <uri@watson.ibm.com>
Message-Id: <9610292122.AA16817@hawpub.watson.ibm.com>
Subject: Re: independence of keying material for multiple transforms
To: Greg Troxel <gdt@bbn.com>
Date: Tue, 29 Oct 1996 16:22:04 -0500
Cc: ipsec@TIS.COM
In-Reply-To: <199610291743.MAA12547@aardvark.bbn.com> from "Greg Troxel" at Oct 29, 96 12:43:17 pm
Reply-To: uri@watson.ibm.com
Content-Type: text
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

Greg Troxel says:
> I'd like to concur with the notion expressed in a recent message that
> documents explicitly make the point that when raw keying material is
> used to generate blobs that whatever entropy was 'used' to generate
> this not be reused when generating another blob.  

I don't think it's really necessary - but it depends on the
exposure of that "blob" in question.

> Or perhaps, that it
> should be computationally infeasible to determine information about
> any bit in blob A given the entire contents of blobs B,C,D.

Yes, this looks like the requirement needed and sufficient.

But again, it depends on "who knows that blob".
-- 
Regards,
Uri		uri@watson.ibm.com
-=-=-=-=-=-=-
<Disclaimer>

From: Dan McDonald <dan.mcdonald@eng.sun.com>
Message-Id: <199610292134.NAA21839@jurassic.eng.sun.com>
Subject: Re: proposed IPSEC changes/extensions
To: daw@cs.berkeley.edu
Date: Tue, 29 Oct 1996 13:34:03 -0800 (PST)
Cc: ipsec@TIS.COM
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

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

You also might have to maintain state for encryption (i.e. was the packet
decrypted or not).

Just make sure that when you get "spaghetti transforms" (to steal from both
structured and object-oriented folks) you don't accidentally accept a packet
that your policy says you shouldn't accept.  Careful implementation will
insure that this doesn't happen.

> Certainly support for *sending* packets with arbitrarily-nested headers
> is harder to implement.

Yep!  I'm not sure you need to support all that many nesting types on outbound
packets.  The NRL IPv6/IPsec code has a relatively simple model, which I plan
on using in my current project.

Dan

independence of keying material for multiple tran… Greg Troxel
Re: independence of keying material for multiple … Uri Blumenthal