[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC requirements
I'm willing to drop this discussion, btw, if there's a
feeling that it's going too far off-track for IPSEC. Let me know.
The reason I'm pursuing this is because I do think it's very
important that whatever IPSEC options evolve are going to need
to work properly with firewalls. What those firewalls look and
act like is a subject of debate. :)
I'd like to define two terms I'm using, FYI:
Firewall -- a system or combination of systems that
enforces a trust boundary at the perimeter of an isolated
network. This may be application level *or* IP level. Masataka
Ohta asserted that all firewalls are IP level systems -- I guess
he's not familiar with the work Cheswick and Bellovin and I
have been doing, which is mostly application level.
Virtual network perimeter -- a network consisting
entirely of trusted links, some of which may be running over
untrusted links via encapsulation/encryption. Link state
*typically* relies on some form of authentication, e.g.,
an authenticated PPP link, or an authenticated encrypted
IP point-to-point route. I think of a virtual network
perimeter of consisting of *HOSTS* *AND* their users.
Conceptually, I think of a virtual network perimeter
as "tunneling through" or "going around" or "gatewaying
through" the firewall. In other words, if you're a member
of the virtual network perimeter, the firewall is transparent.
If you're not, the firewall may stop you, force you to prove
who you are, or whatever, before letting you through.
The reason I draw these distinctions is because, in
my mind at least, the firewall is "gone" if you're a member
of the virtual perimeter. By extension, all members of the
virtual perimeter are "trusted" to some degree [to whatever
degree you'd trust any other machine on your LAN/WAN that
was behind your firewall].
What I suspect most folks are looking for (myself
included) is tools for building virtual network perimeters.
Where things get interesting is if the tools are going to
be extended to permit *USER* membership in the virtual
network perimeter.
I think that's where I have been confusing people,
and I aplogise if the discussion I've started is unproductive.
Host-level membership in the VNP is not a big deal,
since you're implicitly trusting the host and its users,
since you trust the administration of that host. The problem
that I think is going to require some really careful thinking
about is if we try to design a mechanism so that an individual
remote *user* can gain access to the VNP without being on a
host that is a member the VNP. In firewalling terms, the way
this normally works is you somehow authenticate yourself to
the firewall (as an individual) and it thereafter waves you
through. Present technologies for doing this are cumbersome
and could use improvement [any of you who have seen those
of us at conferences who telnet/rlogin through our firewalls
using application level relays with handheld calculators
should be familiar with the level of transparency of these
approaches]
Perhaps this clarifies my original remarks. Now I'd
like to discuss some extracts from the mail from Steve Kent
and Bill Simpson in that light.
Steve Kent writes:
>First, you need a network, not a link layer, protocol for
>integrity and confidentiality, and that is what IPSP will provide. It
>will provide this service not only on an end-to-end basis, but also on
>an enclave-to-enclave or an end-to-enclave basis.
> As for authentication, I disagree with your assertion that it
>is best performed only at the application layer. For single user end
>systems, such as desktop workstations and laptop/notebnook computers,
>authentication provided at the network layer is essentially
>equivalent, in terms of its granularity, to user authentication
Steve is, of course, 100% right. I believe my original
remarks which prompted this response were a result of my confusing
the objectives of the authentication system. What Steve is referring
to here appears to be what I'd call members of the VNP -- they're
all trusted hosts.
Where I get confused is whether one of the objectives
of IPSEC is to permit individual user membership in the VNP.
That was what prompted my remarks about authentication being
best at the application layer. If I'm at a remote site, on
a trusted host that's part of my VNP, then of course, I won't
have any need to do anything especially fancy. If, however,
I am at a remote site, on an untrusted host, is it the case
that IPSEC doesn't help me at all? That's OK, if so, I'm just
trying to delimit the problem space.
This is what prompted my remarks a few weeks ago
that, in effect, we're never going to be rid of firewalls.
Not until we have a robust means of bringing an individual
*user* on an untrusted host into our VNP. Until we can do
that, then we'll have firewalls. [Even if we do, it's
likely that the thing enforcing the access will be called
a "firewall"] [And I'll be building them.]
Steve Kent writes:
> Note that I'm not talking about such things as signing
>software being retrieved acrosss the net or the like, but rather
>reletuive merits of access control measures enforced at the network
>vs. application layer, based on authentication provided at the
>respective layers.
I think we're in agreement, but that I simply didn't
explain my question adequately before. :( Succinctly put, I
don't think that network layer access control measures work
as well as application layer access control measures if the
remote member is an untrusted host. I'm not sure that application
layer approaches work *either*.
Bill Simpson writes: (in response to me)
>All that IP authentication guarantees is that the traffic is arriving
>from the machine which claims to have originated the traffic.
Precisely. And what I'm saying is that this doesn't
buy you much. It means the machine can (possibly) become a member
of your VNP. That's a far, far, far step from "getting rid of
firewalls" which some members on this list seem to think this
is going to do.
Bill Simpson continues:
>So, yes, I would certainly let a public machine access my machine, given
>that I had a security association with the machine.
In other words, if you trust it.
This concerns me. After a while, there will be some
really interesting opportunities for island-hopping attacks
along the strands of the web of trust. [excuse me for being
poetic] This is not really solving a security problem; it's
just developing a tool for building secure virtual perimeters.
Bigger, better firewalls. That's fine with me, but let's be
clear that what's happening is further balkanization, not
an increase in the trustability of the 'net.
Bill Simpson continues:
>(FYI, I exclusively use public access addresses here in Michigan, and
>the firewall which filters traffic allows such addresses through. Note
>the first "received" in this very message. Anyone could spoof being me,
>except that the public access addresses authenticate the users with PPP,
>so the spoofer could ultimately be traced.)
Your PPP node is then part of your VNP, even though
you're not encrypting/authenticating your traffic. So your
firewall is trusting your PPP node. What do you do if you
are logged onto an *untrusted* outside node?? Presumably when
you are, then you have to do something more elaborate to get
through your firewall, no?
Bill Simpson writes: (in response to me)
>> Kerberos is a similar situation. ... Suppose
>> I modify the "klogin" program on my workstation and you use
>> it to log into your home machine. The kerberos part of the
>> system is still perfectly strong, but I now know your kerberos
>> password and can be you.
>
>Why would I have added your workstation to _MY_ IP security
>associations?
Clearly, I see no reason why you would! That's my
point. This system isn't really improving security or
trust, it's just letting folks build bigger, better
trusted virtual network perimeters. We're not making
firewalls go away, and we're not improving the security
of the 'net at all.
>And why wouldn't I be using my own trusted laptop?
If all you're trying to do is build bigger,
better firewalls, then definitely, there's no reason
not to use your own trusted laptop. :) You're not making
the firewall go away -- you're just inventing a magical
way of moving your laptop (virtually) behind the firewall.
mjr.
Follow-Ups: