Date: Mon, 13 Mar 2023 19:25:07 -0700 From: Rick Macklem <rick.macklem@gmail.com> To: FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: RFC: A new NFS mount option to encourage use of Kerberized mounts Message-ID: <CAM5tNy6xKn2BNdz3yBWDn%2Bm4EpJrbdfwxTAThjLvfFCsSC018A@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM5tNy6xKn2BNdz3yBWDn%2Bm4EpJrbdfwxTAThjLvfFCsSC018A>