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; b=hO8wStWHKyGbGVfwwQ6hfukmt4NdTHPLQ8DXVK2wI8qBJuHpvFbWYXLWfBHBgpG4xK1pR5UqWakwvr2SRHjMM1stbmVyq4DgEIrd2qxrz6Z/d5byiJuEk3WcODsKvflYnbs5HeJwMoJnjauII9Ainm7Sc0tBnh6iiptdFVUDsJelXmR0rjjakZgl85o0tBSQ9HbAHqFaOMmwc9Qopq5GMSp7wU41cJciAPj8vZRhAuDC7OQEMLOFtbuI2BjMkqd+QOVoNj1q7p/ifixUMhNsyMWNP6tFX1mhK39dLhwR0Uxoh6ihNUIbV6d5ntRWQUV7kOsUPWPsRaMniDlDL9/u4Q==
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=8zyScuoOSsy3dL6NvEq/MEp8paS4cfda0+kpfQTYmV4=; b=l8kOVWmRkSlYM6oLDZwkWKR3gJ3y4uNrBgH6ZpFGfkiGotZ2dGSBCReFLtG8xuyVdQphx0xVVOcwFjirI4WxYFSyxCdlJHeLUXRAR1TvM6d/wr/DLLadKeJMGPJ0TzRX1LltR42uBAOAhrsK030TGmkqU1nVEiSBj4FX2RLsNUjSfjRUx2kk2DJRZerWHX1Sq4kp2RW5eQ6K6MC1PC9yX0AUNHJ3+ijPA+XPd4KNrmsoq01aCGO8ulOO4ZAIhOkeG+9H84Y8k3eZoRvHidunv1YiX7ZH3Sukwpv7ayrbgI63+DO1Tpnpfk/AgxnHfArt1K3oaeokkbw9ysCB5LgbeQ==
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, 06 Mar 2020 22:53:04 +0000
Message-ID: <YTBPR01MB33742EF89CFFCAAD31B9DFB6DDE30@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM>
References: <YTBPR01MB337482A9420C1AEF05466D3FDDE30@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM> <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: <YTBPR01MB28613318323CD59A09E0778FDDE30@YTBPR01MB2861.CANPRD01.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0334223192
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(366004)(396003)(376002)(346002)(189003)(199004)(66446008)(64756008)(66556008)(55016002)(66476007)(9686003)(5660300002)(66946007)(52536014)(110136005)(2906002)(186003)(7696005)(71200400001)(26005)(4326008)(786003)(8936002)(316002)(81166006)(81156014)(8676002)(66574012)(6506007)(53546011)(76116006)(86362001)(33656002)(966005)(91956017)(478600001); 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: epZF7liSBUgAcrZW+NtQ7uXULhzDKdQloNpA9CItYJNWhbdjzsvFWwSYyNbQ6eNCCYnrE3+T4qZl1oPZ1FLB0CeqtA/Cgz3Dg0yl6CdnseEE0pxCWWJR1i/lxo2FWtQw/ynAI1eKVtF9X92X/CYfYnBcn2R5cNgAJ/haugSuA1TBvGlnjBTtf06s0/0mgowCuj2FvOUM78DRUAKc7mKioJCHi1WQ7MMNQ3Xd9ErMiTHSrCYFgnpVRlpxWLL6jBobElSjw74TXdIOHGmhejV2Fx4t6nnpfhAwjbKpiQmCX3PGBciHroFwUNuz/EPnYaH7x/ryC0c4kNXiR3y7PU3qapPFhdHf1Sm1pd4ayn9gQcFRs3u//70SnI38asETT6nrlet7Q17ay+M5S9HJJuPg5BUslJC40N1Zj8Ey0S9YdV/9+y9hM8OGwg1RYu76HzDEDPs+XOQOtuz+hreVu/9obY/Snh/5HWMBaynoAQy3boYTNxcl3HqGN2IxoP5rPeGwJmsRLb9rSKPYWBqSvvO4JQ==
x-ms-exchange-antispam-messagedata: Pl88GXDVuxL9cht7kdxvkc6penGc9lGfGvwLS+OMK4dKg0ZS1hFpEAoSRMMosgBRLe1fkag6xS96ddncsM83kXpI8ZQDzIWlMGTLsM8gZczyho3IlMRQc6aDnxqrmR3iLAivvegXorkeN/uU0cQCYg==
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: qHvhZx54DHd0D4utP4hoqx7INshO0Tph851NnZePQUXZYRDVL/5bIQe6j445Uvv9SlMoc2uHCMBb2ZsworjNHw==
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
- [nfsv4] NFS over TLS for floating clients Rick Macklem
- Re: [nfsv4] NFS over TLS for floating clients Chuck Lever
- Re: [nfsv4] NFS over TLS for floating clients Mkrtchyan, Tigran
- Re: [nfsv4] NFS over TLS for floating clients Trond Myklebust
- Re: [nfsv4] NFS over TLS for floating clients Trond Myklebust
- Re: [nfsv4] NFS over TLS for floating clients Rick Macklem
- Re: [nfsv4] NFS over TLS for floating clients Rick Macklem
- Re: [nfsv4] NFS over TLS for floating clients Rick Macklem
- Re: [nfsv4] NFS over TLS for floating clients Mkrtchyan, Tigran
- Re: [nfsv4] NFS over TLS for floating clients Benjamin Kaduk
- Re: [nfsv4] NFS over TLS for floating clients Rick Macklem
- Re: [nfsv4] NFS over TLS for floating clients Chuck Lever
- Re: [nfsv4] NFS over TLS for floating clients Benjamin Kaduk
- Re: [nfsv4] NFS over TLS for floating clients Rick Macklem
- Re: [nfsv4] NFS over TLS for floating clients Rick Macklem
- Re: [nfsv4] NFS over TLS for floating clients Chuck Lever
- Re: [nfsv4] NFS over TLS for floating clients Chuck Lever
- Re: [nfsv4] NFS over TLS for floating clients Benjamin Kaduk