From nobody Thu Jul 31 13:51: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 4bt9Vy2yJPz63t26; Thu, 31 Jul 2025 13:52:10 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 4bt9Vx1pwfz3BmX; Thu, 31 Jul 2025 13:52:09 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=Picj5yhX; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::530 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-615622ed677so1381220a12.1; Thu, 31 Jul 2025 06:52:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753969923; x=1754574723; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=BY5vPMrJ2PHPFe1sQeNrqoK9PWruaGqzBjAPPkveWv8=; b=Picj5yhXa5sWCQaFJWpJ4ab4aj3bLNezFM/kFNNlyJezL2rWvMDS6K3nbyocysV4Xj mWcIpj/yCeT78C+CpmifsO4mUnqTZTL5TD7yRkcDvWdkafxH3Dtff/5OszKy2/xDYkkX ZNE9B0Bf5K2UdYxWoKBTaF8SP0fRWBriTK/pjrU9e6NPO384Y1YNdcGeKIx5bxxR/cJ+ Ih8z2SqXM1tULRF5mgOFwvtAKXn4subUGGokyalcm9FKpVlyQ6y55HDmNzwfSnnbsO4A m0A8xyvJwWCgGz98yLVeuvf2q2NPKW1FABXx7QBEourlRr3EqX03TAUL8lJYZfp/Utr/ XeMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753969923; x=1754574723; h=content-transfer-encoding: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=BY5vPMrJ2PHPFe1sQeNrqoK9PWruaGqzBjAPPkveWv8=; b=fdthVq20Lm09wgttHKbYtMy3yxmKOic48jVSiY19rBpC+WM7Uq51QCFG2Tnrjfwv6B f1ON1mneWYjUNjqw+CgdoaC3JolrAhJyo/HN0k0jTFIsr6MC/iAlX8/3dCPQQjbxCkbC 16we+cpbuZymVO36dlE1znb0xGO2xk8KMsOOibWBw3fEWCtPLReRcLKzmD+ciVUx8/Ho yIHYKJyj1unXn74xAH4PAbVtHIMrXeauXySDqcCMO50V1Qokb8jldXJ9lV5Scm8Owkci y9jPRK2kewcPGQ9W8za4XkHMYjg+XOyV0vaMMWahN61/7S9wHteUajemeCKZ77WHDH6O Eo2g== X-Forwarded-Encrypted: i=1; AJvYcCUnUJ/Gq4NxUkFPL31yoK062ACi7oiRjpzWbozScofqsQqPHChFVDS94gQcZuWqmwp6IBGAcZkvO96BKooV+vq1PIXlei0=@freebsd.org, AJvYcCUupsJxYc51HiRfLBQlkoqVU+TxBrc82xZ2NwtUSaYrCAjvjMm+KvjB9ifFWeqsjYppCgIdJ2wH@freebsd.org, AJvYcCVI+stDnFv3kUyqTFwKRNJKSh6Z2Zlmf0PhxHLq8lnYP695uKNZfD9Cz2YtaEjquTBM7KK3KtO0RbatKKs16nDirKf22g==@freebsd.org, AJvYcCW5Z8RK80mzWDcMMaT3b2Siqs5ZDmRN8kGWdypEiTMVLhAjhPRGm4hU9zJ4b4yEIjMOCSDZN3I4fhJvgZpkq+8=@freebsd.org, AJvYcCWz8kjtVyu1xAyoPjCdon/M/+ubeVO5Gpfd0Y6W5BFXKmj4S8tcEH+/CFQhIU1QmSKISA==@freebsd.org X-Gm-Message-State: AOJu0Yxz5T0NFXYGOR3mdvqp4NFbF1cAATcngTi411Y30XNLQXuxw8MN YmFw+to6oZgNtZn69Hm01K1nzgy+tqgWpcROYCYI0kxhqTnLk3kGk0TnpGae1e1ZbjaP96UcxZn UVAk9dk+mZa/59nmijN9yW61qxoELx4cY X-Gm-Gg: ASbGnctmkkz271n7mENGkTEn68QFrimOYXy1qMJS7QS3a6qe9qEQOHO5ByKguZ4Y8JC yZqzBrG6IOGaYjSBu0Lk0mS89cNvh1A2DCjVs2qrKCjWKr7kcVHQB/z6ctzRK8Hq9J3SM8TJl+h EIuxQtFRJ+UQiFfCuX+DAgVT+edr3eAjpj/7/Dbs9nC29/MXyDzKyqeLUS6I4AIuy89oidWoyIc TKW2o+hpFzjviLvpHr4PqvMKcokcODID/7es65I5U09pT3dqA== X-Google-Smtp-Source: AGHT+IEW/QqhztS5Pwa8ymgddjdxuPMWHY724Qt8zFk+GYUxAeskZlzLiRnVRaIsNi43QVa6nU7dpKWwRl3xaOjdQ7Q= X-Received: by 2002:a05:6402:42d4:b0:615:78c6:7aed with SMTP id 4fb4d7f45d1cf-61587213791mr8020647a12.32.1753969922348; Thu, 31 Jul 2025 06:52:02 -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: Rick Macklem Date: Thu, 31 Jul 2025 06:51:51 -0700 X-Gm-Features: Ac12FXzMIrjxSyr7QGXjdnh16RDUb3WGr04zEdzSvjNi9ROiwM_CYoxncVGb7-k Message-ID: Subject: Re: git: c7da9fb90b0b - main - KRB5: Enable MIT KRB5 by default To: Benjamin Kaduk 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: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; TO_DN_EQ_ADDR_SOME(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; TAGGED_FROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; 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)[]; FREEMAIL_CC(0.00)[gmail.com,cschubert.com,freebsd.org]; MLMMJ_DEST(0.00)[dev-commits-src-all@freebsd.org,dev-commits-src-main@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCPT_COUNT_SEVEN(0.00)[8]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::530:from] X-Rspamd-Queue-Id: 4bt9Vx1pwfz3BmX X-Spamd-Bar: --- On Thu, Jul 31, 2025 at 6:07=E2=80=AFAM Rick Macklem wrote: > > On Wed, Jul 30, 2025 at 9:24=E2=80=AFPM Benjamin Kaduk wrote: > > > > 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()= 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