On Thu, Jul 31, 2025 at 6:07 AM Rick Macklem <rick.mack...@gmail.com> wrote:
>
> On Wed, Jul 30, 2025 at 9:24 PM Benjamin Kaduk <bjkf...@gmail.com> wrote:
> >
> > On Wed, Jul 30, 2025 at 10:36 AM Rick Macklem <rick.mack...@gmail.com>
> > wrote:
> >>
> >> On Mon, Jul 28, 2025 at 3:32 PM Benjamin Kaduk <bjkf...@gmail.com> wrote:
> >> >
> >> > On Mon, Jul 28, 2025 at 3:04 PM Benjamin Kaduk <bjkf...@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.
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
