On Sat, 03 May 2008 17:00:48 -0400
"Perry E. Metzger" <[EMAIL PROTECTED]> wrote:
>
> [EMAIL PROTECTED] (Peter Gutmann) writes:
> >>I am left with the strong suspicion that SSL VPNs are "easier to
> >>configure and use" because a large percentage of their user
> >>population simply is not very sensitive to how much security is
> >>actually provided.
> >
> > They're "easier to configure and use" because most users don't want
> > to have to rebuild their entire world around PKI just to set up a
> > tunnel from A to B.
>
> I'm one of those people who uses OpenVPN instead of IPSEC, and I'm one
> of the people who helped create IPSEC.
>
> Right now, to use SSH to remotely connect to a machine using public
> keys, all I have to do is type "ssh-keygen" and copy the locally
> generated public key to a remote machine's authorized keys file.
> When there is an IPSEC system that is equally easy to use I'll switch
> to it.
>
> Until then, OpenVPN let me get started in about five minutes, and the
> fact that it is less than completely secure doesn't matter much to me
> as I'm running SSH under it anyway.
>
There's a technical/philosophical issue lurking here. We tried to
solve it in IPsec; not only do I think we didn't succeed, I'm not at
all clear we could or should have succeeded.
IPsec operates at layer 3, where there are (generally) no user
contexts. This makes it difficult to bind IPsec credentials to a user,
which means that it inherently can't be as simple to configure as ssh.
Put another way, when you tell an sshd whom you wish to log in as, it
consults that user's home directory and finds an authorized_keys file.
How can IPsec -- or rather, any key management daemon for IPsec -- do
that? Per-user SPDs? Is this packet for port 80 for user pat or user
chris?
I can envision ways around this (especially if we have an IP address
per user of a system -- I've been writing about fine-grained IP address
assignment for years), but they're inherently a lot more complex than
ssh.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
