Re: [nfsv4] NFS over TLS for floating clients

Chuck Lever <chuck.lever@oracle.com> Fri, 06 March 2020 17:01 UTC

Return-Path: <chuck.lever@oracle.com>
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 28B463A0AEA for <nfsv4@ietfa.amsl.com>; Fri, 6 Mar 2020 09:01:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com
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 X2gbIHxqu324 for <nfsv4@ietfa.amsl.com>; Fri, 6 Mar 2020 09:01:20 -0800 (PST)
Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9608D3A0AD9 for <nfsv4@ietf.org>; Fri, 6 Mar 2020 09:01:20 -0800 (PST)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 026GvvJ6031086; Fri, 6 Mar 2020 17:01:20 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2020-01-29; bh=vmyhkKbM7TN5jCr9T0iCg+gso6Q6b/A64F157HFhLEw=; b=ccIvoTqtyf/4twiSKYnQrJXypHoWYPwwAHBKaUhLSHaqGaOAW4b3ES3rXTtdj3KDm7um oo922Dm7tSHQyIEzJU1Pqs+OwFRdzwPvnhzmWhCPe8YRGECZZSGyw4EpZfWtpSHQrwxN R6NcLwr5GKWy5ARBu9vMMUOmEetwz1QRGYxlXTjjkGz/o0cChXth0dXto2pLQk+lPNX+ cCHW9+C0SuNs1N02JezSu/HCf9p06D07ax6438AJGWAAoOoMNwYx3GiXECIuDRxNfYaI O1Kb+cOu61yzauPcSg33lacIYcgLSbwRYsvb79s+nbwlWe9FTptXN//PivRp6p5zvCm6 qA==
Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2130.oracle.com with ESMTP id 2ykgys317x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 06 Mar 2020 17:01:20 +0000
Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 026GuvTG067229; Fri, 6 Mar 2020 16:59:19 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3030.oracle.com with ESMTP id 2yjuf43qtg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 06 Mar 2020 16:59:19 +0000
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 026GxIqT028032; Fri, 6 Mar 2020 16:59:18 GMT
Received: from anon-dhcp-153.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 06 Mar 2020 08:59:18 -0800
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: =?utf-8?q?=3CYTBPR01MB337482A9420C1AEF05466D3FDDE30=40YTBPR01MB?= =?utf-8?q?3374=2ECANPRD01=2EPROD=2EOUTLOOK=2ECOM=3E?=
Date: Fri, 6 Mar 2020 11:59:17 -0500
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9A4AABCC-D41D-4E91-BF79-54108F78BB41@oracle.com>
References: =?utf-8?q?=3CYTBPR01MB337482A9420C1AEF05466D3FDDE30=40YTBPR01MB3?= =?utf-8?q?374=2ECANPRD01=2EPROD=2EOUTLOOK=2ECOM=3E?=
To: Rick Macklem <rmacklem@uoguelph.ca>
X-Mailer: Apple Mail (2.3445.104.11)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9552 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 spamscore=0 malwarescore=0 bulkscore=0 adultscore=0 suspectscore=2 mlxlogscore=999 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2003060111
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9552 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=2 lowpriorityscore=0 mlxscore=0 mlxlogscore=999 bulkscore=0 impostorscore=0 phishscore=0 adultscore=0 priorityscore=1501 spamscore=0 clxscore=1011 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2003060111
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/28EFRUEIC_Ft06Wg-Q6XWRQkyKo>
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:01:22 -0000

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