RE: SOI QUESTIONS: 2.3 Authentication styles

["Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>]

Guys, can we try to avoid debating semantics. Darren said "as long as
[public] support for legacy auth in IKEv2 continues". Dan said "[protocol]
support for legacy authentication is not continuing." Both are valid uses of
the word "support". Dan, you even used both meanings in the paragraph below.
This isn't ukases.

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.



> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins
> 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.
> > >
> > >
> >
>