From owner-freebsd-current@freebsd.org Wed Mar 4 07:26:07 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 45323267A56 for ; Wed, 4 Mar 2020 07:26:07 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48XQR16bWCz46cs for ; Wed, 4 Mar 2020 07:26:05 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 0247QUGV047765 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 3 Mar 2020 23:26:36 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 In-Reply-To: <20200304.133515.520383339344620673.hrs@FreeBSD.org> From: Chris Reply-To: bsd-lists@BSDforge.com To: Subject: Re: TLS certificates for NFS-over-TLS floating client Date: Tue, 03 Mar 2020 23:26:36 -0800 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 48XQR16bWCz46cs X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of bsd-lists@BSDforge.com has no SPF policy when checking 24.113.41.81) smtp.mailfrom=bsd-lists@BSDforge.com X-Spamd-Result: default: False [-0.34 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[bsd-lists@BSDforge.com]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; IP_SCORE(-0.27)[ip: (-0.50), ipnet: 24.113.0.0/16(-0.25), asn: 11404(-0.57), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; NEURAL_SPAM_MEDIUM(0.02)[0.020,0]; DMARC_NA(0.00)[BSDforge.com]; REPLYTO_ADDR_EQ_FROM(0.00)[]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(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 07:26:07 -0000 On Wed, 04 Mar 2020 13:35:15 +0900 (JST) Hiroki Sato hrs@FreeBSD=2Eorg said > Rick Macklem wrote > in > : >=20 > 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=2E=2E=2E > rm> /home -tls -network 192=2E168=2E1=2E0 -mask 255=2E255=2E255=2E0 > rm> /home -tlscert > rm> > rm> This syntax isn't implemented yet, but the thinking is that clients o= n > the > rm> 192=2E168=2E1 subnet would use TLS, but would not require a certificate=2E > rm> For access from anywhere else, the client(s) would be required to hav= e a > rm> certificate=2E > rm> > rm> A typical client mounting from outside of the subnet might be my lapt= op, > rm> which is using wifi and has no fixed IP/DNS name=2E > rm> --> How do you create a certificate that the laptop can use, which th= e > NFS > rm> server can trust enough to allow the mount? > rm> My thinking is that a "secret" value can be put in the certificate th= at > the NFS > rm> server can check for=2E >=20 > I do not think it is a good idea to use a certificate with an > embedded secret for authentication and/or authorization=2E >=20 > 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=2E The CA cert must be put to > somewhere the NFS server can read=2E >=20 > The CA cert is secret=2E So if the NFS server can check the client > certificate by the CA certificate, it means the NFS server can > trust the client=2E I think no additional information is required=2E >=20 > 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=2E509 > attributes, of course=2E It can be just a clear text=2E >=20 > 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=2E >=20 > 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"=2E However, the server ca= n > rm> look for the "secret" in the certificate and allow the mount based on > that=2E >=20 > 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=2E This means that the admin must be a CA or trusted > authority=2E >=20 > In practice, one can generate a self-signed certificate by using > openssl(1) and use it as its CA certificate=2E He can issue > certificates signed by it for the NFS clients, and put his CA > certificate to somewhere the NFS server can read=2E >=20 > 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?) >=20 > TLS certificates do not always have (or do not need to have) a domain > name as an attribute=2E 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=2E An > example which is not supported by Let's Encrypt is a certificate for > S/MIME email encryption which has an email address=2E FWIW here's an example from the headers coming from this list=2E Received: from mx1=2Efreebsd=2Eorg (mx1=2Efreebsd=2Eorg [96=2E47=2E72=2E80]) (using TLSv1=2E3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1=2Efreebsd=2Eorg", Issuer "Let's Encrypt Authority X3" (veri= fied OK)) by mx2=2Efreebsd=2Eorg (Postfix) with ESMTPS id 1B07B7E9A8; Wed, 4 Mar 2020 04:37:12 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd=2Eorg) Not sure if it would help with your intent here=2E But there it is=2E :) --Chris >=20 > -- Hiroki