RE: SOI QUESTIONS: 2.3 Authentication styles

["Darren Dukes" <ddukes@cisco.com>]

Dan,

  I should have preceded 'support' with 'WG', regardless you answered my
question.

Thanks,
  Darren

> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@tibernian.com]
> Sent: Thursday, June 20, 2002 11:39 AM
> To: ddukes@cisco.com
> Cc: Paul Hoffman / VPNC; Theodore Ts'o; ipsec@lists.tislabs.com
> Subject: Re: SOI QUESTIONS: 2.3 Authentication styles
>
>
>   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.
> > >
> > >
> >