--=-=-=


Daniel Carosone <dan@geek.com.au> 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
>> 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.

> 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


--=-=-=
Content-Type: application/pgp-signature

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

iQEVAwUAQw9G/do1gLFKFEjAAQLZ6AgAiRBYGlm0GHKD9Tg+ttwMkk0w7A3rHnBe
56tzZFtXwr3Syl3Q6srkmmqNK6Lb6xqd9lBcuQtIocuHCQwCxxbS9/T9CiHsbMsT
PbZvE052UZjWeTH4HAdgifS1y83aUwWE9FQunrmAp2r7pUtC48xqNjLCMkOl678k
/xzdpVt17ZnDQ18VljoM2kjIcGSwK13lL2CgpNiVBrOezBlikdN8RJOzElS7RT6Q
oeTTWkJ8ec6xShvNCzcLDwwqgWer7C7p1JEXS3CkyXT7eZGcDzWiUnNSvFtvivCe
DlGiqh52Ho0uAff1ig6IP++5ZavIt6h6xBl/qlHQvfDNVMAa2TBLVg==
=S9zg
-----END PGP SIGNATURE-----
--=-=-=--