[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IKE must have no Heirs
Dan,
It has been somewhat difficult for anyone in the IETF security area in the
past dacade not to become familliar with the internal machinations of the
IPSEC group.
I would like something no more complex than SKIP that used RSA or DSA.
In 1995 SKIP would have been the right move. At this point to go forward
there has to at least be compatibility with the keying material that is
already distributed.
I would also like to see a more analytical approach to demonstrating the
correctness and security of the protocol. Something that was at least simple
enough to be the subject of a proof.
Phill
Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227
> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@lounge.org]
> Sent: Tuesday, August 07, 2001 10:23 AM
> To: Alex Alten
> Cc: Kory Hamzeh; Hallam-Baker, Phillip; 'mcnelson@mindspring.com';
> ipsec@lists.tislabs.com
> Subject: Re: IKE must have no Heirs
>
>
> It was called SKIP. I suggest you guys familiarize yourselves with
> this WG.
>
> Dan.
>
> On Tue, 07 Aug 2001 00:28:20 PDT you wrote
> >
> > I second the motion. And also propose no port number (i.e.
> do the new
> > one over raw IP).
> >
> > - Alex
> >
> > At 11:07 PM 8/6/2001 -0700, Kory Hamzeh wrote:
> > >
> > >Well said. I agree with you 100%. Throw is out and let's start from
> > >scratch with something more reasonable and realistic.
> > >
> > >Kory
> > >
> > >
> > >On Mon, 6 Aug 2001, Hallam-Baker, Phillip wrote:
> > >
> > >>
> > >> > Unfortunately the notion that IPsec should simply \"bind
> > >> > a key to an IP address\" was rejected repeatedly throughout
> > >> > the history of the IPsec WG.
> > >>
> > >> This is why I think we have to stop talking about 'son of IKE'
> > >> as if the problem was in the 7 years and 9 months of trying to
> > >> implement the requirements and not the 3 months of requirements
> > >> capture.
> > >>
> > >> [ ..... ]
> > >>
> > >> From here there are two routes forward. We could specify
> a reduced
> > >> IKE, eliminating all but 2 of the current 8 modes,
> simplifying the
> > >> negotiation, knife AH... to result in a simpler draft
> that we can be
> > >> confident would get a broad review. I think that would
> have been an
> > >> excellent idea three years ago, I think that it is too late after
> > >> the interop tests have been performed. All that would come out
> > >> is a description of a profile of the current spec that resulted
> > >> in one configuration that was secure. But implementations would
> > >> still be constrained by the existing legacy base which would
> > >> drag deployments back into the mire of unexamined code paths and
> > >> unanticipated interactions.
> > >>
> > >> The second is to burn the current drafts and start from scratch
> > >> with a fresh port number. If any change is made that breaks
> > >> backwards compatibility then this might as well be what you do.
> > >>
> > >> In short the phrase 'Son of IKE' is part of the problem, not
> > >> the solution. IKE must have no heirs, it is time for a
> new dynasty
> > >> to take the throne.
> > >>
> > >>
> > >> Phill
> > >>
> > >>
> > >
> > >
> > --
> >
> > Alex Alten
> >
> > Alten@Home.Com
> >
> >
>
Phillip
Follow-Ups: