From nobody Mon Jul 28 22:32:44 2025 X-Original-To: dev-commits-src-main@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 4brYCN3bHsz63Y9w; Mon, 28 Jul 2025 22:33:04 +0000 (UTC) (envelope-from bjkfbsd@gmail.com) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 4brYCM2m9lz4Dh5; Mon, 28 Jul 2025 22:33:03 +0000 (UTC) (envelope-from bjkfbsd@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=FmFdMHhE; spf=pass (mx1.freebsd.org: domain of bjkfbsd@gmail.com designates 2607:f8b0:4864:20::631 as permitted sender) smtp.mailfrom=bjkfbsd@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-23fc5aedaf0so18507765ad.2; Mon, 28 Jul 2025 15:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753741977; x=1754346777; 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=4A2j7zm42pi9Cgk+5zpTeG+2R5JskTxv+Fo9mXmtVl0=; b=FmFdMHhEznnqFlnWgGnnyuhsXi9OnPX5ivWXvnWdsjfWwe3mcfuqSqNVUP5ZCaUS6J JRAyPy/yJ7PGbctBo/nODD0t5gJ3o1BU9l1P5fRgDhVOibWAMFCAJVzv/BqheSt9pYx9 CyU7KwKGrz4Zs1E/o9kCD6cN0ps8wwcTujWnkHyjbQs4kaMmxylFx1RAe/OuN31VNXb2 qDvmAl8hf9PNAyDyveM0IUCFwRuHNHWlOdzb3fYSTONvWixPUcmNwPsRJi/JvpiHLol7 7PyBo3gZ00CWhzL/BaBNlsA2WbCAOElTpsgpJ898Ob0uR5XmltyKAR98DhOmSPhyR11k eVJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753741977; x=1754346777; 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=4A2j7zm42pi9Cgk+5zpTeG+2R5JskTxv+Fo9mXmtVl0=; b=HJzs1fIfQcPK5rxCJm/Dr2AKDJ0Lw6ioemFQGiref0l/JrucyxeTB3NiuvJX+jnyys +Xeommv8GkYgfLx32lQFvB5NK9QgGe3GaD8LOfzF7pE1s+PjDNFopcFNZkbqhl+EoAsT lCygNDF3KT8kerFMD0UacmR3wMkwH5uXLISIyqtIPR7lTgEY7HEJ/EnQV2l8IrZFgdiW aDbkcxrP3KZbrSJBbr8CWX0LafC+iQ0hLPE43Ua2ttg4FDDmCvZe8uuHV/M70Gypp1CO rXpCG45uYFPZXW3baYtNGjc1xwkR8LktEy4y4bgUoPxvL/SBuatcaBvoZUB4ohSsN+j2 BV8w== X-Forwarded-Encrypted: i=1; AJvYcCUk0RO8gSsYiX4+l4ZfHV1xGSv4G8a2ZrU6St60RdG6Zj5/g0vz/hw24dGxQQCMY0sGaA==@freebsd.org, AJvYcCUxo5bmOIJeiHwUXSIOq1ujBYJoTbXkEiNIT9J4XIYBshhFANBZbjuuf1kB5OYlG4+AYii3m8oB6QAqqAK37FjnMs6kLQ==@freebsd.org, AJvYcCVir57M5RR+QIoTHE34/ekeq23Sz1yZZGORvNbm/d8DF0lQr1JPE+uQU+AMoA1+BxfizHNx6u9En0NCoz7Kmkhwe7/132o=@freebsd.org, AJvYcCVxFWtZz+o4mw9liTSWhulHQo00Wkr3x0QoVoLdkDN+g2sxVz1Mj9kbd3/207++PZQVnRfjFrIF5CDTR2pylnM=@freebsd.org, AJvYcCWkQm7WL72EZGk16WHzzBMWNWhkgMWlxYZfxsgaOortVsy0jCNvOC0/BuSwU02zdvw+A0+ajGBI@freebsd.org X-Gm-Message-State: AOJu0YzTKDYTBjD3JDBPfRvkDiQSEd8SA/msYNOmciUnhvnlOGu/G1M/ j2rqEaGUSIvqGBJyCSh3yquwr+KBMCKCrGmFO7HnPxXJ0mQ6gn1E3ZYcp1On3PJzbPvSfqrmN5z ewmzXwdht4/h2WCpUEcxSZhKSmQMZM00eGy6A X-Gm-Gg: ASbGncu6ow6Sp0+QEtrjjwOAxo8Hy6K7fVVWTdw8wD1eoDecjniTsr7cRQlMZ0MSPOq D+H5sYdVkJjVSCFqS5j8sZra5BAqcvS28iSi+3sNCI77adqholnu/Oqx7NrtiA4z38SNzwEwzqG GRzoqWpGKFuUPe0daUwqodV3l/qQwd1qlIuy+v/sK5GauDupd6BD/x5ld+xDeZrwfEsOzbrhKuz 9NFHcc= X-Google-Smtp-Source: AGHT+IHLcddDeplLV0Nr3DzZNie+FP3T31vdedkZP5mGasTA46hsfGVJKcuJI7L2spYiDXNmyGiBNDvzSsdvDaM27fU= X-Received: by 2002:a17:902:ca95:b0:23f:bb95:6990 with SMTP id d9443c01a7336-23fbb956b99mr131834485ad.21.1753741976866; Mon, 28 Jul 2025 15:32:56 -0700 (PDT) List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@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: Mon, 28 Jul 2025 15:32:44 -0700 X-Gm-Features: Ac12FXwNwBv1t0aMjJDtzIbM9AzLPoXgdCBDLqqUQ9nzURq3yCS06iq98Ye3EIw 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="0000000000008f1cdc063b04dfbb" X-Spamd-Result: default: False [-2.26 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.76)[-0.762]; 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:c]; 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)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; 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)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; 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::631:from] X-Rspamd-Queue-Id: 4brYCM2m9lz4Dh5 X-Spamd-Bar: -- --0000000000008f1cdc063b04dfbb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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() 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 --0000000000008f1cdc063b04dfbb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 28, 2025 at 3:04=E2=80=AFPM B= enjamin Kaduk <bjkfbsd@gmail.com> wrote:

