Daniel Carosone <dan@geek.com.au> writes:

> On Fri, Aug 12, 2005 at 07:48:01AM -0400, Greg Troxel wrote:
>
> > 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.

When I tried this earlier, I found that the pfkey acquire message had
a small integer pointing to the SPD entry that matched.  There was no
way to represent the per-socket policy or refer to it, and racoon
didn't get those policies when it did a SPD dump at startup.

Getting racoon to use an ID per application is one of the steps needed
for user-associated SAs.

> > 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.

So you just mean "run the protocol over IPsec, and have the far end
rely on the confidentiality/integrity/authentication service"?
That's what I was thinking about


> 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.

agreed.

> 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.

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.

> 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.

For Kerberos, the user could just push the ticket into IKE, or let IKE
use the credential cache.  But an agent would make sense.

> >   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?

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.

> >   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

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.

> 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?

Yes, I mean that each endpoint can get the name from the credentials
that were used by the other endpoint in the IKE negotiation.  This can
be a name from an X.509 certificate (FQDN, user@FQDN, X.500 name), a
Kerberos principal, a name from /etc/racoon/psk.txt associated with a
key, or anything else that can be cryptographyically bound to the key
exchange.

-- 
        Greg Troxel <gdt@ir.bbn.com>