From nobody Thu Jul 31 13:07:44 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 4bt8X45gRkz63qZP; Thu, 31 Jul 2025 13:08:04 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 4bt8X43j3Bz4KrT; Thu, 31 Jul 2025 13:08:04 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-615398dc162so1414571a12.3; Thu, 31 Jul 2025 06:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753967278; x=1754572078; 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=meRbfJ2cqUQBqVuicYtW3DoZwyaFCB1zISZzsgXGbsY=; b=hkz7ypjxuPwDxWYcY26v4bPAElkGzgB6p9H+eOmcHfWgvuG0kfPar6YgNAJYm20ZM/ X+N4F+WQmccdy8NcPhvM7ZgJQ2PnmJRkcO7JjGvj8tVbG3HfMqOoROgOHXrE7oLeC4KE gNewkamlZumXliue7X1PM+7HkgZ7+HIVZqL4rimWQGblQmQS6fBcCZ10IuAshEY62irg 5gaieZ4DntBsbccdJP6P8I+5EMRNtNYCK++FCspipezjmTHjyc9S9VBWehB03oVOW3jo g54JAERMkyp0GG5x1WE75RLpyo0oZ5FyEjEq2LMliS0yjyACagITzRX7SLNwWxZbqBLP 9Ecw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753967278; x=1754572078; 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=meRbfJ2cqUQBqVuicYtW3DoZwyaFCB1zISZzsgXGbsY=; b=g4TO+cXo0LW/DkA9uK7Sqrfm5rbazDiuBt0eNL2RjpTRJiUsEiYsiTvtBc3wMgdZk/ +yc+00jngmzrtPPX57En7yEc0U2lbzrJdd2FZrJ/Ra6aurH1gf5lay6TYjyPtZdrnXnz Z5KKWAoZV269rMfjgZzw3bKxlHOI+i/2zyIi1JKbsLoiKz0mAjFJsZ87uYkGrNuxKVSi Dp+JFMhZSttUsrFnfi3V8VqMG4rjmxzteRC7Bmse6vfMTJSg8doQ35avHeVYU0KsBl+m xilaaZ4Jek4FU5/MFUEBejDpnw/yDuiz7Wtm+aJ9b+sppnHyTVazGSLckbvsFS4Lx2Ix OPpQ== X-Forwarded-Encrypted: i=1; AJvYcCUmvIifbTdCsbVf/TeuQbEid3VGaecWB5q/R0DevPMsawfOXCZ4BmpPXhtX3TZ2VpeoKL4BxypW@freebsd.org, AJvYcCV5Bb85vxywQKI5UEXGJNBOXCU8FuD/9VvqKRVsJTovmk9ESutD1OnH2EyBd5QZ3lfDDimPm5Nt549nei+UcovIckQlyw==@freebsd.org, AJvYcCVXDAj8/bh0EsVPeJfLkdHDsGhTJemjMqYHmsoTgAey5Fm/L8CdOANK6tzln6jfQq5LaIg5eOrENKD8kSQpm+LzAJqyB8I=@freebsd.org, AJvYcCXRptddwdCpxeM5Zq9WaIiC3PMDrkHuk2HGjwqMBe/fAy2vjHWAo6lpkR6jo44MrTi/sA==@freebsd.org, AJvYcCXWfAx3cIQ4Zh9cGYwxvWS5AJNONur16WUJXPjTiHsmZxOyn+Zb2RdaiV8pLoIEPEL9xr9M4y9oI4GpLCXmwdI=@freebsd.org X-Gm-Message-State: AOJu0YzCKrn/hJa0TkXsjcxGfi6mE0/Pdp7G1ZrAwk7Oggs7rcah9jWf iI+vKytlulT/cE6ht78KbLw3pmTf1qTr+tfd30ldRldO9RaH7OMBzrOa9L+xe2P1MUXSFAotuZB Cnw1mVLlFz/iFkmcR0RgMlGw1381Okw== X-Gm-Gg: ASbGnct+TMRWvkp8Res6Azobc1//9FHrbkVVo+fPXfEOY/Iy4Yaf2ckjfSTQ0XS5+eA 0fp5MdGM9cxQrjhT3Tv4zbbCPT9MO4bllbGNr4QyFmgGDT6zz3XIp1Icv0K2VsteZO/Y9LJNOyJ F8QyrCYPOk59NyIeVMLCL5gnvkYtCWI5A0bP9ikupj5ZJ4Q4Q4dgz+HKehRFQacYfUjdRCYK50T Mi8A+mV7CKLcf+btEc/OmSZT5pJa3tBHM257eB3u+ttpaHzUQ== X-Google-Smtp-Source: AGHT+IGNf9fI7r4dDsddADpDQAheoO7yHsUVi1n/E50A+CuKQBb2dRSDo2jtIQQ/hz+LtC3RrPl4SjAxuXaxHcgymVc= X-Received: by 2002:a05:6402:35d2:b0:615:756b:1b1d with SMTP id 4fb4d7f45d1cf-615871fa650mr7065553a12.30.1753967277406; Thu, 31 Jul 2025 06:07:57 -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:07:44 -0700 X-Gm-Features: Ac12FXyB_CWjg932hwFWBMz0U-ziOcHK0S0QQQOauMLnCi4NtpT-x3v-_Ednncs 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-Rspamd-Queue-Id: 4bt8X43j3Bz4KrT X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] 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() A= PI 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 con= text" (i.e., do crypto negotiation, authentication, sometimes authorization= , etc.) between two entities, the initiator and the acceprot, and then exch= anging protected messages between the two (which can be either encrypted or= just integrity protection tags for otherweise cleartext data); later exten= sions included the ability to produce identical PRF output on both parties,= etc.. The details are "mechanism-specific", and for this purpose we're ex= clusively talking about the krb5 mechanism. The steps to establish the sec= urity context are complicated and sometimes fiddly, and in the general case= can require a large number of round-trips between the initiator and accept= or before the security context is established. The individual message-prot= ection parts are comparatively simple and amendable to implementation in th= e kernel for processing efficiency. >> > 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. We are abusing that mechanism to export information = about the security context that gssd has established and feed that informat= ion into the kernel implementation of the per-message processing routines. = At present, this necessarily entails knowing the details of the implementa= tion-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 postur= e overall and somewhat future-proofed against future 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_external_luc= id_ctx_v1() >> function. This function only knows about the 0 and 1 setting for gctx->p= roto. >> >> Any ideas, rick >> > > > I'm not seeing anything to suggest that a "gctx->proto" value of 4 is eve= r expected; it looks like it's supposed to just be 0 (for the legacy RFC 19= 64 format) or 1 (for the "CFX" format of RFC 4121, with wider sequence numb= ers for message-protection formats, etc.). So maybe it's worth posting you= r 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 from = the string + a 1 byte), it returns major =3D=3D GSS_S_COMPLETE, but no data and a weird 39756046(decimal) or 0x25ea10e(hex) minor. (Oh, and I tried gss_krb5_export_lucid_sec_context() and got the same weird error.) 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 buil= t? 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 i= s 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 waiti= ng 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 th= ey did was define an OID for it.) > > It looks like a front-end to the same core implementation at least (techn= ically not a wrapper for the public API, though). > (There are a bunch of non-krb5 mechanisms, most not in terribly widesprea= d use.) > > > Btw, do you have any experience porting KDC databases from Heimdal to M= IT? (At this point, Cy has done it, but after doing so, the passwords all h= ad to be reset. He thought he had used "--decrypt" when he dumped the Heimd= al 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) di= fferent techniques for encrypting the per-principal data in the dump file, = so a trip through plaintext helps. I do remember reading about Heimdal hav= ing grown some support for the MIT database format; the commit message at h= ttps://github.com/heimdal/heimdal/commit/57f1545a46fdad9207a71903a56f3c1d1f= ff3a10 is perhaps a very high-level description of what is expected to be p= ossible. > > -Ben