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.) 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
