[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-arch
Subject:    Re: How to update or should we update Kerberos
From:       Benjamin Kaduk <kaduk () mit ! edu>
Date:       2018-05-29 16:16:48
Message-ID: 20180529161645.GF27985 () kduck ! kaduk ! org
[Download RAW message or body]

On Tue, May 29, 2018 at 06:04:23AM -0700, Cy Schubert wrote:
> In message <YTOPR0101MB095376A67E0BBB4A2961F4BBDD6D0@YTOPR0101MB0953.CAN
> PRD01.P
> ROD.OUTLOOK.COM>, Rick Macklem writes:
> > Sean Bruno wrote:
> > [stuff snipped]
> > >Heh, yeah, I asked this question *wrong*.  I know how we use it in the
> > >cluster.  :-)
> > >
> > >I mean to ask, "why aren't we using ports for kerberos?"  What purpose
> > >does it serve in the base system?
> > Although I have no idea how many use it, both the NFS client and server can d
> > o
> > Kerberized mounts. I haven't tried, but it probably needs some bits to build 
> > it
> > and if you move it to ports, there would be duplicates (and the opportunity t
> > o
> > have one change without the other introducing a hard to find bug).
> >
> > Also, I'd argue that security technology like this is pretty "core".
> >
> > I am mainly referring to the libraries and client side stuff and not the KDC.
> 
> IMO the base should only contain the libraries and client side.

I'm inclined to agree -- running a KDC with the implementation in
the base system doesn't seem like a great plan to me.

To expand the NFS use case a bit more, NFS uses the GSS-API to
secure RPCs (only when security features are enabled, of course).
The GSS-API normally operates only with message tokens that are
opaque to the application layer, but for efficiency/speed we want to
do the bulk data processing in the kernel.  The traditional way to
do this is to have an implementation-specific extension to the
GSS-API that exposes a "lucid" (i.e., not opaque) structure with
information about a security context and its key material, and shove
that stuff into the kernel to use for per-message processing.  Since
this non-standard structure is implementation-specific, it's
generally expected that the kernel code is kept in sync with the
userspace code that does the actual security context
negotiation/handshake and the key export.  This basically requires
having it in the base system, AFAICT.

-Ben
_______________________________________________
freebsd-arch@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]