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 > > -Ben
