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