Sletten Kenneth W KPWA wrote [excuse the length history here]:
>
> Wirt writ after Mark Bixby rightly wrote after Jeff (sorry......):
>
> > > The problem with SSH is that special clients and servers
> > > are required.
> > >
> > > It's a far cleaner solution to do security transparently at
> > > the IP transport layer so that no applications have to be
> > > modified.  This is the VPN approach.
> >
> > That is exactly correct. This is the right and proper place to
> > put the security process: at the transport layer. Security
> > should be a process that is completely invisible to everything
> > above it ........ This is the the simple and elegant solution.

> Even at my admittedly limited level of expertise in this area, so
> do I:  "Special clients and servers" quickly brings on unhappy
> visions of major re-writes to complex com systems....  Doing
> IPsec at transport layer and maintaining complete segregation
> of apps and security code seems to be much preferable....

To play devil's advocate, no more "special" than, uhh, NS/VT.  And you
are not talking about rewrites to complex systems, only the client.
It is built upon a telnet client, it just has a slightly different
model for authentication (no worse than Kerberos, LDAP, Secure-ID, etc)
and an encryption model between the client and the network.

> I also go back and pull out last sentence from Mark's email;
> that Wirt did not include:
>
> > FWIW, Windows 2000 supports IPsec, so I want to applaud
> > Microsoft (gasp!) for doing the right thing in this area.
>
> Especially since Win2K handles IPsec out of the box, from
> our perspective getting IPsec support on the e3000 would be
> big step forward......  maybe even a giant leap....  A little site-
> specific background on why this is so;  without (for obvious
> reasons) getting too detailed (expect many on this list could tell
> similar variations on this theme):

I would readily agree, especially putting it on the box; but the
traditional role of VPN is being handled externally (in a router, in
a firewall, or in some external box).  And in those cases it is not,
by default, all that granular.  It is a gateway into an internal
*network*, not just an internal *host*.  And granularity is important.

SSH (and SSL and HTTPS and so forth) are essentially point to point,
while modern VPN is point to intranet, and even older IPSec was net to
net.  Indeed, for geographically disperse sites running over the
internet, the border routers would use IPSec to encrypt the traffic
between sites and tunnel it through encapsulated IP, and users of the
connected sites were gleefully ignorant of the encryption.  This
progressed through DES-40, DES-56, and more recently DES-128 and 5DES
(think md5).

VPNs, to answer a question asked earlier by Jerry Mogelinski:
  "Can someone kindly describe how VPN works..."
are a granular extension of the original net-to-net encryption.  By
placing a proper client on your PC (Yes, Virginia, it still requires
add-ons, just not replacement for your network clients) it creates a
"virtual network interface" and routes a given subnet(s) through that
virtual interface rather than your normal network card.  The virtual
interface establishes a tunnel to the VPN device on the other end,
whether a server, a dedicated VPN concentrator, or a router, using
traditional IP addressing, but it opens a "tunnel" for your secure
network connection from end-to-end encapsulated (and encrypted) inside
a common, ordinary IP packet.  When received on the other end, the
encapsulation is removed and the decrypted payload packet is placed on
the secured network.

There are still a number of encryption and encapsulation schemes, and
yes, while Microsoft supports some of them, they made up some of their
own in the process.  Older versions supported only PPTP (Point to Point
Tunnelling Protocol) which required a like server to connect to for your
initial network connection.  Newer ones support the more generic L2TP
(Layer 2 Tunneling Protocol) which can open an tunnel over whatever
transport method you have active, but likewise requires a
similar-speaking device on the other end.

VPN is still essentially a 'secured remote dialup' to an internal
network; you have to force it to be fine grained.  SSH has been around
for some time and is truly point-to-point (like SSL/https in the web
world).  You also gain the advantage of being able to selectively filter
access via SSH by virtue of it's unique listener port, whereas with
IPSEC you can't really determine the origin of incoming attempts.
Plain IPSEC/externnal VPN make you "look" local and do their best to
hide your true identity from the host's perspective (validation and
auditing is left to the VPN device, whereever it may reside).

> Our organization thinks we have a pretty good active firewall
> between our intranet and the outside world.  FTP, TELNET, and
> "other" access is more-or-less controlled;  email viruses are
> pretty routinely stripped before they get to me.  But as long as
> we are linked to the internet, there is always some level of real
> risk that a deviously cunning being from the dark side will make
> it thru the firewall (may or may not ever have happened in the
> past:  don't ask:  Only allowable answer is "no comment"..  :-) ).
> If that happens, then we've got at least 2 problems:
>
> (1)   The specific machine that is the initial target of the attack.
>
> (2)   All the other machines that might be internally visible to
> the compromised machine in (1) above....  If the (1) machine
> is a UNIX box that has (or "obtains") sniffer software and the
> hacker can make him/herself root, then BIG TIME trouble:  A
> "large number" of end user PCs & servers may be vulnerable.

IPSEC won't protect you from (1) but does limit their choice of
compromises to the VPN device.  SSH need not be deployed at all on
machines you haven't protected "properly" but if SSH is compromised,
they can do (2) above.

Jeff Kell <[log in to unmask]>