Re: [kitten] Question about AES mode in Kerberos

Olga Kornievskaia <aglo@umich.edu> Tue, 17 January 2023 17:06 UTC

Return-Path: <olga.kornievskaia@gmail.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 66083C151711 for <kitten@ietfa.amsl.com>; Tue, 17 Jan 2023 09:06:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.096, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, 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=umich.edu
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 J7Qa4CRLa8qB for <kitten@ietfa.amsl.com>; Tue, 17 Jan 2023 09:06:45 -0800 (PST)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 6D170C1522DB for <kitten@ietf.org>; Tue, 17 Jan 2023 09:06:45 -0800 (PST)
Received: by mail-pl1-x636.google.com with SMTP id y1so34206620plb.2 for <kitten@ietf.org>; Tue, 17 Jan 2023 09:06:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Cb9GOkAa00IZSX9H88BKycDpscs4TvMREIno+4rhV8A=; b=BTHFC6hWJVn3fdQ3uvQAbYS0HfcVA1wkq926mZM9alsXWnMOTDblb85bCHgKFXSC+F NS/8M3XwsV/UtV1Nr3MLGoiZ+9ssyJXAwjw2Nx5c3qDehtfXAdgw19dSJqwKp/e6iWWR nP78jN+wwhG9Bfdi2uW95ParrJzq9VelU1Sny3eQ3/or2JPNkZsNhmG+C5gJjzWy/3fe XKgfLdRXl+li+GPrsT0iMO3QW94B+m1qPpTGFyw5l8vcPfEWsyo17LV/S4uiT0tK4Rvg jY41XSVi42LhVxxl09ZIyqp7F1Gzf421ZvdW+UX4lM4SvHrL8KbPd36AmQkzZ9hoVWoL r2Ag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=Cb9GOkAa00IZSX9H88BKycDpscs4TvMREIno+4rhV8A=; b=EzdMhbyNtPQK9gJCHnofH18sWLIO6iWElqYO1EdF9KCbLKdDSL0dxzz3pdx02vNBmf eZFF+VlS8066fR5Uo7Fhx4HCudwxjOJ0g34U3EtozB/THK7NwxaiWeUDqarRGOVBcloH MkXaCENSqaRrCogZv7qWwQTKePPC1IRpFbqQPDQGcUh0yaa1H/nfFcAUfbWlYYtGJBOv HWxKlD2UJYuQFwl/8yJNv+8RWnuQ2IackytrFA5RpKZ5AwOQWEvYabW6YeNYfKbZslRa vRYU/CCF80kRQc/2+ALAVZEHvcl9+XfqDokeNIT+K3l5rQpWZpUDuzHY6wKWpP/E5qf9 xVQg==
X-Gm-Message-State: AFqh2krm0ZI70LNZnsiVNaKAZBRu97MhjhqAWXqruxHA78sSJclUfdVn fxuoP5QWW3gIWbUQyRICykvPVEoco70BUHNFxMQG+qBg
X-Google-Smtp-Source: AMrXdXuGt+sOyNZ3IyrXsuymE3EEDIi/2XTjGELgVwJfJFha8+73H0ttxBlhI3pZV1+JjEMffFGJIAjGPHRhpR+ggTQ=
X-Received: by 2002:a17:90a:2fce:b0:229:a29:dc2 with SMTP id n14-20020a17090a2fce00b002290a290dc2mr337008pjm.104.1673975204897; Tue, 17 Jan 2023 09:06:44 -0800 (PST)
MIME-Version: 1.0
References: <CAN-5tyGGJXoo9RfKEGTsk8XeQDpZ--VSnO7nunzvnBBzrRB0WQ@mail.gmail.com> <558f31de-7fac-26c7-fe81-8e486968f0ef@secure-endpoints.com> <7B46A5A4-4415-4627-B964-44F2516D84FE@padl.com> <9464B1FF-6784-4D59-A4F6-1B5D58C2B94F@padl.com> <CAN-5tyE4eau116TkDLbvn+pTOjK_C+WEvi9SnUELr+4riTpZcw@mail.gmail.com> <cb3ff38f-7e62-0711-9a6c-50a96b571e2d@mit.edu> <CAN-5tyFA41VMz_3tBmh+FeefBBJOxfi1AoUCqUkRHR3z43qrKg@mail.gmail.com> <9bf334b8-cdde-b5a2-608f-6dbb4a353aa2@mit.edu> <Y8GnikmipD1G68HJ@gmail.com>
In-Reply-To: <Y8GnikmipD1G68HJ@gmail.com>
From: Olga Kornievskaia <aglo@umich.edu>
Date: Tue, 17 Jan 2023 12:06:33 -0500
Message-ID: <CAN-5tyEPnu2hqrFuCiwRnYHsoDmUc6dgQPirmSYNQstk98E_yw@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Cc: Greg Hudson <ghudson@mit.edu>, Luke Howard Bentata <lukeh=40padl.com@dmarc.ietf.org>, "kitten@ietf.org" <kitten@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/Q4mx0zWN_1A2xIjT_8_nJqAlk8Y>
Subject: Re: [kitten] Question about AES mode in 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: Tue, 17 Jan 2023 17:06:49 -0000

