From owner-freebsd-current@freebsd.org Wed Mar 4 04:36:35 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 A0B1B26494C for ; Wed, 4 Mar 2020 04:36:35 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (mx.allbsd.org [IPv6:2001:2f0:104:e001::41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail.allbsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48XLgQ22zmz4tjR for ; Wed, 4 Mar 2020 04:36:33 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail-d.allbsd.org ([IPv6:2409:11:a740:4700:58:65ff:fe00:b0b]) (authenticated bits=56) by mail.allbsd.org (8.15.2/8.15.2) with ESMTPSA id 0244a7J7031929 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK) (Client CN "/CN=mail-d.allbsd.org", Issuer "/C=US/O=Let's+20Encrypt/CN=Let's+20Encrypt+20Authority+20X3"); Wed, 4 Mar 2020 13:36:18 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from alph.d.allbsd.org ([IPv6:2409:11:a740:4700:16:ceff:fe34:2700]) by mail-d.allbsd.org (8.15.2/8.15.2) with ESMTPS id 0244a2vR012968 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 4 Mar 2020 13:36:02 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [[UNIX: localhost]]) (authenticated bits=0) by alph.d.allbsd.org (8.15.2/8.15.2) with ESMTPA id 0244a1L2012964; Wed, 4 Mar 2020 13:36:02 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 04 Mar 2020 13:35:15 +0900 (JST) Message-Id: <20200304.133515.520383339344620673.hrs@FreeBSD.org> To: rmacklem@uoguelph.ca Cc: freebsd-current@FreeBSD.org Subject: Re: TLS certificates for NFS-over-TLS floating client From: Hiroki Sato In-Reply-To: References: X-Old-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-PGPkey-fingerprint: 6C0D 2353 27CF 80C7 901E FDD2 DBB0 7DC6 6F1F 737F X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="--Security_Multipart(Wed_Mar__4_13_35_15_2020_391)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mail.allbsd.org [IPv6:2001:2f0:104:e001:0:0:0:41]); Wed, 04 Mar 2020 13:36:24 +0900 (JST) X-Rspamd-Queue-Id: 48XLgQ22zmz4tjR X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-0.09 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_SPAM_MEDIUM(0.91)[0.912,0]; ASN(0.00)[asn:7514, ipnet:2001:2f0::/32, country:JP] 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 04:36:35 -0000 ----Security_Multipart(Wed_Mar__4_13_35_15_2020_391)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rick Macklem wrote in : rm> Hi, rm> rm> I am slowly trying to understand TLS certificates and am trying to figure rm> out how to do the following: rm> -> For an /etc/exports file with... rm> /home -tls -network 192.168.1.0 -mask 255.255.255.0 rm> /home -tlscert rm> rm> This syntax isn't implemented yet, but the thinking is that clients on the rm> 192.168.1 subnet would use TLS, but would not require a certificate. rm> For access from anywhere else, the client(s) would be required to have a rm> certificate. rm> rm> A typical client mounting from outside of the subnet might be my laptop, rm> which is using wifi and has no fixed IP/DNS name. rm> --> How do you create a certificate that the laptop can use, which the NFS rm> server can trust enough to allow the mount? rm> My thinking is that a "secret" value can be put in the certificate that the NFS rm> server can check for. 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. 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. 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. -- Hiroki ----Security_Multipart(Wed_Mar__4_13_35_15_2020_391)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iMkEABMKAC4WIQRsDSNTJ8+Ax5Ae/dLbsH3Gbx9zfwUCXl8wAxAcaHJzQGZyZWVi c2Qub3JnAAoJENuwfcZvH3N/VwECCQG+Xn5nXW9DI0aXKU7i8JZjCuwjUuxW/ir2 UCcxfZfHoA2ohytd9iQDhai1xpDUbnQUEyd+LU41wK2KU2YbISnVYwII7zQ7PERH XkCtWvkMsYGbpL+u71hr8N9zGLjFYZQ1Np0ylCXfkozbUqR+b2a4rHUyfu9qYuO4 c9OWeUJ3e9CGlUE= =XXV3 -----END PGP SIGNATURE----- ----Security_Multipart(Wed_Mar__4_13_35_15_2020_391)----