On Sat, 2008-05-03 at 23:35 +0000, Steven M. Bellovin wrote: > 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.
Let me restate things just to make sure I understand the problem. You're talking about "binding IPsec credentials to a user," but I want to look at it from the point of view of exactly what problems this causes, so is the following an accurate position? The problem is that we're trying to have entities with different security needs share a common set of authentications. When user 'pat' and user 'sandy' have different security needs (different authorized or trustable communication partners, to start with) we can't give them IPSEC because IPSEC operates on channels between machines rather than on channels between trusting/trusted entities. Even if 'pat' and 'sandy' both have a trusted/trusting entity on a given remote machine from theirs, IPSEC fails them because it cannot differentiate between the various entities (users, agents, services) using that remote machine, when 'pat' and 'sandy' need it to. Similarly, it fails the entities on that remote machine because it cannot differentiate between 'pat', 'sandy' and any other entities using the local machine, when trust relationships might exist only for some subset of those entities. Bear --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]