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

On Sat, Aug 13, 2005 at 04:12:42PM -0400, Greg Troxel wrote:
> Daniel Carosone <dan@geek.com.au> writes:
>=20
> > On Fri, Aug 12, 2005 at 07:48:01AM -0400, Greg Troxel wrote:
>=20
> > You're absolutely right that this fits very well with Kerberos
> > identity handling, and that that's pretty much what I want even
> > without the certificate or tokencode cases.
>=20
> True, but what I meant was that kerberos has a model (generalized from
> rsh) of taking a "network identity", or external name,
> principal/instance@REALM, and asking if that is authorized for a
> particular local uid (kuserok).  Even if IPsec doesn't use Kerberos at
> all, this mapping (or authorization check) of IPsec identity to local
> uids is essentiall to making per-user keying to applications work.

Why do you want to map IPsec identities to local IDs?

[snip]

> > >   racoon being able to negotiate multiple Phase 1s with a given peer
> > >   racoon being able to present an identity to a program and have it
> > >     map it a locally meaningful name
> >=20
> > To which program?
>=20
> To the program on the server side (responder, really - I don't mean
> server) that owns the socket which will receive data over the SA to be
> created, so that it can map the IPsec identity to whatever local
> credentials it wants.  But I think we might have suggested having the
> program able to get the IPsec identity with the data, and then be able
> to do the mappin somehow.  One of the problems is how to deal with
> sockets that can receive data from multiple places.  Putting identity
> on each packet solves this, although it can get verbose.

Is this wise? If I understand you correctly, you are suggesting skipping=20
application-level authentication and just using the IPsec identities for=20
authentication.

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 establish=
=20
IPsec with the attacker who in turn establishes it with the client.

> > >   storing more complex identities, including user names in SPD
> > >   storing more complex identities, including user names in SA
> > >   checking identities when doing SPD/SA matches
> > >   conveying identities to programs via some setsockopt a la IP_RECVIF
> >=20
> > Yeah, pretty much.  While we're adding identity info, the name of the
> > application/executable, as well as the user running it, should be part
> > of the identity carried by the socket.  A listening server process (or
>=20
> I view each identity as some name defined by an authentication
> protocol, and proved by credentials.   I was thinking of program names
> and uids as a local matter.

Maybe you're trying to solve a different problem. But I think applications=
=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. Sorry, I'm repeating myself. :-) But it sounds=
=20
very dangerous.

I suggest you look at the channel binding work. It's not done AFAIK, but=20
it takes a slightly different approach. Rather than look at the IPsec IDs,=
=20
it just requires that both ends of an application authentication are using=
=20
the same end-to-end IPsec negotiation; specifically they agree on a hash=20
of the data. Doesn't matter what the IDs are, or even if they are=20
expressable in terms of the application's ID space. It just matters that=20
they agree.

My gut instinct is that channel binding will be easier and safer in the=20
long run than say using IPsec IDs for application level authentication.

Combine it with a way to require SAs for a TCP connection to be=20
renegotiated with the same identities as initially, and we get a rather=20
secure binding. All we need to add is a way to get the channel bindings=20
and a way to requre the IDs not change.

Take care,

Bill

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

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

iD8DBQFDAojDWz+3JHUci9cRAoiHAJ9Mi2GjEXcTRABcSkT/gm1ubkjXhQCff1sK
T98rB1ycE8XKV2JHUO0s6Ig=
=5tFo
-----END PGP SIGNATURE-----

--MW5yreqqjyrRcusr--