Re: [nfs-utils PATCH 0/2] gssd: improve interoperability with NFS servers that don't have support for the newest encryption types

[Scott Mayhew <smayhew@redhat.com>]

Re-adding the list.

On Mon, 04 Mar 2024, Scott Mayhew wrote:

> On Mon, 04 Mar 2024, Olga Kornievskaia wrote:
> 
> > On Wed, Feb 28, 2024 at 5:23 PM Scott Mayhew <smayhew@redhat.com> 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 server's
> > > keytab has "nfs" keys using the newer encryption types.
> > 
> > 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.
> 
> 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.
> 
> But It turns out that part is not even necessary for the problem to occur. 
> 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@nwra.com/T/#t
> 
> -Scott
> > 
> > > 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 environment
> > > 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 feature,
> > > 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 using
> > > 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 configuration
> > > 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
> > >
> > >
> >