On Jan 3, 2023, at 11:41 PM, Trond Myklebust [off-list ref] wrote:

On Tue, 2023-01-03 at 19:16 -0800, Rick Macklem wrote:

quoted

On Tue, Jan 3, 2023 at 6:12 PM Trond Myklebust [off-list ref]
wrote:

quoted

On Tue, 2023-01-03 at 17:28 -0800, Rick Macklem wrote:

quoted

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.)

Those aren't really likely to use krb5, though.

My intuition is Rick's usage scenario would be common if we made
it possible. It's similar to how Windows/SMB works on laptops,
and is a common deployment scenario in campus environments.

I've been thinking about how to use a public key infrastructure to
provide stronger authentication of multiple individual users' RPC calls
and multiplexing them across a shared TLS connection.

Since the client trusts the server through the TLS connection
authentication mechanism, and you have privacy guaranteed by that TLS
connection, then  really all you want to do is for each RPC call from
the client to be able to prove that the caller has a specific valid
identity in the PKI chain of trust.

So how about just defining a simple credential (AUTH_X509 ?) containing
a timestamp, and a distinguished name, and have it be signed using the
(trusted) private key of the user? Use the timestamp as the basis for a
TTL for the credential so that the client+server don't have to keep
signing a new cred for each and every RPC call for that user, and allow
the client to reuse the cred for a while as a shared secret, once the
signature has been verified by the server.

A laptop typically has a single user. The flexibility of identity
multiplexing isn't necessary in this particular scenario.

--
Chuck Lever