RFC: A new NFS mount option to encourage use of Kerberized mounts

Hi,

I have implemented a new mount option for NFSv4.1/4.2 mounts
that I hope will encourage use of Kerberos and TLS to help
secure NFS mounts.  Although I do not know why users choose
to not use Kerberized NFS mounts, I think that the administrative
issues related to the "machine credential" is a factor.
This new option, which I have called "syskrb5" (feel free to
suggest a better name), avoids the need for a Kerberos machine
credential.

I discussed doing this type of mount on the IETF and Linux
nfs mailing lists and there seemed to be support for the
concept.

Without this patch, a Kerberized NFSv4.1/4.2 mount must provide
a Kerberos credential for the client at mount time.  This credential
is typically referred to as a "machine credential".  It can be
created one of two ways:
- The user (usually root) has a valid TGT at the time the mount
  is done and this becomes the machine credential.
  There are two problems with this.
  1 - The user doing the mount must have a valid TGT for a user
      principal at mount time.  As such, the mount cannot be put
      in fstab(5) or similar.
  2 - When the TGT expires, the mount breaks.
- The client machine has a service principal in its default keytab
  file and this service principal (typically called a host-based
  initiator credential) is used as the machine credential.
  There are problems with this approach as well:
  1 - There is a certain amount of administrative overhead creating
      the service principal for the NFS client, creating a keytab
      entry for this principal and then copying the keytab entry
      into the client's default keytab file via some secure means.
  2 - The NFS client must have a fixed, well known, DNS name, since
      that FQDN is in the service principal name as the instance.

This patch uses a feature of NFSv4.1/4.2 called SP4_NONE, which
allows the state maintenance operations to be performed by any
authentication mechanism, to do these operations via AUTH_SYS
instead of RPCSEC_GSS (Kerberos).  As such, neither of the above
mechanisms is needed.

This new NFSv4.1/4.2 mount option, called "syskrb5" must be used
with "sec=krb5[ip]" to avoid the need for either of the above
Kerberos setups to be done by the client.

Note that all file access/modification operations still require
users on the NFS client to have a valid TGT recognized by the
NFSv4.1/4.2 server.  As such, this option allows, at most, a
malicious client to do some sort of DOS attack.

Although not required, use of "tls" with this new option is
encouraged, since it provides on-the-wire encryption plus,
optionally, client identity verification via a X.509
certificate provided to the server during TLS handshake.
Alternately, "sec=krb5p" does provide on-the-wire
encryption of file data.

So, does this sound like something that should be committed
to FreeBSD?

Thanks for any comments, rick