Note that MIT krb5 provides the= =C2=A0gss_krb5_export_lucid_sec_context() API that does a lot of the work o= f getting useful bits out of an established GSS security context.
=C2=A0


The GSS-API (RFC 2743) is all about a way to "= ;establish a security context" (i.e., do crypto negotiation, authentic= ation, sometimes authorization, etc.) between two entities, the initiator a= nd the acceprot, and then exchanging protected messages between the two (wh= ich can be either encrypted or just integrity protection tags for otherweis= e cleartext data); later extensions included the ability to produce identic= al PRF output on both parties, etc..=C2=A0 The details are "mechanism-= specific", and for this purpose we're exclusively talking about th= e krb5 mechanism.=C2=A0 The steps to establish the security context are com= plicated and sometimes fiddly, and in the general case can require a large = number of round-trips between the initiator and acceptor before the securit= y context is established.=C2=A0 The individual message-protection parts are= comparatively simple and amendable to implementation in the kernel for pro= cessing efficiency.
RFC 2743 also defines functions for GSS_Expor= t_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 implem= entation and version of the implementation), so the contents of the exporte= d blob are opaque and implementation-specific.=C2=A0 We are abusing that me= chanism to export information about the security context that gssd has esta= blished and feed that information into the kernel implementation of the per= -message processing routines.=C2=A0 At present, this necessarily entails kn= owing the details of the implementation-specific opaque blob that is the &q= uot;export sec context token", which is what the sys/kgssapi/krb5/krb5= _mech.c code is doing.=C2=A0 But if we can get the information we want with= out 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 fu= ture-proofed against future evolution by MIT krb5.

--0000000000008f1cdc063b04dfbb--