Re: [nfsv4] NFS over TLS for floating clients

"Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de> Fri, 06 March 2020 17:08 UTC

Return-Path: <tigran.mkrtchyan@desy.de>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667A93A0AC2 for <nfsv4@ietfa.amsl.com>; Fri, 6 Mar 2020 09:08:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.099
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=desy.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTMcXUEuOk4V for <nfsv4@ietfa.amsl.com>; Fri, 6 Mar 2020 09:08:44 -0800 (PST)
Received: from smtp-o-1.desy.de (smtp-o-1.desy.de [131.169.56.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 230153A0ABB for <nfsv4@ietf.org>; Fri, 6 Mar 2020 09:08:43 -0800 (PST)
Received: from smtp-buf-1.desy.de (smtp-buf-1.desy.de [IPv6:2001:638:700:1038::1:a4]) by smtp-o-1.desy.de (Postfix) with ESMTP id 05AEFE042E for <nfsv4@ietf.org>; Fri, 6 Mar 2020 18:08:42 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp-o-1.desy.de 05AEFE042E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=desy.de; 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 smtp-m-1.desy.de (smtp-m-1.desy.de [131.169.56.129]) by smtp-buf-1.desy.de (Postfix) with ESMTP id F1596120262; Fri, 6 Mar 2020 18:08:41 +0100 (CET)
X-Virus-Scanned: amavisd-new at desy.de
Received: from z-mbx-2.desy.de (z-mbx-2.desy.de [131.169.55.140]) by smtp-intra-1.desy.de (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" <tigran.mkrtchyan@desy.de>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Rick Macklem <rmacklem@uoguelph.ca>, NFSv4 <nfsv4@ietf.org>
Message-ID: <1279406655.3520947.1583514521733.JavaMail.zimbra@desy.de>
In-Reply-To: <9A4AABCC-D41D-4E91-BF79-54108F78BB41@oracle.com>
References: =?utf-8?q?=3CYTBPR01MB337482A9420C1AEF05466D3FDDE30=40YTBPR01MB3?= =?utf-8?q?374=2ECANPRD01=2EPROD=2EOUTLOOK=2ECOM=3E?= <9A4AABCC-D41D-4E91-BF79-54108F78BB41@oracle.com>
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: <https://mailarchive.ietf.org/arch/msg/nfsv4/yfm3-tdyus4hnGr-GVWmyarWREo>
Subject: Re: [nfsv4] NFS over TLS for floating clients
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=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.

Tigran.

----- Original Message -----
> From: "Chuck Lever" <chuck.lever@oracle.com>
> To: "Rick Macklem" <rmacklem@uoguelph.ca>
> Cc: "NFSv4" <nfsv4@ietf.org>
> 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 <rmacklem@uoguelph.ca> 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
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4