On Fri, Jan 13, 2023 at 1:48 PM Nico Williams <nico@cryptonector.com> wrote:
>
> On Mon, Jan 09, 2023 at 05:55:24PM -0500, Greg Hudson wrote:
> > On 1/9/23 15:25, Olga Kornievskaia wrote:
> > > May I ask a stupid question? Is there something inherently different
> > > about nonce handling/producing in Kerberos that's different from TLS?
> >
> > The symmetric encryption facilities in TLS are in service only to the
> > channel protocol.  TLS is regularly used to carry large amounts of data in a
> > variety of application protocols.
> >
> > The symmetric encryption facilities in Kerberos are in service primarily to
> > the stateless authentication protocol, which uses long-term keys. Kerberos
> > channel protocols exist (KRB-PRIV and GSS), using the same encryption
> > facilities, but they are used less widely than the authentication protocol
> > and much less widely than TLS.
>
> That GSS is less widely used than TLS for bulk is not a reason not to
> make GSS performant for bulk.
>
> Unless we want to deprecate GSS-API.  Which we well could.  As the world
> moves to JWT-like authentication systems (i.e., single-token, half round
> trip systems with no key exchange) GSS becomes quainter and quainter as
> anything other than an API for TLS in the same way that SSPI
> -Microsoft's GSS equivalent- is an API for TLS in SChannel.
>
> As far as _Internet_ protocols go, the only ones that use GSS for bulk
> are FTP and NFS, with FTP being practically obsolete and NFS moving to
> TLS.  But there are proprietary protocols that use GSS too.

While NFS "moves to TLS" that's only for auth_sys mode. Anybody that
cares about security, uses ACLs for authorization, will require
Kerberos authentication. One of the reasons NFS is moving towards TLS
is the hope of better performance (it seems that NIC's have incentives
to implement onboard TLS or IPSec protocols but not Kerberos GSS).
Another reason unfortunately is because too many folks just want
auth_sys but over a secure channel.

Given that GSS-Kerberos is written into the NFS's IETF spec, I'm not
sure how IETF can consider deprecating it without having NFS define an
alternative first (which I don't see happening). As far as I know NFS
is not even remotely in the same "usage" category as FTP (as in how
much money is spent on NFS-based products and FTP-based ones).

Wouldn't it be wonderful that instead of needing to layer a GSS
authentication on top of TLS (as GSS in itself can provide
authentication and privacy) we could make GSS be a competitor to TLS
by having the same ciphers and having same NIC hardware offload
support (but I realize that the latter is not something a spec can
fix)...

> Nico
> --