Date: Tue, 29 May 2018 11:16:48 -0500 From: Benjamin Kaduk <kaduk@mit.edu> To: Cy Schubert <Cy.Schubert@cschubert.com> Cc: Rick Macklem <rmacklem@uoguelph.ca>, Sean Bruno <sbruno@freebsd.org>, freebsd-arch <freebsd-arch@freebsd.org> Subject: Re: How to update or should we update Kerberos Message-ID: <20180529161645.GF27985@kduck.kaduk.org> In-Reply-To: <201805291304.w4TD4NAr059913@slippy.cwsent.com> References: <rmacklem@uoguelph.ca> <YTOPR0101MB095376A67E0BBB4A2961F4BBDD6D0@YTOPR0101MB0953.CANPRD01.PROD.OUTLOOK.COM> <201805291304.w4TD4NAr059913@slippy.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180529161645.GF27985>