IETF Logo Mail Archive

Re: deriving keying material from the shared secret

Hilarie Orman <ho@earth.hpc.org> Mon, 01 July 1996 13:49 UTC

Received: from relay.tis.com by neptune.TIS.COM id aa21976; 1 Jul 96 9:49 EDT
Received: by relay.tis.com; id JAA04191; Mon, 1 Jul 1996 09:51:03 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma004178; Mon, 1 Jul 96 09:50:39 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA15666; Mon, 1 Jul 96 09:50:39 EDT
Received: by relay.tis.com; id JAA04165; Mon, 1 Jul 1996 09:50:35 -0400
Received: from copernicus.hpc.org(192.187.8.4) by relay.tis.com via smap (V3.1.1) id xma004151; Mon, 1 Jul 96 09:50:20 -0400
Received: from earth.hpc.org (earth.hpc.org [192.187.8.34]) by hpc.org (8.7.1/8.7.1) with SMTP id JAA03828; Mon, 1 Jul 1996 09:55:25 -0400 (EDT)
Received: by earth.hpc.org (SMI-8.6/SMI-SVR4) id JAA04896; Mon, 1 Jul 1996 09:55:13 -0400
Date: Mon, 01 Jul 1996 09:55:13 -0400
From: Hilarie Orman <ho@earth.hpc.org>
Message-Id: <199607011355.JAA04896@earth.hpc.org>
To: smb@research.att.com
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
Cc: ipsec@TIS.COM
In-Reply-To: Yourmessage <199607010217.TAA20630@baskerville.CS.Arizona.EDU>
Subject: Re: deriving keying material from the shared secret
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

This is an important idea, and the OAKLEY draft makes the assumption that
the transforms can take a variable precision integer and do these things.
A separate RFC sounds like a good thing, though it should be careful to
make the hashing function generic, so that one isn't requried to use MD5
to get the key for a SHA transform.

There are some delicate issues about making sure the raw keying material
has enough bits for the transform's use that might be addressed in
such an RFC.

v2.28.0 | Report a Bug | By Email | System Status