Re: [nfsv4] NFS over TLS for floating clients

Rick Macklem <rmacklem@uoguelph.ca> Fri, 06 March 2020 22:53 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 4DFC23A0CDE for <nfsv4@ietfa.amsl.com>; Fri, 6 Mar 2020 14:53:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 Hzm86mMUfFt0 for <nfsv4@ietfa.amsl.com>; Fri, 6 Mar 2020 14:53:07 -0800 (PST)
Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660067.outbound.protection.outlook.com [40.107.66.67]) (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 CF2693A0CDD for <nfsv4@ietf.org>; Fri, 6 Mar 2020 14:53:06 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; =?utf-8?q?b=3DhO8wStWHKyGbGVfwwQ6hfukmt4NdTHPLQ8DXVK2wI8qBJuHpvFbWYXLWfBHBg?= =?utf-8?q?pG4xK1pR5UqWakwvr2SRHjMM1stbmVyq4DgEIrd2qxrz6Z/d5byiJuEk3WcODsKvf?= =?utf-8?q?lYnbs5HeJwMoJnjauII9Ainm7Sc0tBnh6iiptdFVUDsJelXmR0rjjakZgl85o0tBS?= =?utf-8?q?Q9HbAHqFaOMmwc9Qopq5GMSp7wU41cJciAPj8vZRhAuDC7OQEMLOFtbuI2BjMkqd+?= =?utf-8?q?QOVoNj1q7p/ifixUMhNsyMWNP6tFX1mhK39dLhwR0Uxoh6ihNUIbV6d5ntRWQUV7k?= =?utf-8?q?OsUPWPsRaMniDlDL9/u4Q=3D=3D?=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3ACont?= =?utf-8?q?ent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3D8zyScuoOSsy3dL6NvEq/MEp8paS4cfda0+kpfQTYmV4=3D=3B_b=3Dl8kOVW?= =?utf-8?q?mRkSlYM6oLDZwkWKR3gJ3y4uNrBgH6ZpFGfkiGotZ2dGSBCReFLtG8xuyVdQphx0x?= =?utf-8?q?VVOcwFjirI4WxYFSyxCdlJHeLUXRAR1TvM6d/wr/DLLadKeJMGPJ0TzRX1LltR42u?= =?utf-8?q?BAOAhrsK030TGmkqU1nVEiSBj4FX2RLsNUjSfjRUx2kk2DJRZerWHX1Sq4kp2RW5e?= =?utf-8?q?Q6K6MC1PC9yX0AUNHJ3+ijPA+XPd4KNrmsoq01aCGO8ulOO4ZAIhOkeG+9H84Y8k3?= =?utf-8?q?eZoRvHidunv1YiX7ZH3Sukwpv7ayrbgI63+DO1Tpnpfk/AgxnHfArt1K3oaeokkbw?= =?utf-8?q?9ysCB5LgbeQ=3D=3D?=
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 YTBPR01MB2861.CANPRD01.PROD.OUTLOOK.COM (10.255.12.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.15; Fri, 6 Mar 2020 22:53:05 +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 22:53:05 +0000
From: Rick Macklem <rmacklem@uoguelph.ca>
To: "Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de>, Chuck Lever <chuck.lever@oracle.com>
CC: NFSv4 <nfsv4@ietf.org>
Thread-Topic: [nfsv4] NFS over TLS for floating clients
Thread-Index: AQHV82BAxp9O6fa7qEu4EnWyACrtOKg7ymSAgAACoICAAF78/Q==
Date: Fri, 6 Mar 2020 22:53:04 +0000
Message-ID: =?utf-8?q?=3CYTBPR01MB33742EF89CFFCAAD31B9DFB6DDE30=40YTBPR01MB3?= =?utf-8?q?374=2ECANPRD01=2EPROD=2EOUTLOOK=2ECOM=3E?=
References: =?utf-8?q?=3CYTBPR01MB337482A9420C1AEF05466D3FDDE30=40YTBPR01MB3?= =?utf-8?q?374=2ECANPRD01=2EPROD=2EOUTLOOK=2ECOM=3E?= <9A4AABCC-D41D-4E91-BF79-54108F78BB41@oracle.com>, <1279406655.3520947.1583514521733.JavaMail.zimbra@desy.de>
In-Reply-To: <1279406655.3520947.1583514521733.JavaMail.zimbra@desy.de>
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: dbe4f93b-d7c8-4d53-4b76-08d7c22121a9
x-ms-traffictypediagnostic: YTBPR01MB2861:
x-microsoft-antispam-prvs: =?utf-8?q?=3CYTBPR01MB28613318323CD59A09E0778FDDE?= =?utf-8?q?30=40YTBPR01MB2861=2ECANPRD01=2EPROD=2EOUTLOOK=2ECOM=3E?=
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0334223192
x-forefront-antispam-report: SFV:NSPM; =?utf-8?q?SFS=3A=2810009020=29=283986?= =?utf-8?b?MDQwMDAwMikoMTM2MDAzKSgzNjYwMDQpKDM5NjAwMykoMzc2MDAyKSgzNDYwMDIp?= =?utf-8?b?KDE4OTAwMykoMTk5MDA0KSg2NjQ0NjAwOCkoNjQ3NTYwMDgpKDY2NTU2MDA4KSg1?= =?utf-8?q?5016002=29=2866476007=29=289686003=29=285660300002=29=2866946007?= =?utf-8?b?KSg1MjUzNjAxNCkoMTEwMTM2MDA1KSgyOTA2MDAyKSgxODYwMDMpKDc2OTYwMDUp?= =?utf-8?b?KDcxMjAwNDAwMDAxKSgyNjAwNSkoNDMyNjAwOCkoNzg2MDAzKSg4OTM2MDAyKSgz?= =?utf-8?q?16002=29=2881166006=29=2881156014=29=288676002=29=2866574012=29?= =?utf-8?q?=286506007=29=2853546011=29=2876116006=29=2886362001=29=283365600?= =?utf-8?q?2=29=28966005=29=2891956017=29=28478600001=29=3B?= DIR:OUT; SFP:1101; SCL:1; SRVR:YTBPR01MB2861; H:YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: =?utf-8?q?epZF7liSBUgAcrZW+NtQ7uXULhzDKdQ?= =?utf-8?q?loNpA9CItYJNWhbdjzsvFWwSYyNbQ6eNCCYnrE3+T4qZl1oPZ1FLB0CeqtA/Cgz3D?= =?utf-8?q?g0yl6CdnseEE0pxCWWJR1i/lxo2FWtQw/ynAI1eKVtF9X92X/CYfYnBcn2R5cNgAJ?= =?utf-8?q?/haugSuA1TBvGlnjBTtf06s0/0mgowCuj2FvOUM78DRUAKc7mKioJCHi1WQ7MMNQ3?= =?utf-8?q?Xd9ErMiTHSrCYFgnpVRlpxWLL6jBobElSjw74TXdIOHGmhejV2Fx4t6nnpfhAwjbK?= =?utf-8?q?piQmCX3PGBciHroFwUNuz/EPnYaH7x/ryC0c4kNXiR3y7PU3qapPFhdHf1Sm1pd4a?= =?utf-8?q?yn9gQcFRs3u//70SnI38asETT6nrlet7Q17ay+M5S9HJJuPg5BUslJC40N1Zj8Ey0?= =?utf-8?q?S9YdV/9+y9hM8OGwg1RYu76HzDEDPs+XOQOtuz+hreVu/9obY/Snh/5HWMBaynoAQ?= =?utf-8?q?y3boYTNxcl3HqGN2IxoP5rPeGwJmsRLb9rSKPYWBqSvvO4JQ=3D=3D?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?Pl88GXDVuxL9cht7kdxvkc6penGc9l?= =?utf-8?q?GfGvwLS+OMK4dKg0ZS1hFpEAoSRMMosgBRLe1fkag6xS96ddncsM83kXpI8ZQDzIW?= =?utf-8?q?lMGTLsM8gZczyho3IlMRQc6aDnxqrmR3iLAivvegXorkeN/uU0cQCYg=3D=3D?=
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: dbe4f93b-d7c8-4d53-4b76-08d7c22121a9
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2020 22:53:04.9687 (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: =?utf-8?q?qHvhZx54DHd0D4utP4hoq?= =?utf-8?q?x7INshO0Tph851NnZePQUXZYRDVL/5bIQe6j445Uvv9SlMoc2uHCMBb2ZsworjNHw?= =?utf-8?q?=3D=3D?=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB2861
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/02VWsXlhJeYey2R2H_oP5L4B6dw>
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 22:53:09 -0000

Mkrtchyan, Tigran wrote:
>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.
Yes, I suppose this is true. I'll admit when I read "unique global identity" I
thought DNS domain name, since that is what the trusted CAs are signing
off on, if I understand it correctly. (Which I might not, since I'm new to this
stuff and definitely not a security guy.)

rick

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