From owner-freebsd-current@freebsd.org Thu Mar 26 14:33:50 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 38AD72A181E for ; Thu, 26 Mar 2020 14:33:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-qb1can01on0631.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5c::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48p6t44y2Kz41MX for ; Thu, 26 Mar 2020 14:33:31 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HcIBzFQ4+lzAWWlFlHKzynZmLT2/OlreANIYFFhSz2YWv8Yhk7JuL7YubDUuo4N9APOFHvB+K85SOyXzzMPJR+Ad06yxbeVgvQ71nztoTH7wqusSczpZGUNpbxpp8qxlGEnF0Zc6JQTwLO2/tLEZOM8cRCXgJ8e1HeqK/GCPEpA2wukGl4zHdmmlJs764vFLva7gDJWdscu9TlOKIXv5YiaAcS17AuKye/SegEW37E71OrZ6rmg7O8X6HRtWlKtoP636CUp9ohLDenTeJ6lUMX91EtWJ2fhJB1w3CPjRu57RVD2oiszt8X8QoezqcrRFM6Zwkgt9gvECSRATbiT0tQ== 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=7SiNmBwqmmP6U/9aVBrOSKnaOYLf3MPaTGcia8U/8g0=; b=aidyeRtbvEUxnwAKDQEKBNPdYJ9uuEFjmJOuDnCR+rBdzjXx2MmkstLYIR/21UWijUnJ2hhIGpxtj5M/XsCVTY+e/ie5/kbHEeVrGJWhd5Ab8rkSgXeodyYHM9w+hroUClDaTy7m7Kbkhgy0ng1YNqK9W7hgUUMIl2Ve5XNeOBOOQdlatTvpnO6CBfGVuCNrHgK7krQHSOwuq57dVOi95YrtZc68MU8q5NVYI0wk/BDpdxV2XcOgo848hcOSf5lYZbSPa0QTnrXU3nZclvZOHKxp12RQGLOzRN1kbbNlpuuxPJy63uA1691gvGIEmBPUOZnG7Aq0cWOy1/gk2YJd3g== 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 QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM (52.132.86.26) by QB1PR01MB3940.CANPRD01.PROD.OUTLOOK.COM (52.132.88.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Thu, 26 Mar 2020 14:33:19 +0000 Received: from QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM ([fe80::ed8c:7662:79ba:5f9f]) by QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM ([fe80::ed8c:7662:79ba:5f9f%5]) with mapi id 15.20.2835.023; Thu, 26 Mar 2020 14:33:12 +0000 From: Rick Macklem To: John-Mark Gurney CC: Alexander Leidinger , "freebsd-current@FreeBSD.org" Subject: Re: TLS certificates for NFS-over-TLS floating client Thread-Topic: TLS certificates for NFS-over-TLS floating client Thread-Index: AQHWAWnI+UIiEJS9mke8ubtYdFBhy6hZ8jaAgAAC+s2AABatAIAA3gv9 Date: Thu, 26 Mar 2020 14:33:12 +0000 Message-ID: References: <20200325231005.GQ4213@funkthat.com> , <20200326004154.GT4213@funkthat.com> In-Reply-To: <20200326004154.GT4213@funkthat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4b50e2cc-8b93-40ba-2100-08d7d1929d07 x-ms-traffictypediagnostic: QB1PR01MB3940: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0354B4BED2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39850400004)(396003)(376002)(366004)(346002)(6506007)(8676002)(5660300002)(55016002)(52536014)(9686003)(33656002)(2906002)(81156014)(786003)(7696005)(316002)(6916009)(186003)(71200400001)(478600001)(86362001)(81166006)(8936002)(76116006)(66946007)(64756008)(66476007)(66446008)(66556008)(54906003)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:QB1PR01MB3940; H:QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; 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: UYRWUQBPzMPpbFwFj+0NVGz6gRNzRu3/ULAcKtJtgUcxCSXk1JoYK2Jjh9ovYMtpGYPhfjQP7dXwOBekt/qmgIMjYhBkQWxeXGJ5h+9XOoIl9LwKAY0O29pBzRn+w5OHCaD8MU3mhLpNOpA4WjwuyogEeLxUnDyjK9Xve74UrD56LNTOb8RrrEKmkk5/kVrF5WemHiECxyqbQM1pjJsYtQ2BQc2i/krNApfndIyZNIdZovkoEy4XtgE82ktz5/hYdugUeDiXI8sB5HEnPDMEJuUU5nNtZ3OeAPJmFkx/WVI3/s/psprURa8X0smbFsynIeFV3Mxoq+EGabVa+wGPaRpZNll9ZY2cme7ziyZ2/TgXhUSY0oPClgYAO8B8zWGVvYFQkwhvtvOKEj58Qe4pgPyNRO6dfsQ/pBmu6oDzbXA2oRYxKuvS2G3bWdB3WSJ1 x-ms-exchange-antispam-messagedata: 8zZTycvRKHobnRMuH9Y7ZMQxZCSKtcrDLmz04mWo7YzJ1FM8vDR+yAZ9i3MDrvYZ5mRNjtBRNxp7SOQ6TwtgefPrqw2jB0mWyzcokZI+AVbpw+l1EC9KtI81qeVxPoM0BCg6anxjMML8LeMfwXT9pGFd2UThSWcI06L2yijqUKE/xt6nqWStJCTFL3+AU1ebXvRB0frMAmVacaT1SpXCFw== 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: 4b50e2cc-8b93-40ba-2100-08d7d1929d07 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2020 14:33:12.5265 (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: TGNUJVbq4f+QKktugZ9AiAjviS79I8g2no3z8SixFX/g26qgQH1KfM6uBi3/MHnySx1fQva/6ayeF5oSxeZbdA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB3940 X-Rspamd-Queue-Id: 48p6t44y2Kz41MX X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 2a01:111:f400:fe5c::631 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.74 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[uoguelph.ca]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-1.44)[ipnet: 2a01:111:f000::/36(-4.03), asn: 8075(-3.13), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; ARC_ALLOW(-1.00)[i=1] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 14:33:50 -0000 John-Mark Gurney wrote:=0A= [lots of stuff snipped]=0A= >Rick Macklem wrote:=0A= >> I had originally planned on some "secret" in the certificate (like a CN = name=0A= >> that satisfies some regular expression or ???) but others convinced me t= hat=0A= >> that wouldn't provide anything beyond knowing that the certificate was= =0A= >> signed by the appropriate CA, so I have not implemented anything.=0A= >=0A= >Yeah, having a "secret" in the CN doesn't make sense, but what does make= =0A= >sense is allowing the exports line to specify what the CN should contain= =0A= >to be authenticated...=0A= >=0A= >Say as a corp, you issue personal certificates to everyone. This is=0A= >because you require everyone to sign and/or encrypt their email w/=0A= >S/MIME. Each cert includes the email address of that person, so you=0A= >could simply do something like:=0A= >/home/alice -tlscert -tlsroot /etc/company.pem -email alice@example.com=0A= >=0A= >And anyone who has the certificate w/ alice@example.com that was signed=0A= >by the public key in /etc/company.pem would be granted access to the=0A= >export /home/alice.=0A= >=0A= >If it allowed ANY cert signed by the CA specified, then that introduces=0A= >an authentication problem, as now if Malory is a coworker of Alice=0A= >could also access Alice's home directory...=0A= >=0A= >IMO, this is one auth feature that MUST be supported...=0A= The draft does not address user authentication, only machine authentication= .=0A= --> ie. The certificate is used to decide if a system can do a mount.=0A= Users are still identified via user credentials in the RPC message he= ader.=0A= For AUTH_SYS, that still means .=0A= Otherwise, you need to use Kerberos (sec=3Dkrb5[ip]).=0A= You could use "tls,sec=3Dkrb5" for a mount, but the only advantage th= at=0A= might have over "sec=3Dkrb5p" is performance, if there is hardware as= sist=0A= for TLS or something like that.=0A= =0A= >Now that I reread your comments, it sounds like any certificate would be= =0A= >allowed in #2 as long as it is valid, and that would only be marginally=0A= >better than verification by IP, and in some ways worse, in that now any=0A= >user could pretend to be any other user, or you have to do something=0A= >crazy like have a CA per user.=0A= The case where I see #2 is useful is where this discussion started some wee= ks ago.=0A= The example I started with was:=0A= /home -tls -network 192.168.1.0 -mask 255.255.255.0=0A= /home -tlscert=0A= =0A= This says that machines on the local lan can mount and do not need to have= =0A= certificates, but must use TLS so data is encrypted on the wire.=0A= Mounts from anywhere else (presumably laptops) are allowed so long as they = have a=0A= certificate signed by me (as in the site local CA).=0A= I trust these machines enough that I am willing to allow them to use AUTH_S= YS,=0A= which is what 99.9...% of NFS mounts do now.=0A= (So, I'd agree that the site local certificate is not a lot better than IP = address=0A= for client machine identity, just that it is an alternative that can be us= eful.=0A= Without TLS, a line like "/home" allows anyone to mount /home from anywher= e=0A= and I think you'd agree that few NFS admins. will want to do that. I'm ass= uming=0A= no external firewall for this example.)=0A= =0A= Now, your suggestion of identifying a user via the CN and then having the= =0A= server do all RPCs for the mount as that user is an interesting one.=0A= My concern w.r.t. implementing it would be interoperability.=0A= Put another way, if other servers such as Linux, Netapp,... don't adopt it= =0A= (and they won't until there is a draft/RFC specifying it), it would be=0A= FreeBSD server specific and I'd like to avoid that.=0A= There was some discussion w.r.t. user authentication via certificates=0A= during development of the draft, but they decided to defer that work for=0A= now, so they could get something in place for machine authentication first.= =0A= (If I understood the discussion on nfsv4@ietf.org.)=0A= =0A= rick=0A= =0A= >I'm wonder if your use of the term secret was the problem, and not the=0A= >idea... Anything that goes in the client cert is by definition public...= =0A= >TLS prior to 1.3 sends the client cert in clear text... But keying=0A= >based upon the contents of the cert is fine, as that's the point of=0A= >what a cert is.. It's trusting the CA to say that the CN and other=0A= >fields in the cert corresponds to this user, and you can use parts of=0A= >the cert, like the CN to decide which user the public key in the cert=0A= >corresponds to.=0A= =0A= --=0A= John-Mark Gurney Voice: +1 415 225 5579=0A= =0A= "All that I will do, has been done, All that I have, has not."=0A=