From owner-freebsd-current@freebsd.org Mon Mar 23 23:53:47 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 80D18273F9E for ; Mon, 23 Mar 2020 23:53:47 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670059.outbound.protection.outlook.com [40.107.67.59]) (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 48mWRs2q5zz4PfT for ; Mon, 23 Mar 2020 23:53:45 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oAavEKInfzqKsNSisb6KNM2ZulqnPt9YwTQAGMSiMDg8A0RuLfqZ4IpIrko8zBGUMxRC/ek/wXNXYMSW12NA8Q/xrcKjZAe3GcHJ6OKkxO53+cIcJq+eB8DrpisBrRFBht02CN1Yw8qjaXCGVUQfXtHtWmr8jMrENoB5p+pskawL+A7N3aNnPiqkkktQ1t9ZtbdSpmW3cetNn4pXiwh/CzmFBBeSEYQzGgQMrRxb51Jsh0rZ+gW3MeUn28pzo8qdmB7TsBsVKfa9L05oUMdZNesBAuZqfSOSKqS9sNkXgiN3cRhEnL4FWxGP2TXB8PJaTfY2ZpsmGtgkqSvNRON8Eg== 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=Sp79liBBKaFxoAa5bEzeA19b6TqcaYFXJpP5I/p7AxE=; b=ftN27lOUXWX1WxASzkxHXQMOazcB3PaBaSFeJCwl4m15QPHAMScjfpgt7lI2+ropfLF1CAj4+/DqXaM8zolmejSWfFz/RVWOwZ93qvMMqEr/jfeQpWabpGKpQ/CNDj5yiHX4i5Xrc2icLzwtEUNYnBor2szfY8S2DKu8xBwufODCDMlr2RfQOoBhd7rhTIzos3P5NGmB2V2IsCM7EqQgAhb5E8lZ7QGBmtGjqRWEnDQR3Sgg2eMXxCM3iovJINZEMnyfHdxObtELciXorcTcfarD9gmBrnyepIGnRBqBWaSJxeW0IHX+D502vqtenoZGKDe2PxwS9iT8CsDShGnIfA== 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 QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM (52.132.86.26) by QB1PR01MB3921.CANPRD01.PROD.OUTLOOK.COM (52.132.85.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.20; Mon, 23 Mar 2020 23:53:43 +0000 Received: from QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM ([fe80::ed8c:7662:79ba:5f9f]) by QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM ([fe80::ed8c:7662:79ba:5f9f%5]) with mapi id 15.20.2835.021; Mon, 23 Mar 2020 23:53:34 +0000 From: Rick Macklem To: Alexander Leidinger , John-Mark Gurney 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: AQHWAWnI+UIiEJS9mke8ubtYdFBhyw== Date: Mon, 23 Mar 2020 23:53:34 +0000 Message-ID: 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: ab9639e1-1d24-4788-daa7-08d7cf8565cc x-ms-traffictypediagnostic: QB1PR01MB3921: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2331; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(366004)(396003)(136003)(376002)(110136005)(966005)(478600001)(76116006)(52536014)(33656002)(2906002)(4326008)(9686003)(55016002)(5660300002)(186003)(86362001)(8676002)(7696005)(6506007)(8936002)(81166006)(81156014)(786003)(64756008)(66946007)(66446008)(71200400001)(66476007)(316002)(66556008); DIR:OUT; SFP:1101; SCL:1; SRVR:QB1PR01MB3921; H:QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; 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: Dc8Ktp1WQchmBq+TCK91t67ExOeYJT39mZdRwVUTySMYEQfGNeDDUsEks2FFJOncAWst/dg22MToz3kQJAMkFkQPDoM3LbLk96LMg1/xgQjTaAKN/Lless74uGahfogP1KS8zoLkOureSJoBxw7iNupPUBfwzdp5n4OJrQjoTLBWQ9KjX9i0r5HaOWhrELckbNPD21Lm07hUzstithykmzEoWNYRw/EWCzGPszCiLSY6EHXHqCbiD8yYUIg9TE6a/oUoTQwFRuBXQC0eBYc5/R23OGX8CFLkFFOtadrVhzjtjV/EdhymuQegJXhWWVAEZLejmiXmzK4m1wqkZO9Bt2H40jkLxbbe5s0kmmUZcYNT2gKLDJ0Z9WNMzPxFrkqSTYwfPNa469ol13Q34FqzUsuUSpL/iz3vH56OykpdRwvr2n4vpOKqlvWFxR18ZouqhwQp9Fj+964SJUgJikbZBLDHlO0rkit4tjgQxRnoOc7ZA82SayyYhQJrPfkwqp9wVw9jfL1r4wJB/x4v8jhzqw== x-ms-exchange-antispam-messagedata: BNKihki0b2Nit9ESsAO2jGN3EsqfzWxCDxeyzAdtpm1W1NeHozoLG8zPuFX/4nG5oaOGIc5+XdqsNVN6BvTsilfNSWEIhLx6od1SIujAXf1CkLBlq+5vNKQxfcAleoCX8QWkSb11YHGlHxEI4aDqtlUmDyDSMbcJNYGDZyb9LFmrnbBhu3dFInlekkVPkpOS6DgNHhp8N9+yKch3X7bsnQ== 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: ab9639e1-1d24-4788-daa7-08d7cf8565cc X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2020 23:53:34.1228 (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: movSKP4mSVdESybc0sxlvYBk/r13y5+gft6su9BX39LNMlApxXsX9mUORVjdJIckd6Jr+xEiDCW3Nmq+Ix2loQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB3921 X-Rspamd-Queue-Id: 48mWRs2q5zz4PfT 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.59 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-3.63 / 15.00]; FAKE_REPLY(1.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.949,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)[59.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.12), 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: Mon, 23 Mar 2020 23:53:47 -0000 Alexander Leidinger wrote:=0A= John-Mark Gurney wrote:=0A= >>Rick Macklem wrote:=0A= >>> to be the best solution. The server can verify that the certificate=A0 = =0A= >>> was issued by=0A= >>> the local CA. Unfortunately, if the client is compromised and the=A0 = =0A= >>> certificate is copied=0A= >>> to another client, that client would gain access.=0A= >>=0A= >> This is why CRLs/OSCP is necessary, but there isn't anything you can do= =0A= >> to prevent that.=A0 This is both a better situation than what we have=0A= >> today (no auth/confidentiality), and if you tie the cert to an IP, it's= =0A= >> of limited use, and better than today...=0A= >=0A= >There are multiple ways to handle that:=0A= >=A0 - First of all, you can just validate based upon "cert is signed by=A0= =0A= >trusted CA".=0A= >=A0 - Then you can require that the CN matches the hostname and the=A0 =0A= >reverse lookup matches.=0A= >=A0 - Or (similar to browsers today) you can ignore the CN and require=A0 = =0A= >that the hostnames of the client matches one of the subject=A0 =0A= >alternative name (SAN) entries (requires reverse DNS lookup to work=A0 =0A= >and match).=0A= At this point, I have three variants in the code (strictest to less strict)= :=0A= 1 - A "-h" command line option on the server handshake daemon (called rpctl= ssd).=0A= This requires that all clients have=0A= certificates that validate and have the FQDN acquired via reverse DNS = of=0A= the IP address of the client for the TCP connection (getnameinfo(NI_NA= MEREQD))=0A= in either the subjectAltName or CommonName. (I call X509_check_host()= =0A= and this is what I understand it checks.)=0A= --> This case implies that the NFS server admin. does not "trust" the= =0A= client's IP address enough to apply exports(5) line(s)to it to = decide to=0A= allow the client to do an NFS mount.=0A= (An NFS server *might* be willing to allow client(s) to mount via any = IP address=0A= for the #2 case below and not use this option.)=0A= 2 - Without "-h" the rpctlssd daemon passes flags into the kernel to indica= te=0A= if the client provided a certificate and whether or not it verified.= =0A= Then the "-tlscert" option on the appropriate exports(5) line(s) =0A= indicates that the client must have provided a certificate that verifi= ed.=0A= --> For this case (and #3), the server admin. is willing to "trust" th= e client's=0A= IP address enough to apply exports(5) rules to it.=0A= --> This is the case where a floating (no fixed IP) laptop could have = a=0A= certificate signed by a site local CA.=0A= 3 - Similar to #2, but uses the "-tls" option on the exports(5) line(s).=0A= In this case, the client must use TLS so that data is encrypted on the= wire,=0A= but does not need to have a certificate.=0A= --> The NFS server admin. "trusts" the client IP address enough that t= hey=0A= are willing to allow the client to mount based on that IP, but w= ants the=0A= data to be encrypted on the wire.=0A= - Avoids the bother of generating certificates for the client(s)= .=0A= =0A= A part of this (as discussed in the IETF draft) is to make this easy enough= to=0A= use that it does get used. (sec=3Dkrb5p achieves both user authentication a= nd=0A= data encryption on the wire, but does not get widely used, due to the need= =0A= to run a KDC, etc).=0A= =0A= Comments on the above options is welcome, since this does need to be=0A= reviewed by users.=0A= =0A= rick=0A= =0A= =0A= At this point you prevent simple cert theft as additionally you=A0 =0A= require that someone also has to be able to modify the DNS (or NFS=A0 =0A= server hosts file, but then he probably can already add an additional=A0 = =0A= cert to the truststore of nfsd).=0A= =0A= Additional protection is possible by also adding the IP to the SAN. I=A0 = =0A= haven't put an effort into evaluating if either IP or DNS is enough=A0 =0A= from a security point of view, or if it makes a difference if the "IP=A0 = =0A= in SAN" case has an additional benefit in terms of security if it is=A0 =0A= in addition to the reverse DNS requirement.=0A= =0A= Yes this makes it more inconvenient to change the IP of a host, but if=A0 = =0A= all the policy possibilities are up to the admin to configure (e.g.=A0 =0A= "cert is signed by trusted CA" as a default, and all the other=A0 =0A= possibilities as an option for nfsd), it is up to the admin and the=A0 =0A= security requirement.=0A= =0A= In general, all the possibilities are can either be distinct, or=A0 =0A= accumulative. There is also the possibility that you do not go with=A0 =0A= any CA but configure X self-signed certs for X clients as being=A0 =0A= trusted and the cert of the client needs to be an exact match with one=A0 = =0A= of the X self-signed certs in the truststore.=0A= =0A= Whatever the policy(/ies) is/are in nfsd, I suggest to make it=A0 =0A= explicit in the docs what is required and what is checked for each=A0 =0A= policy. And even if it may be obvious for you Rick, please also print=A0 = =0A= out why a client was rejected. Unfortunately I've seen a lot of cases=A0 = =0A= where the error is a simple/frustrating "certificate rejected", but no=A0 = =0A= info which part of the certificate check failed.=0A= =0A= Bye,=0A= Alexander.=0A= -- =0A= http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF=0A= http://www.FreeBSD.org=A0=A0=A0 netchild@FreeBSD.org=A0 : PGP 0x8F31830F9F2= 772BF=