Re: SOI QUESTIONS: 2.3 Authentication styles

[Dan Harkins <dharkins@tibernian.com>]

  Darren,

  Support for legacy authentication is not continuing; it has not even
started yet. That's what this discussion is about, determining whether
there is support for legacy authentication. At the end of this discussion
we'll know whether there is WG consensus to support legcay authentication.
Some CRACK-like extension won't be added unless the WG supports it.

  If you feel strongly one way or the other please make your opinion known.

  Dan.

On Thu, 20 Jun 2002 11:02:32 EDT you wrote
> So Dan et al., as long as the support for legacy auth in IKEv2 continues
> should we expect a CRACK-like addition to the next IKEv2 draft?
> 
> From: Dan Harkins
> >
> > On Wed, 19 Jun 2002 11:25:31 PDT you wrote
> > >
> > > >2.3.A.)  Does SOI need to natively support "legacy authentication
> > > >systems"?
> > >
> > > As draft-ietf-ipsec-revised-identity points out, if SOI supports
> > > preshared secrets that are not tied to IP addresses (that is, where
> > > each party says what ID is associated with the preshared secret it is
> > > using), legacy authentication comes for free. The only requirement on
> > > the legacy authentication system is that it returns authentication
> > > proof that is large enough to be broken into an ID and a preshared
> > > secret, and that the preshared secret part is not susceptible to a
> > > dictionary attack.
> >
> > That's not necessarily true. IKEv2 supports pre-shared key authentication
> > but the Responder has to have access to the Initiator's secret to
> > authenticate her. In popular remote access scenarios that is not the case.
> > The secret is known by some backend server (like a RADIUS server) which
> > is not part of the exchange and the Responder would only pass a blob off
> > to the server and get back a yea, nea or continue.
> >
> > Basically a remote access solution requires that the Initiator present
> > her credentials and not just prove possession of them. This also means
> > that the Responder should authenticate first to establish a secure
> > channel in which she can place them.
> >
> > It would be easier to graft legacy authentication support onto JFK
> > than IKEv2 since in JFK the Responder authenticates first but it
> > would not be hard to do it with IKEv2 either. CRACK did it for IKEv1
> > and something similar could do it with IKEv2.
> >
> > To answer Ted's question though I think this is absolutely necessary.
> > Lots of problems with IKEv1 had to do with the fact that we ignored this
> > subject and people attempted to add it in various ways after the fact,
> > some more clumsily than others. That tends to work against
> > interoperability
> > and for single vendor solutions.
> >
> > We made a mistake by ignoring this the first time and it would be
> > a mistake
> > to do so again. PIC is not a solution to this problem.
> >
> >   Dan.
> >
> >
>