Thanks Ben: Being an IPSec fan, I like this approach. When I last looked at this, it was slow and the deployment was difficult because it typically required client SW and deployment of client certs. The 100Mbps crypto NICs from Intel and 3Com are cheap, the OS's have native IPSec in the stack and it's easy to config, and the IPSec RA group is proposing solutions for IP client config and an alternative to client certs which would use legacy auth.
> I've been > advocating internal IPSec for years. Has anyone deployed it? Any issues? Successes? > As we all know, Microsoft is now favouring IPSec > throughout the LAN, Do you have any pointers to MS info describing this? Thanks, Eric Bomarsi --- Ben Nagy <[EMAIL PROTECTED]> wrote: > I think it's clear that there's an evolution in the > direction of > ubiquitous IPSec - even leaving aside the fact that > it's more or less > built in to IPv6. The hardware is there to support > it (NICs with crypto > offload processors, single-task VPN gateways), the > user-based > authentication infrastructure has now come up to > speed - the only thing > that might not be out-of-the-box is a good > accounting regime, but it > should be easy to piece together out of RADIUS + > bits and pieces. > > As we all know, Microsoft is now favouring IPSec > throughout the LAN, > using Kerberos for station-to-station auth and their > own Beautiful Brand > of user auth. Say what you will about their > implementation of the two > protocols, the paradigm is good and they have the > market push to drive > it into at least the frontal brains of all the > sysadmins out there. > > As a user-based-auth technical aside, MS use L2TP > over IPSec, which gets > around the user auth problem at a higher level than > the machine-level > auth. Protocols like Cisco's Xauth (which is likely > to remain in IETF > draft form more or less forever) build user-based > auth into the actual > IKE part of IPSec itself, which is nice. Reading the > initial working > draft for IKEv2, one gets the impression that some > user-auth stuff is > likely to be folded into son-of-ike by the time it > gets done. Other > vendors may also have proprietary ways of folding in > user based auth, > but do be aware that it's not really part of "pure" > IPSec in any way. > > Also, remember that you don't need to run the > encrypted part of IPSec > unless confidentiality is one of your concerns - you > can quite happily > run AH only and get strong authentication and > session integrity. That > may be quite enough for some people, and still > leaves packets open for > sniffing on the internal LAN, which is useful in > many cases (internal > IDS systems, HTTP accounting software, legit > administrative > hunter-seeker activity etc). > > In short, I think that IPSec is the best way to > handle your problem, and > that it will become the default way as time goes by. > I've been > advocating internal IPSec for years. > > Cheers, > > -- > Ben Nagy > Network Security Specialist > Mb: +61 414 411 520 PGP Key ID: 0x1A86E304 > > > > -----Original Message----- > [...] > > > > I am interesting in hearing from people who > have implemented user > > > > based AAA for internal access to > > > a > > > > secure data center or similar deployment.[...] > __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
