From owner-freebsd-current@freebsd.org Wed Mar 4 03:22:41 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 B670A262F3D for ; Wed, 4 Mar 2020 03:22:41 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 48XK280W9pz4XL0 for ; Wed, 4 Mar 2020 03:22:39 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0243MYUA014725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 3 Mar 2020 22:22:36 -0500 Date: Tue, 3 Mar 2020 19:22:34 -0800 From: Benjamin Kaduk To: Rick Macklem Cc: "freebsd-current@FreeBSD.org" Subject: Re: TLS certificates for NFS-over-TLS floating client Message-ID: <20200304032234.GY98042@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-Rspamd-Queue-Id: 48XK280W9pz4XL0 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of kaduk@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=kaduk@mit.edu X-Spamd-Result: default: False [-5.40 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[mit.edu]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[11.28.9.18.list.dnswl.org : 127.0.11.2]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-2.90)[ip: (-9.63), ipnet: 18.9.0.0/16(-4.78), asn: 3(-0.03), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2] 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 03:22:41 -0000 On Wed, Mar 04, 2020 at 03:15:48AM +0000, Rick Macklem wrote: > Hi, > > I am slowly trying to understand TLS certificates and am trying to figure > out how to do the following: > -> For an /etc/exports file with... > /home -tls -network 192.168.1.0 -mask 255.255.255.0 > /home -tlscert > > This syntax isn't implemented yet, but the thinking is that clients on the > 192.168.1 subnet would use TLS, but would not require a certificate. > For access from anywhere else, the client(s) would be required to have a > certificate. My gut reaction: that doesn't sound like a good idea. Trusting the local network to be secure is pretty risky, in general. > A typical client mounting from outside of the subnet might be my laptop, > which is using wifi and has no fixed IP/DNS name. > --> How do you create a certificate that the laptop can use, which the NFS > server can trust enough to allow the mount? You can give your laptop a certificate for an arbitrary name, provided that the NFS server knows to "validate" that name in an appropriate fashion. (I don't remember what draft-ietf-nfsv4-rpc-tls says about this validation.) > My thinking is that a "secret" value can be put in the certificate that the NFS > server can check for. > The simplest way would be a fairly long list of random characters in the > organizationName and/or organizationUnitName field(s) of the subject name. > Alternately, it could be a newly defined extension for X509v3, I think? It would be better to just make a site-local CA and trust everything it issues (which, admittedly, is not the greatest option itself.) > Now, I'm not sure, but I don't think this certificate can be created via > a trust authority such that it would "verify". However, the server can > look for the "secret" in the certificate and allow the mount based on that. > > Does this sound reasonable? I'm not sure what goal you're trying to achieve by this "security through obscurity". > Also, even if the NFS client/server have fixed IP addresses with well known > DNS names, it isn't obvious to me how signed certificates can be acquired > for them? > (Lets Encrypt expects the Acme protocol to work and that seems to be > web site/http specific?) RFC 8738 specifies the ACME protocol for validating IP addresses. -Ben