Re: [kitten] Replacing Kerberos

Nico Williams <nico@cryptonector.com> Thu, 23 February 2023 20:32 UTC

Return-Path: <nico@cryptonector.com>
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 5912EC14F740 for <kitten@ietfa.amsl.com>; Thu, 23 Feb 2023 12:32:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.75
X-Spam-Level:
X-Spam-Status: No, score=-0.75 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, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cryptonector.com
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 dQkHnOwk0wvb for <kitten@ietfa.amsl.com>; Thu, 23 Feb 2023 12:32:54 -0800 (PST)
Received: from dog.elm.relay.mailchannels.net (dog.elm.relay.mailchannels.net [23.83.212.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8EB3C152574 for <kitten@ietf.org>; Thu, 23 Feb 2023 12:32:45 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id CEDCF92164C; Thu, 23 Feb 2023 20:32:44 +0000 (UTC)
Received: from pdx1-sub0-mail-a302.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 6341C920FA7; Thu, 23 Feb 2023 20:32:44 +0000 (UTC)
ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1677184364; a=rsa-sha256; cv=none; b=eMev5cVypskdbKf066OFCi9ZxbhpHCZARLWVfW4aXoMx4SYnb+LZnHJayJpl3Z1sO09J66 jqo4E9Y/ael3Fa4uiTYi1xlU7rf9AUWnVSAX0SGsRD8ZWNK0gIeEwsy/dJeV536fAtNpmO 5ZSjeSnFcBWtyp0nVmOfEner5hQXYi5LHw/am9X+5dlf9R0qcPU/RLzZnK484OZWbH1t+M AbLmGazXhPF18Hk13i2lelkBZHMYSaA3bX1/ZwEtszMk+Zd5+rjuD/XoVkrp7T2zSjrUMJ uoaBrEjkKglNJ5EFWqZQtbv4jigC1LrBcEWEqu2oM0NtTvn9kwpl3PhD2YUo+A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1677184364; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ZqcdXTtVfUyO3KiBujTlgZLyVNwRKmZFvG3ov1R0t04=; b=FkPooOoOiEq6X/R3WRMwfTds9gd2dgRBPdwRR7gbJ1O+dkcNRO0ZCsi5PjxJixIlGLJ2es I9kpOmcKuteUbt5WqS1asco25HbEYYYFKy3Hu7BNi4wV2Iqn6oT4l/nzXGa9UbJ6OvwhyJ H5U0eBjFiAYxJwteUl0YAfBgoII0a3kyRc96F09tfk7RTPe6f0+JwueGR56S8vhewWK4xl gCcAhWUTQWuGEZhRS8+l+Q+mISH53C/shDd1+EfPPm2CMH/ftmOLpDCzPlalw1DZxeC2Xe LBvEL/lHPIdi+Plgi6AV1nX713Cazs9y4dstNHTM6AVX2qx+tAaWGagBJTUT4Q==
ARC-Authentication-Results: i=1; rspamd-9788b98bc-chzs8; auth=pass smtp.auth=dreamhost smtp.mailfrom=nico@cryptonector.com
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Bottle-Wiry: 24dbbe0f7b43716f_1677184364672_3400244267
X-MC-Loop-Signature: 1677184364671:2091468378
X-MC-Ingress-Time: 1677184364671
Received: from pdx1-sub0-mail-a302.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.99.229.15 (trex/6.7.1); Thu, 23 Feb 2023 20:32:44 +0000
Received: from gmail.com (075-081-095-064.res.spectrum.com [75.81.95.64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a302.dreamhost.com (Postfix) with ESMTPSA id 4PN4TR59zgz1F; Thu, 23 Feb 2023 12:32:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cryptonector.com; s=dreamhost; t=1677184364; bh=ZqcdXTtVfUyO3KiBujTlgZLyVNwRKmZFvG3ov1R0t04=; h=Date:From:To:Cc:Subject:Content-Type:Content-Transfer-Encoding; b=oQUd/wB8S2Akv2J5VoilXAwHJRLs/rnLsjPOOWS8CC4URInSd4O6x+QzuqlISoPVE qyertFPpYSIN2+KFdq4XXVph1sTcv5Ir4aTyk/YAarpXPEgyJFoL2fhmc1lMhHkC0g y8hs36mg2d5oqK5dhYhYKWje6M3VzluAZt82WqIurS1e4/GO0wOI9eSaDSwyINC3xY pRj7F6q27upV7XTLgcB/gY3Bzhs0Ppz098bJ3Lsxbw6/+uWKA1im923rUHYO/XlZ92 UN69dIDcTzrbvbRaOTRWBNSZSYbBqmKx0GphOP0aCx0vvIrjEAxV0kLwF3GA95YJ8E n3fpVbCflLAtA==
Date: Thu, 23 Feb 2023 14:32:40 -0600
From: Nico Williams <nico@cryptonector.com>
To: Erin Shepherd <erin.shepherd@e43.eu>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Message-ID: <Y/fNaFUq3YMjhahD@gmail.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <134D46FA-1E2A-4DB0-9B8D-6897136972CA@e43.eu>
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/xq_arHpH6S6-a17wntRT3eBkd9U>
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: Thu, 23 Feb 2023 20:32:58 -0000

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).

> 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!)

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).

> (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.

Nico
--