Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 7 Jan 2018 21:03:01 +0000
From:      Rick Macklem <rmacklem@uoguelph.ca>
To:        Benjamin Kaduk <kaduk@mit.edu>, Garrett Wollman <wollman@bimajority.org>
Cc:        "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org>
Subject:   Re: Anyone managed to build a static gssd?
Message-ID:  <YTOPR0101MB21723D8BB5B9AFFCD051F512DD120@YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM>
In-Reply-To: <20180107190802.GD25484@kduck.kaduk.org>
References:  <23121.48634.348216.421634@hergotha.csail.mit.edu>, <20180107190802.GD25484@kduck.kaduk.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Benjamin Kaduk wrote:
>On Sun, Jan 07, 2018 at 01:28:10AM -0500, Garrett Wollman wrote:
>> I'm interesting in experimenting with GSSAPI security for NFS mounts,
>> but we run MIT Kerberos, not Heimdal.  AIUI, the kernel code has to
>> have the same data structures as the userland code in gssd, which
>> implies that gssd has to be built against Heimdal libraries, not MIT.
>
>I think you might want to test that hypothesis experimentally --
>both Heimdal and MIT have gss_export_lucid_sec_context() that
>generate the gss_krb5_lucid_context_v1_t data type, which seems
>to be defined identically between them.  AIUI, this "lucid" (i.e.,
>non-opaque) type is what is used for sending the GSS information
>into the kernel.
I haven't worked with this for a long time, but I vaguely recall that
the kernel RPCSEC_GSS code uses a relatively small subset to the
KGSSAPI upcalls to userland.

If you grep around in sys/rpc/rpcsec_gss you should be able to find
which ones they are (and see if they happen to be the same for Heimdal/MIT)=
.
I think the client side uses more than the server side, but beware that
the server becomes a client for callbacks for NFSv4.

Also, just fyi, RPCSEC_GSS Version 1 (the only one supported by FreeBSD)
uses good old DES and uses the session key created by the Kerberos
libraries via a TGT or keytab entry for this.
--> As such, your TGT encryption choice must result in a 56/64 bit session =
key.
     (I never went beyond using DES for TGT encryption, but I suspect MIT
      doesn't like that idea;-)

Good luck with it, rick



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTOPR0101MB21723D8BB5B9AFFCD051F512DD120>