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

On Mon, Aug 15, 2005 at 07:35:30PM +0200, Love H?rnquist ?strand wrote:
> Pushing down the credential into IKE is one way to do it.
>=20
> Another way is to not care about what credential IKE negotiated, but rath=
er
> 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.
>=20
> 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. =20

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

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.

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

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

iD8DBQFDAosmEAVxvV4N66cRAjuXAKDO6yEGXs7N+vAx/RAmTmUH9Z38ZQCdE533
q4LRr2MKXhHvNMMAjU5q4C0=
=ixqM
-----END PGP SIGNATURE-----

--cih9CcvR6VAUKoGd--