[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC Security Gateways & NAT
On Thu, 14 Jun 2001, Ricky Charlet wrote:
> Howdy,
>
> Question below:
Answer 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
I don't think that Dan was suggesting what you say, but in any case
such suggestion would make all non-signature modes insecure.
In particular, the preshared mode.
> 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 written a note intended to give a high level answer to this.
I'll send it next to the list.
>
> 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.
The note is trying to explain this too (btw, what I called "essential" is
the fact that SKEYID needs to be different in the different modes).
The note maybe a bit too long to be included in son-of-ike draft,
but Dan is welcome to transcribe any information from there to the
draft.
Hugo
>
> --
> Ricky Charlet : Redcreek Communications : usa (510) 795-6903
>
References: