Re: [nfsv4] NFS over TLS for floating clients

Trond Myklebust <trondmy@gmail.com> Fri, 06 March 2020 20: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 43FE93A093D for <nfsv4@ietfa.amsl.com>; Fri, 6 Mar 2020 12:07:35 -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 S8aiEnVXHC9R for <nfsv4@ietfa.amsl.com>; Fri, 6 Mar 2020 12:07:33 -0800 (PST)
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 2C3573A0930 for <nfsv4@ietf.org>; Fri, 6 Mar 2020 12:07:33 -0800 (PST)
Received: by mail-il1-x12c.google.com with SMTP id a14so58620ilk.6 for <nfsv4@ietf.org>; Fri, 06 Mar 2020 12:07:33 -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=FIOmCVwhukr0x9oaMHT0RYPSE1K+FLEto2k3zvfDSXQ=; b=C+ZsGDePddHeEnZce7Q8ddPXlYifcp21LJGX0Qzaqypk6xFdEelHTSgWgeLV5mfXT+ i+9E8hMqPR5xbXftlMowNbN66aR9JZwbPT3TvnvHeuQsy4+t8bnirSmbDynHME/yqv86 o/roX9YJMELUBsmeeWY/mJnF2+guUgrPuKu4J9mxC2TAJF4DM6hKjoMlaaaiwDa3XLY1 Fsho1H0G/8tNfy0iqhPvUMBD48CO7Fz3bcNldUe/nzvE5uwz6K5kCSB6xtC9jLmTD/1R MMnl8XAfdySVtU6GsHekJgRwfnR7oKnahHfr2XbWrsNg3yRbpVkIH8Bn1IUDblpPvuyM sx6Q==
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=FIOmCVwhukr0x9oaMHT0RYPSE1K+FLEto2k3zvfDSXQ=; b=qHD+3qH3H4KYBT95rpfo2mTZVK7rNYTJGPbVx/k+8jp9Zbpu+SIPtLIGO8R/bpfXRB p52b38Ov0u4AbSNxKRPDWZ6dcW2XE550gw//boINzbdMHQt3Zw8xbGnxbSqJWJ5t2Br6 PlnHeCURODRmxNoKtYmUZsG2MysdOVlu4OzZrLrlhKMP6irJxgfvk6maqL9dZT2EiudE JJyMCce71daJzhscbwLHj71ICk8wxCCXI3kIZWcecIr59OCcdJElrPBZF6AzfdDOV78a AOERFu3NSdOPoHeewQw7OX1N36ychtn+fB2Ow5xBP3Wd+CkZg5acl97aTBTK9ppmzP0h LSVA==
X-Gm-Message-State: ANhLgQ3rAyTgytEg2yGlZxvu+7gFPdBH7DfZmEOl8h9VFeU3yFqmz2hj /vJsRxY5ybrP5ZbFkblPKt+Ub/ZMwHXbrRfYnOu3n8k=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vvi5ULboDvEGjga6KMH7wI7QF/X2sCEpjCEO7LA?= =?utf-8?q?4jLf46aqlXP0r8tS9kiLfHwY+RzZoMY44KOjxM5f1kaYbIs=3D?=
X-Received: by 2002:a92:c90c:: with SMTP id t12mr4634707ilp.246.1583525252208; Fri, 06 Mar 2020 12:07:32 -0800 (PST)
MIME-Version: 1.0
References: =?utf-8?q?=3CYTBPR01MB337482A9420C1AEF05466D3FDDE30=40YTBPR01MB3?= =?utf-8?q?374=2ECANPRD01=2EPROD=2EOUTLOOK=2ECOM=3E?= <CAABAsM7mSfULv974gPQmCSt+Nt2zdH1wMvemwPXw365SeEGTQg@mail.gmail.com> <CAMhwm99ZUf5fshkkOtRyf2u8DjeRLdVk=Q05H8YF4A+ycZi8fA@mail.gmail.com>
In-Reply-To: <CAMhwm99ZUf5fshkkOtRyf2u8DjeRLdVk=Q05H8YF4A+ycZi8fA@mail.gmail.com>
From: Trond Myklebust <trondmy@gmail.com>
Date: Fri, 6 Mar 2020 15:07:21 -0500
Message-ID: <CAABAsM6ufsdFB+WSBAgWMW1nPKYr26XOOPVH=ceucNx6ELf14w@mail.gmail.com>
To: Craig Everhart <cfeverhart@gmail.com>
Cc: Rick Macklem <rmacklem@uoguelph.ca>, "nfsv4@ietf.org" <nfsv4@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/cC3MCSl19-_Zhcjc80ybQctCmRc>
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 20:07:36 -0000

On Fri, 6 Mar 2020 at 14:37, Craig Everhart <cfeverhart@gmail.com> wrote:
>
> I think the problem statement contains the issue here:
> > 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.
> What attribute is the server looking for that will "allow" the server to be mounted?
> And can it be done anonymously, which this "anywhere" laptop really wants to be?
>
> Note that on-the-wire encryption will be done even if there is no client certificate--as long as the server has a certificate (or if the client/server are using a pre-shared key, which is a little further afield).
>
> If the client owns a domain, somehow, then the PKI machinery is available to it; a certificate will allow it to prove that it is able to speak for that domain name.  Is that what's being checked as this stuff about "allowing" the mount?
>
> I think that there's a problem with the NFS server wanting to know much about the client, unless it's limited to a DNS name.

The main purpose I can see for wanting to authenticate the client to
the server is to decide whether or not to allow user authentication
through weak mechanisms that rely on trust of the client itself (i.e.
AUTH_SYS). However there are also several mechanisms today that rely
on IP and port number tracking to identify clients (e.g. the duplicate
reply cache and side band protocols such as lockd, statd, mounts) and
that could benefit from stronger client identification. Ditto the
NFSv4.0 callback mechanism, and the NFSv4 lease mechanism.

We already agreed that describing how to modify NFSv4 etc,  is out of
scope for this document, but these are all motivations for ensuring
that this document should describe how we might go about identifying
clients.

> Craig
>
> On Fri, Mar 6, 2020 at 2:08 PM Trond Myklebust <trondmy@gmail.com> wrote:
>>
>> 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
>>
>> _______________________________________________
>> nfsv4 mailing list
>> nfsv4@ietf.org
>> https://www.ietf.org/mailman/listinfo/nfsv4