[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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