On Thu, 7 Jun 2001, Ben Nagy wrote: > > Nothing on the market currently prevents a malicious client > > from being the > > source of authentication, and that's the biggest tunnel issue > > out there-- > > the "Microsoft source code out the window" stuff. > > I take it you're talking about Joe Luser VPN'ing in to work when his PC is > already r00ted by some trojan, or similar circumstances? I've seen at least It's true not just of VPN tunnels, but yes, that is probably the predominantly hanging vector. > one client (Cisco - the old SafeNet one) that can chop off all other traffic > if a VPN connection is up. That doesn't prevent time-bombs, but it does I proposed this as a fix at an NISSC panel discussion on VPNs I particpated in back in '98. Back then I think it was potentially valid- but now-a-days I'm thinking it's actually less useful than it would appear... The problem is that everyone seems to _require_ HTTP/HTTPS access these days, so there's your trojan's control vector happily provided either directly, or via the corporate firewall. That doesn't even speak to the "malcode designed to defeat such blocks" issue, which may become an issue if either you're targeted specificly or a given solution obtains significant mindshare. In pure terms, virtual systems bring a whole new class of problem, and the physical realities of home-based workers start to make such attacks at least interesting- though probably too far down the line to delve into now. > > VPNs are sold as security solutions when in reality they're > > trust boundary > > weakeners- if you understand their limitations, then > > deploying them isn't > > as much of an issue as if you don't understand that key point and go > > happily extending trust to every employee and business partner's own > > private networks with their own weak and weaker trust boundaries. > > Yeah, that's all pretty much true. It's exactly the same as the dialup > problem, really. Many VPN clients are now configured to effectively only > need one password - not even a username/password combo. After that the > tunnel is up and people can start grinding at the network for second-tier > logons. It's not exactly the same as the dial-up problem because it pretty much requires you to be on a shared public network with inband control signals. If you employ client-side filtering, then it begins to approach the same order of problem though. > So, to go back to a throw-away point you made, Paul: > > > I've always thought that it would be interesting to extend the firewall > > paradyne to be more of a trusted introducer than a particularly heavy > > generic policy engine, and have firewalls enforce trust relationships > > rather than connectivity relationships > > I had a crazy idea which I posted a long time ago, involving LAN PCs all > having IPSec Ah-only SAs with the firewall. Using L2TP in IPSec stuff you > can also make this effectively a username/password auth which would allow > for nice portable trust relationships based on users rather than boxes. You > seem to be talking about a similar thing - could you flesh your concept out > a little? Well, we have two classes of authentication and security issue to deal with in the terms I'll present this in: The unknown and external attacker and the internal attacker. Most security problems are easily overcome for the transit case, such as SSL shows us can be done (ignoring for a minute the anonymous connecting issues because I think we'll take care of them in the schema.) So if I connect to my corporate gateway, using whatever local connectivity and authentication mechanisms are appropriate for that particular entity, then that gateway basicly proxies authentication credentials on my behalf (sort of an electronic trusted introducer) then I'm able to start to solve the "Who's connecting" issue from the company perspective-- obviously a compromised internal authentication becomes a weak point, but the risk and blame for that can be apportioned on a business entity- without having to solve the really difficult last-mile issues. I've always proposed extending it though, so that the switch auths the machine, and then the gateway checks with that to see if the machine has used valid credentials... Add in some group stuff and service type things and you can start to provide some rather interesting trust modeling, quarentining, approving, accepting or simply rejecting anything for which there isn't an existing trust relationship by authenticating authority, service, date/time, etc. If it's extended out further, it could also form the basis of a "like policy" relationship by the addition of a certification or arbitration broker. Things like "approved adminsitrative access for a certified vendor who's been audited by XYZZY in teh last month" could eventually become an access policy trust decision. Add in some insurance and assurance stuff and it becomes a fairly workable scheme. IPSec looks like an interesting first step, and I've got a few more schema and application extensions that I'm pondering or have briefly outlined here and there. I think though that I need more time to go back over the older stuff and see what makes sense where, as well as make sure I'm not stepping on anyone's toes on some things that I haven't put in this note. I'm starting to merge a few things I've tried to get going over the years with some realistic business-friendly concepts that don't require overly complex setups. Leaving trust revocation to a local entity does seem to scale well though- so long as a good arbitration scheme can be worked out for places that mess it up. Paul ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions proberts@patriot.net which may have no basis whatsoever in fact." - [To unsubscribe, send mail to majordomo@lists.gnac.net with "unsubscribe firewalls" in the body of the message.]