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.
Yes, that was my thinking too. > (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.) Good to hear, just in case there is a decision to go that way. (At this point, I doubt that.) 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.) 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.) rick > > -Ben
