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

Re: swIPe available for FTP.

	 
	 >The second problem is the lack of filtering on input.  That is, you
	 >may have a key -- which guarantees authenticity -- between you and
	 >some host Foo.  But no check is made to ensure that packets from Foo
	 >are properly encrypted.  This means that you can't trust a received
	 >packet; you only know that genuine packets haven't been tampered with
	.

	 Can you explain this on more detail? Just curious.

Let me use this message as an opportunity to respond to several other
folks as well, and to further explain my thinking.

First of all, I'm not criticizing swIPe (at least, not yet...).  In
fact, though I'd advocated similar ideas in the past, the availability
of tangible code made me think about just how I'd deploy it, how I'd
really use it, today.

My tentative conclusion was that the current implementation -- as
opposed to the architecture -- is deficient, in that it doesn't let me
do the sorts of things I'd like to do.  Nor do I find most of the
suggestions by the designers to be suitable.

The basic problem is that the application has no knowledge of the
cryptographic state of an arriving packet.  It thus does not know what
sorts of activities are appropriate.  Consider, for example, a login
process.  If the stream is encrypted, a simple password may be
accepted; if not, perhaps it will demand a one-time password.  But
there's no way for it to know with swIPe; the best it can do is tell
what policies will be applied to outgoing packets.  Similarly, consider
a Morris sequence number attack on rsh.  Network-level authentication
should prevent this, since it provides one with strong assurance of the
source of the packet.  But that information has been lost by the time
rsh sees the input data.

Another example would be a cryptographically protected tunnel from
outside of a firewall.  Again, the tunnel relay doesn't know if the
packets are really genuine.  The suggestion made here is to have an
external filter that drops unswIPed packets from sources that should
know how to encrypt them.  The problem, though, is that implementing
this scheme requires that the same information be in two places.
Maintaining consistency here is *hard*.  At best, a single high-level
tool could parse a single configuration file and tell two different
gadgets what to do.  (The filter gadget might be an internal per-host
component, or it might be a border router.)  I'm willing to ignore the
race condition, at least for now -- but I'm still not happy with
putting such a delicate data structure in more than one place.

As JI has noted, implementation of the kind of capability I want is
rather difficult in a Berkeley-derived socket() environment.  My first
thought was to look up the source address on all incoming packets, and
to determine what security policy should have been associated with it.
The expense of that could be offset by caching; most incoming packets
will be followed very quickly by a reply which will need the same
information.  And you can integrate the security function lookup with
the outbound routing table.  Such a scheme would, I think, work, but
the implementation is likely to be more complex than I'd really like.
(I've become quite allergic to complexity in my declining years....)  A
better model might be to mimic what RFC793 says to do for the security
option.  When a protected packet arrives, add a pseudo-IP option to
it.  Delete any such option arriving from vanilla interfaces, of
course, though you may want to preserve the notion of a `secure'
interface protected by outboard cryptography.  An application can use
getsockopt() to find out what policies are in force for that
connection.  Similarly, it can use setsockopt() to require some
policies -- and packets arriving with the wrong option should be
dropped.  (RFC793 requires that TCP abort the connection via RST; I'm
not sure which is proper here.  In an environment without true
multilevel security, dropping the connection might leave you open to
denial of service attacks.)

I think this conveys the sense of my objections, and what I'd like an
implementation (as opposed to an architecture) to look like.  None of
this is cast in concrete (or even etched in silicon), of course.  But I
think we need to decide what we want our security mechanisms to do, in
our real world, before we deploy them.

As for key management -- it's probably just as well that it isn't there
yet.  I don't completely agree with mjr that it would be a negative
feature; what I do think is that we don't yet understand what it should
look like.  swIPe will provide us with a platform for experimentation
and development -- but only in the context of application and site-
specific needs.

		--Steve Bellovin