IPSEC and user vs machine authentication

[Daniel Carosone]

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.

In either case, however, authentication for the resulting SA is done
using what are essentially machine credentials; the PSK or certificate
or Kerberos ticket used has to be available to racoon, even if they
really belong to a user (such as might be the case in a remote-access
user VPN scenario).

Even if one trusts racoon with these credentials, there doesn't appear
to be any way to select which identity should be used for a given
socket, or to bind an identity with a local uid, or to pass/delegate
credentials to racoon per user. This has implications both for
multi-user machines (including 'non-credentialled processes' on
single-user machines), and for users who move between multiple
machines.

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.

There are similarities in requirements here for other kernel-mediated
network activities that may involve authentication, too, such as
potential Kerberised-RPC NFS or SMBFS. Are there any facilities for
this I have missed, prior art, thoughts, designs, active work,
comments, etc?

--
Dan.

[Greg Troxel]

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.

(speling nit: IPSEC is the kernel option, IPsec is the protocol)

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

I'm not sure I follow 'by encapsulation', but this makes sense.

Several years ago, I did a rough outline for per-user credentials.
Note that RFC2401 allows them, but NetBSD's implementation does not.
Basically, it involved

users being able to push keys or hook up an agent to racoon
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
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

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

But seriously, what you want is the direct analog of how Kerberos
handles user identities, except that it's far more complicated due to
racoon, SPD, SA insteadof all being in process, and I think it is
entirely doable and sensible, and within the IPsec architecture.

[Jason Thorpe]

Post by Greg Troxel
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.

Racoon doesn't do anything with policy negotiation. But AFAIK it can
negotiate SAs for per-socket policies just fine.

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Daniel Carosone]

Post by Daniel Carosone
Right now, there are two paths into having a particular network
either via the setkey packet-filter SPD, or via per-socket policy set
by the application.
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.

Post by Daniel Carosone
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.
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.

Post by Daniel Carosone
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.)

Post by Daniel Carosone
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?

Post by Daniel Carosone
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?

Post by Daniel Carosone
If you want to send money we finish the project as proposed :-)

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

--
Dan.

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----
Bill> I think that's dangerous as you have no reliable way to tell
Bill> if the IPsec is end-to-end. So you open yourself up to MITM
Bill> attacks where you establish IPsec with the attacker who in
Bill> turn establishes it with the client.

That's what channel bindings are for.

- --
] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [
] mcr @ xelerance.com Now doing IPsec training, see |net architect[
] http://www.sandelman.ca/mcr/ www.xelerance.com/training/ |device driver[
] I'm a dad: http://www.sandelman.ca/lrmr/ [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQwM5OIqHRg3pndX9AQFcLwP/f+n9W6TW+g6Soz+bDCn3a2XYq4nXYpQW
mVyAS6eqycay4HmAklImXziz+p59O0tKKkFC2njfXPfG6PR9lDbfuxcDW0ndwc2y
355FSHwr2XdvkRTgq5x23FbvCpqOHiOPOtxgmpj3aay7cga/XDLkwAsYkds2j7kF
atTb1s2cydI=
=IYeX
-----END PGP SIGNATURE-----

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael Richardson]

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

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

Bill, since I was too quick on the last one, (and I've now had another
swig of caffeine) let me continue:

There are a number of classes of application where you don't care who
the end-user is, as long as they are the same user as they were last
time.

You may even use other authentication mechanisms the first time to
match the ID (expressed in the form of a public key!) to the user. You
can do this inband of the protocol, in IKE (XAUTH for instance), or even
out-of-band (SMB's certificate enrollment process).

Channel binding then replaces the in-band authentication that the
process would normally do, to assure everyone that they are not being
MITM.

- --
] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [
] mcr @ xelerance.com Now doing IPsec training, see |net architect[
] http://www.sandelman.ca/mcr/ www.xelerance.com/training/ |device driver[
] I'm a dad: http://www.sandelman.ca/lrmr/ [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQwM6CoqHRg3pndX9AQHBIQQAuFwp9Mfu2iytJvYIUaVJQA2jjMv5fvX9
N4mFmrg2HocbjeCTxasvXREoy9THdVAIXySvR/VKZpshFLg9G4+fbLOF1S4v0mE7
VeTGxX9QECMMo8IDmxFDxvhO0k5YyiAERQLNwQ6uXG/pxaVeNY9Ijlzl86GbDswU
OomE2m02YHM=
=1qGb
-----END PGP SIGNATURE-----

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jason Thorpe]

