Re: allocation of key material into keys

"C. Harald Koch" <chk@border.com> Mon, 28 October 1996 21:30 UTC

Received: from relay.hq.tis.com by neptune.TIS.COM id aa28651; 28 Oct 96 16:30 EST
Received: by relay.hq.tis.com; id QAA14008; Mon, 28 Oct 1996 16:34:54 -0500
Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma014006; Mon, 28 Oct 96 16:34:27 -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 QAA08541 for <ipsec@tis.com>; Mon, 28 Oct 1996 16:36:19 -0500 (EST)
Received: by relay.hq.tis.com; id QAA14002; Mon, 28 Oct 1996 16:34:24 -0500
Received: from mail.border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma014000; Mon, 28 Oct 96 16:34:15 -0500
Received: by janus.border.com id <18437-1>; Mon, 28 Oct 1996 16:34:21 -0500
Message-Id: <96Oct28.163421est.18437-1@janus.border.com>
To: Bill Sommerfeld <sommerfeld@apollo.hp.com>
cc: Ran Atkinson <rja@cisco.com>, ipsec@TIS.COM
Subject: Re: allocation of key material into keys
References: <199610282029.PAA03172@thunk.orchard.medford.ma.us>
In-reply-to: sommerfeld's message of "Mon, 28 Oct 1996 15:29:06 -0500". <199610282029.PAA03172@thunk.orchard.medford.ma.us>
From: "C. Harald Koch" <chk@border.com>
Organization: Secure Computing Canada Ltd.
Phone: +1 416 368 7157
X-uri: <URL:http://www.eng.border.com/homes/chk/>
X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2; hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm; z:NJ7pss)l__Cw+.>xUJ) did@Pr9
Date: Mon, 28 Oct 1996 16:36:06 -0500
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

In message <199610282029.PAA03172@thunk.orchard.medford.ma.us>, Bill Sommerfeld writes:
> Here's a rephrase which I think is more precise.  Let me know if this
> is not what you intended..
> 
>     I'd like to propose that the key management protocol
>     specifications only be responsible for generating a "blob" of
>     key material at least N bits long containing at least K bits of
>     entropy.  For obvious reasons, K <= N.
> 
>     Each transform would need to specify minimum values for K and
>     N, and precisely how to transform a variable-length "blob"
>     of key material of at least N bits into the session keys, initial
>     sequence numbers, and other shared state it needs.

The problem with this is that it doesn't cover the problem of creating
*independent* keys for multiple transforms, which is the concern Hugo
raised. I suspect that everyone will define simple keying material functions
such that one could (for example) derive the HMAC-MD5 key from a cracked DES
key.

As has been discussed, this is a key management layer issue. I'd modify your
statement to include that somehow, the "blobs" handed to different
transforms or algorithms must be 'independent' (i.e. it's cryptographically
hard to derive one key from another). They can still be generated from the
same key exchange, as long as the key manager runs an intermediate step to
obscure the source keying material.

-- 
C. Harald Koch          | Senior System Developer, Secure Computing Canada Ltd.
chk@border.com          | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8
+1 416 368 7157 (voice) | "Madness takes its toll. Please have exact change."
+1 416 368 7789 (fax)   |		-Karen Murphy <karenm@descartes.com>