[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Use IPSEC as SSH replacement
"Perry E. Metzger" wrote:
>
> I had originally hoped, in fact, that IPSec would make tools like SSH
> unnecessary by providing upper layer tools sufficient information that
> they could simply ask the identity of the other side of any TCP
> session from the security layer and not need to manage any
> cryptography on their own at all. Sadly, things have not thus far
> worked out this way, but it is not an unreasonable goal for people to
> be striving for.
It seems that one of the greatest impediments to this is the perceived
vulnerability of the channel between the application and the ipsec
layer. I've been giving this a lot of thought lately due to the
implications this vulnerability has for using ipsec to secure the
(remote) configuration of ipsec-enabled devices. The argument I've heard
most often is that in this and many other cases, there is a requirement
for securing the data all the way to the (configuring) application, and
that our current implementations don't fulfill this requirement. The
diagram below illustrates:
+-------------------------------------------------+
| User Space |
| +-------------+ +--------------+ |
| | configuring | | rogue | |
| | (or other) | | |
| | application | | application,| |
| +-----------|-+ | | |
+--------------------|-------| code, +-----+
| Kernel Space +--|-------+ | |
| | ~ driver, etc. | |
| +--|-------+--------------+ |
| +--|-------------------------+ |
| | V IPSEC Layer | |
| +----------------------------+ |
+-------------------------------------------------+
In general, the user application seems to be vulnerable to the rogue
application in several ways: (1) unencrypted data may be inspected prior
to arriving in and after leaving the application, (2) unencrypted data
may be inspected within the user app's runtime memory, (3) any
additional (second factor) software authentication mechanism utilized by
the user application is subject to compromise via the same avenues.
I'm inclined to think that (3) renders the TLS case equivalent unless a
hardware device (such as a smart card) is added to the picture, and that
this really amounts to a problem of physical security. However, while
this may represent a tidy characterization of the ipsec-device-config
problem, it does not address the general case you refer to above, i.e.
securing user sessions on systems in arbitrary environments. This is an
interesting problem which may not have a solution outside of the
smartcard class.
Scott
Follow-Ups: