Date: Thu, 31 Jul 2025 06:51:51 -0700 From: Rick Macklem <rick.macklem@gmail.com> To: Benjamin Kaduk <bjkfbsd@gmail.com> Cc: Konstantin Belousov <kostikbel@gmail.com>, Cy Schubert <Cy.Schubert@cschubert.com>, Jessica Clarke <jrtc27@freebsd.org>, Cy Schubert <cy@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "dev-commits-src-all@freebsd.org" <dev-commits-src-all@freebsd.org>, "dev-commits-src-main@freebsd.org" <dev-commits-src-main@freebsd.org> Subject: Re: git: c7da9fb90b0b - main - KRB5: Enable MIT KRB5 by default Message-ID: <CAM5tNy78DEgmx4z=RJbMsBkRuO6sX%2BhK9OfKbg4ACcRMnrOQgA@mail.gmail.com> In-Reply-To: <CAM5tNy6Va=edwT5TTa8NEtCHrpbAnN1NMDsBKNNbqNgPoCjVng@mail.gmail.com> References: <202507211410.56LEAD6J066633@gitrepo.freebsd.org> <47C3CC37-6F32-4376-900A-B5387B9817D5@freebsd.org> <20250721144645.3BA391BE@slippy.cwsent.com> <aH98iNXobigu39On@kib.kiev.ua> <20250722155941.AC7EB121@slippy.cwsent.com> <CAM5tNy63Ri73x3ByJUPFh7a0eCVjWPGW1hQwrkG0wz6pJ6-W3Q@mail.gmail.com> <aIcyq6JuYngAm4Ko@kib.kiev.ua> <CAM5tNy6pAUS1HD4W1=rxLXvfctAs1Ms_fxwUWz1X3tFNuVTVZg@mail.gmail.com> <CAJ5_RoBjpX_BoKgZTdOof5b83cdxjZyvn4iPM4m5voPHEr2SeQ@mail.gmail.com> <CAJ5_RoBXD4rkudaqo4BA%2BrggYcy%2BLUSnPrK2_FO4Cp_xG0fS=Q@mail.gmail.com> <CAM5tNy5DjktV54JaNcXSwc=9W9kyKTbYANyWp3wmgWu1aMvmLg@mail.gmail.com> <CAJ5_RoDdhmpsLWtuCiaWJoR1yMvAq_4r-E%2BpUk03TiQofTZELQ@mail.gmail.com> <CAM5tNy6Va=edwT5TTa8NEtCHrpbAnN1NMDsBKNNbqNgPoCjVng@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 31, 2025 at 6:07=E2=80=AFAM Rick Macklem <rick.macklem@gmail.co=
m> wrote:
>
> On Wed, Jul 30, 2025 at 9:24=E2=80=AFPM Benjamin Kaduk <bjkfbsd@gmail.com=
> wrote:
> >
> > On Wed, Jul 30, 2025 at 10:36=E2=80=AFAM Rick Macklem <rick.macklem@gma=
il.com> wrote:
> >>
> >> On Mon, Jul 28, 2025 at 3:32=E2=80=AFPM Benjamin Kaduk <bjkfbsd@gmail.=
com> wrote:
> >> >
> >> > On Mon, Jul 28, 2025 at 3:04=E2=80=AFPM Benjamin Kaduk <bjkfbsd@gmai=
l.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 establish=
ed 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 c=
ontext" (i.e., do crypto negotiation, authentication, sometimes authorizati=
on, etc.) between two entities, the initiator and the acceprot, and then ex=
changing protected messages between the two (which can be either encrypted =
or just integrity protection tags for otherweise cleartext data); later ext=
ensions included the ability to produce identical PRF output on both partie=
s, etc.. The details are "mechanism-specific", and for this purpose we're =
exclusively talking about the krb5 mechanism. The steps to establish the s=
ecurity context are complicated and sometimes fiddly, and in the general ca=
se can require a large number of round-trips between the initiator and acce=
ptor before the security context is established. The individual message-pr=
otection 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 ab=
out 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 i=
mplementation-specific. We are abusing that mechanism to export informatio=
n about the security context that gssd has established and feed that inform=
ation into the kernel implementation of the per-message processing routines=
. At present, this necessarily entails knowing the details of the implemen=
tation-specific opaque blob that is the "export sec context token", which i=
s what the sys/kgssapi/krb5/krb5_mech.c code is doing. But if we can get t=
he information we want without breaking the abstraction barrier, such as vi=
a the gss_krb5_export_lucid_sec_context() API, we are in a more robust post=
ure overall and somewhat future-proofed against future evolution by MIT krb=
5.
> >> > (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 Hei=
mdal 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 oi=
d
> >> for the GSS_KRB5_EXPORT_LUCID_SEC_CONTEXT_OID with version 1.
> >> It kept failing.
> >> The problem seems to be that "gctx->proto =3D=3D 4" in make_external_l=
ucid_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 e=
ver 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 nu=
mbers for message-protection formats, etc.). So maybe it's worth posting y=
our 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 fro=
m the
> string + a 1 byte), it returns major =3D=3D GSS_S_COMPLETE, but no data a=
nd
> 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_contex=
t()
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 diffe=
rent
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.
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 bu=
ilt?
>
> 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 wai=
ting 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 (tec=
hnically not a wrapper for the public API, though).
> > (There are a bunch of non-krb5 mechanisms, most not in terribly widespr=
ead 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 Hei=
mdal KDC.)
> >
> > I do not have such experience, but the conventional way to do it involv=
es an unencrypted dump (which I presume is what the aforementioned "--decry=
pt" 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 h=
aving grown some support for the MIT database format; the commit message at=
https://github.com/heimdal/heimdal/commit/57f1545a46fdad9207a71903a56f3c1d=
1fff3a10 is perhaps a very high-level description of what is expected to be=
possible.
> >
> > -Ben
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM5tNy78DEgmx4z=RJbMsBkRuO6sX%2BhK9OfKbg4ACcRMnrOQgA>