"Steven M. Bellovin" <[EMAIL PROTECTED]> writes:
> 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.

I disagree. Fundamentally, OpenVPN isn't doing anything IPSEC couldn't
do, and yet is is fairly easy to configure. I believe that I could
easily come up with a simpler configuration still, but we have a
worked example, so I don't think we can claim it is impossible any

It is true that I can't make it easy to configure all possible
uses of IPSec easily, but it should be easy to do the easy things and
it isn't. If it was easy to do easy things and possible to do
complicated things, that would be a reasonable place to get to -- I
know of no IPSec configuration system that is like that.

> 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?

Almost exclusively the use for such things is nailing up a tunnel to
bring someone inside a private network. For that, there is no need for
per user auth -- the general assumption is that the remote box is a
single user laptop or something similar anyway. You really just want
to verify that the remote host has a particular private key, and if it
does, you nail up a tunnel to it (possibly allocating it a local IP
address in the process). That solves about 95% of the usage scenarios
and it requires very little configuration. It also covers virtually
all use of IPSec I see in the field.

Again, there are more complex usage scenarios, and it may be more
complicated to set one of *those* up, but it is a shame that it is
difficult to do the simple stuff.

Perry E. Metzger                [EMAIL PROTECTED]

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

Reply via email to