RE: Position statement on IKE development

["Glen Zorn" <gwz@xxxxxxxxx>]

Dan Harkins [mailto:dharkins@xxxxxxxxxx] writes:

>   It's not going to be any less extensible than it already is but unless
> there is a massive change of heart by our ADs it will not include legacy
> user authentication or keepalives or any of the other things that we all
> think users expect. If you remember, the Position Statement said:
>
>     "This effort is at serious risk of suffering the 'second system
>      effect', where all the features that were left out of the first
>      version, end up in the second.  For this to happen would be a
>      spectacular disaster, and very much detract from the goal: to
>      produce a more secure, simpler, and more robust version of IKE."
>
> I think if you ask Marcus or Jeff they would say that legacy user
> authentication and keepalives fall into the "second system effect"
> class of feature.

Only because the first system was flawed by design: to call legacy
authentication a 'bell' or 'whistle' is manifestly silly; but on the other
hand, so is designing a PK-based system in a world where PKI is a fond
dream...

>
>   If you also re-read the Position Statement you'll note that the
> moratorium is temporary until the process of cleaning and simplifying
> is done. I believe we can revisit things like legacy user authentication
> when the moratorium is lifted.
>
>   Dan.
>
> On Sat, 04 Aug 2001 02:09:08 MDT you wrote
> > Dan,
> >
> > Is there any plan to make son-of-ike extensible for things like
> legacy user
> > authentication, keepalives, etc?  Or will it just simplify the existing
> > solution?  Without adding this new functionality, I think that IKE will
> > still fall short of what user expectations are.
> >
> > Mike
> >
> > > -----Original Message-----
> > > From: Dan Harkins [mailto:dharkins@xxxxxxxxxx]
> > > Sent: Friday, August 03, 2001 4:35 PM
> > > To: Henry Spencer
> > > Cc: IP Security List; ietf-ipsra@xxxxxxxx; ipsec-policy@xxxxxxxx
> > > Subject: Re: Position statement on IKE development
> > >
> > >
> > >   I discussed this in Minneapolis. The plan is to combine ISAKMP, IKE,
> > > and the IPsec DOI into a single draft describing a key management
> > > protocol for IPsec.
> > >
> > >   The intent, as well-meaning as it was, was to have a
> > > generic language
> > > (ISAKMP) in which to describe a key management protocol and
> > > there could
> > > be many key management protocols with IKE as just one of
> > > them. IKE, then,
> > > was supposed to be a generic key exchange protocol which could create
> > > "SAs" for multiple services, of which IPsec (specified in the
> > > DOI) was
> > > just one. But IKE is the only thing that used ISAKMP and the other two
> > > DOI documents-- OSPF and RIP-- died a quiet death.
> > >
> > >   The benefit of having this artificial layering is nil and the cost
> > > (the nuisance factor you mention, the conflicting verbage,
> > > the unnecessary
> > > repetition of things, the incredible complexity it causes) is high so
> > > it is being done away with. There should be only one thing
> > > that listens
> > > on UDP port 500 and that is a key management protocol for IPsec which
> > > should be described in a (relatively) short and concise draft. I'm
> > > working on it.
> > >
> > >   Dan.
> > >
> > > On Fri, 03 Aug 2001 15:29:09 EDT Henry Spencer wrote
> > > > On Fri, 3 Aug 2001, Bill Sommerfeld wrote:
> > > > > > Therefore, I would suggest that any effort in replacing
> > > IKE also consider
> > > > > > replacing/rewriting portions of IPSEC DOI ...
> > > > >
> > > > > Last I heard, the son-of-ike plan was to merge the DOI
> > > into the key
> > > > > mgmt document.
> > > >
> > > > Realistically, there's no meaningful distinction between
> > > IKE and the DOI.
> > > > In fact, the separation between the two documents is a real
> > > nuisance when
> > > > one is looking for obscure details.  They need to be
> > > considered as a unit.
> > > >
> > > >
> > > Henry Spencer
> > > >
> > > henry@xxxxxxxxxxxxx
> > >
>