[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SOI QUESTIONS: 2.3 Authentication styles
Well about 10 people have so far spoken up in favour of legacy auth. Unless
11 people are waiting until the last minute to voice their opposition to
legacy auth, I'd say the support is there.
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: Dan Harkins [mailto:dharkins@tibernian.com]
> Sent: Thursday, June 20, 2002 1:15 PM
> To: andrew.krywaniuk@alcatel.com
> Cc: ddukes@cisco.com; ipsec@lists.tislabs.com
> Subject: Re: SOI QUESTIONS: 2.3 Authentication styles
>
>
> You're putting (different!) words in both our sentences and then
> unsurprisingly coming to an incorrect conclusion that this is a
> issue of semantics. Stop doing that.
>
> What I said was that we have not yet determined whether the thing
> Darren assumes exists (and is continuing) in fact exists. This is
> a process issue.
>
> Dan.
>
> On 20 Jun 2002 12:48:41 EDT you wrote
> > 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.
> > > > >
> > > > >
> > > >
> > >
> >
>