From owner-freebsd-current@freebsd.org Thu Mar 19 02:09:14 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 8846C275F01 for ; Thu, 19 Mar 2020 02:09:14 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670075.outbound.protection.outlook.com [40.107.67.75]) (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 48jVhR36nsz3Kqx; Thu, 19 Mar 2020 02:09:10 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UpOd1z79cFkXDtjnfIeW/3XYNEwgA0qhxyz6mtdJid5rjo8LJ/tfrutJO749C72hRZD1tu34aCyxcQNmgNCXnKaNd/RTMdUNbFFwnF7Rt5u9MeJdaSwPhBWPggdzY0n7y4ASSFqG+aw1OeilLhmX9JHQjIO/MtwiDxTikXXBpH/qqDKLFCNuDTs9PRR21fPzigt3BHVa7ZIpM9t8VsBjSZkMfbeUsuhBfnTlEq6NaVhmO0tYUisuf9P5gOWM5WU8f3iP1ZyHhQAq0XquDrXWxBp9XQAsy/6u3XexsKyzdu6jaaD2w8WKI+/fr3I43U0iC0pt9ZzPI6H9WbbpcXVylg== 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=7Wi2Tbn4iZCdrcyxpYPlf7stG1SfRIV9ueNJucZHQTo=; b=nxzTjfuqQGobZmDqoUsM9x1v645R+ZUi1qk8xyBMqSUAu28zVcxLH3uaK1OKxteOj+ITmL8iOlagAt5rNrR09rkzZRlBVA1LnO7VySbMyjHMJCMcevLRWTr4lVgAnye6P7B7aKuUfev9kiSLK+9jvVhVxBYFAscs98BY8if6Gri1GYUl/XtMgMIpA0Y1IGnzZLYjyxe3DsZKd4DFzjr57LCltyuEokKmIemsmyr+GMCkLe9jXgbbHyBoJFGkpWlCp9zKnU5BmRHZVNqsVjgHkYICmJFCV73nJW8lrF3njO2kVI/3pCc53WnlCLjUPAMe1ZaxnJlZnmLsLfGHIIOFFw== 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 YTBPR01MB2559.CANPRD01.PROD.OUTLOOK.COM (10.255.46.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.22; Thu, 19 Mar 2020 02:09:09 +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.2814.025; Thu, 19 Mar 2020 02:09:09 +0000 From: Rick Macklem To: Miroslav Lachman <000.fbsd@quip.cz>, Hiroki Sato CC: "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: AQHV8dDjD29GK4BL2kGnxfg+gW2rAag32PeAgABluQCAFwCY9g== Date: Thu, 19 Mar 2020 02:09:08 +0000 Message-ID: References: <20200304.133515.520383339344620673.hrs@FreeBSD.org>, 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: 139250ad-a962-4dec-f77f-08d7cbaa827f x-ms-traffictypediagnostic: YTBPR01MB2559: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0347410860 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(376002)(396003)(39860400002)(366004)(199004)(478600001)(110136005)(2906002)(786003)(86362001)(4326008)(316002)(33656002)(71200400001)(966005)(8936002)(9686003)(6506007)(55016002)(66476007)(66556008)(81156014)(52536014)(186003)(76116006)(8676002)(66446008)(64756008)(66946007)(5660300002)(7696005)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:YTBPR01MB2559; H:YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; 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: Uo2zMy+aoJWOH9ttVkWNpzevgigI5B4w9iJwtZbz7EJCmFTFzu27rXX83yykkmFKr7xZbDKFe6Ln7iJPBSOMXuUNmuSx96haRXBeb5vOpmnQF5fnXjuvpgmDC06VJmiV4CkI9sI7EbExAVFkF5hdxkWhEMWoMZznK/n/tzFfa4GsaBQgyuzpzrgIIOb+61YiyGmnXchVizK0DLcf8coHHPuSIM8yt4AQPzrPfTiYCWIq9+JgiyXzoH6Layh1Q8wz9miGKACLCViHR2ro8G6czZaS+cdkR6pn9UGMfzYM2hjvldADwn3bjCv+iuMMv4vdxsPHAyafnKENUCuhPKqPujtxtOyqSQJ56QeQsj9Z7zlJk7GR7OUr+C7djgJo/2xJC03yOhtmNATvoanwCHVc3aRwx+mUgomp/oSu1QY2sQoihJxLyld8WlhxkuPPCAK317n4q0p5JwGeHh6KHgmcoK6D/oli5E1bgpajPHknf+2SLQK9bj0SeC1l3s3S0xfFvOdMOunCY7Ttch1xGNGBkA== x-ms-exchange-antispam-messagedata: 3TVb+2MIM8TM6qyko0622PhmZPHjM0ZKCuz7CgEVOcZawPiGPE/NO7qNfhrFsr4vLWH1m9S9NCjQmQlT+jgv7uth7s4P6v5LglG93zeSOm+bU/MPyeLZ7DaeIAp+NBH/OgHYOdeNJXx8dcS0DXPwbeao4O6Fnqhj2FpTapT7OTE8JVgZpLExWFR+YRZOw67jK/u2k+pnMdAotyz6nC30Rg== 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: 139250ad-a962-4dec-f77f-08d7cbaa827f X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2020 02:09:08.9418 (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: lyk7/FHNGZp1FrOwEZip6/r1ZvTgZyA/Fp+WY+XIfLO3jojTTO1be1Pipey5oQI6CO/2ffTyAEZZlkvN6bAAbA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB2559 X-Rspamd-Queue-Id: 48jVhR36nsz3Kqx X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.75 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.67 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.989,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; 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)[]; RCVD_IN_DNSWL_NONE(0.00)[75.67.107.40.list.dnswl.org : 127.0.3.0]; IP_SCORE(-1.38)[ipnet: 40.64.0.0/10(-3.75), asn: 8075(-3.10), 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:40.64.0.0/10, 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, 19 Mar 2020 02:09:14 -0000 Miroslav Lachman wrote:=0A= >Hiroki Sato wrote on 2020/03/04 05:35:=0A= >=0A= [...]=0A= >=0A= >> I do not think it is a good idea to use a certificate with an=0A= >> embedded secret for authentication and/or authorization.=0A= >>=0A= >> In the case that the client offers a certificate upon establishing a= =0A= >> TLS connection for authentication purpose, the authenticity will be=0A= >> checked on the server usually by using the CA certificate which was=0A= >> used to issue the client certificate. The CA cert must be put to=0A= >> somewhere the NFS server can read.=0A= >>=0A= >> The CA cert is secret. So if the NFS server can check the client=0A= >> certificate by the CA certificate, it means the NFS server can=0A= >> trust the client. I think no additional information is required.=0A= >=0A= >NFS (or any other server) should check list of revoked certificates too.= =0A= >Otherwise you will not be able to deny access to user which you no=0A= >longer want to have an access.=0A= Yes, good point.=0A= I won't claim to understand this stuff, but from what I can see, all that i= s=0A= done is the CRL is appended to the CAfile (the one with the CA certificates= =0A= are in being used for certificate verification via SSL__CTX_load_verify_loc= ations().=0A= (https://raymii.org/s/articles/OpenSSL_manually_verify_a_certificate_agains= t_a_CRL.html=0A= shows a CAfile and CRLfile being concatenated and then used to verify a cer= tificate.)=0A= =0A= There is code in sendmail that loads a CRL file separately, but it seems to= =0A= just put it in the X509 store returned by SSL_CTX_get_cert_store(), which= =0A= is the one where the CAfile certificates are stored via SSL_CTX_load_verify= _locations(),=0A= I think?=0A= (It just seems easier to append it to CAfile than do this. The sendmail cod= e uses=0A= poorly documented functions where the man page says=0A= "SSL_CTX_load_verify_locations()" normally takes care of this.)=0A= =0A= Does this sound right? rick=0A= =0A= > Authorization such as which mount point can be mounted by using the=0A= > client cert can be implemented by using the CN field or other X.509=0A= > attributes, of course. It can be just a clear text.=0A= >=0A= > I think this is one of the most reliable and straightforward ways=0A= > because in most cases both NFS servers and the clients are under the=0A= > sysadmin's control.=0A= >=0A= > rm> Now, I'm not sure, but I don't think this certificate can be created = via=0A= > rm> a trust authority such that it would "verify". However, the server ca= n=0A= > rm> look for the "secret" in the certificate and allow the mount based on= that.=0A= >=0A= > In the way described above, to use TLS client authentication, the NFS= =0A= > server admin has to have a certificate which allows to sign another=0A= > certificate. This means that the admin must be a CA or trusted=0A= > authority.=0A= >=0A= > In practice, one can generate a self-signed certificate by using=0A= > openssl(1) and use it as its CA certificate. He can issue=0A= > certificates signed by it for the NFS clients, and put his CA=0A= > certificate to somewhere the NFS server can read.=0A= =0A= Take a look on easy-rsa=0A= https://www.freshports.org/security/easy-rsa/=0A= =0A= It is used for example by OpenVPN to create private CA and sign=0A= certificates of clients. It is good starting point to understand what=0A= and how can work.=0A= =0A= > rm> Also, even if the NFS client/server have fixed IP addresses with well= known=0A= > rm> DNS names, it isn't obvious to me how signed certificates can be acqu= ired=0A= > rm> for them?=0A= > rm> (Lets Encrypt expects the Acme protocol to work and that seems to be= =0A= > rm> web site/http specific?)=0A= >=0A= > TLS certificates do not always have (or do not need to have) a domain= =0A= > name as an attribute. Data in attributes are restricted depending on= =0A= > the purpose, so certificates issued by Let's Encrypt can have only=0A= > domain names (CN or Subject Alternative Name), for example. An=0A= > example which is not supported by Let's Encrypt is a certificate for=0A= > S/MIME email encryption which has an email address.=0A= =0A= Kind regards=0A= Miroslav Lachman=0A=