What I see as good options today for encrypted NFS

May 22, 2023

A comment on my entry on NFS with Kerberos versus normal NFS mentioned that one advantage of NFS with Kerberos is that it can encrypt all of the NFS traffic between your servers (whether they be NFS clients or NFS servers). My view is that there are better ways to achieve this in today's world, ones that I trust more for this purpose.

The first option is to use IPsec for at least the NFS traffic between NFS servers and NFS clients. IPsec has the advantage that IPsec security policies will generally let you encrypt all NFS traffic and only the NFS traffic, so you don't have to spend CPU cycles encrypting other traffic (if any). You'd most likely want to set up an IKE environment to establish IPsec keys between relevant machines and to authenticate them.

The second option is to use some kind of VPN system, with the NFS servers running VPN endpoints and the NFS clients authenticating to them to create encrypted connections. To force all NFS traffic to be encrypted, you would give the NFS servers and NFS clients IP addresses that can only be reached over a VPN connection, then do your NFS mounts (and NFS mount permissions) using those IP addresses (or names associated only with them). Like IPsec, a well done version of this would have the side effect of authenticating all of the machines involved. You'd distribute the necessary VPN configurations, keys, and identification information through whatever existing configuration management system you use for your servers. If I was doing this, I would use WireGuard if possible.

(Since you want all of the NFS servers to be VPN endpoints, you're naturally interested in mesh-capable VPN solutions.)

Given that encryption is encryption, I would expect good implementations of any of these options to have performance comparable to NFS with Kerberos. WireGuard is reportedly capable of significant bandwidth under the right circumstances, so hopefully other options can perform decently as well. You wouldn't get as much NFS bandwidth (with as little CPU overhead) as you would without encryption, so if the best bandwidth possible is your priority you need to build a physically secure network and run NFS unencrypted over it.

Even if NFS with Kerberos had no other effects, I would rather use one of these other options to get encrypted NFS, for two reasons. The largest reason is that I have far more trust in the cryptographic quality and security of something like WireGuard than I do in NFS with Kerberos, because the former is much more of interest to people and thus much more scrutinized. The lesser reason is that using Kerberos necessarily means your Kerberos server (or servers) are now a critical part of your NFS infrastructure.

(Of course, you might already have Kerberos as a critical part of your environment for other reasons.)

PS: Done well, both IPsec and VPNs will authenticate all of the machines involved to each other. It's not sufficient for an imposter to grab an IP address of a NFS server or client and start talking; they'd also need the machine's key material as well. In some environments this is important. Of course at this point you get into provisioning issues and how secure the provisioning process is.


Comments on this page:

From 193.219.181.219 at 2023-05-23 00:45:13:

The third option is NFS-over-TLS or "RPC-TLS", initial support for which has just been merged into Linux a few weeks ago (I believe FreeBSD has already had it for a little longer); you could probably test it with mainline and ktls-utils, and the latest nfs-utils as well.

Either sec=sys over mutually authenticated TLS (with server and client certificates) or authentication-only sec=krb5 (without Kerberos-level integrity or encryption, leaving that to TLS) over normal TLS would probably be the most useful combinations, though you could use it whichever way.

Generally all those options (both TLS and VPN) will likely have performance far better than Kerberos; at least in my tests sec=krb5i-over-IPsec seems to offer 2x-3x the performance than sec=krb5p. I'm not entirely sure why, perhaps the way Kerberos uses AES-CTS doesn't easily lend itself to offloading (or perhaps just because AES-CTS is not AES-GCM, and it's the latter that CPUs really like).

From 193.219.181.219 at 2023-05-23 01:05:26:

Generally all those options (both TLS and VPN) will likely have performance far better than Kerberos

(On that note, Microsoft has probably learned the same lesson, as they traditionally have been using Kerberos encryption for LDAP and all the various DCE-RPC stuff that was implemented in 2000s, but when they finally added encryption to SMBv3 they deliberately chose to not do the same – Kerberos in SMBv3 only performs authentication and key-exchange, while bulk encryption is done at the SMB protocol layer in a way that's easier to offload to hardware.)

Written on 22 May 2023.
« NFS with Kerberos and NFS without Kerberos are two quite different things
Some views on protocols and encryption »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon May 22 21:57:25 2023
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.