RE: SOI QUESTIONS: 2.3 Authentication styles

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

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.
>
>