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
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
