[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC requirements
Several of the things which you said make no sense to me:
> From: Marcus J Ranum <mjr@tis.com>
> If the trust boundary is your trusted machine, you can't
> assume that data from an untrusted machine is authentic. Even if
> it's authenticated and has the IP security stamp of approval.
If it's authenticated, then it _must_ be a trusted machine. You have
already shared a secret or otherwise added that machine to your web of
trust. I don't understand how it could be authenticated otherwise.
You seem to be confusing application authentication with IP
authentication.
> To put this another way: would you let traffic through
> your firewall if it was protected by IP security options and
> was coming from an authenticated user logging in from, say,
> gnu.ai.mit.edu, or a public access machine? I wouldn't.
Again, why would you have added such a machine to your IP security
associations, except that you trust that machine's administration?
All that IP authentication guarantees is that the traffic is arriving
from the machine which claims to have originated the traffic.
So, yes, I would certainly let a public machine access my machine, given
that I had a security association with the machine.
(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.)
> 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?
And why wouldn't I be using my own trusted laptop?
Again, login is an application authentication. IP authentication has
nothing to do with Kerberos.
> Your trust boundary is going to encompass all the systems
> you control, or the systems people you are willing to trust
> control, and nobody else.
That's right.
> That's the *CURRENT* situation with
> firewalls
HUH? Firewalls merely allow certain IP addresses/protocols through.
They say nothing about trust, and nothing about control!
For example, every time I go to IETF, I have to get the firewall where
my POP3 server is located to allow a range of IP addresses through.
That doesn't mean we either trust or control those addresses. It just
means that we have limited the expectations of where such POP requests
might originate.
The authentication of the POP3 request is what establishes the trust of
the session. And that is easily compromised, which is why we want
something better.
Moreover, we know that practically everybody who goes to IETF is capable
of sniffing the application authentication as it goes through. Do I
trust _everybody_ at IETF? Hey, you're fine folks, but hell NO!
Sorry, as I said before, firewalls don't buy you _anything_ except a
buffer against malicious "denial of service" attacks.
Otherwise, they are worthless, a pain to administer, and nothing but
trouble for the users, whether stationary or mobile.
The IP authentication will completely obsolete firewalls, because it
_does_ add trust and control.
Bill.Simpson@um.cc.umich.edu