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

-Ben

Reply via email to