Subject: Re: IPSEC and user vs machine authentication
To: None <tech-security@netbsd.org>
From: =?iso-8859-1?q?Love_H=F6rnquist_=C5strand?= <lha@kth.se>
List: tech-security
Date: 08/15/2005 19:35:30
--=-=-=


Daniel Carosone <dan@geek.com.au> writes:

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


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

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

iQEVAwUAQwDSZdo1gLFKFEjAAQLIzwf+IpXskAkfOh1KpgZIn39x8V9ZHYj9ptpa
Z3SvfrKCvEBDnU0nfd0ID7TATeGgw7GlGgc6M2+Ad1i1gd+AR2cOdaQV0A2dJEEX
DlmBgI1c0R3p+UdDAZUWBJJ20TZtEwwHm++BuEqiuDIeZ22F3d8vcRDeunjMf9X2
ndigeaNAVxUCtw/oMwMG88P+odIx7nR7v7F6ZemCx3lYdh1EDPjgXF1nOLxbEc7J
hXUsmSSVWlyx7qgo63ZHZQG1N7YEJqSo2EaEtBrMN8n4GbEAw8uAdlvzNSIegnGP
+3mGykvpwu4SvhILFp5tsdpEiejFAOAxecbPciubwrUVomHGmKUmpg==
=KlwS
-----END PGP SIGNATURE-----
--=-=-=--