From owner-freebsd-current@freebsd.org Thu Mar 26 14:59:51 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 6D1D52A2107 for ; Thu, 26 Mar 2020 14:59:51 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-qb1can01on0615.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5c::615]) (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 48p7S65hcNz4B58 for ; Thu, 26 Mar 2020 14:59:33 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L5CRIg1K9ZJoPENUojJgXkrRr47nBb/cWVeq5eZDg6AHss9tUOJMLkljaixEtCnq06KjBkDCn206NS5LGX761fMRrXaMtsu7OPYJp6eJi34K1894x4bWnQZUTBrJlnHrnPpJ1Slahyu39rZXnAGR+hcbFdn8vqu7CTTXdvqhaT8i3ii8cX3DyOD04zG9qshSgStHNXY8q9VUbmCNHq/MBIssWHCzrY84uFomGhTT3u4157No0nHYvgbfWcJe3Slxg0em5mQ7BvQGroYN0BifQhEq3GzutahR5OnEc8DeueNDxewdo7b6dWHw7cgwJLWth19Ag+RXAih2jPBbkAS7ww== 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=WHr9/5q9MecWUlYDByf5hORcPrdQdpARlFlIhZJ/ldA=; b=mA6Of/A6zW1AvztYxGj2aOUhvkHo/b0Pl2O4fn3t9xa1i7fSkdqMblORrbTajr1qOupfru4V6nHD8ziS0/r6PONj0XaIJgXIuDt3+9Dw1Vof9nzA/YczvYTrSnzX/AIwRNzJMNdaZFHgJnGuf9Oo6FT97uHYXV/go7NKVu2TM+Y4zLZI3z7e9lYm6XfjPdF2WFvyeYq4/hC7OLjK/0hdt/9wRztK9c679zoM0Ky6a13j3odOgPx/ibnvZ25G+chrzIiebthD7G5HcS9k6FB6ybmDHE095Mh73ifUn3QA/ryuN+qXUAPCUppSZzT7EFCI/2nVe745OGiGLFobb77rug== 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 QB1PR01MB3539.CANPRD01.PROD.OUTLOOK.COM (52.132.89.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.19; Thu, 26 Mar 2020 14:59:23 +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:59:23 +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+s2AABatAIAA3gv9gAANKB0= Date: Thu, 26 Mar 2020 14:59:23 +0000 Message-ID: References: <20200325231005.GQ4213@funkthat.com> , <20200326004154.GT4213@funkthat.com>, In-Reply-To: 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: 8e3e5248-fd07-487e-fd16-08d7d1964547 x-ms-traffictypediagnostic: QB1PR01MB3539: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0354B4BED2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(396003)(136003)(366004)(53546011)(6506007)(7696005)(66946007)(66556008)(64756008)(66446008)(316002)(478600001)(786003)(86362001)(66476007)(52536014)(5660300002)(966005)(76116006)(2906002)(54906003)(55016002)(9686003)(33656002)(71200400001)(8936002)(186003)(81156014)(4326008)(8676002)(2940100002)(81166006)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:QB1PR01MB3539; 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: DJujv0Ay7n+Y1RlOTKQls5i4h1uF5eahnrrHKTm5GgnQM+2DKloUI3Va61JboAHyRAh9a9G/a2DsZUVTEBf2ckQkmpxDGNnLQMfIKfPXFMQXF9cZDzJPEEzLjq7HMp8YcsPAFVuKJRiW9liT9ghZLtjJri59/THUVXg6HhlXlg8poUpdvlDCvBWiok5qWK65I1aNbisCE6iiBFYmDBShMVuHIeKfuYFSzwcKoY3BLZawI2Gl6Ugez8kU2rw1C4Of4lOfSBcHC3Q61Q9Z8gBCCUAdXkx7yrTmOgMtC+GfeqhK0zFQDqLsH9neBchU9L/fl4AGLvTjazmnsjA3SdCiTMvKl21d5g2Z7gPV+sIX8MyBcWyZ69NekiKBEiAP/aOa/yDbYwHhK4t3jyJ35P8anUxmsAKZfkThotqmL574uhMtNvuyWRPp/qjjmTtH7rQaWmwnj4GQ1fGSH33xV49ROSRMFuwpFrVlj+nvnc6BROlUcxMs15t0FzfUShQzOWs5+jo3ipHthFCSNkntNb65oA== x-ms-exchange-antispam-messagedata: btFADF+Y1rgKz1bqx1aObjfSKWYPPkkulsxMia8KcUGXYExXkX7rhPUtCDRZAThZZctmx9KwqMZkqDeMiciCMfiI+XHKeYRqJM2QP8y4bovqVDDI7ltSMvSBUkHoHxfvfwL3YfZ7FI0qHtrqNxXQL2hmDEXsH/mZPajlQSOg80zFCsTmZ+CBSC9krWyoTUo1QCX94T/Xh8b8BxBKQzIA/A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 8e3e5248-fd07-487e-fd16-08d7d1964547 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2020 14:59:23.3150 (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: hn32F78Vpsb0mMt1AD85to7aV7yrusZDeURGYUv7wMWvjcvXJn//GLZGBHbE0htcvUL6KuBVrxErbo9mZUbPlw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB3539 X-Rspamd-Queue-Id: 48p7S65hcNz4B58 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::615 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]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[uoguelph.ca]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; 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:59:51 -0000 Sorry about the top post, but I thought of a few things to add to my last post to this thread... 1 - I agree that for systems like laptops, the line between machine and user authentication is fuzzy. 2 - I do like your idea of having an exports(5) option that specifies a CN that identifies a user and then does all RPCs as that user. I'm not sure if an issuer needs to be specified (or even can be speci= fied), since the CAfile argument to the rpctlssd daemon determines if a cert= ificate from a particular CA will verify and the verification must happen bef= ore the exports(5) export options can be applied. (Basically, certificate ver= ification happens via a NULL RPC that does a STARTTLS when a TCP connection to the server is first established.) 3 - I'll post to nfsv4@ietf.org to see what others think of this, since it = would not require any changes to the draft/RFC. 4 - Although it does require a revision to the export_args structure, I thi= nk it is worth doing even if others don't implement it. Again, thanks for your comments, rick ________________________________________ From: owner-freebsd-current@freebsd.org = on behalf of Rick Macklem Sent: Thursday, March 26, 2020 10:33 AM To: John-Mark Gurney Cc: Alexander Leidinger; freebsd-current@FreeBSD.org Subject: Re: TLS certificates for NFS-over-TLS floating client John-Mark Gurney wrote: [lots of stuff snipped] >Rick Macklem wrote: >> I had originally planned on some "secret" in the certificate (like a CN = name >> that satisfies some regular expression or ???) but others convinced me t= hat >> that wouldn't provide anything beyond knowing that the certificate was >> signed by the appropriate CA, so I have not implemented anything. > >Yeah, having a "secret" in the CN doesn't make sense, but what does make >sense is allowing the exports line to specify what the CN should contain >to be authenticated... > >Say as a corp, you issue personal certificates to everyone. This is >because you require everyone to sign and/or encrypt their email w/ >S/MIME. Each cert includes the email address of that person, so you >could simply do something like: >/home/alice -tlscert -tlsroot /etc/company.pem -email alice@example.com > >And anyone who has the certificate w/ alice@example.com that was signed >by the public key in /etc/company.pem would be granted access to the >export /home/alice. > >If it allowed ANY cert signed by the CA specified, then that introduces >an authentication problem, as now if Malory is a coworker of Alice >could also access Alice's home directory... > >IMO, this is one auth feature that MUST be supported... The draft does not address user authentication, only machine authentication= . --> ie. The certificate is used to decide if a system can do a mount. Users are still identified via user credentials in the RPC message he= ader. For AUTH_SYS, that still means . Otherwise, you need to use Kerberos (sec=3Dkrb5[ip]). You could use "tls,sec=3Dkrb5" for a mount, but the only advantage th= at might have over "sec=3Dkrb5p" is performance, if there is hardware as= sist for TLS or something like that. >Now that I reread your comments, it sounds like any certificate would be >allowed in #2 as long as it is valid, and that would only be marginally >better than verification by IP, and in some ways worse, in that now any >user could pretend to be any other user, or you have to do something >crazy like have a CA per user. The case where I see #2 is useful is where this discussion started some wee= ks ago. The example I started with was: /home -tls -network 192.168.1.0 -mask 255.255.255.0 /home -tlscert This says that machines on the local lan can mount and do not need to have certificates, but must use TLS so data is encrypted on the wire. Mounts from anywhere else (presumably laptops) are allowed so long as they = have a certificate signed by me (as in the site local CA). I trust these machines enough that I am willing to allow them to use AUTH_S= YS, which is what 99.9...% of NFS mounts do now. (So, I'd agree that the site local certificate is not a lot better than IP = address for client machine identity, just that it is an alternative that can be us= eful. Without TLS, a line like "/home" allows anyone to mount /home from anywher= e and I think you'd agree that few NFS admins. will want to do that. I'm ass= uming no external firewall for this example.) Now, your suggestion of identifying a user via the CN and then having the server do all RPCs for the mount as that user is an interesting one. My concern w.r.t. implementing it would be interoperability. Put another way, if other servers such as Linux, Netapp,... don't adopt it (and they won't until there is a draft/RFC specifying it), it would be FreeBSD server specific and I'd like to avoid that. There was some discussion w.r.t. user authentication via certificates during development of the draft, but they decided to defer that work for now, so they could get something in place for machine authentication first. (If I understood the discussion on nfsv4@ietf.org.) rick >I'm wonder if your use of the term secret was the problem, and not the >idea... Anything that goes in the client cert is by definition public... >TLS prior to 1.3 sends the client cert in clear text... But keying >based upon the contents of the cert is fine, as that's the point of >what a cert is.. It's trusting the CA to say that the CN and other >fields in the cert corresponds to this user, and you can use parts of >the cert, like the CN to decide which user the public key in the cert >corresponds to. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"