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

On Fri, Aug 12, 2005 at 07:48:01AM -0400, Greg Troxel wrote:
>   Right now, there are two paths into having a particular network
>   connection (say, a TCP session) encrypted/authenticated with IPSEC:
>   either via the setkey packet-filter SPD, or via per-socket policy set
>   by the application.
>=20
> Is racoon able to negotiate per-socket policy now?  I haven't looked
> in a while.  But per-socket vs. SPD is an orthogonal issue to your
> main concern, I think.

I used it as a partial example of the difference between 'machine
policy' and 'application/user policy'.  It's not up to the task yet,
but since each socket has an owning uid and application, it would be
nice if these properties were available to the IKE negotiation.

>   I'm looking for the ability to have network connections authenticated
>   with IPSEC on a per-user basis (using certificates, kerberos and/or
>   XAUTH hybrid mode) via encapsulation, both for applications and
>   protocols without native support for such mechanisms in the endpoints,
>   and for authenticated traversal of intermediate gateways.
>=20
> I'm not sure I follow 'by encapsulation', but this makes sense.

Encapsulation of the existing protocol, rather than making changes
in-stream; especially useful in the gateway traversal case, where the
gateway isn't an endpoint for the inner protocol at all.

>   users being able to push keys or hook up an agent to racoon

Yes; I probably prefer the agent model in general, and it's the only
one that will be practical for PKCS#11 smartcards or similar pki
tokens, and for password prompts for XAUTH and OTP tokens.

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.

In the Kerberos model, I see a login by the user to a racoon
(kernel) helper service, which then grants the service a delegated
authentication for IKE (NFS, SMB) participation on the users behalf
via a forwardable or proxiable ticket. In practice this probably
requires the user running a program that looks very much like an agent
anyway.

(As an aside, such a service/agent is probably a better model for the
user's credential cache than dotfiles, if it implements better access
control policy protecting the identity from abuse by unauthorised
programs. I wish ssh-agent did so.)

>   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

To which program?

>   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

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
the gateway) needs the ability to inspect these authenticated
properties of the connection/SA at the other end, too; was that what
you meant about presenting the identity to a program?

> If you want to send money we finish the project as proposed :-)

Always comes back to that, doesn't it.. :-)

--
Dan.
--uwJuRjKj6RbLtb4h
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFC/U2cEAVxvV4N66cRAtFFAKCtE8CKPTLWGfmP3yurUIXtJP7MawCgs/5N
wemeIEMTyCK3RQrjnMlGLUM=
=MIQR
-----END PGP SIGNATURE-----

--uwJuRjKj6RbLtb4h--