So, this was work that Bill Sommerfeld and I were trying to
standardize as a piece of work that many call "PF_POLICY" (but we
didn't
want to actually make the API a socket-based one, leaving that for the
implementor to worry about).

Has that effort died? I attended a few informal discussions about
this topic when it was first being discussed, but was not able to
stay involved and have not heard much about it since, until you
mentioned it now.

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----

So, this was work that Bill Sommerfeld and I were trying to
standardize as a piece of work that many call "PF_POLICY" (but we
didn't want to actually make the API a socket-based one, leaving
that for the implementor to worry about).

Jason> Has that effort died? I attended a few informal discussions
Jason> about this topic when it was first being discussed, but was
Jason> not able to stay involved and have not heard much about it
Jason> since, until you mentioned it now.

I'm still working on it, but I can't write a "standard" in isolation.
I wrote code for Openswan to prototype the first part [query] (and we even
demonstrated it at a BlackHat conference).

I'm still interesting in continuing on this.

- --
] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [
] mcr @ xelerance.com Now doing IPsec training, see |net architect[
] http://www.sandelman.ca/mcr/ www.xelerance.com/training/ |device driver[
] I'm a dad: http://www.sandelman.ca/lrmr/ [

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQwDIhYqHRg3pndX9AQF5XgP7B/vo55Jz/KkveyiojCEF1WZX9E5zZVNl
ubJYkNjYy7zk1flS8KU02lh/p3CDH2f9UxcjsCcrtUgEDXKh7mBv3xL99H8Q2YhE
RD+XUNN1AQRQqw9CsTAyLN//zh+o7SqVCME+B3FGwphNRi5xq1fsF55KjjA63gYT
8mHv4ulShPg=
=gXv3
-----END PGP SIGNATURE-----

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Steven M. Bellovin]

Post by Michael Richardson
-----BEGIN PGP SIGNED MESSAGE-----

So, this was work that Bill Sommerfeld and I were trying to
standardize as a piece of work that many call "PF_POLICY" (but we
didn't want to actually make the API a socket-based one, leaving
that for the implementor to worry about).

Jason> Has that effort died? I attended a few informal discussions
Jason> about this topic when it was first being discussed, but was
Jason> not able to stay involved and have not heard much about it
Jason> since, until you mentioned it now.
I'm still working on it, but I can't write a "standard" in isolation.
I wrote code for Openswan to prototype the first part [query] (and we even
demonstrated it at a BlackHat conference).
I'm still interesting in continuing on this.

As am I. I tried hard to get the IPsec WG interested in the question,
way back when, but with little success.

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----
Jason> Has that effort died? I attended a few informal discussions
Jason> about this topic when it was first being discussed, but was
Jason> not able to stay involved and have not heard much about it
Jason> since, until you mentioned it now.

Post by Michael Richardson
I'm still working on it, but I can't write a "standard" in
isolation. I wrote code for Openswan to prototype the first part
[query] (and we even demonstrated it at a BlackHat conference).
I'm still interesting in continuing on this.

Steven> As am I. I tried hard to get the IPsec WG interested in the
Steven> question, way back when, but with little success.

Do you perhaps have students who might want to get involved?

