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]