RE: Why TLS and Kerberos are not useful for NFS security Re: [PATCH nfs-utils] exportfs: make "insecure" the default for all exports

["Frank Filz" <ffilzlnx@mindspring.com>]

> -----Original Message-----
> From: Dan Shelton [mailto:dan.f.shelton@gmail.com]
> Sent: Sunday, May 18, 2025 7:14 PM
> To: Linux NFS Mailing List <linux-nfs@vger.kernel.org>; libtirpc-
> devel@lists.sourceforge.net
> Subject: Re: Why TLS and Kerberos are not useful for NFS security Re: [PATCH
> nfs-utils] exportfs: make "insecure" the default for all exports
> 
> On Wed, 14 May 2025 at 23:51, Martin Wege <martin.l.wege@gmail.com>
> wrote:
> > Interoperability is also a big problem (nay, it's ZERO
> > interoperability), as this is basically a Linux kernel client/kernel
> > server only solution.
> > libtirpc doesn't support TLS, Ganesha doesn't support TLS, so yeah,
> > this is an issue, and not a solution.
> >
> > Fazit: Supporting your argumentation with Kerberos5 or TLS is not gonna fly.
> 
> I tried to add TLS support to libtirpc, but I think it's simply not possible. The APIs
> are just not compatible.
> Ganesha folks also tried the same, and failed - their ntirpc would require a major
> redesign to support TLS.

For what it's worth, we (Ganesha) are still working on offering TLS. There are options (including kTLS) that seem like they would work (mostly) for us, the issue is if there needs to be a rekeying negotiation.

I can see how once a TLS session is started, we could integrate a ktls socket into our ntirpc epoll loop and send and receive packets on the TLS session. But when rekeying is necessary, I don't quite see how to get back into a library to do that, particularly in a way that still uses our epoll loop. That is the same for user space libraries. We have looked at OpenSSL and s2n.

We do see a demand for protected RPC sessions for NFS and TLS seems to be the best option at the moment.

Frank