Re: [kitten] Replacing Kerberos
Erin Shepherd <erin.shepherd@e43.eu> Mon, 27 February 2023 00:29 UTC
Return-Path: <erin.shepherd@e43.eu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5824C14CE4F for <kitten@ietfa.amsl.com>; Sun, 26 Feb 2023 16:29:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.797
X-Spam-Level:
X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=e43.eu header.b="WnMXr8mq"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="TEPbFDVK"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJcF5SG3wFgq for <kitten@ietfa.amsl.com>; Sun, 26 Feb 2023 16:29:20 -0800 (PST)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CC48C14CF13 for <kitten@ietf.org>; Sun, 26 Feb 2023 16:29:20 -0800 (PST)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 2E8CD32001C6; Sun, 26 Feb 2023 19:29:17 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sun, 26 Feb 2023 19:29:17 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=e43.eu; h=cc:cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1677457756; x=1677544156; bh=d67WuREgPL 9SHQuy51eY+5WXp1KigawSKOF7Y/n5Zfw=; b=WnMXr8mqn1N9JU8SFTNXwHsxSE nVX+SwWJbwQkQNoYRTzgj6Vm7UHvtCYKgzS3YOvj2py0Z5DsW/SOa/nIZdoEDBVf qk5SW4bto9IBgf7xYeyxa2oxuZV5haBS93aCKbypJTvdDBZoFT7lh3ocvagHY1Gr ca+wccXv28CmZqvcMjtAEyq2RU9sfvTlqv5frq0TqHM8eUv/EeewjoO/tdcWUOwI jcZhJjlzGNDl8zeXB8cqcET9WeCn4RUGWqOZcOU0hO6QFYUPsZ658XSj1y3yukZT kw1fjNcXVHDrN1jeI9KZR78ELwLjqYCd19j5d2Y48BM4IMH8WJ1cYCpbnohA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1677457756; x=1677544156; bh=d67WuREgPL9SHQuy51eY+5WXp1Ki gawSKOF7Y/n5Zfw=; b=TEPbFDVK+r6bAVb+1AhsO/yw2/jTvidSmHLaDeS75Uvd qjuoa1Nmn9kAPGlLBGG4BJIsmi4eS+zqPqc1fJWfBH9thLW/oVVsyMu7RJ0h409w HXkHR5sCcUVlcQE9Nt83+XoA848DB7gsx8c9oxXMyPzLyZVnByOBm8fEBOSeIchl guw+liN2+Kn4jP4KFuD2oLcUN4czb0ykbj01YTWystIMcAYu5CZSkefpsHmNlQd5 c8CWwsumpbDeZtO79JttyVwxVmBcwe8CZeUfpazE8Hlp4DEPMPXGzHv806rIb+HN qU7eOG19NjWBmEWMXv/i5u3j2mOpmz6YWv6HPlhugg==
X-ME-Sender: <xms:XPn7YwY3YXpvkjfVDWQ1A1SZg_8FKXMEUP-BGwt68hu25tt3QlKT9Q> <xme:XPn7Y7btUagoZgJya567RCQP_0WDCH_gM8cacGmZbN4BL6YLax8NiPVcHdQgTRplr cUAJxIOq3sI0zQTzRI>
X-ME-Received: <xmr:XPn7Y68SnDUn3X8KUp-P9R9QCIlH6AO3XPWP2KGntejDNSl6uI0f0nGwgbDPBpGnaZlLc53NU0uc1ePtUUJ6>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudekledgvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffktgggufffjgevvfhfofesrgdtmherhhdtjeenucfhrhhomhepgfhrihhn ucfuhhgvphhhvghrugcuoegvrhhinhdrshhhvghphhgvrhgusegvgeefrdgvuheqnecugg ftrfgrthhtvghrnhepffelteelfedvfffhudduteduvdethfeiveeuffffgeelledvfeej ueffueelheefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepvghrihhnrdhshhgvphhhvghrugesvgegfedrvghu
X-ME-Proxy: <xmx:XPn7Y6qadExXj4rmia47ivZo-f7tRMusIkCvGZ7wWb73Bq4MT0svAQ> <xmx:XPn7Y7palo0u0SqZLGeqQUIv1IBg9WgpnzMGU19LPiVE6sgPbnLC8w> <xmx:XPn7Y4RZ5s7y0lNtX0yX3XQhTvp9YkLsik2qKQL1mzBg-CDx8brwJw> <xmx:XPn7Y6Q2UWW8W_AwFoMybJ6LYEsRa0DeMOZi8qPqB-Wh03YuJ27NfA>
Feedback-ID: i313944f9:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 26 Feb 2023 19:29:15 -0500 (EST)
From: Erin Shepherd <erin.shepherd@e43.eu>
Message-Id: <3254E2DC-A6A8-4071-B3EB-BBD73056547C@e43.eu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_22CFDF10-8C59-412D-9401-A01FDDA15D5B"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Date: Mon, 27 Feb 2023 01:29:13 +0100
In-Reply-To: <Y/fNaFUq3YMjhahD@gmail.com>
Cc: "kitten@ietf.org" <kitten@ietf.org>
To: Nico Williams <nico@cryptonector.com>
References: <MW4PR21MB1970A9D254B943A1763C55FF9CA09@MW4PR21MB1970.namprd21.prod.outlook.com> <de4cbe7b-85b5-7001-3a8c-74787990c6e0@secure-endpoints.com> <eb9fa7a4-a00d-f388-27aa-3624df8ce4f2@secure-endpoints.com> <MW4PR21MB197060FB388E7922FAADEB079CA19@MW4PR21MB1970.namprd21.prod.outlook.com> <Y/GFY3wTO+TBg638@gmail.com> <134D46FA-1E2A-4DB0-9B8D-6897136972CA@e43.eu> <Y/fNaFUq3YMjhahD@gmail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/T2uJHo50ao6HEWbzbzxOoPdlxl0>
Subject: Re: [kitten] Replacing Kerberos
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Feb 2023 00:29:24 -0000
> On 23 Feb 2023, at 21:32, Nico Williams <nico@cryptonector.com> wrote: > > On Thu, Feb 23, 2023 at 09:20:49PM +0100, Erin Shepherd wrote: >>> - the ability to use this mechanism as a TLS 1.3 PSK > > What I meant above by "the ability to use this mechanism as a TLS 1.3 > PSK" is that TLS applications should be able to use Kerberos / Kerberos > replacement in TLS a la RFC 2712 (which is essentially obsolete and > broken). So effectively a standardised way of using it as a TLS keying material importer? Makes a lot of sense. >> How do people feel about the security layer just being raw TLS 1.3 >> bootstrapped using PSK, or as close to that as possible? (Not quite >> sure what to do with the GSS MIC functions here, though. Maybe just >> draw a MAC key from a TLS exporter?) > > That's not a complete replacement for the GSS functionality in RFC 4121 > because TLS is an ordered octet stream protocol (well, ordered record), > but GSS is not. DTLS 1.3 w/ PSK would be more appropriate but that > still would only get us wrap tokens and not MIC tokens. > > I.e., there's an impedance mismatch between GSS and TLS semantics. > > We could do this with DTLS and then add a MIC token to that. But the > RFC 4121 tokens and the update that Luke is working on to support OCB is > really fairly simple. (The only complex thing in RFC 4121 is the > rotation count RRC, which is a legacy SSPI API design / use bug > workaround that... MSFT would still want to have if we did a DTLS thing, > so the one bit of complexity might not go away!) Of course. (I do wonder how many GSS-API applications actually handle reordered messages though…) > Somewhat related: Windows' SChannel is an SSPI binding of TLS, and we > ought to standardize a corresponding GSS binding of TLS. > >> I say this in part because re-using Kerberos encryption types as other >> mechs have done makes implementing a new mech outside of Kerberos a >> gigantic pain in the arse. If we use TLS 1.3 PSKs, you can just use a >> TLS stack, which you probably already have. > > I hear you. A GSS per-msg tokens only library using OCB only should be > very light-weight. A TLS/DTLS thing would impose a great deal more in > the way of dependencies on Heimdal and MIT Kerberos (for example), and > still needs a bit more (see above), so it's not terribly appealing (but > if I end up on the rough side of consensus on that it's not the end of > the world). I think this is a bit of a symptom here of the existing GSS-API implementations being an outgrowth of Kerberos implementations. Despite the defacto standardisation on Kerberos derived message tokens, they’re not really exposed as a reusable API One thing I would really like, as an aside, is a proxy mech which allows delegating all the context establishment business to an external process but just returns the master keys to the caller. This is an implementation matter though >> (Maybe we could define this framework style, provide a knob which can >> be used to turn this on for supporting existing mechs, and update >> those existing mechs to support it, and then just make it the only >> option for the new mech) > > Certainly we should do that for GSS. We should have a single set of > per-msg tokens that all GSS mechs can use. > >> One other thing I’d like to suggest, since we were just talking about it: >> >> - Builtin-in ability to proxy credential acquisition through the >> acceptor, IAKerb-style, where the “KDC” authentication is itself just >> recursively tunnelled GSS-API (so we can do SCRAM or something) > > So, generalize IAKERB to not-just-Kerberos. I like that. > >> Probably should be optional on both ends, but I think building this in >> will avoid a bunch of the complications seen with IAKerb. >> >> I suspect we’d end up with multiple ways of getting our TGT equivalent >> for this system, but maybe that’s not the worst thing in the world (in >> fact it’s probably just pragmatic) > > More negotiation headaches, but of the kind that we've discussed good > fixes for in this thread already, so I think it's OK. I was thinking just specifically for our hypothetical “Kerberos replacement” mechanism: Authentication to our KDC should just be able to reuse the “direct” GSS-API mechanisms (SCRAM, etc) We should have a proxy-to-“kdc"-via-server mechanism Out Of The Box A bit of me wonders if things should just always be proxied via the server to the server’s “KDC", EAP/RADIUS style; it certainly reduces the complexity in terms of configuring endpoints with cross-realm trust information.
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Greg Hudson
- [kitten] Windows Intent to revive and implement I… Steve Syfuhs (AP)
- Re: [kitten] Windows Intent to revive and impleme… Luke Howard Bentata
- Re: [kitten] Windows Intent to revive and impleme… Greg Hudson
- Re: [kitten] Windows Intent to revive and impleme… josh.howlett
- Re: [kitten] Windows Intent to revive and impleme… Luke Howard Bentata
- Re: [kitten] Windows Intent to revive and impleme… Jeffrey Altman
- Re: [kitten] Windows Intent to revive and impleme… Jeffrey Altman
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Steve Syfuhs (AP)
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Nico Williams
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Nico Williams
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Steve Syfuhs (AP)
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Luke Howard
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Nico Williams
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Luke Howard Bentata
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Steve Syfuhs (AP)
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Luke Howard Bentata
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Luke Howard Bentata
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Steve Syfuhs (AP)
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Nico Williams
- [kitten] Replacing Kerberos (Re: Windows Intent t… Nico Williams
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Simo Sorce
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Simo Sorce
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Ken Hornstein
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Nico Williams
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Paul Romero
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Nico Williams
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Nico Williams
- Re: [kitten] Replacing Kerberos (Re: Windows Inte… Luke Howard
- Re: [kitten] Replacing Kerberos (Re: Windows Inte… Nico Williams
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Steve Syfuhs (AP)
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Nico Williams
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Nico Williams
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Luke Howard Bentata
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Nico Williams
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Luke Howard
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Nico Williams
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Steve Syfuhs (AP)
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Steve Syfuhs (AP)
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Nico Williams
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Steve Syfuhs (AP)
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Nico Williams
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Andrew Bartlett
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Simo Sorce
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Nico Williams
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Steve Syfuhs (AP)
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Nico Williams
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Nico Williams
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Steve Syfuhs (AP)
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Nico Williams
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Steve Syfuhs (AP)
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Nico Williams
- Re: [kitten] [EXTERNAL] Re: Windows Intent to rev… Nico Williams
- [kitten] Updates to IAKERB (Re: Windows Intent to… Nico Williams
- Re: [kitten] Updates to IAKERB (Re: Windows Inten… Nico Williams
- Re: [kitten] Replacing Kerberos Erin Shepherd
- Re: [kitten] Replacing Kerberos Nico Williams
- Re: [kitten] Replacing Kerberos D.Rogers
- Re: [kitten] Replacing Kerberos Nico Williams
- Re: [kitten] Replacing Kerberos Nico Williams
- Re: [kitten] Replacing Kerberos Erin Shepherd
- Re: [kitten] Replacing Kerberos Watson Ladd
- Re: [kitten] Replacing Kerberos Nico Williams
- Re: [kitten] Replacing Kerberos Simo Sorce