Date: Wed, 30 Jul 2025 10:36:36 -0700 From: Rick Macklem <rick.macklem@gmail.com> To: Benjamin Kaduk <bjkfbsd@gmail.com> Cc: Konstantin Belousov <kostikbel@gmail.com>, Cy Schubert <Cy.Schubert@cschubert.com>, Jessica Clarke <jrtc27@freebsd.org>, Cy Schubert <cy@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "dev-commits-src-all@freebsd.org" <dev-commits-src-all@freebsd.org>, "dev-commits-src-main@freebsd.org" <dev-commits-src-main@freebsd.org> Subject: Re: git: c7da9fb90b0b - main - KRB5: Enable MIT KRB5 by default Message-ID: <CAM5tNy5DjktV54JaNcXSwc=9W9kyKTbYANyWp3wmgWu1aMvmLg@mail.gmail.com> In-Reply-To: <CAJ5_RoBXD4rkudaqo4BA%2BrggYcy%2BLUSnPrK2_FO4Cp_xG0fS=Q@mail.gmail.com> References: <202507211410.56LEAD6J066633@gitrepo.freebsd.org> <47C3CC37-6F32-4376-900A-B5387B9817D5@freebsd.org> <20250721144645.3BA391BE@slippy.cwsent.com> <aH98iNXobigu39On@kib.kiev.ua> <20250722155941.AC7EB121@slippy.cwsent.com> <CAM5tNy63Ri73x3ByJUPFh7a0eCVjWPGW1hQwrkG0wz6pJ6-W3Q@mail.gmail.com> <aIcyq6JuYngAm4Ko@kib.kiev.ua> <CAM5tNy6pAUS1HD4W1=rxLXvfctAs1Ms_fxwUWz1X3tFNuVTVZg@mail.gmail.com> <CAJ5_RoBjpX_BoKgZTdOof5b83cdxjZyvn4iPM4m5voPHEr2SeQ@mail.gmail.com> <CAJ5_RoBXD4rkudaqo4BA%2BrggYcy%2BLUSnPrK2_FO4Cp_xG0fS=Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 28, 2025 at 3:32=E2=80=AFPM Benjamin Kaduk <bjkfbsd@gmail.com> = wrote: > > On Mon, Jul 28, 2025 at 3:04=E2=80=AFPM Benjamin Kaduk <bjkfbsd@gmail.com= > wrote: >> >> >> Note that MIT krb5 provides the gss_krb5_export_lucid_sec_context() API = that does a lot of the work of getting useful bits out of an established GS= S security context. >> > > > > > And a bit more context on what is going on here and why kgssapi has to ca= re: > The GSS-API (RFC 2743) is all about a way to "establish a security contex= t" (i.e., do crypto negotiation, authentication, sometimes authorization, e= tc.) between two entities, the initiator and the acceprot, and then exchang= ing protected messages between the two (which can be either encrypted or ju= st integrity protection tags for otherweise cleartext data); later extensio= ns included the ability to produce identical PRF output on both parties, et= c.. The details are "mechanism-specific", and for this purpose we're exclu= sively talking about the krb5 mechanism. The steps to establish the securi= ty context are complicated and sometimes fiddly, and in the general case ca= n require a large number of round-trips between the initiator and acceptor = before the security context is established. The individual message-protect= ion parts are comparatively simple and amendable to implementation in the k= ernel for processing efficiency. > RFC 2743 also defines functions for GSS_Export_sec_context() and GSS_Impo= rt_sec_context(), that are designed essentially to pass information about a= n established security context from one process to another on the same mach= ine (which are presumably using the same implementation and version of the = implementation), so the contents of the exported blob are opaque and implem= entation-specific. We are abusing that mechanism to export information abo= ut the security context that gssd has established and feed that information= into the kernel implementation of the per-message processing routines. At= present, this necessarily entails knowing the details of the implementatio= n-specific opaque blob that is the "export sec context token", which is wha= t the sys/kgssapi/krb5/krb5_mech.c code is doing. But if we can get the in= formation we want without breaking the abstraction barrier, such as via the= gss_krb5_export_lucid_sec_context() API, we are in a more robust posture o= verall and somewhat future-proofed against future evolution by MIT krb5. > (I note that recent Heimdal versions seem to also expose a gss_krb5_expor= t_lucid_sec_context() API, so part of the problem is just that the Heimdal = in base is so old.) Well, here's some "not so good" news... I've been trying to use gss_inquire_sec_context_by_oid(..) with the oid for the GSS_KRB5_EXPORT_LUCID_SEC_CONTEXT_OID with version 1. It kept failing. The problem seems to be that "gctx->proto =3D=3D 4" in make_external_lucid_= ctx_v1() function. This function only knows about the 0 and 1 setting for gctx->prot= o. Any ideas, rick > > -Ben
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM5tNy5DjktV54JaNcXSwc=9W9kyKTbYANyWp3wmgWu1aMvmLg>