Re: [nfsv4] NFS over TLS for floating clients

"Mkrtchyan, Tigran" <> Fri, 06 March 2020 17:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 667A93A0AC2 for <>; Fri, 6 Mar 2020 09:08:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.099
X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wTMcXUEuOk4V for <>; Fri, 6 Mar 2020 09:08:44 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 230153A0ABB for <>; Fri, 6 Mar 2020 09:08:43 -0800 (PST)
Received: from ( [IPv6:2001:638:700:1038::1:a4]) by (Postfix) with ESMTP id 05AEFE042E for <>; Fri, 6 Mar 2020 18:08:42 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.11.0 05AEFE042E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1583514522; bh=660qAgjV/cGvcr9GGjBWY59nV2EoyeiGAnLE3Epf16Y=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=mMyoBY8PRzWa0RTnmwGJjEb1C3LJDarsRoHUltpS06YeZj9gYs6z2sLk7KdMzcYdE czEJTQHUCl2fsz2wFpaPbDZoRMyg95ixWZQI28edcvl8lRTUeFTgBHnmZXzO4ppSSI KIwrGkjP/ktHsgCKb6/IXfTqL6XGpoodN96lXbN0=
Received: from ( []) by (Postfix) with ESMTP id F1596120262; Fri, 6 Mar 2020 18:08:41 +0100 (CET)
X-Virus-Scanned: amavisd-new at
Received: from ( []) by (Postfix) with ESMTP id C821FC00A2; Fri, 6 Mar 2020 18:08:41 +0100 (CET)
Date: Fri, 6 Mar 2020 18:08:41 +0100 (CET)
From: "Mkrtchyan, Tigran" <>
To: Chuck Lever <>
Cc: Rick Macklem <>, NFSv4 <>
Message-ID: <>
In-Reply-To: <>
References: =?utf-8?q?=3CYTBPR01MB337482A9420C1AEF05466D3FDDE30=40YTBPR01MB3?= =?utf-8?q?374=2ECANPRD01=2EPROD=2EOUTLOOK=2ECOM=3E?= <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Mailer: Zimbra 8.8.15_GA_3901 (ZimbraWebClient - FF73 (Linux)/8.8.15_GA_3895)
Thread-Topic: NFS over TLS for floating clients
Thread-Index: K54Oq3CxonzhNqWN4eKpN+NbbiPVZg==
Archived-At: <>
Subject: Re: [nfsv4] NFS over TLS for floating clients
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Mar 2020 17:08:47 -0000

Well, you certificate contains your public key which is (in combination with
your private key) a global identity, other wise the whole PKI staff is dead.


----- Original Message -----
> From: "Chuck Lever" <>
> To: "Rick Macklem" <>
> Cc: "NFSv4" <>
> Sent: Friday, March 6, 2020 5:59:17 PM
> Subject: Re: [nfsv4] NFS over TLS for floating clients

> Hi Rick-
> Just a couple of observations below.
>> On Mar 5, 2020, at 10:06 PM, Rick Macklem <> wrote:
>> Hi,
>> As I am working through implementation of NFS over TLS, I have run into
>> a couple of things related to certificates.
>> Here's an example scenario:
>> - The client is a laptop that wants to mount a server from "anywhere" using
>>  TLS, so that data is encrypted on the wire.
>>  The server understandably wants to use "mutual authentication" to determine
>>  that the client is indeed one that is allowed to mount the server.
>> Ok, so now how do you get a certificate for the client that the server can
>> reasonably verify?
>> --> After a discussion over on a FreeBSD mailing list, it sounds like the easy
>>      (maybe only?) way to do this is for the NFS server admin. to run a site local
>>      CA and generate certificates against that.
>>      - Although I'm sure there are other ways, you can create a site local CA
>>         certificate with two openssl commands and sign a certificate for a client
>>         with two more openssl commands.
>>     Then the server can verify the certificate using the CAcert that was used to
>>     sign the client's certificate.
>> Now, when I read the sections around Page 6 of the draft...
>>   Mutual Host Authentication
>>      In this type of deployment, the client possesses a unique global
>>      identity (e.g., a certificate).  As part of the TLS handshake,
>>      both peers authenticate using the presented TLS identities.  If
>>      authentication of either peer fails, or if authorization based on
>>      those identities blocks access to the server, the client
>>      association MUST be rejected.
>> For the above, the client does not possess a unique global identity,
>> it might more correctly be called a "site local identity" that the server
>> can authenticate.
>> Is the "unique global identity" requirement necessary? It seems to me
>> that a site local CA issued certificate might be appropriate.
>> (RFC 5280 page 12, second (a) item seems to allow site local CA
>> certificates).
> "unique global identity" is probably overkill. It's text I made up.
> I am willing to replace it with a term that encompasses site local
> identities as well. We absolutely want this to work with self-signed
> certs, although that's not going to provide an ultimate degree of
> security.
>> Also, w.r.t. server certificates, the draft says:
>>   Each RPC server that supports RPC-over-TLS MUST possess a unique
>>   global identity (e.g., a certificate that is signed by a well-known
>>   trust anchor).  Such an RPC server MUST request a TLS peer identity...
>> I wonder if the above must be a MUST?
>> For example, I have an NFS server at home. It doe not have a well known
>> fixed DNS address (residential internet connection, where it sits behind
>> a NAT gateway where the address stays the same most of the time).
>> --> If I want to mount this server from anywhere, I do want to use TLS
>>      so that data is encrypted on the wire. Although it would be nice for
>>      the laptop to be able to verify the server's identity, I don't see how I
>>      can get a certificate for it from a well known trust anchor. I can live
>>      with it having a self-signed certificate.
>> Also, although an NFS server administrator can get a certificate from a
>> well known trust anchor, it might cost $$ or it might not be easy. (Lets
>> Encrypt expects to be able to use ACME on a web site or similar to issue
>> a certificate, if I understand their setup?)
>> Acquiring a certificate from a "well known trust anchor" might be a
>> significant effort that will discourage use of TLS. (Again, you can easily
>> create a self-signed certificate with a couple of openssl commands.)
>> --> Maybe this could be a recommendation instead of a MUST and
>>       the choice of accepting a self-signed certificate be left up to the
>>       client via configuration?
> In a Proposed Standard, IMO we want to keep very strong security
> recommendations. An implementer or administrator is of course free
> to ignore these requirements, at some risk to them.
>> So, what do others think about this? rick
> --
> Chuck Lever
> _______________________________________________
> nfsv4 mailing list