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

Re: SOI QUESTIONS: 2.3 Authentication styles



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.