Re: New extensible GSSAPI implementation
From: Doug Rabson (dfr_at_nlsystems.com)
Date: 11/12/05
- Previous message: Robert Watson: "Re: New extensible GSSAPI implementation"
- In reply to: Robert Watson: "Re: New extensible GSSAPI implementation"
- Next in thread: Robert Watson: "Re: New extensible GSSAPI implementation"
- Reply: Robert Watson: "Re: New extensible GSSAPI implementation"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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"
- Previous message: Robert Watson: "Re: New extensible GSSAPI implementation"
- In reply to: Robert Watson: "Re: New extensible GSSAPI implementation"
- Next in thread: Robert Watson: "Re: New extensible GSSAPI implementation"
- Reply: Robert Watson: "Re: New extensible GSSAPI implementation"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
- 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) - RE: rfc2385 support
... Thanks for the info. I'm currently rebuilding the kernel on FreeBSD5.4 ... with
FAST_IPSEC and TCP_SIGNATURE added to options and crypto added to ... responsibility for
the security of the contents of this or other emails. ... Whilst TeleCity take measures
to prevent any virus contamination of our ... (freebsd-net)