- --
] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [
] mcr @ xelerance.com Now doing IPsec training, see |net architect[
] http://www.sandelman.ca/mcr/ www.xelerance.com/training/ |device driver[
] I'm a dad: http://www.sandelman.ca/lrmr/ [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQwDyGoqHRg3pndX9AQFoDAP/YyXq0dhnVIga3o4k9cj0fmoqpPiSGsUY
eCzt8R121Lzx5PwKEh69Wp6u6BcNeYqV00kX/z+yWeXXV2dnXE/X7aNydB8tvdUN
OO4L/bxB7QMc0WeE+klt0Stok8oVfV1SzZKxb72SfvqECqVKIAMcb+fcO0+LibBf
VNSqAES6QKo=
=5GF+
-----END PGP SIGNATURE-----

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Love Hörnquist Åstrand]

Post by Daniel Carosone
Right now, there are two paths into having a particular network
either via the setkey packet-filter SPD, or via per-socket policy set
by the application.

[...]

Post by Daniel Carosone
There are similarities in requirements here for other kernel-mediated
network activities that may involve authentication, too, such as
potential Kerberised-RPC NFS or SMBFS. Are there any facilities for
this I have missed, prior art, thoughts, designs, active work,
comments, etc?

Pushing down the credential into IKE is one way to do it.

Another way is to not care about what credential IKE negotiated, but rather
just use the channel and bind it to your applications security context
negotiation. One way to do that would be to fold something like IKE
equvalent of secsh's `The exchange hash H' into your applications
authentication.

The this one of BTNS working groups items.

Love

[Bill Studenmund]

Post by Love Hörnquist Åstrand

Post by Daniel Carosone
Right now, there are two paths into having a particular network
either via the setkey packet-filter SPD, or via per-socket policy set
by the application.

[...]

Post by Daniel Carosone
There are similarities in requirements here for other kernel-mediated
network activities that may involve authentication, too, such as
potential Kerberised-RPC NFS or SMBFS. Are there any facilities for
this I have missed, prior art, thoughts, designs, active work,
comments, etc?

Pushing down the credential into IKE is one way to do it.
Another way is to not care about what credential IKE negotiated, but rather
just use the channel and bind it to your applications security context
negotiation. One way to do that would be to fold something like IKE
equvalent of secsh's `The exchange hash H' into your applications
authentication.
The this one of BTNS working groups items.

And the KITTEN working group and NFSv4 groups are working with channel
bindings regarding this. I have most of a draft extending iSCSI CHAP to
include this too.

The other thing that would be quite useful (required, depending on whom
you ask) for channel bindings is a way to require that TCP connection foo
is bound to a given set of identities. So if you use Kerberos Identity BAR
to log in, you can't later renegotiate IPsec FOR THIS CONN using PSK ID
BAZ. You can renego PSK, and you can make new connections, but the app
will see connection termination/establishment.

Solaris supposedly has this last feature.

Take care,

Bill

[Daniel Carosone]

Post by Love Hörnquist Åstrand
Pushing down the credential into IKE is one way to do it.
Another way is to not care about what credential IKE negotiated, but rather
just use the channel and bind it to your applications security context
negotiation. One way to do that would be to fold something like IKE
equvalent of secsh's `The exchange hash H' into your applications
authentication.
The this one of BTNS working groups items.

I'm not clear on the details of these proposals, but they seem like
related or complementary ideas, rather than clear alternatives.

For example, they seem to me more like a session-management mechanism
than an authentication mechanism per-se; rather like how some web load
balancers or reverse proxies can use the SSL session-id to correlate
multiple web requests from the same browser. Perhaps this helps me
recognise when an IKE phase 1 SA (as the equivalent of an SSL session)
is being reused for multiple connections.

Or is the idea to have the initial (IKE) session later be associated
with a user, on the basis of an application authentication that occurs
inside that session? There are equivalent ideas used successfully in
the SSL models above, certainly.

That's fine as far as it goes, but I don't think it quite covers what
I was describing.

You'd also need some stronger criteria around which new connections
were allowed to join the session at the remote end, otherwise we're
really back to machine policy and authentication again. Such
constraints are less problematic in the SSL case, because you
typically assume the SSL session belongs to a user application such as
a single browser.

However the identity is negotiated and authenticated, you still need
the ability to query the session state for this information. I had
considered this as the second part of the problem, rather than the
first as has been others' focus previously; both components are
needed.

