[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
allocation of key material into keys
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
>
>
> --
>
>