From owner-freebsd-current@freebsd.org Sat Mar 28 16:11:22 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 EFAAF2A6804 for ; Sat, 28 Mar 2020 16:11:21 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670047.outbound.protection.outlook.com [40.107.67.47]) (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 48qNxm2NCBz41Sc for ; Sat, 28 Mar 2020 16:11:07 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MfKJqU0FM70MYHcmLmSXRhGhYRCtdn79dzSHInNtFsPjbutE969a8TDjrKGsZKh417uBek0FKZzzcqITHZlQVebSd59JX92K6pro3i0ROcKosXmbnUxQDdFgxrIK+anEBADc3iFEZ2C0Q3W9KJEA8/y84sGyDB40ZQ62/joQx8M7AiVU1kR182VKuk8ICmTf+hpqkxjbS3n/Y91CJjcnc0vsKWzTq8B8qGZBt55EN8iqX/qJyGuakbDmuJZQQ48hb37lhRpkDmqg4VPJSG7K1p6ucHVooH0lgtA5/psbt+2fOd/GWhSODu3ZaFWeN0ayWts3YZaQ3xMS1b4AL4OBFg== 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=iHvUSTDse+5UOgWAwM7T/A0IkxxkgLlj+TJGXvZMETY=; b=D4K6bn5X+H4OmQQdo5WATirL/iShNEwUrjEafF1eqOYy+Dgp3sc/E465gnlt0oECE774IfUoYyjkDNlnE2kpRyf6Uis0/epKrf7I7lirELH/td7B/tnAogoSH13rTUB1uRe74b7OTYEveMnFpVXfwxz4vkrBT7rS4XpIRvfj86z+q2MZfOTL+z8ki+6gXFk3BOy/ub27YzybmB3ip45wHCadRbwtESn0moy2sBFxMdEBibVFshCZCgq5WmppXovenGUZcLMIGG1GjRFwbmYsQn2utezrWN+KiViDDa8d7BeUNa9l2mmizqKuaNCrwZrFnXbR3pLyhIaFoHlYzTxeNg== 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 QB1PR01MB3140.CANPRD01.PROD.OUTLOOK.COM (52.132.89.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.19; Sat, 28 Mar 2020 16:10:58 +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.2856.019; Sat, 28 Mar 2020 16:10:49 +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: AQHWBM20voRSAnj550my91BNnYCx3qheIHLx Date: Sat, 28 Mar 2020 16:10:49 +0000 Message-ID: References: , <20200328065331.GU4213@funkthat.com> In-Reply-To: <20200328065331.GU4213@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: 71fbf7bc-21ae-406d-ef9a-08d7d33294a2 x-ms-traffictypediagnostic: QB1PR01MB3140: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03569407CC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(39860400002)(346002)(396003)(136003)(8676002)(9686003)(8936002)(81166006)(55016002)(81156014)(71200400001)(4326008)(33656002)(2906002)(66946007)(76116006)(66446008)(64756008)(66556008)(66476007)(478600001)(316002)(786003)(5660300002)(54906003)(86362001)(7696005)(186003)(6506007)(52536014)(30864003)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:QB1PR01MB3140; 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: h0HQNv4VuYpLfn/c8TItil02YrsB8iYjQ4VqGNGH1mTpKmlqZxwcy+ywKAx8r3/D5RSEWM0yE2cojEDVwxk23WKximBNOgXfZu27OyauhNKlbbNG3n/Pt0KNnrBMnAYmdjaZmXB7RTkZStNp2YaKwXhnKbZzIpomc4V9jrSuCNIPfQ/fAYjOOuD5+dZcj1Klw9I8CIm2HdhvloHYfL4+t4rkqpajHrLkq0p/jfhCfOjYTKgFcL49y8SPUzIRT/HJHlS6V/QjCTi5wAmThbW+bck6gk6TiLtYymDtvtl+7Om1eLkX1olk9lgRYNQd7gDAToBoUe8JoFeEAH/1LxvsuEf+wgohrop7ePNvmB4iilfyKQTdHwYALBtvSr4rtVa4P+LuAxu7Q/otl/lN4yMD0nJE/iqMms7/f4oZHuhasuV72J3J3i1JPkcWbfJApz3M x-ms-exchange-antispam-messagedata: hlXRA6nq7Z9dowm3HV1TzQt6JC6avjAEv7wiagYnGgmIq2DF15yB6kAvf0dgIYyU+ZuRKXmlLHQfQBgAStkCSlxQK3QCB8aKnE+luestlVpYGRxz9jtcmLMavF15YoVsNZosp7T1hsGJVn1+TUkSmM3QtD9jbE26Lf/HuikUmgSBCJhjE8MVy283exRm/gjmes0GJOJ57OACC9AM0yGi2Q== 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: 71fbf7bc-21ae-406d-ef9a-08d7d33294a2 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2020 16:10:49.0576 (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: SwwLR82zNSBgNudPKaIyVuS/zXNqXE4eMsBdaPhSU//v9u3JMvJct2ieFKhM2WASxjjmOHkto39LIyNdtq3kmg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB3140 X-Rspamd-Queue-Id: 48qNxm2NCBz41Sc 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.47 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.69 / 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)[47.67.107.40.list.dnswl.org : 127.0.3.0]; IP_SCORE(-1.39)[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: Sat, 28 Mar 2020 16:11:22 -0000 John-Mark Gurney wrote:=0A= >Rick Macklem wrote this message on Thu, Mar 26, 2020 at 14:33 +0000:=0A= >> John-Mark Gurney wrote:=0A= >> [lots of stuff snipped]=0A= >> >Rick Macklem wrote:=0A= >> >> I had originally planned on some "secret" in the certificate (like a = CN name=0A= >> >> that satisfies some regular expression or ???) but others convinced m= e that=0A= >> >> that wouldn't provide anything beyond knowing that the certificate wa= s=0A= >> >> signed by the appropriate CA, so I have not implemented anything.=0A= >> >=0A= >> >Yeah, having a "secret" in the CN doesn't make sense, but what does mak= e=0A= >> >sense is allowing the exports line to specify what the CN should contai= n=0A= >> >to be authenticated...=0A= >> >=0A= >> >Say as a corp, you issue personal certificates to everyone. This is=0A= >> >because you require everyone to sign and/or encrypt their email w/=0A= >> >S/MIME. Each cert includes the email address of that person, so you=0A= >> >could simply do something like:=0A= >> >/home/alice -tlscert -tlsroot /etc/company.pem -email alice@example.com= =0A= >> >=0A= >> >And anyone who has the certificate w/ alice@example.com that was signed= =0A= >> >by the public key in /etc/company.pem would be granted access to the=0A= >> >export /home/alice.=0A= >> >=0A= >> >If it allowed ANY cert signed by the CA specified, then that introduces= =0A= >> >an authentication problem, as now if Malory is a coworker of Alice=0A= >> >could also access Alice's home directory...=0A= >> >=0A= >> >IMO, this is one auth feature that MUST be supported...=0A= Here's what I have just coded up:=0A= - If an option is set for the server TLS handshake daemon and it gets a ver= ified=0A= certificate from the client=0A= - It looks at the CN and if it is of the form "user@domain", it tries to = translate=0A= "user@domain" to a POSIX using the same mechanism that= =0A= nfsuserd(8) currently uses. ("user@domain" is what NFSv4 uses for a fil= e Owner.)=0A= - Then all RPCs on this TCP connection are done using the above,=0A= ignoring the authenticator in the RPC message header. (Yes, similar = to the=0A= -mapall exports option.)=0A= I have also added a "-tlscnuser" exports option that would require all clie= nts=0A= to have the above form of certificate. (Without this exports option, the ab= ove=0A= would work assuming the daemon option is set, but other mounts would be=0A= allowed as well.)=0A= =0A= The problem of handling multiple "user" domains has never been solved.=0A= (That is what your -tlsroot option was intended to do assuming a 1 to 1=0A= relationship between CA root and username domains, I think?)=0A= The problem is that getpwnam(3) needs to know how to look up user names=0A= for these different "domain" values. (Now, both nfsused(8) and this daemon= =0A= only strips off the default domain, if it matches, and then hands the rest = of=0A= the string to getpwnam(2).)=0A= =0A= Although "user@domain" isn't exactly an email address, they often are the= =0A= same string in practice.=0A= =0A= I have not yet posted to nfsv4@ietf.org to see what they think.=0A= However, I don't think there is any changes in the draft required to do thi= s.=0A= Also, I think interoperability should be ok, since it is controlled by whoe= ver=0A= issues the certificate for the client and the NFS client will normally just= =0A= handle this certificate opaquely.=0A= =0A= Btw, the server TLS handshake daemon does do a SSL_CTX_set_client_CA_list()= ,=0A= so it tells the client which CA (usually only one) that it wants a certific= ate for.=0A= =0A= >> The draft does not address user authentication, only machine authenticat= ion.=0A= >> --> ie. The certificate is used to decide if a system can do a mount.=0A= >> Users are still identified via user credentials in the RPC message= header.=0A= >> For AUTH_SYS, that still means .=0A= >> Otherwise, you need to use Kerberos (sec=3Dkrb5[ip]).=0A= >> You could use "tls,sec=3Dkrb5" for a mount, but the only advantage= that=0A= >> might have over "sec=3Dkrb5p" is performance, if there is hardware= assist=0A= >> for TLS or something like that.=0A= >>=0A= >> >Now that I reread your comments, it sounds like any certificate would b= e=0A= >> >allowed in #2 as long as it is valid, and that would only be marginally= =0A= >> >better than verification by IP, and in some ways worse, in that now any= =0A= >> >user could pretend to be any other user, or you have to do something=0A= >> >crazy like have a CA per user.=0A= >> The case where I see #2 is useful is where this discussion started some = weeks ago.=0A= >> The example I started with was:=0A= >> /home -tls -network 192.168.1.0 -mask 255.255.255.0=0A= >> /home -tlscert=0A= >>=0A= >> This says that machines on the local lan can mount and do not need to ha= ve=0A= >> certificates, but must use TLS so data is encrypted on the wire.=0A= >> Mounts from anywhere else (presumably laptops) are allowed so long as th= ey have a=0A= >> certificate signed by me (as in the site local CA).=0A= >> I trust these machines enough that I am willing to allow them to use AUT= H_SYS,=0A= >> which is what 99.9...% of NFS mounts do now.=0A= >> (So, I'd agree that the site local certificate is not a lot better than = IP address=0A= >> for client machine identity, just that it is an alternative that can be= useful.=0A= >> Without TLS, a line like "/home" allows anyone to mount /home from anyw= here=0A= >> and I think you'd agree that few NFS admins. will want to do that. I'm = assuming=0A= >> no external firewall for this example.)=0A= >>=0A= >> Now, your suggestion of identifying a user via the CN and then having th= e=0A= >> server do all RPCs for the mount as that user is an interesting one.=0A= >> My concern w.r.t. implementing it would be interoperability.=0A= >> Put another way, if other servers such as Linux, Netapp,... don't adopt = it=0A= >> (and they won't until there is a draft/RFC specifying it), it would be= =0A= >> FreeBSD server specific and I'd like to avoid that.=0A= >> There was some discussion w.r.t. user authentication via certificates=0A= >> during development of the draft, but they decided to defer that work for= =0A= >> now, so they could get something in place for machine authentication fir= st.=0A= >> (If I understood the discussion on nfsv4@ietf.org.)=0A= >=0A= >There's a fine line between machine and user authentication when you can= =0A= >add -mapall=3Dsomeuser. :)=0A= Yes, I agree. You can argue what I've coded as explained above is just serv= er=0A= implementation and has nothing to do with the draft, which covers what goes= =0A= "on-the-wire", similar to "-mapall".=0A= =0A= >Yes, a certificate may be used to identify a machine, but if any machine= =0A= >can be identified by any cert as it appears that #2 is proposed to do, the= n=0A= >you're not actually identifying a machine, you're identifying group of=0A= >machines... Though per the draft, this is explicitly allowed.=0A= >=0A= >It'd be nice to be able to identify particular machines though, and be=0A= >able to set the options based upon that..=0A= Well, the only thing the server has to use for exports(5) is the client's I= P address.=0A= In a sense, you can say that "alice@example.com" identifies the machine tha= t=0A= Alice uses.=0A= =0A= At least, it means that if the certificate with "alice@example.com" in it i= s copied=0A= to a different machine, that machine will access the NFS server as "alice" = as well=0A= and cannot access files that Alice cannot access.=0A= =0A= >> >I'm wonder if your use of the term secret was the problem, and not the= =0A= >> >idea... Anything that goes in the client cert is by definition public.= ..=0A= >> >TLS prior to 1.3 sends the client cert in clear text... But keying=0A= >> >based upon the contents of the cert is fine, as that's the point of=0A= >> >what a cert is.. It's trusting the CA to say that the CN and other=0A= >> >fields in the cert corresponds to this user, and you can use parts of= =0A= >> >the cert, like the CN to decide which user the public key in the cert= =0A= >> >corresponds to.=0A= >=0A= >Rick Macklem wrote this message on Thu, Mar 26, 2020 at 14:59 +0000:=0A= >> Sorry about the top post, but I thought of a few things to add to my=0A= >> last post to this thread...=0A= >> 1 - I agree that for systems like laptops, the line between machine and= =0A= >> user authentication is fuzzy.=0A= >=0A= >yep, exactly. IMO, laptops are more important for this work, and where=0A= >you want to identify per machine at a finer grain level than server=0A= >machines...=0A= >=0A= >> 2 - I do like your idea of having an exports(5) option that specifies a = CN=0A= >> that identifies a user and then does all RPCs as that user.=0A= >> I'm not sure if an issuer needs to be specified (or even can be sp= ecified),=0A= >> since the CAfile argument to the rpctlssd daemon determines if a c= ertificate=0A= >> from a particular CA will verify and the verification must happen = before the=0A= >> exports(5) export options can be applied. (Basically, certificate = verification=0A= >> happens via a NULL RPC that does a STARTTLS when a TCP connection = to=0A= >> the server is first established.)=0A= >=0A= >Yeah, this will need some work, but IMO is fine as a future=0A= >improvement...=0A= >=0A= >Yeah, this could be a bit tricky from a code perspective.. I don't know=0A= >how well most SSL libraries are being able to auth client certs via=0A= >different roots after the fact... One option, but maybe not a great=0A= >option would be to verify the cert after the connection is established..= =0A= >=0A= >You could extract the cert identify the candidate export lines, and=0A= >then attempt a cert verification w/ a specified root if a default one=0A= >isn't specified... Not exactly clean, but as long as the client can't=0A= >proceed without this check, shouldn't be a major problem...=0A= Well, the certificate verification normally occurs during the handshake=0A= using the location information provided via SSL_CTX_load_verify_locations()= .=0A= However, this does not included checking for specific fields in the certifi= cate.=0A= =0A= The daemon could pass the subjectName from the certificate into the kernel= =0A= for use by the exports(5) handling code later, but then another upcall to a= =0A= daemon needs to be done to translate the subjectName to .=0A= Since even nfsuserd(8) only knows how to do this for a default domain,=0A= that would be a lot more work and I don't think it gains anything at this= =0A= time.=0A= getpwnam(3) needs to be done in userland and is a little bit scary to do,= =0A= since it could get hung on a broken LDAP server or similar.=0A= If done by the TLS handshake daemon, that means new mounts hang, but=0A= at least current mounts keep working.=0A= =0A= >> 3 - I'll post to nfsv4@ietf.org to see what others think of this, since = it would not=0A= >> require any changes to the draft/RFC.=0A= >> 4 - Although it does require a revision to the export_args structure, I = think it is=0A= >> worth doing even if others don't implement it.=0A= Oh, and implementing what is described above did not require the export_arg= s structure to be revised.=0A= =0A= rick=0A= =0A= Thanks. Let me know if you'd like code reviews as well...=0A= =0A= > Again, thanks for your comments, rick=0A= =0A= And thanks for doing the work!=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=