From nobody Thu Jul 31 04:23:51 2025 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4bswvb1djLz63QBF; Thu, 31 Jul 2025 04:24:11 +0000 (UTC) (envelope-from bjkfbsd@gmail.com) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4bswvY68N6z3K7Y; Thu, 31 Jul 2025 04:24:09 +0000 (UTC) (envelope-from bjkfbsd@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="W5+/Kx2H"; spf=pass (mx1.freebsd.org: domain of bjkfbsd@gmail.com designates 2607:f8b0:4864:20::102e as permitted sender) smtp.mailfrom=bjkfbsd@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pj1-x102e.google.com with SMTP id 98e67ed59e1d1-31ecdf5faaeso5722a91.0; Wed, 30 Jul 2025 21:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753935844; x=1754540644; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=CcJ2apdFYpdA+awUmlzT4iZJzAUq3ten/tkzBbfzY5k=; b=W5+/Kx2HzKNqhl6i2Jm5TO7Z09wFPn3j79pr7TVuhPUNZ+VpJ44mUL+c6DqcVFEJ0t y+8qA7v1B/teF02xWdWlANINgMut+Z71GR3dRyTfAfx5TN4hHw9CGQt3PhSdN/KpxHli 4V7iQ+S88rM6cGEv1diyv87KYM0XGgGpHrjQUDPDiQts0qg335Z7WsZtrfbZax2dOKBs do16XFnuHlljO+bPVduNDPHnsK8LVibnjTddhjqHENHjW5EeiYhnKpylQm7oJHzXWkIR UQtjY7ZLUGWtsX84I1QIiU/ddBUsLQXkgLLCtd84Lv59qWRBsxSlrLayk7LWhe80sud7 e9cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753935844; x=1754540644; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=CcJ2apdFYpdA+awUmlzT4iZJzAUq3ten/tkzBbfzY5k=; b=QO/4t4qOeoiflqhL8jHvO7lm85CM0QN0apSITOBbzlHc+PWCccvFBqR3yFKnh1Oedg RNVFgwIPPqK/VQcCH5uCUj5URXUeXjzQBmj11Dj5+0I+DrdOGYRvUZnuhMqqCs/7F5my OxQUY4FYHPawJdXrO0crmgtrZIZEIDRc9ekNGiOOsv02Obx90dLSl0owI+A/L4duQ312 2ZdI/Rs+X0XDl/hhSltGA0z0hcAnJfA0EdGSseuYCG+eAH7TroczzcLLSCUZNe+TvVTv 7ou+sFLNsNRL5aj+wu2JRv15RZYHVwRK7q3V1sm4u4Ic/NdpYraz94hYGo3KmOp5G+zb mUTg== X-Forwarded-Encrypted: i=1; AJvYcCUqwrIYplyMhXfIBmhNW2KfsXA/Pb6I/LkgyIB2Fqk0etzgcFhebzaCjf9DAPOElRjPmaVArinHYJDXdjRdAsyOnjM6Rg==@freebsd.org, AJvYcCVggVdQQMzpkctXVViiSVytQWPQEN9IhPMVq6FqnpP90AwOspS5U1ZCUj9i6prWBETvlKDesO4GoZttXkVxA/Y=@freebsd.org, AJvYcCWjIMLzldLQ5qprrhuUS/Ebb2ZMHqF1wA20etyXXIR5X0oMr+vUuujzjGPaEquJcIUC3M+iA/WF@freebsd.org, AJvYcCX2PpmdCKyXfAZjJ8ks3g8lso/XIe3HN4ml09sCDQGxQLSoqPxvUfwNbNHQ9CgbRTBhbA==@freebsd.org, AJvYcCXM2FU+Uhj1w/0o6fneQPWEDzHrb2kCSsIKQutu/2ETPJnr3g+xY2JhuQ4THvPjGmWiePXKGOXbd0cgQi5nwNOrnw4gr9A=@freebsd.org X-Gm-Message-State: AOJu0YwTU8L7Df7QfcMLTEs0KkVjYPiuFtMCs2RY7ns3Y24hT8MiLuyU XwjC2kI7tW2bCNbMYo6P3vpAjhU9b/hl2On6rdo0rUAznx3F++pfsNZDsE7OTS90jgoWFkaaxTB a6FQFAuLVLns045XcCYcjs0nCZaucK8fRIpM8 X-Gm-Gg: ASbGnctDWxVV0CAZvm/0h9pJJPdcJtZ3nbzhDCvpAZKvaDVVrcA0RJ6ZlNQhAKRWSvR rfcs5SJpS5rROSBiy1FPSfBwX8G6x65IoOuyJXl7f2rBYOkK4g5nhWzt05UQaBLV/2j84Nqia8H NolaLSH4870rbtgbMdMbxMPkchLNwG3tqiylqAm6iCyRidjI21+Z0LSX52FvTXOqSlw8UdeGKov 7zlzcc= X-Google-Smtp-Source: AGHT+IHjqiEf1stZQ4IO429gZKb2vUkM2tHQyFc7C5Doo5AbL8/WHEqhqHXdUoWrzV/xZLLHv5zvgqZ60Z1YT11tX8o= X-Received: by 2002:a17:90b:5282:b0:312:1d2d:18e2 with SMTP id 98e67ed59e1d1-31f5de5564bmr7844386a91.20.1753935843596; Wed, 30 Jul 2025 21:24:03 -0700 (PDT) List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 References: <202507211410.56LEAD6J066633@gitrepo.freebsd.org> <47C3CC37-6F32-4376-900A-B5387B9817D5@freebsd.org> <20250721144645.3BA391BE@slippy.cwsent.com> <20250722155941.AC7EB121@slippy.cwsent.com> In-Reply-To: From: Benjamin Kaduk Date: Wed, 30 Jul 2025 21:23:51 -0700 X-Gm-Features: Ac12FXzAmVZeM8B1wr6eqiBzAQ9f6O11CiKZ0E1vzEJ3AXe4_qU0tUlITrESFXs Message-ID: Subject: Re: git: c7da9fb90b0b - main - KRB5: Enable MIT KRB5 by default To: Rick Macklem Cc: Konstantin Belousov , Cy Schubert , Jessica Clarke , Cy Schubert , "src-committers@freebsd.org" , "dev-commits-src-all@freebsd.org" , "dev-commits-src-main@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000ea9e8f063b320264" X-Spamd-Result: default: False [-2.45 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.95)[-0.953]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DN_EQ_ADDR_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_SOME(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,cschubert.com,freebsd.org]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[dev-commits-src-all@freebsd.org,dev-commits-src-main@freebsd.org]; TAGGED_RCPT(0.00)[]; RCPT_COUNT_SEVEN(0.00)[8]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102e:from] X-Rspamd-Queue-Id: 4bswvY68N6z3K7Y X-Spamd-Bar: -- --000000000000ea9e8f063b320264 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 30, 2025 at 10:36=E2=80=AFAM Rick Macklem wrote: > On Mon, Jul 28, 2025 at 3:32=E2=80=AFPM Benjamin Kaduk wrote: > > > > On Mon, Jul 28, 2025 at 3:04=E2=80=AFPM Benjamin Kaduk > wrote: > >> > >> > >> Note that MIT krb5 provides the gss_krb5_export_lucid_sec_context() AP= I > 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 eith= er > 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 amendabl= e > 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 informati= on > 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 a= nd > 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 se= c > 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 =3D=3D 4" in > make_external_lucid_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 ever 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 numbers for message-protection formats, etc.). So maybe it's worth posting your current WIP somewhere to take a closer look at what's going on. >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 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.) It looks like a front-end to the same core implementation at least (technically not a wrapper for the public API, though). (There are a bunch of non-krb5 mechanisms, most not in terribly widespread 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 Heimdal KDC.) I do not have such experience, but the conventional way to do it involves an unencrypted dump (which I presume is what the aforementioned "--decrypt" 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 having grown some support for the MIT database format; the commit message at https://github.com/heimdal/heimdal/commit/57f1545a46fdad9207a71903a56f3c1d1= fff3a10 is perhaps a very high-level description of what is expected to be possible= . -Ben --000000000000ea9e8f063b320264 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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@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 establis= hed 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 securit= y context" (i.e., do crypto negotiation, authentication, sometimes aut= horization, etc.) between two entities, the initiator and the acceprot, and= then exchanging protected messages between the two (which can be either en= crypted or just integrity protection tags for otherweise cleartext data); l= ater extensions included the ability to produce identical PRF output on bot= h parties, etc..=C2=A0 The details are "mechanism-specific", and = for this purpose we're exclusively talking about the krb5 mechanism.=C2= =A0 The steps to establish the security context are complicated and sometim= es fiddly, and in the general case can require a large number of round-trip= s between the initiator and acceptor before the security context is establi= shed.=C2=A0 The individual message-protection parts are comparatively simpl= e and amendable to implementation in the kernel for processing efficiency.<= br> > RFC 2743 also defines functions for GSS_Export_sec_context() and GSS_I= mport_sec_context(), that are designed essentially to pass information abou= t an established security context from one process to another on the same m= achine (which are presumably using the same implementation and version of t= he implementation), so the contents of the exported blob are opaque and imp= lementation-specific.=C2=A0 We are abusing that mechanism to export informa= tion about the security context that gssd has established and feed that inf= ormation into the kernel implementation of the per-message processing routi= nes.=C2=A0 At present, this necessarily entails knowing the details of the = implementation-specific opaque blob that is the "export sec context to= ken", which is what the sys/kgssapi/krb5/krb5_mech.c code is doing.=C2= =A0 But if we can get the information we want without breaking the abstract= ion barrier, such as via the gss_krb5_export_lucid_sec_context() API, we ar= e in a more robust posture overall and somewhat future-proofed against futu= re evolution by MIT krb5.
> (I note that recent Heimdal versions seem to also expose a gss_krb5_ex= port_lucid_sec_context() API, so part of the problem is just that the Heimd= al 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 =3D=3D 4" in make_ex= ternal_lucid_ctx_v1()
function. This function only knows about the 0 and 1 setting for gctx->p= roto.

Any ideas, rick



I= 9;m not seeing anything to suggest that a "gctx->proto" value = of 4 is ever expected; it looks like it's supposed to just be 0 (for th= e legacy RFC 1964 format) or 1 (for the "CFX" format of RFC 4121,= with wider sequence numbers for message-protection formats, etc.).=C2=A0 S= o maybe it's worth posting your current WIP somewhere to take a closer = look at what's going on.=C2=A0

From your previ= ous message,

> I am working on using gss_inquir= e_sec_context_by_oid(), which I think is just a front-end to gss_krb5_expor= t_lucid_sec_context()? If that doesn't work, I'll switch to gss_krb= 5_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.)

It looks like a front-end to th= e same core implementation at least (technically not a wrapper for the publ= ic API, though).
(The= re are a bunch of non-krb5 mechanisms, most not in terribly widespread 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 pas= swords all had to be reset. He thought he had used "--decrypt" wh= en he dumped the Heimdal KDC.)

I do n= ot have such experience, but the conventional way to do it involves an unen= crypted dump (which I presume is what the aforementioned "--decrypt&qu= ot; does).=C2=A0 Heimdal and MIT use (or at least used, the last time I loo= ked) different techniques for encrypting the per-principal data in the dump= file, so a trip through plaintext helps.=C2=A0 I do remember reading about= Heimdal having grown some support for the MIT database format; the commit = message at https://github.com/heimdal/heimdal/commit/57= f1545a46fdad9207a71903a56f3c1d1fff3a10 is perhaps a very high-level des= cription of what is expected to be possible.

-Ben
--000000000000ea9e8f063b320264--