[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC Security Gateways & NAT
Howdy,
Question below:
Hugo Krawczyk wrote:
> SKEYID and related key derivation is the SIMPLEST possible mechanism I can
> think of to support in a UNIFORM way the myriad of current requirements
> and options. I actually worked hard to make SKEYID the only changing piece
> with all of SKEYID_a/d/e and HASH_I/R all derived in the SAME way in
> spite of all the different modes.
>
>
> Hugo
> Dan Harkins wrote:
> >
> > Provided that the Diffie-Hellman is authenticated I guess we could say
> > that the resultant secret is something known only by the parties to
> > the exchange and therefore having g^xy (and not the pre-shared key) is
> > good enough. But I'm not a cryptographer and I didn't come up with the
> > key derivation.
> >
> > I'm all for simplifying and unifying SKEYID generation. Are there any
> > comments on this proposal? Hugo, are you out there?
> >
> > Dan.
> >
> >
I have long been confused by the derivation of SKEYID. I'm certianly
not expert enough to suggest changing it, but I do request that we
formally document its design goals. As Dan menetions, using g^xy alone
for SKEYID in all cases seems entirely sufficient to me (and I'm sure to
most implementors). What goals/requiremetns lead us to wish to include
other elemetns and in 2 cases NOT use g^xy at all in SKEYID?
I have seen the assertion that SKEYID is a SIMPLE as it can be and yet
meet all the requirements. I've also seen the assertion that these other
data elements in SKEYID are ESSENTIAL to security. Well then, it sounds
like something I as an impelementor should be able to understand. I need
a document showing the design reqirements, how they lead to the current
SKEYID derivations and how these decisions shore up security. Preferably
in the form of a few added paragraphs to the son-of-ike draft. Please.
--
Ricky Charlet : Redcreek Communications : usa (510) 795-6903
Follow-Ups:
References: