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.


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

Reply via email to