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
From:   Rick Macklem <rick.macklem@gmail.com>
Date:   Tue, 3 Jan 2023 17:28:01 -0800
Message-ID: <CAM5tNy6nfvuqM30DwUVjTFHfewL8tSEQcyEJsSBzyWMTvDkEQw@mail.gmail.com>
Subject: RFC:Doing a NFSv4.1/4.2 Kerberized mount without a machine credential
To:     linux-nfs@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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?

rick