[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Granularity of authentication in swIPe



>How does this relate to IPSP/swIPe?  It occurs to me that swIPe would be
>  a potentially better way for us to go in the long-term, but there is
>  an implicit assumption in the protocol that an authenticator is bound
>  in some way to a source ip-address, and not an individual user of the
>  network.

	I don't think protocols like swIPe are going to solve the
problem of distributed TCBs (sorry!)  :)   In effect, swIPe gives
you the ability to rely that packets claiming to come from host "alice"
that you have exchanged keys with are indeed from that host. It also
ensures (within some reasonable tolerance) that the data hasn't been
inspected or tampered with in transit.

	swIPe isn't going to be able to solve the problem of
distributing trust between networks -- in other words, if host "alice"
has yet another sendmail hole that lets anyone on "alice" become
root, then you can't really trust that "mjr@alice" is in fact "mjr" --
it could be anyone. One might attempt to address this by pushing one's
authentication up into the application layer, and doing encrypted
application-to-application communication (something I think there
is a place for) which would possibly be more resistant to spoofing
userids -- but the problem remains that someone who is smart/motivated
enough to swipe a live TCP connection is also smart/motivated enough
to steal a connected tty/pty session. Suppose "mjr@alice" is using
encrypted telnet with kerberos authentication and key exchange to
log in as "mjr@bob". Let's imagine that Bad Guy has properly prepared
himself, and simply punches down into /dev/kmem and rewires a few
sockets manually, so that "mjr@alice"s established terminal session
is now connected to Bad Guy's terminal. He's "mjr@bob" and he's
authenticated, validated, etc.

	In short: untrusted hosts remain untrustworthy. :)

	All that being said, I think there are very good uses to
which tools like swIPe can be put. First and foremost, we need
something we can experiment with, to see how some of the problems
I've described above actually *work* in real life. After all, if
we sit back and try to design the perfect be-all-end-all system,
we might overlook something we'd have discovered if we had a
chance to actually experiment with (and improve on) things like
swIPe. That is, unless I'm mistaken, The Internet Way.

mjr.


Follow-Ups: