In message <CAM5tNy4N301K4SK-Ow+T_ojg_xKfy2hy2TtNmLHDQVTse_VUyA@mail.gmail.c
om>
, Rick Macklem writes:
> On Thu, Jul 31, 2025 at 8:28=E2=80=AFAM Cy Schubert <Cy.Schubert@cschubert.=
> com> wrote:
> >
> > In message <CAM5tNy4XupPGXHMS0p0TK0Wf_zAg5bsOzx4C1K1e-_2b=3d3e...@mail.gm=
> ail.c
> > om>
> > , Rick Macklem writes:
> > > On Thu, Jul 31, 2025 at 6:51=3DE2=3D80=3DAFAM Rick Macklem <rick.mackle=
> m...@gmail.co=3D
> > > m> wrote:
> > > >
> > > > On Thu, Jul 31, 2025 at 6:07=3DE2=3D80=3DAFAM Rick Macklem <rick.mack=
> lem@gmail.=3D
> > > com> wrote:
> > > > >
> > > > > On Wed, Jul 30, 2025 at 9:24=3DE2=3D80=3DAFPM Benjamin Kaduk <bjkfb=
> sd@gmail.c=3D
> > > om> wrote:
> > > > > >
> > > > > > On Wed, Jul 30, 2025 at 10:36=3DE2=3D80=3DAFAM Rick Macklem <rick=
> .macklem@g=3D
> > > mail.com> wrote:
> > > > > >>
> > > > > >> On Mon, Jul 28, 2025 at 3:32=3DE2=3D80=3DAFPM Benjamin Kaduk <bj=
> kfbsd@gmai=3D
> > > l.com> wrote:
> > > > > >> >
> > > > > >> > On Mon, Jul 28, 2025 at 3:04=3DE2=3D80=3DAFPM Benjamin Kaduk <=
> bjkfbsd@gm=3D
> > > ail.com> wrote:
> > > > > >> >>
> > > > > >> >>
> > > > > >> >> Note that MIT krb5 provides the gss_krb5_export_lucid_sec_con=
> text=3D
> > > () API that does a lot of the work of getting useful bits out of an est=
> abli=3D
> > > shed GSS security context.
> > > > > >> >>
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > And a bit more context on what is going on here and why kgssap=
> i ha=3D
> > > s to care:
> > > > > >> > The GSS-API (RFC 2743) is all about a way to "establish a secu=
> rity=3D
> > > context" (i.e., do crypto negotiation, authentication, sometimes autho=
> riza=3D
> > > tion, etc.) between two entities, the initiator and the acceprot, and t=
> hen =3D
> > > exchanging protected messages between the two (which can be either encr=
> ypte=3D
> > > d or just integrity protection tags for otherweise cleartext data); lat=
> er e=3D
> > > xtensions included the ability to produce identical PRF output on both =
> part=3D
> > > ies, etc.. The details are "mechanism-specific", and for this purpose =
> we'r=3D
> > > e exclusively talking about the krb5 mechanism. The steps to establish=
> the=3D
> > > security context are complicated and sometimes fiddly, and in the gene=
> ral =3D
> > > case can require a large number of round-trips between the initiator an=
> d ac=3D
> > > ceptor before the security context is established. The individual mess=
> age-=3D
> > > protection parts are comparatively simple and amendable to implementati=
> on i=3D
> > > n the kernel for processing efficiency.
> > > > > >> > RFC 2743 also defines functions for GSS_Export_sec_context() a=
> nd G=3D
> > > SS_Import_sec_context(), that are designed essentially to pass informat=
> ion =3D
> > > about an established security context from one process to another on th=
> e sa=3D
> > > me machine (which are presumably using the same implementation and vers=
> ion =3D
> > > of the implementation), so the contents of the exported blob are opaque=
> and=3D
> > > implementation-specific. We are abusing that mechanism to export info=
> rmat=3D
> > > ion about the security context that gssd has established and feed that =
> info=3D
> > > rmation into the kernel implementation of the per-message processing ro=
> utin=3D
> > > es. At present, this necessarily entails knowing the details of the im=
> plem=3D
> > > entation-specific opaque blob that is the "export sec context token", w=
> hich=3D
> > > is what the sys/kgssapi/krb5/krb5_mech.c code is doing. But if we can=
> get=3D
> > > the information we want without breaking the abstraction barrier, such=
> as =3D
> > > via the gss_krb5_export_lucid_sec_context() API, we are in a more robus=
> t po=3D
> > > sture overall and somewhat future-proofed against future evolution by M=
> IT k=3D
> > > rb5.
> > > > > >> > (I note that recent Heimdal versions seem to also expose a gss=
> _krb=3D
> > > 5_export_lucid_sec_context() API, so part of the problem is just that t=
> he H=3D
> > > eimdal 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 =3D
> > > oid
> > > > > >> for the GSS_KRB5_EXPORT_LUCID_SEC_CONTEXT_OID with version 1.
> > > > > >> It kept failing.
> > > > > >> The problem seems to be that "gctx->proto =3D3D=3D3D 4" in make_=
> external=3D
> > > _lucid_ctx_v1()
> > > > > >> function. This function only knows about the 0 and 1 setting for=
> gct=3D
> > > x->proto.
> > > > > >>
> > > > > >> Any ideas, rick
> > > > > >>
> > > > > >
> > > > > >
> > > > > > I'm not seeing anything to suggest that a "gctx->proto" value of =
> 4 is=3D
> > > ever expected; it looks like it's supposed to just be 0 (for the legac=
> y RF=3D
> > > C 1964 format) or 1 (for the "CFX" format of RFC 4121, with wider seque=
> nce =3D
> > > numbers for message-protection formats, etc.). So maybe it's worth pos=
> ting=3D
> > > 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 offse=
> t
> > > > > in the structure).
> > > > > It is weird, though. If I do gss_inquire_sec_context_by_oid(&minor,=
> ctx=3D
> > > ,
> > > > > 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 byt=
> es f=3D
> > > rom the
> > > > > string + a 1 byte), it returns major =3D3D=3D3D GSS_S_COMPLETE, but=
> no data=3D
> > > and
> > > > > a weird 39756046(decimal) or 0x25ea10e(hex) minor.
> > > > > (Oh, and I tried gss_krb5_export_lucid_sec_context() and got the sa=
> me
> > > > > weird error.)
> > > > --> Now (after doing a "make buildworld"), gss_krb5_export_lucid_sec_=
> cont=3D
> > > ext()
> > > > returns GSS_S_BAD_MECH. Looking at the src, that error has to be=
> fro=3D
> > > m
> > > > gss_inquire_sec_context_by_oid(). So, same function fails, but a=
> dif=3D
> > > ferent
> > > > 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_typ=
> e
> > > > returned by it has a bogus pointer in the reply).
> > > > --> It looks like the "mech_type" field of "ctx" is busted, for some =
> reas=3D
> > > on?
> > > >
> > > > I'm going to try building krb5 from ports and linking to that, to see=
> if =3D
> > > it
> > > > does the same thing.
> > > Finally some good news...
> > > All I did was "pkg install krb5" and then linked the gssd to the librar=
> ies =3D
> > > in
> > > /usr/local/lib and it worked!!
> >
> > gssapi/gssapi.h from krb5/lib/gssapi/generic is overwritten by our
> > lib/libgssapi. As we have two the MIT gssapi.h is put in
> > /usr/include/gssapi_krb5/gssapi.h.
> >
> > This patch should fix the problem. I haven't tested this yet.
> >
> > diff --git a/usr.sbin/gssd/Makefile b/usr.sbin/gssd/Makefile
> > index 569e2c7e18f5..4c9d342c48c3 100644
> > --- a/usr.sbin/gssd/Makefile
> > +++ b/usr.sbin/gssd/Makefile
> > @@ -14,7 +14,7 @@ LIBADD=3D gssapi
> > .if ${MK_MITKRB5} !=3D "no"
> > # MIT KRB5
> > LIBADD+=3D krb5 k5crypto krb5profile krb5support
> > -CFLAGS+=3D -DMK_MITKRB5=3Dyes
> > +CFLAGS+=3D -DMK_MITKRB5=3Dyes -Iinclude/gssapi_krb5
> > .else
> > # Heimdal
> > LIBADD+=3D krb5 roken
> Just to be clear to everyone, this might allow it to be built after
> being patched for MIT, but it does not fix it so that it works.
>
> I will be debugging the patches that makes it works later to-day.
>
> You state that Heimdal didn't have a gssapi.h, but it does and it
> has always been included in gssd.c. (It was the other ones like
> gssapi_krb5.h, which needs the MIT gssapi.h.)
/usr/include/gssapi/gssapi.h is installed by /usr/src/lib/libgssapi not by
Heimdal v
Using the port as an example, the gssapi.h MIT installs is not the same as
the gssapi_krb5.h.
include/Makefile installs include/gssapi/gssapi.h to
/usr/include/gssapi/gssapi.h. Do we need this then?
--
Cheers,
Cy Schubert <cy.schub...@cschubert.com>
FreeBSD UNIX: <c...@freebsd.org> Web: https://FreeBSD.org
NTP: <c...@nwtime.org> Web: https://nwtime.org
e**(i*pi)+1=0
