From owner-freebsd-current@freebsd.org Wed Mar 4 10:39:28 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 546AC26B2DC for ; Wed, 4 Mar 2020 10:39:28 +0000 (UTC) (envelope-from SRS0=Wgu4=4V=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48XVk63jjNz4CZJ; Wed, 4 Mar 2020 10:39:26 +0000 (UTC) (envelope-from SRS0=Wgu4=4V=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 1EDD028429; Wed, 4 Mar 2020 11:39:23 +0100 (CET) Received: from illbsd.quip.test (ip-62-24-92-232.net.upcbroadband.cz [62.24.92.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id B9D1D28417; Wed, 4 Mar 2020 11:39:20 +0100 (CET) Subject: Re: TLS certificates for NFS-over-TLS floating client To: Hiroki Sato , rmacklem@uoguelph.ca Cc: freebsd-current@FreeBSD.org References: <20200304.133515.520383339344620673.hrs@FreeBSD.org> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: Date: Wed, 4 Mar 2020 11:39:20 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <20200304.133515.520383339344620673.hrs@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 48XVk63jjNz4CZJ X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of SRS0=Wgu4=4V=quip.cz=000.fbsd@elsa.codelab.cz has no SPF policy when checking 94.124.105.4) smtp.mailfrom=SRS0=Wgu4=4V=quip.cz=000.fbsd@elsa.codelab.cz X-Spamd-Result: default: False [3.76 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; IP_SCORE(0.84)[ip: (0.30), ipnet: 94.124.104.0/21(0.15), asn: 42000(3.64), country: CZ(0.09)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[quip.cz]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.72)[0.722,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.999,0]; RCVD_IN_DNSWL_NONE(0.00)[4.105.124.94.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=Wgu4=4V=quip.cz=000.fbsd@elsa.codelab.cz]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=Wgu4=4V=quip.cz=000.fbsd@elsa.codelab.cz]; MID_RHS_MATCH_FROM(0.00)[] 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: Wed, 04 Mar 2020 10:39:28 -0000 Hiroki Sato wrote on 2020/03/04 05:35: [...] > I do not think it is a good idea to use a certificate with an > embedded secret for authentication and/or authorization. > > In the case that the client offers a certificate upon establishing a > TLS connection for authentication purpose, the authenticity will be > checked on the server usually by using the CA certificate which was > used to issue the client certificate. The CA cert must be put to > somewhere the NFS server can read. > > The CA cert is secret. So if the NFS server can check the client > certificate by the CA certificate, it means the NFS server can > trust the client. I think no additional information is required. NFS (or any other server) should check list of revoked certificates too. Otherwise you will not be able to deny access to user which you no longer want to have an access. > Authorization such as which mount point can be mounted by using the > client cert can be implemented by using the CN field or other X.509 > attributes, of course. It can be just a clear text. > > I think this is one of the most reliable and straightforward ways > because in most cases both NFS servers and the clients are under the > sysadmin's control. > > rm> Now, I'm not sure, but I don't think this certificate can be created via > rm> a trust authority such that it would "verify". However, the server can > rm> look for the "secret" in the certificate and allow the mount based on that. > > In the way described above, to use TLS client authentication, the NFS > server admin has to have a certificate which allows to sign another > certificate. This means that the admin must be a CA or trusted > authority. > > In practice, one can generate a self-signed certificate by using > openssl(1) and use it as its CA certificate. He can issue > certificates signed by it for the NFS clients, and put his CA > certificate to somewhere the NFS server can read. Take a look on easy-rsa https://www.freshports.org/security/easy-rsa/ It is used for example by OpenVPN to create private CA and sign certificates of clients. It is good starting point to understand what and how can work. > rm> Also, even if the NFS client/server have fixed IP addresses with well known > rm> DNS names, it isn't obvious to me how signed certificates can be acquired > rm> for them? > rm> (Lets Encrypt expects the Acme protocol to work and that seems to be > rm> web site/http specific?) > > TLS certificates do not always have (or do not need to have) a domain > name as an attribute. Data in attributes are restricted depending on > the purpose, so certificates issued by Let's Encrypt can have only > domain names (CN or Subject Alternative Name), for example. An > example which is not supported by Let's Encrypt is a certificate for > S/MIME email encryption which has an email address. Kind regards Miroslav Lachman