Re: git: c7da9fb90b0b - main - KRB5: Enable MIT KRB5 by default

On Thu, Jul 31, 2025 at 7:18 AM Rick Macklem <rick.macklem@gmail.com> wrote:
>
> On Thu, Jul 31, 2025 at 6:51 AM Rick Macklem <rick.macklem@gmail.com> wrote:
> >
> > On Thu, Jul 31, 2025 at 6:07 AM Rick Macklem <rick.macklem@gmail.com> wrote:
> > >
> > > On Wed, Jul 30, 2025 at 9:24 PM Benjamin Kaduk <bjkfbsd@gmail.com> wrote:
> > > >
> > > > On Wed, Jul 30, 2025 at 10:36 AM Rick Macklem <rick.macklem@gmail.com> wrote:
> > > >>
> > > >> On Mon, Jul 28, 2025 at 3:32 PM Benjamin Kaduk <bjkfbsd@gmail.com> wrote:
> > > >> >
> > > >> > On Mon, Jul 28, 2025 at 3:04 PM 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 GSS security context.
> > > >> >>
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > And a bit more context on what is going on here and why kgssapi has to care:
> > > >> > The GSS-API (RFC 2743) is all about a way to "establish a security context" (i.e., do crypto negotiation, authentication, sometimes authorization, etc.) between two entities, the initiator and the acceprot, and then exchanging protected messages between the two (which can be either encrypted or just integrity protection tags for otherweise cleartext data); later extensions included the ability to produce identical PRF output on both parties, etc..  The details are "mechanism-specific", and for this purpose we're exclusively talking about the krb5 mechanism.  The steps to establish the security context are complicated and sometimes fiddly, and in the general case can require a large number of round-trips between the initiator and acceptor before the security context is established.  The individual message-protection parts are comparatively simple and amendable to implementation in the kernel for processing efficiency.
> > > >> > RFC 2743 also defines functions for GSS_Export_sec_context() and GSS_Import_sec_context(), that are designed essentially to pass information about an established security context from one process to another on the same machine (which are presumably using the same implementation and version of the implementation), so the contents of the exported blob are opaque and implementation-specific.  We are abusing that mechanism to export information about 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 implementation-specific opaque blob that is the "export sec context token", which is what the sys/kgssapi/krb5/krb5_mech.c code is doing.  But if we can get the information 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 overall and somewhat future-proofed against future evolution by MIT krb5.
> > > >> > (I note that recent Heimdal versions seem to also expose a gss_krb5_export_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 == 4" in make_external_lucid_ctx_v1()
> > > >> function. This function only knows about the 0 and 1 setting for gctx->proto.
> > > >>
> > > >> Any ideas, rick
> > > >>
> > > >
> > > >
> > > > I'm not seeing anything to suggest that a "gctx->proto" value of 4 is ever expected; it looks like it's supposed to just be 0 (for the legacy RFC 1964 format) or 1 (for the "CFX" format of RFC 4121, with wider sequence numbers for message-protection formats, etc.).  So maybe it's worth posting your current WIP somewhere to take a closer look at what's going on.
> > >
> > > Yea, the debugging I did was flawed (I probably got the wrong offset
> > > in the structure).
> > > It is weird, though. If I do gss_inquire_sec_context_by_oid(&minor, ctx,
> > > OID_FOR_GSS_INQUIRE_SSPI_SESSION_KEY, &key), it
> > > works and gives me the key and encryption type.
> > >
> > > If I do the same, but with the 12 byte OID for LUCID v1 (the 11 bytes from the
> > > string + a 1 byte), it returns major == GSS_S_COMPLETE, but no data and
> > > a weird 39756046(decimal) or 0x25ea10e(hex) minor.
> > > (Oh, and I tried gss_krb5_export_lucid_sec_context() and got the same
> > > weird error.)
> > --> Now (after doing a "make buildworld"), gss_krb5_export_lucid_sec_context()
> >      returns GSS_S_BAD_MECH. Looking at the src, that error has to be from
> >      gss_inquire_sec_context_by_oid(). So, same function fails, but a different
> >      error return?
> >
> > It looks like "gssint_get_mechanism (ctx->mech_type)" is failing.
> > I'm currently just passing GSS_C_NULL_OID into gss_init_sec_context(),
> > but I've also tried the Kerberos 9 byte OID (both work, in the sense that
> > gss_init_sec_context() seems to work, except that the actual_mech_type
> > returned by it has a bogus pointer in the reply).
> > --> It looks like the "mech_type" field of "ctx" is busted, for some reason?
> >
> > I'm going to try building krb5 from ports and linking to that, to see if it
> > does the same thing.
> Finally some good news...
> All I did was "pkg install krb5" and then linked the gssd to the libraries in
> /usr/local/lib and it worked!!
Just to clarify, "it" refers to the gss_krb5_export_lucid_sec_context()
call. I now have to debug the patch that uses it to get the kerberized NFS
mounts working.

rick

>
> Now I can test/debug the changes.
>
> Btw, the stuff in /usr/local/include/gssapi are correct and not messed up
> like the stuff in /usr/include/gssapi. (The ones in /usr/local/include define
> GSS_DLLIMP for example.)
>
> I'm going to leave figuring out why the libraries in /usr/lib are messed up
> to someone else.
>
> rick
>
> >
> > rick
> >
> > >
> > > Also, if I look at the actual_mech_type returned by gss_init_sec_context(),
> > > I get an instant crash, because the "elements" pointer cannot be
> > > accessed (this doesn't much matter, since the info should always be just
> > > the Kerberos OID).
> > > --> I suspect there is some problem w.r.t. how the libraries are being built?
> > >
> > > I'm now building from sources to try and dig into the library functions.
> > >
> > > rick
> > >
> > > >
> > > > From your previous message,
> > > >
> > > > > I am working on using gss_inquire_sec_context_by_oid(), which I think is just a front-end to gss_krb5_export_lucid_sec_context()? If that doesn't work, I'll switch to gss_krb5_export_lucid_sec_context(). (I am still waiting for the day when there is another mechanism. I have heard rumblings w.r.t. a mechanism for the Oauth stuff, but as far as I know, about all that they did was define an OID for it.)
> > > >
> > > > It looks like a front-end to the same core implementation at least (technically not a wrapper for the public API, though).
> > > > (There are a bunch of non-krb5 mechanisms, most not in terribly widespread use.)
> > > >
> > > > > Btw, do you have any experience porting KDC databases from Heimdal to MIT? (At this point, Cy has done it, but after doing so, the passwords all had to be reset. He thought he had used "--decrypt" when he dumped the Heimdal KDC.)
> > > >
> > > > I do not have such experience, but the conventional way to do it involves an unencrypted dump (which I presume is what the aforementioned "--decrypt" does).  Heimdal and MIT use (or at least used, the last time I looked) different techniques for encrypting the per-principal data in the dump file, so a trip through plaintext helps.  I do remember reading about Heimdal having grown some support for the MIT database format; the commit message at https://github.com/heimdal/heimdal/commit/57f1545a46fdad9207a71903a56f3c1d1fff3a10 is perhaps a very high-level description of what is expected to be possible.
> > > >
> > > > -Ben