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

On Fri, Aug 26, 2005 at 06:44:40PM +0200, Love wrote:
>=20
> The point is that you don't need to push down user credentials to the
> process that handles IKE for you.=20

Yeah, understood.

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

Indeed; that's almost exactly what I was trying to say in this next bit:

> > 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.
>=20
> Why is this diffrent from the BTNS/channel binding case than what you are
> describing ?

So it's not really that different as far as it goes, as I said.

But still channel binding only goes part way towards what I was looking for:

 - it requires that the application in the channel do some later
   authentication that can be bound back to the channel.  Some of the
   apps I was considering don't have the capability.

 - it requires that the application be exposed to the channel in order
   to do the auth step.  Some of the apps I was considering, even if
   they do authentication, I might be worried about exposing
   vulnerabilities.

 - it requires some way for a channel-aware application to push its
   auth results back into the channel, and for later instances to
   retrieve it.

 - in the gateway traversal case, the channel and the app connection
   doing the authentication terminate on different hosts, so I need to
   invent some other way for the binding to take place, or for the app
   to even be aware of the channel.

Perhaps a way to mitigate several of the above points would be by only
exposing a simple "authentication app" (possibly on the gateway) until
the binding has occurred, but then you're putting more policy
functionality and management requirement into the channel. At that
point, it starts to look more like a "VPN client/server" model, the
deficiencies of which were part of my original motivation.

I'm looking for something more pervasive: useful on a more diverse
network where each app might be on a different server (ie, many
channels), and perhaps where some of those apps are behind gateways.

Plus, as above, you still need some policy about what connections are
allowed to join the bound channel (in both directions), or the binding
is too weak and too many things can 'borrow' the initial session
authentication.

--
Dan.
--7jzg8fevGm/yfsZp
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFDD6a3EAVxvV4N66cRAlRUAJ42IME5fi4yfjVwuLE/gBhoSvN9/ACgqZOg
MBqeKf+gnW2Sbyt65BLnXKY=
=76Mq
-----END PGP SIGNATURE-----

--7jzg8fevGm/yfsZp--