Subject: Re: IPSEC and user vs machine authentication
To: Love H?rnquist ?strand <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 08/16/2005 17:18:20
Content-Type: text/plain; charset=us-ascii
On Mon, Aug 15, 2005 at 07:35:30PM +0200, Love H?rnquist ?strand wrote:
> Daniel Carosone <email@example.com> 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 rath=
> 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.
And the KITTEN working group and NFSv4 groups are working with channel=20
bindings regarding this. I have most of a draft extending iSCSI CHAP to=20
include this too.
The other thing that would be quite useful (required, depending on whom
you ask) for channel bindings is a way to require that TCP connection foo
is bound to a given set of identities. So if you use Kerberos Identity BAR=
to log in, you can't later renegotiate IPsec FOR THIS CONN using PSK ID=20
BAZ. You can renego PSK, and you can make new connections, but the app=20
will see connection termination/establishment.
Solaris supposedly has this last feature.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----