[nfsv4] NFS over TLS for floating clients

Rick Macklem <rmacklem@uoguelph.ca> Fri, 06 March 2020 03:06 UTC

Return-Path: <rmacklem@uoguelph.ca>
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 E4A6E3A11CD for <nfsv4@ietfa.amsl.com>; Thu, 5 Mar 2020 19:06:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 gUM5lucoZbvk for <nfsv4@ietfa.amsl.com>; Thu, 5 Mar 2020 19:06:04 -0800 (PST)
Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660047.outbound.protection.outlook.com [40.107.66.47]) (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 EBAFF3A11B2 for <nfsv4@ietf.org>; Thu, 5 Mar 2020 19:06:03 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k+GE0p4xVbeIsHlUQs/tnz7DlMQ1llSSJ/idblmaH+CA9uROeJ+p30T72QcYB9Ao3kCJHBmf6JoQlxSFImreE27F8Qhz4dcwdQBywXexBizdo8c4itdaVWFXgxnq91N4sRx9nymGpO1+Db4ou7pFtXkx35V3Gf9O0mZ5DLN+9S4VBgBS2efRTM47VZt7K9QTQnKju2g1UnqMgpp7hbC54mUAlbc9lld8E3OUgtHhLsCFjtWdQdwDuAjJoGBfwTKlkvvoZ6XX1j8/XLtmYnVBE4vUiXDQIDxI+KMNW5IEfPPcHYMGv331J1rDkuPdCvUX6ubPk8lASCKKkCCZWkz3RA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=JgnbZ3qLSw0FGBH68GYWaFu4CJQBj3snjGcIHmlcx1w=; b=kki93QbYVHiV/eGz26UwnV1dspA/aD5JMua6ReUPjKe2gYdl1YP+6lZaEQnFSyVHiCJfLnHV0mcLc+MKnEz3hprp756xFETZFL77OCV1Y30gX0yq6aK1MdQSb8ipLQMOM8lsoMEEzOEnsPwhDBBAUt64zJbV6fzKfu6tM4u7dpXLvQd4p29MaOVghTDCEUZYaHT+8VN1pjWWnIig/5alQrPN7edF4R6NvUvid24/Lmy5NifQGzw/oW8wt8n9NERK6RnZ+av1CBdsx87gXgFG528Oh50aTatlmIXPXlEOKJPxTBDzbh0zK7OOEJkfWk/fEldWTlT/+fjJkABBAyBRrQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none
Received: from YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM (10.255.46.82) by YTBPR01MB3504.CANPRD01.PROD.OUTLOOK.COM (10.255.47.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14; Fri, 6 Mar 2020 03:06:02 +0000
Received: from YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM ([fe80::a50d:6237:4074:f9c4]) by YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM ([fe80::a50d:6237:4074:f9c4%6]) with mapi id 15.20.2772.019; Fri, 6 Mar 2020 03:06:02 +0000
From: Rick Macklem <rmacklem@uoguelph.ca>
To: "nfsv4@ietf.org" <nfsv4@ietf.org>
Thread-Topic: NFS over TLS for floating clients
Thread-Index: AQHV82BAxp9O6fa7qEu4EnWyACrtOA==
Date: Fri, 06 Mar 2020 03:06:02 +0000
Message-ID: <YTBPR01MB337482A9420C1AEF05466D3FDDE30@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0efad729-eda1-40ee-99e8-08d7c17b4d9e
x-ms-traffictypediagnostic: YTBPR01MB3504:
x-microsoft-antispam-prvs: <YTBPR01MB3504254CF8427274488E5334DDE30@YTBPR01MB3504.CANPRD01.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0334223192
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(366004)(396003)(346002)(39860400002)(199004)(189003)(8676002)(66574012)(86362001)(81166006)(7696005)(2906002)(52536014)(81156014)(6916009)(8936002)(33656002)(71200400001)(186003)(6506007)(76116006)(66946007)(55016002)(66556008)(66476007)(66446008)(64756008)(9686003)(478600001)(5660300002)(786003)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTBPR01MB3504; H:YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: EQb4whhXFRtchw8juKh3PoRXhKhG+cgaitn44N3F65gU71EJXKs1HVPlZ153jFVaK0+lp2wo5TDI9e40BXRfeBCr0p4svNP9vny3J4a7/GJzb2W8DIUS0dyo4rjwZ5z30L8nPEbBKHw7oWo/qn79gBwQwCfoXejalxOeDHxAnwE8aJoVSsXivna5P7kgJMC6sY6bYLOhj5vK/34BsL/T1oXWCfnrqd8tJGQVVLHxdtoZZxCeXDbQNGr7pzx5YTI9OzDuuNWLY9yBFMQml8uskS6dud6WGv2IaDkPTRpsOdV83KCgPjmVP7JWUL+uKGvN3RFmsjzazlWAlWSMMty4jbFhtTRV1qAWmNLdNFVR9H6JKU4tPq1JEYGFfvlKZ9xYq+mYhCeoufSW+9rM11WpBBHmxa6Ywzx14NkVMdm9hI9akaReOitJlQ2Eo0yqMLR/
x-ms-exchange-antispam-messagedata: y4YhDkm2i3C59vNlRrdkPmWbV98iwEKu8ruENTN5DudiwIXLqrFpDl2Gp30AUOq2xdPqHAuSbv31ikPQTUQfwHroCcdgbLv9RtirCoYwlyPJUV/zVol+iQj9Qm5vpQ0xlODlwWBKogwrUoz6w59V/46F23oNLLPUdTwvJF1JncrGVQpZWVowph3jSewhED53TzawPqFHGNTMQVSdaTzdGg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: uoguelph.ca
X-MS-Exchange-CrossTenant-Network-Message-Id: 0efad729-eda1-40ee-99e8-08d7c17b4d9e
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2020 03:06:02.2922 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: NHLYGik3BaR7RoeUyBG15qEbJCl8bk+Lo1d8RU7ykkvaBmN+h/D7fvzk3Iuf+wwIg8Cii5bdY+a0yzrRfqSoHA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB3504
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/Q8sL3yUGmtGH-wPMhc9ZwVf9LJ0>
Subject: [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 03:06:06 -0000

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).

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