From owner-freebsd-current@freebsd.org Thu Mar 5 22:55:15 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 79F6C24F409 for ; Thu, 5 Mar 2020 22:55:15 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-qb1can01on0624.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5c::624]) (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 48YR0d61TWz47LY for ; Thu, 5 Mar 2020 22:55:13 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QkibHiAU6TAy8BqSipIXkyx2wVoDEkCNCRMjjUp8NAv9gvAdh0SJZ380008mu+BJLhoaONT+giyeLP7ADKPFNY0qOkCA/u6crStvE5Mi1kBQBMpHbOH+dE7+B10aLNbUoJtQLLnjuDp4+je8z1wtRBe0wvOaKQCfRHF6RKjcxDpoixeKFJR/c5E6F+YeweJ1GfoYn+ZaeVMxbHm8TEzOZDqGyYso+hf/0d82Y3d71wk4tDULwc7HkoPiCxFIN17j+yz9nBEu82n5T2f20mvxpGXWyrjn/mTPLwWqSaeK0ePtvfb4wNXRYtazww6IzmRfMlRBDeM0hsQg1FCQiWPbqA== 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=oBUNj0Et9rYE7yzCUCNtJYEwzV3Nxg526AAvxh+RGz0=; b=PnDAsH2PgT0z7xymDN5sgLGn4U9M2Jk9ouEFjZY3XARfPnHflj1d9krBV+2FxdHroBd+fO6ERvzgJ8NajD6xcaitCO/CFDwCAy91uDIVE0wc+JtvfbLztWEvqOjNTHQ1ebT3LFFxNdaWdV+Pd79kjL3PX16CUdJlRBpe2zTaobBuIQ15BJeDCrtZGSZAXf6hZNQXrg7PVY8OJnzuVzcok5mfiCD0dgBzFquUk6WwskACF9Cs9gZI8yz9R6oFjKfb8jK5/jUO6Qrwi8396PKqHNAMa1uZfFU8dFux2OoT7lEnfQE3LFG6DkkZx4tkGTu/vCx2X0o41jzyd5fDm5QPSg== 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 YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM (10.255.46.82) by YTBPR01MB3886.CANPRD01.PROD.OUTLOOK.COM (10.255.12.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15; Thu, 5 Mar 2020 22:55:11 +0000 Received: from YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM ([fe80::a50d:6237:4074:f9c4]) by YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM ([fe80::a50d:6237:4074:f9c4%6]) with mapi id 15.20.2772.019; Thu, 5 Mar 2020 22:55:11 +0000 From: Rick Macklem To: Benjamin Kaduk 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: AQHV8dDjD29GK4BL2kGnxfg+gW2rAag3xKkAgALVOQw= Date: Thu, 5 Mar 2020 22:55:10 +0000 Message-ID: References: , <20200304032234.GY98042@kduck.mit.edu> In-Reply-To: <20200304032234.GY98042@kduck.mit.edu> 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: e623fab2-33f6-46ac-4808-08d7c1584253 x-ms-traffictypediagnostic: YTBPR01MB3886: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2803; x-forefront-prvs: 03333C607F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(376002)(366004)(39860400002)(136003)(199004)(189003)(5660300002)(186003)(64756008)(26005)(76116006)(66476007)(66946007)(66556008)(91956017)(71200400001)(33656002)(66446008)(52536014)(4326008)(786003)(316002)(81156014)(55016002)(8936002)(81166006)(8676002)(2906002)(6506007)(7696005)(6916009)(86362001)(9686003)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:YTBPR01MB3886; H:YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 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: Y0IKHsae9rneEVmhUfxZJqp6uXNpsdgH54xo48grSMNvt3RMEzLwc0cGGXiI/LXf9HBuLJr791mgdpVv862zYmx2h/A1sWNW6Tmwazo/Mq8+UAwtfaL8lnD9OYtwIWXpPRRiXu8D5fGeGm9F5xAgYsqDRbnNDngGVh0c9V2evm8la4EaVOilTz9mHZvqomCMwVBucfkG7Q1rE+lUxjf2OYPyyASp8T2E5BG08E0VVThqKwoylbtyuVMzzArQVit6sWV/wU4H6fsS6hRfCczkA8/ZBOSdrNTA8izTB6gp40QvuvVDur01NP3yuWVlkPxYKBRXQVYzUCiO9Smhdxe1+/ODbs3C53GHgBT60+5U4RFXBgeQwc+kcJ2veds/z2RvMkqJKwWkfWY6fvlSDgEtsa5nOLODg5wi3Ut42UvSF+nFNnK0RGsv3k9sLsE1rbY0 x-ms-exchange-antispam-messagedata: +Fr/I2C1W/HHFYAu1ihx/JmduuRrG0Q3tzK8gNY46YgaFmtW6o6rkcyWUi1Fku7BkJuUJfifsU9KOcOHQEYBfZZ/RMBmUdop3Kt+zl73PWAk5Qr5I9itj4ONW5HDHgwMfKLfAHT1jLK1UYS2wlVXLA== 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: e623fab2-33f6-46ac-4808-08d7c1584253 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2020 22:55:10.9432 (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: 0HQRfLd059VQbF1m5TPwgMRuhdgPp58w3FNSeV7AcuGsSnvoe/T+ynuYbhQ6Bkyd9PECwHTSj+zNbnb0zFD70g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB3886 X-Rspamd-Queue-Id: 48YR0d61TWz47LY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 2a01:111:f400:fe5c::624 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.72 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; 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]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-1.43)[ipnet: 2a01:111:f000::/36(-3.99), asn: 8075(-3.09), 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:2a01:111:f000::/36, 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: Thu, 05 Mar 2020 22:55:15 -0000 Benjamin Kaduk wrote:=0A= >On Wed, Mar 04, 2020 at 03:15:48AM +0000, Rick Macklem wrote:=0A= >> Hi,=0A= >>=0A= >> I am slowly trying to understand TLS certificates and am trying to figur= e=0A= >> out how to do the following:=0A= >> -> For an /etc/exports file with...=0A= >> /home -tls -network 192.168.1.0 -mask 255.255.255.0=0A= >> /home -tlscert=0A= >>=0A= >> This syntax isn't implemented yet, but the thinking is that clients on t= he=0A= >> 192.168.1 subnet would use TLS, but would not require a certificate.=0A= >> For access from anywhere else, the client(s) would be required to have a= =0A= >> certificate.=0A= >=0A= >My gut reaction: that doesn't sound like a good idea.=0A= Yep, I thought that the stuff in the certificate was encrypted in a way tha= t the=0A= client couldn't see it. I now see that isn't the case.=0A= =0A= >Trusting the local network to be secure is pretty risky, in general.=0A= Well, for my personal case, the subnet has a few machines plugged into it= =0A= around my desk and wifi isn't enabled on the modem/NAT gateway, so=0A= I'm fairly confident the local machines are ok.=0A= To be honest, I don't need encryption on the wire, but since the phone=0A= company uses Huawei technology, I could see some wanting the data=0A= encrypted on the wire, if the data were sensitive.=0A= This case is meant to be easy to do, since the clients don't have to have= =0A= certificates.=0A= =0A= I am trying to provide whatever people might need/want when I implement=0A= this. The rest is obviously up to them.=0A= =0A= >> A typical client mounting from outside of the subnet might be my laptop,= =0A= >> which is using wifi and has no fixed IP/DNS name.=0A= >> --> How do you create a certificate that the laptop can use, which the N= FS=0A= >> server can trust enough to allow the mount?=0A= >=0A= >You can give your laptop a certificate for an arbitrary name, provided tha= t=0A= >the NFS server knows to "validate" that name in an appropriate fashion. (= I=0A= >don't remember what draft-ietf-nfsv4-rpc-tls says about this validation.)= =0A= As you note below, creating a site local CA is probably appropriate and the= =0A= server should be able to check that the certificates were signed by this.= =0A= (I haven't quite figured out how to do this yet. I think I've created the C= A=0A= and used to sign a client certificate, but haven't yet gotten the server da= emon=0A= to verify it. (Playing with SSL_set_verify_locations() to try to get it to = work.;-)=0A= =0A= >> My thinking is that a "secret" value can be put in the certificate that = the NFS=0A= >> server can check for.=0A= >> The simplest way would be a fairly long list of random characters in the= =0A= >> organizationName and/or organizationUnitName field(s) of the subject nam= e.=0A= >> Alternately, it could be a newly defined extension for X509v3, I think?= =0A= >=0A= >It would be better to just make a site-local CA and trust everything it=0A= >issues (which, admittedly, is not the greatest option itself.)=0A= I had thought this would be too much work, but it seems fairly straightforw= ard,=0A= so this is what I am now working on.=0A= =0A= >> Now, I'm not sure, but I don't think this certificate can be created via= =0A= >> a trust authority such that it would "verify". However, the server can= =0A= >> look for the "secret" in the certificate and allow the mount based on th= at.=0A= >>=0A= >> Does this sound reasonable?=0A= >=0A= >I'm not sure what goal you're trying to achieve by this "security through= =0A= >obscurity".=0A= Yes. I now see it is the CA stuff that can stay secret.=0A= =0A= >> Also, even if the NFS client/server have fixed IP addresses with well kn= own=0A= >> DNS names, it isn't obvious to me how signed certificates can be acquire= d=0A= >> for them?=0A= >> (Lets Encrypt expects the Acme protocol to work and that seems to be=0A= >> web site/http specific?)=0A= >=0A= >RFC 8738 specifies the ACME protocol for validating IP addresses.=0A= I had looked at an older RFC, where it seemed to be web site specific.=0A= Since none of my stuff has fixed well known DNS names, I'm not going to=0A= worry about using an established CA for now.=0A= =0A= Thanks to everyone for their comments.=0A= I may respond to some of the other posts, but I'm figuring things out for n= ow.=0A= =0A= rick=0A= =0A= -Ben=0A=