allocation of key material into keys
HUGO@watson.ibm.com Tue, 29 October 1996 19:40 UTC
Received: from relay.hq.tis.com by neptune.TIS.COM id aa28801; 29 Oct 96 14:40 EST
Received: by relay.hq.tis.com; id OAA08200; Tue, 29 Oct 1996 14:44:29 -0500
From: HUGO@watson.ibm.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma008191; Tue, 29 Oct 96 14:44:08 -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 OAA29708 for <IPSEC@tis.com>; Tue, 29 Oct 1996 14:45:52 -0500 (EST)
Received: by relay.hq.tis.com; id OAA08182; Tue, 29 Oct 1996 14:43:59 -0500
Received: from igw3.watson.ibm.com(129.34.139.18) by relay.tis.com via smap (V3.1.1) id xma008156; Tue, 29 Oct 96 14:43:30 -0500
Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id OAA05044; Tue, 29 Oct 1996 14:45:18 -0500
Received: from yktvmv.watson.ibm.com (yktvmv.watson.ibm.com [9.117.33.29]) by mailhub1.watson.ibm.com (8.7.1/10-26-96) with SMTP id OAA192971; Tue, 29 Oct 1996 14:45:06 -0500
Message-Id: <199610291945.OAA192971@mailhub1.watson.ibm.com>
Received: from YKTVMV by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9289; Tue, 29 Oct 96 14:45:04 EST
Date: Tue, 29 Oct 1996 14:28:06 -0500
To: rja@cisco.com, IPSEC@TIS.COM
cc: dharkins@cisco.com
Subject: allocation of key material into keys
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Ref: Your note of Mon, 28 Oct 1996 11:21:23 PST (attached) > I'm not sure what other folks think, but I've been persuaded by various people > that we need some standard and clearly stated way of transforming a "blob" of > key material generated by key management (e.g. the D-H exponentiation) into > one or more actual session keys. up to here we are in full agreement > > I'd like to propose that the key management protocol specifications only > be responsible for generating a "blob" of key material with sufficient > bits of entropy. > > Each transform would need to specify how many bits of entropy are needed from > key management for an SA and precisely how to transform a single "blob" of key > material into one or more session keys. This depends on what exactly you mean by "transform". Does the transform defines *all* the algorithms (and their needs for keys) that will be used with that particular blob. Or there is more than one transform that will use the same blob?. In the later case, I would disagre with you. This is what I was trying to explain in my previous message on key derivation. Giving *different* transforms (algorithms) the freedom to derive their keys from the *same* blob (I call it RKM for raw key material) is wrong. It does not guarantee key independence. As I said, form that single blob/RKM the key management needs to derive keys for each algorithm (the algorithm itself can then expand/manipulate that key as much as it wants). I do not care whether one sees the derivation of a transform key from RKM as part of the key exchange definition or a layer between key exchange and transform definitions, as long as key independence is enforced. > > Does this seem OK to people ? What do the editors of ISAKMP and Oakley related documents think (or more importantly, what do they plan to do)? (This is in my view a simple but fundamental issue). Hugo > > Ran > rja@cisco.com > > > -- > >