--m62MDEjg5u5lTXSK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 16, 2005 at 05:45:55PM -0700, Bill Studenmund wrote:
> Why do you want to map IPsec identities to local IDs?

Not so much or specifically to local id's, but that's somewhat
implicit in the fact that applications run on local systems under
local id's.  The idea is that (some) applications on a local system
should be able to run in a context that includes network credentials
(carried via ipsec), and furthermore that other applications don't
have such credentials.

That might map simply to local uid's (such as it does by implication
for the current kerberos credential cache or ssh agent models, with
secrets protected by uid and file perms). Or it might map to some
smaller resolution, such that (say) a word processor compromised by a
scripting virus can't send spam email via direct SMTP.

> If I understand you correctly, you are suggesting skipping
> application-level authentication and just using the IPsec identities
> for authentication.

No and yes. No, I'm not suggesting *skipping* app authentication, but
"Yes" in the sense that this would be useful because it would also
allow applications or protocols with no concept of user authentication
(consider ping) to be authenticated.

The other point is that the span of the authentication may be
different, or even multiply nested; the clearest example is for
authenticated gateway traversal.  Lets say I want to write user-based
firewall-like rules about who's allowed to ping which protected server
host, or make outbound connections to foreign hosts, regardless of
which workstation or multi-user shell server they're presently logged
into.

My first goal is to supplement existing authentication mechanisms
around the existing protocols. If a strong session-management /
channel-binding etc model emerges to tie these together, that's a
bonus as far as I'm concerned.

> I think that's dangerous as you have no reliable way to tell if the IPsec=
=20
> is end-to-end. So you open yourself up to MITM attacks where you establis=
h=20
> IPsec with the attacker who in turn establishes it with the client.

In fact that's exactly part of the problem I'm trying to solve: with
IPsec SA's established on the basis of user rather than machine
credentials, I may have a stronger defence against MITM attacks.  I
move one of the endpoints just about as close as possible to the
user. I need to ensure that the implementation details don't weaken or
expose the user's credentials to abuse, but given a strong design I
can have greater confidence that the user in question is at the
workstation and initiating the connections in question.

As a semi-aside, don't equate the user endpoint with the client role
only; I'd like to authenticate the (network) user owning listening
sockets too.

With machine credentials I have more cases to worry about where the
MITM attack is being perpetrated on the machine. (Consider the
multiuser machine example, to avoid the further complexities of the
discussion about compromised software on the platform).  I have at
best a weak binding between the user and the machine, or the user has
to give his credentials to the machine and thus weaken the
credentials.

> Maybe you're trying to solve a different problem. But I think application=
s=20
> really shouldn't care about the specifics of the identities used to=20
> establish IPsec to the extent that successful IPsec -> successful=20
> applicaiton authentication.=20

The application might not see the IPsec credentials protecting the
transport (as I said above and elsewhere, in my view, that comes
second, useful though it might be).  I'm looking for primarily an
infrastructure- / system-level mechanism, that can be applied
consistently regardless of application vagaries, but one that allows
network credentials to be user-based, and more strongly contained
withing smaller security domains within the remote platform.

I might achieve that at an application level by making them krb- or
ssl-aware, with the corresponding protocol and programming changes
necessary.  I might not be able to do so for some applications, but
even where I am able to do so, I might still want an infrastructure
level filter/gateway in front of that, to protect my application's
potential implementation vulnerabilities from exposure other than to
legitimate users, or to impose a single consistent user communications
policy.

With that in place, I might further adjust the apps to examine the
transport credentials used, too; the first step there would be to make
sure the same credentials were used at both layers, to prevent other
kinds of user impersonation attacks, before considering removing any
application authentications in place.  We start to overlap
meaningfully with the channel-binding discussion at that point, I
think.

So, yes, I think I'm trying to solve a slightly different problem;
hopefully I've better illustrated those goals now.

--
Dan.

--m62MDEjg5u5lTXSK
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (NetBSD)

iD8DBQFDAspzEAVxvV4N66cRAouuAKD0kWq1Z1tAmu2oHjoTfE+Bqn0NIQCg+oSy
Y/QL87/1ZqlBpX6X0A9v+HA=
=d7lb
-----END PGP SIGNATURE-----

--m62MDEjg5u5lTXSK--