Subject: Re: IPSEC and user vs machine authentication
To: None <email@example.com>
From: Love <firstname.lastname@example.org>
Date: 08/26/2005 18:44:40
Daniel Carosone <email@example.com> writes:
> 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.
>> 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
>> 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.
> 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
If you don't trust you kernel to separate connections, why should you trust
it with your credentials ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
-----END PGP SIGNATURE-----