--
Dan.

[Love]

Post by Daniel Carosone

Post by Love Hörnquist Åstrand
Pushing down the credential into IKE is one way to do it.
Another way is to not care about what credential IKE negotiated, but rather
just use the channel and bind it to your applications security context
negotiation. One way to do that would be to fold something like IKE
equvalent of secsh's `The exchange hash H' into your applications
authentication.
The this one of BTNS working groups items.

I'm not clear on the details of these proposals, but they seem like
related or complementary ideas, rather than clear alternatives.
For example, they seem to me more like a session-management mechanism
than an authentication mechanism per-se; rather like how some web load
balancers or reverse proxies can use the SSL session-id to correlate
multiple web requests from the same browser. Perhaps this helps me
recognise when an IKE phase 1 SA (as the equivalent of an SSL session)
is being reused for multiple connections.
Or is the idea to have the initial (IKE) session later be associated
with a user, on the basis of an application authentication that occurs
inside that session? There are equivalent ideas used successfully in
the SSL models above, certainly.

The point is that you don't need to push down user credentials to the
process that handles IKE for you. Just a way to seperate the each user from
each other and then withing that bind that within the application
authentication to the IKE assosication.

Post by Daniel Carosone
That's fine as far as it goes, but I don't think it quite covers what
I was describing.
You'd also need some stronger criteria around which new connections
were allowed to join the session at the remote end, otherwise we're
really back to machine policy and authentication again. Such
constraints are less problematic in the SSL case, because you
typically assume the SSL session belongs to a user application such as
a single browser.

Why is this diffrent from the BTNS/channel binding case than what you are
describing ?

If you don't trust you kernel to separate connections, why should you trust
it with your credentials ?

Love

[John Nemeth]

On Oct 25, 3:57pm, "Steven M. Bellovin" wrote:
} On Wed, 4 Jun 2008 15:03:06 +0200
} Petar Bogdanovic <***@smokva.net> wrote:
}
} > I recently noticed that ipfilter with `block return-icmp' is returning
} > ICMP Type 3 Code 0 (Network unreachable) to the sender of a blocked
} > broadcast:
} >
} > 130.3.3.3 ---------[***@130.3.3.255]--------> 130.3.3.4
} > 130.3.3.3 <----[ICMP Network unreachable]---- 130.3.3.4
} >
} >
} > This seems wrong, considering RFC1122, page 39:
} >
} > An ICMP error message MUST NOT be sent as the result of
} > receiving:
} >
} > * an ICMP error message, or
} >
} > * a datagram destined to an IP broadcast or IP multicast
} > address, or
} >
} > * a datagram sent as a link-layer broadcast, or
} >
} > * a non-initial fragment, or
} >
} > * a datagram whose source address does not define a single
} > host -- e.g., a zero address, a loopback address, a
} > broadcast address, a multicast address, or a Class E
} > address.
} >
} >
} > Is this desired behaviour?
}
} I don't see the conflict. The intent of that section of 1122 is to
} rule out troublesome ICMPs. The first condition prevents loops; the
} second two prevent ICMP implosions, the fourth assumes that the initial

Using the English language (which usually works with RFCs) along
with the RFC definition of "MUST NOT", it sure looks like either the
second or third condition applies depending on the link layer address.

} fragment will cause the proper message, and the last is for an ICMP
} that can't be delivered to a single host. Your example concerns none
} of those cases. Furthermore, the very next page of 1122 defines an
} ICMP type code for "administratively prohibited" communication, which
} is exactly what I hope ipf is returning here.

The second line of the stuff you quoted says, "ICMP Type 3 Code 0
(Network unreachable)". "administratively prohibited" would be Code 9,
10, or 13.

The question I have is, is 130.3.3.4 a router of some sort? If
not, then I believe it is misbehaving. If so, then RFC1122 may not be
applicable as it only deals with end hosts. However, even if it is a
router, it isn't a packet that needs to be passed through, so RFC1122
is probably still applicable.

}-- End of excerpt from "Steven M. Bellovin"

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de