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

RE: Altenatives for IKE and legacy user authentication combinations



Sara and Tamir,

> > - One of the requirements that appear in the proposed charter, is to
> > have multiple entry points to the network.

I agree with Tamir.

The only real advantage of a solution from category 1 (Legacy user
authentication before IKE) is that you could deploy a CA and Radius server
out on the Internet somewhere (on a network not protected by legacy auth).
The client tunnels to this network (or single machine), does a Radius
authentication, and the CA gives it a temporary cert.

What is the advantage of this approach? The advantage is that the client can
now use the cert to connect to multiple legacy auth-protected networks (if
they have the same user database) without prompting the user for a login.

But how realistic is this scenario? 

Imagine the fairly ridiculous case of a road warrior who needs to get his
e-mail from his home office in San Fran, then connect to Australia to access
some documents, then browse the intranet at the Central Europe office?

What is the chance that this company is using legacy auth at each branch
office (with the same user database)?

It seems far more likely that the user will simply tunnel into his home
office in San Fran (using legacy auth) and then access the remote offices
using the fast, permanent tunnels that exist between the various branch
offices.

This keeps the configuration of the user's DNS, WINS, Routing, Internet
Proxy, etc. settings as simple as possible.


But if the user is only going to be connecting to ONE REMOTE OFFICE using
legacy authentication, then all the entry points to that office are
REDUNDANT (as far as the client is concerned) and can thus share IKE state
information as Tamir pointed out.

I really can't think of any advantages of a category 1 approach, unless the
legacy authentication takes place on a dedicated server (which is what I
thought Steven was proposing, but which does not appear to be the situation
Sara is discussing).

And in that case, the only real advantage is that this server takes some of
the load off the sgw.


To address the other Category 2 (Legacy user authentication during IKE) Cons
suggested by Sara:

> > - Need to change IKE. Increase the complexity in IKE, which 
> is already
> > too complicated.

Yes, we all know complexity is bad, but this argument is too quickly
becoming the first resort of those who have nothing important to say. It's
almost as bad as [CENSORED].

Honestly, some of the arguments I've been hearing... "Such and such about
IKE is bad because it is too easy for the user to misconfigure." 

Doesn't anyone have GUIs for their products? Some of the comments you hear
make it sound like the user has to choose the security level by typing it in
as a raw SA proposal payload.


> > - If the user is authenticated between phase 1 and phase 2, 
> phase 1 is
> > completed before any authentication is taking place. This 
> phase one must
> > be thrown away.

I don't even know what this means. Why would you "throw the phase 1 away?"
Is this some kind of wierd requirement for ID PFS? 

Andrew
_______________________________________________
 Beauty without truth is insubstantial.
 Truth without beauty is unbearable.