Re: [secdir] secdir review of draft-ietf-netconf-zerotouch-22
Kent Watsen <kwatsen@juniper.net> Fri, 27 July 2018 02:42 UTC
Return-Path: <kwatsen@juniper.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D26A12785F; Thu, 26 Jul 2018 19:42:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQ_6VXF6yCz6; Thu, 26 Jul 2018 19:42:12 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4949E127333; Thu, 26 Jul 2018 19:42:12 -0700 (PDT)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6R2dwxO030349; Thu, 26 Jul 2018 19:42:11 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=Yeby97JpZtt3aC730P4twF8SOBc8wDOr2ARDrklQ9Mo=; b=T4+oMacMvo3mwoWktUYE/a7JsKYcIlF39CwVOxe0jZCuer19wIFb4HGPBsBBj2pU80r7 h0x0LolvuNHtaje4wavNboNRiATY6TIZbjeengfM5bRWArqrVcfykdDU9ReuDOxHGyLy TFQVCB5pNo3Kq1yClGkODWXGZ0lntJGLA0Unp+5PeitYqeN9kVFYwcxkBv0eljtooXwM WNRu9jtQIo73GSAd6PjKt5x7QgMXQxcL5UHC2QDxw8DjmFYDCjFP56Q8Hx5/rG+cgZra Jy5Xpu42k3iCB72fZTItJWvFI5iQHsobAq2zlm1E11htzw+1yRlf168zBL+TCoL4/SOg Bw==
Received: from nam04-bn3-obe.outbound.protection.outlook.com (mail-bn3nam04lp0115.outbound.protection.outlook.com [216.32.180.115]) by mx0b-00273201.pphosted.com with ESMTP id 2kfp3r0fhm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 26 Jul 2018 19:42:11 -0700
Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB4104.namprd05.prod.outlook.com (52.135.199.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.5; Fri, 27 Jul 2018 02:42:09 +0000
Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::84c5:999c:9159:d416]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::84c5:999c:9159:d416%2]) with mapi id 15.20.0995.014; Fri, 27 Jul 2018 02:42:09 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: David Mandelberg <david+work@mandelberg.org>, "draft-ietf-netconf-zerotouch.all@ietf.org" <draft-ietf-netconf-zerotouch.all@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: secdir review of draft-ietf-netconf-zerotouch-22
Thread-Index: AQHUI6TomGkNAzmsB0eB34I+6n1ia6SiHHoA
Date: Fri, 27 Jul 2018 02:42:08 +0000
Message-ID: <47EEE9B6-5BC2-4A1F-ABB2-2ACB1C494545@juniper.net>
References: <361393b0-6666-08ff-bdf4-3ba3bf4323c7@mandelberg.org>
In-Reply-To: <361393b0-6666-08ff-bdf4-3ba3bf4323c7@mandelberg.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR05MB4104; 6:3MOK9rGgxrlfPT5H/jGDnBX7UjQQ5ddW+fze/nvm9aS73VkztvCEiDfL2j4GhuzPROm6KFxxKVzahHMTFD6q2FF7QpsasOxFldFtUyV9ryAkwM4jAri7wXEueGNOSv5/dBUYojGUiLLkl7ntly/0A6qR/XQBE/zoawjHY3Qt0ysx6EnGxl5YbsKv7tdIGixE8Ksb4f2g7J91LfAxpabhKtd03kQNgl7w/8PvskekGS0LSGSqiCCdWsp2h16HJrtqfBq7AlH9nuR2csFwaEJWMwG9vq51h4un2YxTnGtz7qefJMh3RLPHM5g5bqe0KP9cMZMiM0vN6tH2gARxiBeuwTLvY2UYrs2m09g786fWBIO2f+u2EQMxoIIvZ+9QfFhm9iJE7dk/0iw9XFglBTm3V7oRKujeJ0BlwlUqR/Z2p3BqNCdxjKruXhNHTu/ha9ZCAq2iT9ezhldQTnSja38Fhw==; 5:09MeGSj0DnytLiXhxAaz9aQF3RSOWnd4kSi5NE8EWamQnlErG0VSi2+QHzuWOnqvKr4fj7hh+2+4m097IkswTUWgQmJqd8ELqmg9SXRB2kRO1xXrzk3RFxcAbaMaPm8x8Il3G2VNaa6xzb47Kc6UE1QzGxWo/tzVnMMfstScd2M=; 7:6LNoJEJq1Dp8GSiBP1YZ9uWJGfSJbVzZMRhB0dg2E/NknphpVaRr7Gk8B9GVkfAby3uF/b2qiih9F4eOAzSc8U2ks3NScrw+q8OhStMGjF0LCiEOFSedO3CbHegmCicQQgHnbNHWQffvCYC+Cxd6U/slY3ylxXLzZwx338C6agzrSzPmprqLqg182AO7f86cWfE+6KtvANT77SPr/WfETiDrqCDH2C608OjYTERCe5fNxU9HWslK/bFBPGILQ/PS
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 46f51c24-09a8-494e-4fbd-08d5f36a8c7b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4104;
x-ms-traffictypediagnostic: BYAPR05MB4104:
x-microsoft-antispam-prvs: <BYAPR05MB4104EE1E4693E75678D3C5D2A52A0@BYAPR05MB4104.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(60795455431006)(158342451672863)(209352067349851)(192374486261705)(788757137089);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB4104; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4104;
x-forefront-prvs: 07467C4D33
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(346002)(136003)(39860400002)(376002)(189003)(199004)(51444003)(478694002)(58126008)(8936002)(7736002)(83716003)(99286004)(82746002)(110136005)(68736007)(345774005)(316002)(86362001)(106356001)(25786009)(11346002)(6116002)(2201001)(53936002)(446003)(3846002)(81166006)(6246003)(2906002)(81156014)(305945005)(2900100001)(8676002)(97736004)(14444005)(966005)(66066001)(36756003)(6436002)(478600001)(14454004)(229853002)(2501003)(2616005)(476003)(6306002)(5660300001)(6506007)(5250100002)(76176011)(26005)(102836004)(186003)(6512007)(486006)(105586002)(256004)(6486002)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4104; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: a67NAjCyfylW4PttQwItUoTmY3x6MzpimVZhVMMaJdbuULn+1LVB/uvD6k5DQqa1pTbWJhCUro4ES33hRZQenghaKxhsSrHfrGIjdih4mr8WXbXG2JMIFNwcuGW8gLX3f+a4SbdhVzqXB8jOa1b3Kw3rA1aIF6Pr3JCB9UegdwSG1l74KcihVcdPhNZoqvSReg/Qe85ka1dYYj0XIY6RDuh6VkX0m3soVtlE25hpNKZmrutQBsF6kR1sXRH1nga8W0Rzrajq46RQs0opWz6FxA7ET5T4ts2PkDZ+VU6KzoVBKVr/9bUshc/WBNRh+Nai7OHSLsGec/XEYk7m3qR9tvnuXaw25gDOI/JFv4AANgw=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <6AA22ACC73EE794487FE89EE7F9AD466@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 46f51c24-09a8-494e-4fbd-08d5f36a8c7b
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2018 02:42:09.0205 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4104
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-26_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807270023
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Q3RV9XxbvPMGX5CeeRMdkgME2JE>
Subject: Re: [secdir] secdir review of draft-ietf-netconf-zerotouch-22
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Jul 2018 02:42:16 -0000
Hi David, Thank you for your review! Please find comments below. Kent > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The summary of the review is Almost ready. > > Is there any protection against old signed Zero Touch Information? I see > that Ownership Vouchers and Owner Certificates both have mechanisms for > expiration (and for certs, revocation), but I don't see anything > comparable for redirect or onboarding information. If an owner creates a > valid redirect or onboarding object and discovers a bug in it, is there > any way for the owner to make that object no-longer-valid without > getting an entirely new owner certificate and revoking the old cert? Is > that intentional? No, as you say, it is not possible to revoke signed data, other than to revoke the Owner Certificate associated with the private key that signed it. I wouldn't say that this was/is intentional, other than note that it seems consistent with assumptions made when the bootstrapping device obtains unsigned data from a trusted bootstrap server, in that the data is only protected by the bootstrap server's TLS certificate; the device can check that the certificate hasn't been revoked, but that doesn't say anything about the current validity of the data. Do you think a Security Consideration would cover it? Something like: Zerotouch information, regardless of how obtained or how trusted, does not have a validity assertion beyond the PKI used to authenticate it. Zerotouch information neither expires nor can be revoked. When provided by a trusted bootstrap server, the validity of the zerotouch information is implied by its availability. However, when zerotouch information is provided outside the purview of a bootstrap server (i.e., signed data on a removable storage device), its current validity is less certain. Operators are advised to ensure only accurate zerotouch information is ever published. In case inaccurate zerotouch information is published, or otherwise deemed no longer valid, and it is deemed a security risk, the signing certificate SHOULD be revoked and a new one created having a chain to trust leading to the same 'pinned-domain-certificate' provided in the Ownership Voucher for the device. However, doing so, will necessarily affect the validity of any other previously published zerotouch information artifacts signed using the just-revoked certificate. It the need to do this is fairly common, operators can define an Owner Certificate per device. > It seems like this protocol places more trust in device manufacturers > than was previously required, but I don't see any discussion of that in > the security considerations. If necessary, is there any way to disable > zero touch, and configure a device manually? E.g., if the supply chain > is presumed-secure, but the manufacturer's well-known bootstrap server > is compromised, is there any way to securely provision a new device? Regarding placing more trust in device manufacturers, and a potential Security Considerations statement, I'm trying to determine what statements you're looking for. But first, I think you mean "well-known bootstrap servers" more so than "manufacturers". AFAIK, the draft never says in normative text that the well-known bootstrap servers are hosted by the manufacturer (though entirely possible and somewhat likely). So maybe a couple Security Consideration statements related to: 1) the security issue that the well-known bootstrap server may have been compromised. Though, it seems that this is a statement that any TLS-protected resource could make. 2) the privacy issue that the information provided to the well-known bootstrap service may be visible to others (e.g., admins of the bootstrap server) if not encrypted. Are these what you had in mind? If not, can you please jot down a few lines capturing what you hope to see? Regarding "is there any way to disable zero touch, and configure a device manually", I think that this is outside the scope of the document. Some vendors may lock down a device such that it can only activate thru the bootstrapping process, while other devices simultaneously enable console access. Regarding "is there any way to securely provision a new device" when a well-known bootstrap server is known to be compromised. My first thought is, if it's known to be compromised, then it's also likely patched. But let's say the issue is more like an operator not trusting a particular well-known bootstrap server for some other reason, and would like to never allow devices to obtain bootstrapping data there...then the options are slim, an external firewall policy blocking access to that bootstrap server may be needed. > Section 3.4 mentions a device identify certificate. I assume the > public keys in those certificates are unique per-device? If not, > I want to think a bit more about possible attacks where the > attacker correlates encrypted artifacts without being able to > decrypt them. Yes, probabilistically/cryptographically unique keys per device. > Section 5.4 says what to do "if the revocation status is not > attainable". What does that mean precisely? E.g., I assume failure to > download a CRL, absence of a CRL in the CMS data, and failure to contact > an OCSP server all count. But what if the device acquires a valid CRL > that is stale (nextUpdate < now)? Yes, exactly, it meant to cover those cases, as well as the "stale" case, though I admit the text doesn't exactly say it. How about this? OLD if the revocation status is not attainable NEW if suitably-fresh revocation status is not attainable > If I'm understanding correctly, the intent of well-known bootstrap > servers is that the manufacturer can redirect devices to customer > bootstrap servers that have the actual onboarding information. But I > also don't see any reason that a (potentially compromised) trusted > manufacturer's bootstrap server couldn't provide the onboarding > information directly. It's probably easier to secure the (potentially > offline) private keys used to sign ownership vouchers than it is to > secure the (presumably highly available, online) well-known bootstrap > servers. So it seems like the system as a whole could be more secure if > well-known bootstrap servers could only provide untrusted redirects. First, let's replace "manufacturer" with "well-known bootstrap server" above. But, to your main point, absolutely, any bootstrap-server could return either redirect or onboarding information, and perhaps it is a feature for some well-known bootstrap servers to do so. And yes again, the keys for an online service are potentially more easily compromised, perhaps a Security Consideration for the use of HSMs similar to [1] would help? While I agree with your conclusion, it brings into question what "trusted" means. What about an OCSP server with its online key? If the manufacturer no longer deems (through audits or whatever) that a well-known bootstrap server is no longer trusted, it can revoke the bootstrap server's certificate. Just wondering, is this really a problem? Can a Security Consideration be used to address this to your satisfaction? [1] https://tools.ietf.org/html/draft-ietf-anima-voucher-07#section-7.2 > I don't understand the error cases around the "flag to enable zerotouch > bootstrapping" in section 5.1. How exactly is that flag set to false? Is > it by the initial configuration step in section 5.6? If that's where the > flag is set to false, won't some owners forget to include that in their > config? Also, how atomic is the application of initial configuration? Is > there any possible case in which some of the initial configuration can > be applied without touching the flag, so that the device appears to be > correctly configured, but will try to bootstrap again on the next > reboot? Conversely, can the flag be set to false without the device > being fully configured? (I don't think that's a security issue, just > potentially a management headache.) Yes, the initial-step in Section 5.6. Yes, some operators may forget (though they will learn). The config is intended to either be applied completely or not at all. The second paragraph in section 5.6 says "If the device encounters an error at any step, it MUST NOT proceed to the next step." Perhaps the 6th paragraph in that section could could state that an "error" constitutes anything less than 100%? > Section 9.4 says to assume owner certificates "are not revokable" if > there's no accurate clock. Is there no value in checking for a CRL or > OCSP response, even without the ability to determine if it's recent? It > seems to me that checking with an active server (CRL Distribution Point > or OCSP server, as opposed to a stapled CRL or OCSP response) would make > it significantly harder (not infeasible, just harder) for an attacker to > use a revoked cert against a device with no clock. Okay, fair point, a live response sort of reflects "now", regardless what the device clock says. That said, without an accurate clock, the device wouldn't be able to validate the signing certificate and, if provided over an HTTPS transport, it wouldn't be able to validate the server's end-entity certificate either. In fact, certain device bad clock values might actually block the TLS connection due to it being outside the end-entity cert's validity period. Ugh. Currently the text says that device "implementations should assume [things] are not revocable" - do you want to add a text like "but MAY check 'current' revocation using on online CRL Distribution Point or OCSP server"? BTW, the end of this section says "Implementations SHOULD NOT rely on NTP for time, as NTP is not a secure protocol." - any thoughts on this statement? Thanks again, David. Kent
- [secdir] secdir review of draft-ietf-netconf-zero… David Mandelberg
- Re: [secdir] secdir review of draft-ietf-netconf-… Kent Watsen
- Re: [secdir] secdir review of draft-ietf-netconf-… David Mandelberg
- Re: [secdir] secdir review of draft-ietf-netconf-… Kent Watsen
- Re: [secdir] secdir review of draft-ietf-netconf-… David Mandelberg
- Re: [secdir] secdir review of draft-ietf-netconf-… Kent Watsen
- Re: [secdir] secdir review of draft-ietf-netconf-… David Mandelberg
- Re: [secdir] secdir review of draft-ietf-netconf-… Kent Watsen
- Re: [secdir] secdir review of draft-ietf-netconf-… David Mandelberg