On Tue, Jan 3, 2023 at 6:12 PM Trond Myklebust <trondmy@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
>
>
