From owner-freebsd-current@freebsd.org Wed Mar 25 23:51:16 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 B31AC267488 for ; Wed, 25 Mar 2020 23:51:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660046.outbound.protection.outlook.com [40.107.66.46]) (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 48nlHv22qjz4N5w for ; Wed, 25 Mar 2020 23:51:06 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Sd+bC/mPvEsVGs0G1005EP9QdLgYUcppKYFP11hOp0thrOyKsW+ER25xY6G0QGmc1VAQb9RyQDk2F2FnWUlyqRkD4HeeCCUEJyAL9DoyDK1/ksgkeqA8oHyWuwUcFDTHXOkLG6/Ldkvoefa6r/vr+gXQTsY2Bryfe5arKkAe4ILYwhaM7nJMRE/jkHAf4xYwMk6XwUNBFeJ3v81UQH78exsfE+5PfJZ95KM5iO+p/8dK1EpMgK3GP2eFBJsO/YnXnbYesEJloIN2p+i5WJTYwAulEyVdPBnEApZuJ8blyAYeFtgkcLTEn+pAqYaA7599HvFqxzamtk8cor/rMcB4GQ== 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=vVH4bzMTYlJadhEBtRO1y+gsFUog8zF7EHdEQV0HbBE=; b=Ideme+f6Nv92tskbwAIRinGFy3nXa13UmKrtVPLjCL8i51avja/BOJwhU2K9YxjwpWr+I3QiRznw/ZzwBtd3HOcSsXq6vLVeVVLs9EwnzU4rwkZPB4Ael9hJXD0cGXiq8Khl/nZnqxUx3ddeGM6FvElv3qd/K+w/o2MxMMo8W9xilXSW9fI2Vv4iF6/M63ClSitI8bMP08gFCObLIZ8gVMGk3tSobUn4m+AwXIv8BVVnsBh7MDbR0C/NWLM02JWNeFhZmapT9lACjGsQDO4DENpqyKBDhOu+9FUNopSgdwHKNafWayQXN7xoPzAy5UIt5Ys+RvdyAioxQ3vWtbmM0Q== 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 QB1PR01MB3396.CANPRD01.PROD.OUTLOOK.COM (52.132.88.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.15; Wed, 25 Mar 2020 23:50:56 +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.023; Wed, 25 Mar 2020 23:50:56 +0000 From: Rick Macklem To: John-Mark Gurney CC: Alexander Leidinger , "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+UIiEJS9mke8ubtYdFBhy6hZ8jaAgAAC+s0= Date: Wed, 25 Mar 2020 23:50:56 +0000 Message-ID: References: , <20200325231005.GQ4213@funkthat.com> In-Reply-To: <20200325231005.GQ4213@funkthat.com> 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: cf8d351d-6193-405e-5048-08d7d1175c92 x-ms-traffictypediagnostic: QB1PR01MB3396: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0353563E2B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(396003)(376002)(39860400002)(346002)(81156014)(316002)(81166006)(8676002)(86362001)(786003)(8936002)(54906003)(52536014)(5660300002)(2906002)(64756008)(66556008)(71200400001)(33656002)(66476007)(66946007)(66446008)(4326008)(6506007)(478600001)(186003)(55016002)(6916009)(9686003)(76116006)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:QB1PR01MB3396; 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: kzhYiBLoReZkTuVj3FrgWcnsN9HrLfshSIpN5GF3x5rvoZU6+/i3GdCJwmDrPsSp5df6mu718x6DVKb3V2Upxbdyuc2jQW7HLT+Ygp3ZxzR31mqTQw0idOprGlMByVTIzm7T0G8d0yIpT6WdFBWBQhfbLe34nAs9ugCJaClA+6HNNqLYqioJDjjDIzkddZeymLW/53KVQpzMrB7pNFhbOTBoaitp5BAOgWeYkAILn8FQJZbbCyJ4zw+otriF+ZAMX0GecKEtqbzZ+hd7cV2OXza36tYWa3taIdDxqlQDPKBEDrE5b6GeLgD4oXLi27345q+Esx7M5R/q/E5Pt/B98dWN1dNgsq+z6SsYEYXki6xeCyYz4/dPfY0EZe4wwcF7FJZcA7oXPKXuLPmwpwbaawbOpU2rAXZoz+uaOrAwkKpwEVsQvbvwa5HE/5d/cp1F x-ms-exchange-antispam-messagedata: mLWKHLUosv7PGYv3JV511FjRZ/nrT3EoppL5MXVxIGL1V897tFpyDibHFIo+KYxpuYiiwYK6DH/lUbZDPyzbxtFs8oxJlOjrPgBAycY/grYfs15pHXjt5x/Wj5mCqfWMTKDO8F8JnXDU/nIFPoMzAtFWTqqNf935NAglauGnKh3QrXY9PEr1BPUAuxCG46bzsQjg00kiNE4T0+9wyEQ40Q== 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: cf8d351d-6193-405e-5048-08d7d1175c92 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2020 23:50:56.2900 (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: rN3OwfNVw6sbtu9Dxc/MTlTK6WzkbC4kQH3hnEJN8Wxs1BIWe18irhnsEpE5cI/B93gLiIChY8qaLkXgeaEs5A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB3396 X-Rspamd-Queue-Id: 48nlHv22qjz4N5w 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.66.46 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.68 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,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)[46.66.107.40.list.dnswl.org : 127.0.3.0]; IP_SCORE(-1.38)[ipnet: 40.64.0.0/10(-3.75), asn: 8075(-3.13), 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: Wed, 25 Mar 2020 23:51:17 -0000 John-Mark Gurney wrote:=0A= >Rick Macklem wrote this message on Mon, Mar 23, 2020 at 23:53 +0000:=0A= >> 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= =0A= >> >>> was issued by=0A= >> >>> the local CA. Unfortunately, if the client is compromised and the=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. 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= =0A= >> >trusted CA".=0A= >> >=A0 - Then you can require that the CN matches the hostname and the=0A= >> >reverse lookup matches.=0A= >> >=A0 - Or (similar to browsers today) you can ignore the CN and require= =0A= >> >that the hostnames of the client matches one of the subject=0A= >> >alternative name (SAN) entries (requires reverse DNS lookup to work=0A= >> >and match).=0A= >> At this point, I have three variants in the code (strictest to less stri= ct):=0A= >> 1 - A "-h" command line option on the server handshake daemon (called rp= ctlssd).=0A= >> This requires that all clients have=0A= >> certificates that validate and have the FQDN acquired via reverse D= NS of=0A= >> the IP address of the client for the TCP connection (getnameinfo(NI= _NAMEREQD))=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" t= he=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 a= ny 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 ind= icate=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 ver= ified.=0A= >> --> For this case (and #3), the server admin. is willing to "trust"= the 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 ha= ve 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 tha= t they=0A= >> are willing to allow the client to mount based on that IP, bu= t wants 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 eno= ugh to=0A= >> use that it does get used. (sec=3Dkrb5p achieves both user authenticatio= n and=0A= >> data encryption on the wire, but does not get widely used, due to the ne= ed=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= >Maybe I'm missing the option where the cert needs to be authenticated,=0A= >but matching against IP/dns name does not need to be done. Or is this=0A= >a case of #2. I'm just confused by the first point of #2 in that the=0A= >server admin is wiling to trust the IP address...=0A= Yes, that is #2. "trust the IP address" probably wasn't a good way to=0A= express it. I was simply trying to say "the NFS server admin. is willing to= =0A= use the client IP address to select rules via the exports(5) file".=0A= =0A= >I'd like to see where CN or other field is freeform/provided by exports=0A= >entry, and validated to gain access to those resources... i.e. it=0A= >doesn't matter what IP or DNS name the client is, it's based solely on=0A= >the certificate. This would allow roaming users.. This maybe be=0A= >addressed by #2 point 2, but it isn't clear in your description that=0A= >it isn't dns tied or something else...=0A= Yes, for #2 the daemon only validates the certificate (actually uses the op= enssl=0A= default verification library function). It does not filter the certificate'= s CN or=0A= other fields in any way. (It does have the implication that all the NFS cli= ents=0A= could use the same certificate. I'm not sure that would be a good plan, sin= ce=0A= revoking the certificate would revoke it for all clients and having it on N= clients=0A= would increase the risk of it being compromised, but ...)=0A= --> The only way I can see that the server can enforce each client to use a= =0A= separate certificate for each client is by using #1.=0A= =0A= I had originally planned on some "secret" in the certificate (like a CN nam= e=0A= that satisfies some regular expression or ???) but others convinced me that= =0A= that wouldn't provide anything beyond knowing that the certificate was=0A= signed by the appropriate CA, so I have not implemented anything.=0A= =0A= >As the CA admin, they control what is valid/gets signed in the CN or=0A= >other fields, so this is safe to do... If you can't trust your CA to=0A= >sign only valid (to your policy) certs, then you shouldn't be using=0A= >that CA..=0A= Yes, that is my thinking for #2, as suggested by others.=0A= (For cases like using LetsEncrypt, my impression, which could be wrong, is= =0A= that anyone with a well known DNS name can get a certificate. As such,=0A= without using #1, those certificates seem meaningless to the NFS server to= me?)=0A= =0A= I, personally, don't think many NFS admins. will want #1, but if they happe= n=0A= to have NFS clients with well known DNS addresses, they can enable this che= ck.=0A= I think it is also a required capability according to the draft that will b= ecome=0A= an RFC at some point. (At some point I need to re-read the draft to try and= =0A= make sure I am playing by the rules. When I first read it, I thought that s= ite=0A= local CAs were not allowed, but the author clarified that site local CAs ar= e=0A= meant to be allowed.)=0A= =0A= Thanks for the comments, rick=0A= =0A= --=0A= John-Mark Gurney Voice: +1 415 225 5579=0A= =0A= "All that I will do, has been done, All that I have, has not."=0A=