Received-SPF: pass (google.com: domain of linux-nfs+bounces-2210-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Tue, 5 Mar 2024 08:30:31 -0500
From: Scott Mayhew <smayhew@redhat.com>
To: Olga Kornievskaia <aglo@umich.edu>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [nfs-utils PATCH 0/2] gssd: improve interoperability with NFS
 servers that don't have support for the newest encryption types
Message-ID: <Zeced5frADc9oA0G@aion>
References: <20240228222253.1080880-1-smayhew@redhat.com>
 <CAN-5tyFUXLrRLXiFmiN0X3fOAS4UBR+5Uo1XrN1sApD5K3W3wg@mail.gmail.com>
 <ZeYHMYoVglzPreL1@aion>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <ZeYHMYoVglzPreL1@aion>

Re-adding the list.

On Mon, 04 Mar 2024, Scott Mayhew wrote:

> On Mon, 04 Mar 2024, Olga Kornievskaia wrote:
>=20
> > On Wed, Feb 28, 2024 at 5:23=E2=80=AFPM Scott Mayhew <smayhew@redhat.co=
m> wrote:
> > >
> > > In order for an NFS client with support for the newer encryption types
> > > (AES with SHA2 and Camellia) in its RPCSEC GSS kernel code to connect=
 to
> > > an NFS server without support for those encryption types in its RPCSEC
> > > GSS kernel code, it is sometimes necessary for configuration changes =
on
> > > the NFS server... particularly if the NFS server's userspace krb5 code
> > > does have support for the newer encryption types and/or the NFS serve=
r's
> > > keytab has "nfs" keys using the newer encryption types.
> >=20
> > I'm stuck on "the NFs server's keytab has nfs keys" with newer
> > encryption types. That sounds like a misconfigured server. The
> > administrator shouldn't have issued a keytab knowingly that those
> > encryption types are not supported.
>=20
> I think it's probably pretty common for administrators to omit the -e
> option when they use 'kadmin ktadd' or 'ipa-getkeytab', so they get keys
> for whatever's enabled in their krb5 configuration.
>=20
> But It turns out that part is not even necessary for the problem to occur=
=2E=20
> As long as the krb5 configuration has those encryption types enabled, the
> problem can occur.  See the thread posted by Orion Poplawski on 2/29:
> https://lore.kernel.org/linux-nfs/181e6547-a0ec-4c02-844b-bf1eda464acd@nw=
ra.com/T/#t
>=20
> -Scott
> >=20
> > > Rather than
> > > rehashing the whole discussion here in the cover letter, see the
> > > description in the first patch for the gory details.
> > >
> > > These patches make it easier for a "newer" NFS client to work with an
> > > "older" NFS server.
> > >
> > > The first patch adds support for an "allowed-enctypes" option in
> > > nfs.conf, allowing the the client to restrict the permitted encryption
> > > types to a subset of what is otherwise supported in its krb5 environm=
ent
> > > so that it doesn't use an encryption type that the NFS server doesn't
> > > support when negotiating a GSS context.
> > >
> > > The second patch builds on this by adding an automatic backoff featur=
e,
> > > where if the NFS client fails to negotiate a GSS context with the NFS
> > > server using the newer encryption types, it will try again without us=
ing
> > > the newer encryption types.
> > >
> > > With these patches in place on the NFS client, the "newer" NFS client
> > > will work with an "older" NFS server without requiring any configurat=
ion
> > > changes.
> > >
> > > Scott Mayhew (2):
> > >   gssd: add support for an "allowed-enctypes" option in nfs.conf
> > >   gssd: add a "backoff" feature to limit_krb5_enctypes()
> > >
> > >  nfs.conf               |   1 +
> > >  utils/gssd/gssd.c      |   6 ++
> > >  utils/gssd/gssd.man    |   9 +++
> > >  utils/gssd/gssd_proc.c |  15 ++++-
> > >  utils/gssd/krb5_util.c | 135 ++++++++++++++++++++++++++++++++++++++-=
--
> > >  utils/gssd/krb5_util.h |   3 +-
> > >  6 files changed, 159 insertions(+), 10 deletions(-)
> > >
> > > --
> > > 2.43.0
> > >
> > >
> >=20