User interface, security, and "simplicity"

Steven M. Bellovin smb at cs.columbia.edu
Tue May 6 11:22:58 EDT 2008


On Sun, 04 May 2008 11:22:51 +0100
Ben Laurie <ben at links.org> wrote:

> Steven M. Bellovin wrote:
> > On Sat, 03 May 2008 17:00:48 -0400
> > "Perry E. Metzger" <perry at piermont.com> wrote:
> > 
> >> pgut001 at cs.auckland.ac.nz (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.
> 
The problem is more on the server end.




		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list