Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAM5tNy6nfvuqM30DwUVjTFHfewL8tSEQcyEJsSBzyWMTvDkEQw@mail.gmail.com>
 <e9fea39e926486146505c385dca50c116deb22f9.camel@kernel.org>
In-Reply-To: <e9fea39e926486146505c385dca50c116deb22f9.camel@kernel.org>
From:   Rick Macklem <rick.macklem@gmail.com>
Date:   Tue, 3 Jan 2023 19:16:02 -0800
Message-ID: <CAM5tNy7GM-5m-O2GUBwXCY=psSN2LKiE4bPPFyK=ABhObMdFCg@mail.gmail.com>
Subject: Re: RFC:Doing a NFSv4.1/4.2 Kerberized mount without a machine credential
To:     Trond Myklebust <trondmy@kernel.org>
Cc:     linux-nfs@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Jan 3, 2023 at 6:12 PM Trond Myklebust <trondmy@kernel.org> wrote:
>
> On Tue, 2023-01-03 at 17:28 -0800, Rick Macklem wrote:
> > I have recently implemented a NFSv4.1/4.2 client mount
> > on FreeBSD that uses AUTH_SYS for ExchangeID, CreateSession
> > (and the other state maintenance operations)
> > using SP4_NONE and then it defers an RPC that does:
> >    PutRootFH { Lookup, Lookup,... Lookup } GetFH
> > until a user process/thread attempts to use the mount.
> > Once an attempt succeeds, the file handle for the mount
> > point is filled in and the mount works normally.
> > This works for both a FreeBSD NFSv4 server and a Linux
> > 5.15 one.
> >
> > Why do this?
> >
> > It allows a sec=krb5 mount to work without any
> > machine credential on the client. (Both installing
> > a keytab entry for a host/nfs-client.domain in the
> > client or doing the mount based on a user principal's
> > TGT are bothersome.) The first user with a valid TGT
> > that attempts to access the mount completes the mount's
> > setup.
> >
> > I envision that this will be used along with RPC-with-TLS
> > (which can provide both on-the-wire encryption and
> > peer authentication).  The seems to be a reasonable
> > alternative to a machine credential and a requirement
> > for RPCSEC_GSS integrity or privacy.
> >
> > Why am I posting here?
> >
> > I am wondering if the Linux client implementors are
> > interested in doing the same thing?
> >
> > I think it is possible to extend NFSv4.2 with a new
> > enum state_protect_how4 value (SP4_PEER_AUTH?) that
> > would allow the client to specify what operations must
> > use RPC-with-TLS including peer authentication and which
> > must be allowed for this case (similar to SP4_MECH_CRED).
> > However, if the server forces the client to use RPC-with-TLS
> > plus peer authentication, that may be sufficient and does
> > not require any protocol extensions.
> >
> > Comments?
> >
>
> Are there really that many use cases for this? If you are using krb5
> authentication, then you pretty much have to support identity mapping.
> Unless you are talking about a hobby setup, then that usually means
> backing your Kerberos server with either LDAP or Active Directory to
> serve up account mappings, and it usually means protecting those
> databases with some form of strong authentication as well.
>
> IOW: for most setups, I would expect the machine credential requirement
> to be a non-negotiable part of the total AD/Krb5+LDAP security package
> that is implemented in userspace. Am I wrong?
>
For systems in machine rooms, you are probably correct, although I
think many of these environments would just use AUTH_SYS, since they
trust the clients.

What about mounts from mobile devices that do not have a fixed
client IP host address?
(I suspect that, currently, they seldom if ever use NFS, but I think
 trying to support them could be useful.  A mobile client can use
 a X.509 certificate to do a reasonable job of verifying its identity
 if signed by a site local CA, although it cannot have a "wired-down"
 DNS name in the certificate.)

rick

> --
> Trond Myklebust
> Linux NFS client maintainer, Hammerspace
> trond.myklebust@hammerspace.com
>
>