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

RE: New XAUTH draft



> 
> I'd like to add a voice in favor of separating the legacy user
> authentication mechanisms from IKE. There are several arguments
> supporting this separation:
> 
> * First and foremost, IKE is hard to analyze and implement  correctly
> as is. Adding modes and functionalities will only make it harder.
> KISS (keep is simple and secure)!
> 

IKE is hard to implement, and it took a long time to get it right.  However,
the problem is that we need to provide a secure, easy to use way of
providing legacy system authentication.  So, what's the *best* way to do
this?  

> * IKE/IPSEC is primarily meant for host-to-host protection. User
> authentication seems to be best done on top of IKE/IPSEC,
> not as a part of it.
> 

I believe that user authentication IS part of IKE.  Don't let the user into
your network until he's been authenticated.

> * Having relatively simple and separate modules is a nice 
> feature of the
> IPSEC suite, as opposed to other, monolythic security 
> protocols. Let's keep
> it this way.
> 
> 
> A seemingly "natural" alternative to XAUTH is to first do 
> IKE, and then
> complete the user authentication via the IPSEC-protected connection
> (using either AH or ESP). Are there overwhelming arguments to 
> not do it
> this way, and break the modularity of IPSEC?
> 

I have heard many say that this is a bad alternative for several reasons.
One of those reasons is that you end up setting up multiple IPSec SAs which
should only live for a few minutes.  Let's suppose that you need to talk to
3 different devices in order to authenticate / manage a remote user.  For
example, a user might need to talk to a DHCP server, a RADIUS accounting
server, and an SDI server.  Then, the SG might need to set up 3 IPSec SAs
before he's given full access to the network.  This not only takes away from
the entropy of the phase 1, but creates SA management nightmares as well as
slow down an edge device.  If your device is supporting ten thousand remote
users, setting up all these SAs is very expensive.

Also, many people are adverse to letting anyone onto their network at all
until they are fully authenticated.  Setting up special conditions for
management / authentication servers would require special care, and would
require that all of these servers are invulnerable to attacks.

P.S Hopefully we can resolve all of these issues at the IPSRA BOF in Oslo :)

regards,
Stephane.


Follow-Ups: