New extensible GSSAPI implementation

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

New extensible GSSAPI implementation

Doug Rabson
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.

The new GSS-API code acts as a plugin framework which can use any shared
library GSS-API implementation that conforms to the C-bindings set out
in RFC2744. I have changed the heimdal build process to build its
GSS-API implementation as a plugin. I have not implemented any new
GSS-API mechanisms.

One clear advantage to this system is that the GSS-API framework itself
is tiny (20k of code on i386) and includes no crypto code. It also has
no dependencies so applications don't have to supply a random list of
heimdal implementation details when they link with it.

In an attempt to move us closer to the de-facto standard for GSS-API,
I've moved the gssapi header file to /usr/include/gssapi. This is where
it lives on every non-BSD system that I've looked at, including OS X. I
have also included a complete set of manpages for the api with text
culled from the RFC (markup by me - mandoc police take note). It is
currently missing manpages for two new config files, /etc/gss/mech
and /etc/gss/qop. You can read the Solaris manpages for these files at
http://docs.sun.com/app/docs/doc/816-5174/6mbb98uh0?a=view.

The patch is too large to post here but you can find it at
http://people.freebsd.org/~dfr/gss-12112005.diff. It has survived
limited buildworld testing on one architecture and limited testing on a
newly install FreeBSD-current machine. I have not attempted to build
any GSS-API using ports and I expect there to be problems in that area
due to the moved header file and changed linking requirements.

Any comments, feedback, patches welcome...
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: New extensible GSSAPI implementation

Robert N. M. Watson-2

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).

Robert N M Watson
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: New extensible GSSAPI implementation

Doug Rabson
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.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: New extensible GSSAPI implementation

Robert N. M. Watson-2

On Sat, 12 Nov 2005, Doug Rabson wrote:

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

I agree entirely with the above sentiments.  Are you sure you can't make
it to EuroBSDCon to talk about NFSv4 there? :-)

Robert N M Watson
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: New extensible GSSAPI implementation

Doug Rabson
On Saturday 12 November 2005 11:25, Robert Watson wrote:

> On Sat, 12 Nov 2005, Doug Rabson wrote:
> > 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.
>
> I agree entirely with the above sentiments.  Are you sure you can't
> make it to EuroBSDCon to talk about NFSv4 there? :-)

Sorry, I really just can't make it this year :-(
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: New extensible GSSAPI implementation

Doug Rabson
In reply to this post by Doug Rabson
On Saturday 12 November 2005 10:42, Doug Rabson wrote:
> The patch is too large to post here but you can find it at
> http://people.freebsd.org/~dfr/gss-12112005.diff. It has survived
> limited buildworld testing on one architecture and limited testing on
> a newly install FreeBSD-current machine. I have not attempted to
> build any GSS-API using ports and I expect there to be problems in
> that area due to the moved header file and changed linking
> requirements.
>
> Any comments, feedback, patches welcome...

I've put up a new iteration of the patch at
http://people.freebsd.org/~dfr/gss-20112005.diff which fixes a number
of problems with the manpages and some issues that showed up while
testing with ssh/sshd. It also adds an implementation of gss_add_cred
which I managed to miss out before.

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"