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

["Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de>]

[-- Attachment #1: Type: text/plain, Size: 2515 bytes --]



----- Original Message -----
> From: "Martin Wege" <martin.l.wege@gmail.com>
> To: "Linux NFS Mailing List" <linux-nfs@vger.kernel.org>
> Sent: Wednesday, 14 May, 2025 23:50:00
> Subject: Why TLS and Kerberos are not useful for NFS security Re: [PATCH nfs-utils] exportfs: make "insecure" the
> default for all exports

> On Wed, May 14, 2025 at 1:55 PM NeilBrown <neil@brown.name> wrote:
>>
>> On Wed, 14 May 2025, Jeff Layton wrote:
>> Ignoring source ports makes no sense at all unless you enforce some other
>> authentication, like krb5 or TLS, or unless you *know* that there are no
>> unprivileged processes running on any client machines.
> 
> I don't like to ruin that party, but this is NOT realistic.
> 
> 1. Kerberos5 support is HARD to set up, and fragile because not all
> distributions test it on a regular basis. Config is hard, not all
> distributions support all kinds of encryption methods, and Redhat's
> crusade&maintainer mobbing to promote sssd at the expense of other
> solutions left users with a half broken, overcomplicated Windows
> Active Directory clone called sssd, which is an insane overkill for
> most scenarios.
> gssproxy is also a constant source of pain - just Google for the
> Debian bug reports.
> 
> Short: Lack of test coverage in distros, not working from time to
> time, sssd and gssproxy are more of a problem than a solution.
> 
> It really only makes sense for very big sites and a support contract
> which covers support and bug fixes for Kerberos5 in NFS+gssproxy.
> 
> 
> 2. TLS: Wanna make NFS even slower? Then use NFS with TLS.
> 
> NFS filesystem over TLS support then feels like working with molasses.
> 
> Exacerbated by Linux's crazy desire to only support hyper-secure
> post-quantum encryption method (so no fast arcfour, because that is
> "insecure", and everyone is expected to only work with AMD
> Threadripper 3995WX), lack of good threading through the TLS eye of
> the needle, and LACK of support in NFS clients.
> 
> Interoperability is also a big problem (nay, it's ZERO
> interoperability), as this is basically a Linux kernel client/kernel server only
> solution.

dCache (a-ka nfs4j) server supports TLS, FreeBSD, ... 

So, it's not a Linux-only solution.

Tigran.

> 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.
> 
> Thanks,
> Martin

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2826 bytes --]