Re: User interface, security, and "simplicity"

[Ben Laurie]

Steven M. Bellovin wrote:
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.

I don't see why.

The ssh server determines who the packets are for from information sent 
to it by the ssh client.

The ssh client knows on whose behalf it is acting by virtue of being 
invoked by that user (I'll admit this is a simplification of the most 
general case, but I assert my argument is unaffected), and thus is able 
to include the information when it talks to the server.

Similarly, the client end of an IPSEC connection knows who opened the 
connection and could, similarly, convey that information. That data may 
not be available in some OSes by the time it gets to the IPSEC stack, 
but that's a deficiency of the OS, not a fundamental problem.

It seems to me there's no real difference between the two cases.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]