Date: Sat, 12 Nov 2005 11:15:38 +0000 From: Doug Rabson <dfr@nlsystems.com> To: Robert Watson <rwatson@freebsd.org> Cc: arch@freebsd.org Subject: Re: New extensible GSSAPI implementation Message-ID: <200511121115.38732.dfr@nlsystems.com> In-Reply-To: <20051112110504.X33260@fledge.watson.org> References: <200511121042.42425.dfr@nlsystems.com> <20051112110504.X33260@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 12 November 2005 11:06, Robert Watson wrote: > On Sat, 12 Nov 2005, Doug Rabson wrote: > > For quite a while now (far too long in fact), I've been slowly > > working on an extension framework for GSS-API. This was partly > > prompted by an interest in NFSv4 which requires both LIPKEY > > [RFC2847] as well as Kerberosv5 as security providers. The existing > > FreeBSD GSS-API library comes from Heimdal and only provides > > Kerberosv5. It is also a necessary pre-requisite for an > > implementation of RPCSEC_GSS which I'm not quite ready to commit. > > This is great news! Have you taken a look at the Solaris inclusion > of gssapi parts in their kernel: > > http://fxr.watson.org/fxr/source/common/gssapi/?v=OPENSOLARIS > > I assume this is associated with NFSv4 support, but haven't dug > around at all yet other than noticing it there the other day. Most > other discussion of GSSAPI I've seen assumes that the crypto takes > place in user space, but having it in kernel has some significant > advantages (especially if you have a fully preemptive kernel, which > we now have). I have looked at the Solaris kernel GSS-API code. As far as I can see on a first reading, they defer the context establishment out to userland and once the context is up, they do the actual crypto for signing etc. in the kernel, via a plugin model. Doing all the crypto in userland isn't really a good idea because even when you aren't using message privacy and integrity, parts of the RPC header are still signed for basic replay detection. Flipping all that out to userland would be devastating for performance. Rick Macklem's NFSv4 server code does its crypto in the kernel in a similar way to Solaris but it is hard-wired to kerberosv5.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200511121115.38732.dfr>