From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 11:15:53 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DAED16A420; Sat, 12 Nov 2005 11:15:53 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47D8D43D46; Sat, 12 Nov 2005 11:15:52 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring [10.0.0.2]) by itchy.rabson.org (8.13.3/8.13.3) with ESMTP id jACBFe9K046651; Sat, 12 Nov 2005 11:15:40 GMT (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Robert Watson Date: Sat, 12 Nov 2005 11:15:38 +0000 User-Agent: KMail/1.8.2 References: <200511121042.42425.dfr@nlsystems.com> <20051112110504.X33260@fledge.watson.org> In-Reply-To: <20051112110504.X33260@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511121115.38732.dfr@nlsystems.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (itchy.rabson.org [80.177.232.242]); Sat, 12 Nov 2005 11:15:40 +0000 (GMT) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on itchy.rabson.org X-Virus-Scanned: ClamAV 0.83/1169/Fri Nov 11 21:28:05 2005 on itchy.rabson.org X-Virus-Status: Clean Cc: arch@freebsd.org Subject: Re: New extensible GSSAPI implementation X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2005 11:15:53 -0000 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.