On Thu, Jul 31, 2025 at 7:18 AM Rick Macklem <rick.mack...@gmail.com> wrote: > > On Thu, Jul 31, 2025 at 6:51 AM Rick Macklem <rick.mack...@gmail.com> wrote: > > > > 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. > 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
