Re: New extensible GSSAPI implementation

From: Doug Rabson (dfr_at_nlsystems.com)
Date: 11/12/05

  • Next message: Robert Watson: "Re: New extensible GSSAPI implementation" 
    To: Robert Watson <rwatson@freebsd.org>
Date: Sat, 12 Nov 2005 11:15:38 +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.
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Robert Watson: "Re: New extensible GSSAPI implementation"

    Relevant Pages

    • Re: Linux und BSD sind kalter Kaffee
      ... und mich zunächst gewundert das ich sie nicht auf einem 64 Bit AMD ... Gibt es keine grafischen Verwaltungswerkzeuge für VirtualBox? ... keinen modifizierten Kernel, sondern nur ein Kernel-Modul. ... Es kann nativ nur Solaris im Container laufen. ...
      (de.comp.os.unix.linux.misc)
    • Re: Announce loop-AES-v3.0b file/swap crypto package
      ... Regarding the "backdoor", perhaps it is a poor choice of words, but clearly ... |>>Nothing about kernel crypto is backdoored. ... confusing the kernel with util-linux is a strange trick. ... Every tried Jari's loop-AES module? ...
      (Linux-Kernel)
    • Re: Solaris: The Most Advanced OS?
      ... >> I used Solaris for many years for serious embedded development work, ... >> it has a few which Linux doesn't have. ... >> found the Solaris kernel to be much more robust than Linux. ...
      (Debian-User)
    • Re: Solaris impossible to use for desktop
      ... > supported by Sun these days, and in general it tends to render IE ... > Is the Linux kernel fully preemptive now? ... Solaris both on x86 and sparc. ... > system on a 600 MHz Athlon is still more responsive than Linux ...
      (comp.unix.solaris)
    • Re: [PATCH resend][CRYPTO]: RSA algorithm patch
      ... > reason to _not_ do asymmetric crypto in the kernel either. ... > -- why break strong crypto algorithms such as RSA by implementing them ... duplicating the PKCS padding for themselves! ...
      (Linux-Kernel)