Re: [nfsv4] NFS over TLS for floating clients

Trond Myklebust <trondmy@gmail.com> Fri, 06 March 2020 19:07 UTC

Return-Path: <trondmy@gmail.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 0CA593A00D9 for <nfsv4@ietfa.amsl.com>; Fri, 6 Mar 2020 11:07:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 lf-X4BGyiHxM for <nfsv4@ietfa.amsl.com>; Fri, 6 Mar 2020 11:07:45 -0800 (PST)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ECF63A00C9 for <nfsv4@ietf.org>; Fri, 6 Mar 2020 11:07:45 -0800 (PST)
Received: by mail-io1-xd2d.google.com with SMTP id u17so3111809iog.11 for <nfsv4@ietf.org>; Fri, 06 Mar 2020 11:07:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ya2yXkxdxrvB5eYkB7FVo7NCl6uNvGg0zlhG7Z9+o/s=; b=UrFSHSHjGjj0/DOsS22Rf2eqMfjQAUUUT1e5lyTTXzQdDDkxnelzEuwBdlrw88/mbn XUTIS3Bo9XK/FOQrYjbaHVs4x8dh76jaWHUT6O7AQHtzT3Scbc72PJLZJKGERupH/DSc 6rG8ND8hN+jE1qzhNQzEi+ilgkNoGxY4otVK5dnSThzCekPxIUZ9oE4wa8cZIJN81fR2 YP0Pp2RiQgcECZfDOfeQcolSn0sANwAMmno0r7CcFQKpdxGlurPP3g0ogUx9tQjeRwKC kwGLD9J2YM0ABbFOg/R4egjKqQPClI5Be8NpGNQlePYR1aC8NWujOa4irs6SgRDbecHo LGxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ya2yXkxdxrvB5eYkB7FVo7NCl6uNvGg0zlhG7Z9+o/s=; b=Rp4pPALE67NAwlk3HJ3JNnq3SF/XGoWiRcPAKwEI3caImWL7IWUr//bbiooJ7o+1sV k1JQvt4CELHQk1I6mTzEQotOpXlGKHENT7did4ZdvkXHlQ/BkumfNzZXw/Pg10vdJg9u oWvyuH0YM8lV4ffP/KU3AzcH1PgxMzaHx7cp4OPeurpjAddzWtiCexz4F01IKaUVRaNe gcHsBYTkDJRfOxYv11+DqmVyR+jyKWXUzw4zbmZoSbFKomG3lNcQeLlQK3rujHVVxIfU WoBDQHd3yVpGEfawLaaZytr48aT6h1TmXYmv8I47y+92SJ5zuhvY1qqgKq5Uu8dO8Kzm izww==
X-Gm-Message-State: ANhLgQ1zaUQAJ77mBwYetc/SNZxNuvVMkIXvjZdY7++fWNloV/K/LqaO Y8Cmui0cpX4Ckts2aZd50Cw9UpNZIUas+0rGwQ==
X-Google-Smtp-Source: =?utf-8?q?ADFU+vuyqBTnhQQMU7vPsVsytt11pbctnLHsDSgsfUwk?= =?utf-8?q?SraT4GRevX8BTLKtB9tjP/Bsm5hPGwQJ8RcdwsCs0X3QQV4=3D?=
X-Received: by 2002:a02:caa2:: with SMTP id e2mr4635326jap.6.1583521664158; Fri, 06 Mar 2020 11:07:44 -0800 (PST)
MIME-Version: 1.0
References: =?utf-8?q?=3CYTBPR01MB337482A9420C1AEF05466D3FDDE30=40YTBPR01MB3?= =?utf-8?q?374=2ECANPRD01=2EPROD=2EOUTLOOK=2ECOM=3E?=
In-Reply-To: =?utf-8?q?=3CYTBPR01MB337482A9420C1AEF05466D3FDDE30=40YTBPR01MB?= =?utf-8?q?3374=2ECANPRD01=2EPROD=2EOUTLOOK=2ECOM=3E?=
From: Trond Myklebust <trondmy@gmail.com>
Date: Fri, 6 Mar 2020 14:07:33 -0500
Message-ID: <CAABAsM7mSfULv974gPQmCSt+Nt2zdH1wMvemwPXw365SeEGTQg@mail.gmail.com>
To: Rick Macklem <rmacklem@uoguelph.ca>
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/tLOSMwXv374aVNcNA8B2yKCqtYY>
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 19:07:47 -0000

On Thu, 5 Mar 2020 at 22:06, 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.

It really boils down to the question of who do you trust to assert
what information.

If you own a domain, you can usually buy SSL certificates for it that
assert a given name within that domain. As long as you trust the major
CA vendors not to sell such a certificate to someone who does not own
the rights to the domain, then you might have your server use that
chain of trust to verify that this is indeed a trusted laptop. You
might decide to compare the full name appearing in the certificate to
a trusted list, or maybe just verify that the domain or subdomain info
matches a list of trusted domains or subdomains. Yes, you can do this
more cheaply by creating your own site-local CA, but it is essentially
the same process of setting up a chain of trust for your source of
information and then of asserting that information in a 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).

It might be better to word in terms of the language of chains of
trust. "...the client possesses an identity (e.g. a certificate) that
is backed by a trusted entity."

> 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?
>
> So, what do others think about this? rick
>
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4