[Netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Tue, 04 December 2018 06:28 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86ACD127B4C; Mon, 3 Dec 2018 22:28:51 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-netconf-zerotouch@ietf.org, Mahesh Jethanandani <mjethanandani@gmail.com>, Bert Wijnen <bwijnen@bwijnen.net>, Bert Wijnen <bwietf@bwijnen.net>, netconf-chairs@ietf.org, mjethanandani@gmail.com, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154390493154.31734.13025584839857369253.idtracker@ietfa.amsl.com>
Date: Mon, 03 Dec 2018 22:28:51 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/a0vUuE6UmDS4Wxv16cNPbCxG7X0>
Subject: [Netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Dec 2018 06:28:52 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-netconf-zerotouch-25: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- First off, thanks for this clear and considered document and design; it really lays out the scenario of applicability and the functionality quite well. I just have a couple lingering places that we might want to nail down a little bit tighter... (1) SSH key formats The module in Section 7.3 says: leaf-list ssh-host-key { type binary; description "The binary public key data for this SSH key, as specified by RFC 4253, Section 6.6, i.e.: string certificate or public key format identifier byte[n] key/certificate data."; reference "RFC 4253: The Secure Shell (SSH) Transport Layer Protocol"; but RFC 4523 Section 6.6 says: The key type MUST always be explicitly known (from algorithm negotiation or some other source). It is not normally included in the key blob. Certificates and public keys are encoded as follows: string certificate or public key format identifier byte[n] key/certificate data How is the key type known for the SZTP usage? (2) Privilege escalation by design There's text in Section 2.1 (and, really, throughout) that indicates that a device being boostrap should allow a trusted bootstrap server to behave as (i.e., supply) a trust anchor for verifying a different service. In some sense this is elevating an EE cert to a CA cert, and I had hoped to see some discussion of this escalation in the security considerations. (Same for the owner cert, though there's a stronger argument that the owner should be considered fully privileged here.) (3) Nonce length Section 7.3 describes the nonce leaf: leaf nonce { type binary { length "8..32"; There is probably some discussion to be had about the minimum nonce length (not necessarily in the document itself). Do you have a pointer handy to previous disucsions or do we need to have it now? (I do see that this is just following RFC 8366, so hopefully this is an easy question.) (4) OPTION_V4_ZEROTOUCH_REDIRECT repeated instances (In Section 8.1.) I think I may just be misunderstanding things here, but aren't As the list of URIs may exceed the maximum allowed length of a single DHCPv4 option (255 octets), the client MUST implement [RFC3396], allowing the URI list to be split across a number of OPTION_V4_ZEROTOUCH_REDIRECT option instances. and The DHCPv4 server MAY include a single instance of Option OPTION_V4_ZEROTOUCH_REDIRECT in DHCP messages it sends. Servers MUST NOT send more than one instance of the OPTION_V4_ZEROTOUCH_REDIRECT option. in conflict about sending more than one instance of OPTION_V4_ZEROTOUCH_REDIRECT? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Should we consider recommending AuthEnvelopedData throughout instead of just EnvelopedData? TLS and CMS are probably good enough about adding context in their signatures (well, provided modern versions are used) that we don't get too much heartburn about reusing the same key directly for both zerotouch decryption and TLS client certificates, but it's generally the sort of thing that we frown upon. I a little bit wonder if we want references for TLS and/or HTTP client authentication. Section 2.5 of RFC 8040 might be enough (though it is of course not citing TLS 1.3). (Are there generic RESTCONF internationalization considerations? I see 8040 say "just use UTF-8", but is more needed?) Section 1.2 Network Management System (NMS): The acronym "NMS" is used throughout this document to refer to the deployment specific nit: deployment-specific (with hyphen) Section 2.1 Does RFC 8340 require a "ro" (or similar) to appear in the tree diagram? (Both here and in §2.2.) Section 3.2 Do we want to impose any ordering requirements on the certificate chain (e.g., owner cert must come first, each cert SHOULD certify the one immediately prior to it, etc.)? Section 3.4 Thank you for including the motivating text about sign-then-encrypt. I do wonder if it's worth saying anything about why the well-publicised security risks of mac-then-encrypt do not apply. (The authors of draft-campbell-sip-messaging-smime probably already have some text that could be used, but it doesn't seem to be in the public view yet.) Section 4.1 Mounting all filesystems found on removable devices can be a security risk, with intentionally malformed filesystem images causing system compromise in some cases. Section 4.2 I agree with Adam about registering "zerotouch" (and the name is perhaps overly generic?). I'm also not sure I properly understand the "zt-info"/zt-* TXT records' usage; would they need to be registered akin to draft-moonesamy-dnsop-special-use-label-registry? Section 5.3 This is the first time we talk about "serial number" as device identity; maybe a forward-reference is in order? Does the device have any reason to track whether the incoming artifact is encrypted (whether at the CMS layer or the transport layer)? I can't think of one, but sometimes this is useful information in other settings. If the zero touch information artifact contains onboarding information, and trust-state is FALSE, the device MUST exit the recursive algorithm (as this is not allowed, see the figure above), returning to the bootstrapping sequence described in Section 5.2. Otherwise, the device MUST attempt to process the onboarding information as described in Section 5.6. In either case, success or failure, the device MUST exit the recursive algorithm, returning to the bootstrapping sequence described in Section 5.2, the only difference being in how it responds to the "Able to bootstrap from any source?" conditional described in the figure in the section. Does this "either case" refer to just the processing of onboarding information, or the exit vs. attempt to process cases? (I assume the former, but perhaps some editorial work is in order.) If the zero touch information artifact is signed, and the device is able to validate the signed data using the algorithm described in Section 5.4, then the device MUST set trust-state to TRUE; otherwise, if the device is unable to validate the signed data, the device MUST set trust-state to FALSE. Note, this is worded to cover the special case when signed data is returned even from a trusted bootstrap server. Having read Section 5.4, I'm still unsure where the special handling for this special case is described. Section 5.5 Processing redirect information is straightforward, the device sequentially steps through the list of provided bootstrap servers until it can find one it can bootstrap from. nit: I think this is a comma splice. Section 5.6 Regardless the reporting-level indicated by the bootstrap server, the device MAY send progress reports beyond the mandatory ones specified for the given reporting level. nit: "Regardless of" When the onboarding information is obtained from an untrusted bootstrap server, the device MUST NOT send any progress reports to the bootstrap server. I'm not sure if I would want a parenthetical "(that is, the onboarding information was authenticated at the CMS layer)", but I would think about adding one. The device MUST parse the provided onboarding information document, to extract values used in subsequent steps. Whether using a stream- based parser or not, if there is an error when parsing the onboarding This line makes me consider the scenario where a stream-based parser is used with a trusted bootstrap server and no CMS-layer signature. At the TLS layer, a truncation attack by the network is possible, and if truncation is not detectable at the application layer, the device could end up misconfigured with neither party aware (unless there's an additional response or something that I'm forgetting about). I think that for the XML and JSON formats we know and love, truncation would make for a malformed stream due to the outermost scope container, but please correct me if I'm wrong. There are probably some security considerations to mention w.r.t. any future new encodings of this data model, though. * Most steps are atomic. For instance, when a commit fails, it is expected to have no impact on the configuration. Similarly, if the error occurs when executing a script, the script will gracefully exit. As a reader it's hard to tell if this is giving guidance to script authors or consumers. Section 6.2 "base64encodedvalue==" is pretty cute, though maybe we could add some trailing numbers to provide different values for the different fields? Section 6.3 The YANG module boilerplate is still on the RFC 2119 version of BCP 14 (not RFC 8174). Section 7.2 If we're going to say "and receives signed data in the response", maybe we could actually give an example that shows the (base64'd) CMS structure that corresponds to the signature? Not necessarily the whole payload, but enough to see the outer structure at least... Section 7.3 The YANG module boilerplate is still on the RFC 2119 version of BCP 14 (not RFC 8174). enum "boot-image-installed-rebooting" { description "Indicates that the device successfully installed a new boot image and is about to reboot. After sending this progress type, the device is not expected to access the bootstrap server again."; Is this just scoped to the current connection/session? (As opposed to "bootstrap-complete", which probably is a global statement.) container trust-anchor-certs { [...] The CMS MUST contain only a single chain of certificates. The device's end-entity certificate MUST only authenticate to last intermediate CA certificate listed in the chain. I'm not sure whether "authenticate to" means that the CA cert directly certifies or is the trust anchor. Could we maybe use language like "directly certifies the [next|previous]" certificate? Also, the split of references of RFC 6187 for trust-anchor-certs but RFCs 5280 and 5652 for trust-anchor-cert seems unusual, since potentially all three would be relevant for both nodes, if I understand correctly. Section 9.1 At this point draft-ietf-ntp-using-nts-for-ntp exists, though I don't know whether it's appropriate to be citing it yet. Section 9.6 There is perhaps some room for discussion of the consequences of the device telling the bootstrapping server whether the device thinks the connection is trusted, in that it gives an attacker information about the target. (Granted, it does not seem like much information, but it might be cleaner to define the semantics of the node as being whether the client would like the server to sign its responses at the application layer, which need not have complete overlap with whether the client considers the server to be trusted. Section 9.8 Does recommending frequent private key refreshes actually help in environments where revocation is unusable (i.e., by virtue of not having reliable time)? (If not, perhaps that caveat should be more explicit here, even though it is mentioned in Section 9.1 already.) Section 9.10 I would suggest also mentioning the (lack of) mitigations possible if the operator does not trust all the pre-configured authorities designated by the manufacturers. Section 9.11 revealing (e.g., network topology, firewall policies, etc.). It is RECOMMENDED that operators encrypt the bootstrapping data when its contents are considered sensitive, even to the administrators of a bootstrap server. I don't understand what is meant by "even to the administrators of a bootstrap server"? Section 9.12 nit: the last word is "revoked". Section 9.13 Implementations should be aware that signed bootstrapping data only protects the data from modification, the contents are still visible to others. [...] nit: this is a comma splice This information should be considered sensitive and precautions should be taken to protect it (e.g., encrypt artifact with device public key). nit: I think it's more conventional to "encrypt to" a public key than "encrypt with" one. Section C.3 We could perhaps recommend ecdsa-sha2-* keys instead of ssh-rsa keys. 4. Otherwise, if redirect information is found, the device iterates through the list of specified bootstrap servers, checking to see if it has bootstrapping data for the device. [...] The "it" is perhaps ambiguous; I would suggest "each server in turn".
- [Netconf] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… ianfarrer
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Kent Watsen
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Kent Watsen
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Benjamin Kaduk
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Benjamin Kaduk
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Kent Watsen
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Benjamin Kaduk
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Kent Watsen
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Kent Watsen
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Dave Crocker
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Benjamin Kaduk
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Kent Watsen
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Kent Watsen
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Dave Crocker
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Benjamin Kaduk
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Dave Crocker
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Dave Crocker
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Dave Crocker
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Adam Roach
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Benjamin Kaduk
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Kent Watsen
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Adam Roach
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Kent Watsen
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Benjamin Kaduk
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Kent Watsen
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Benjamin Kaduk
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Kent Watsen
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Adam Roach
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Benjamin Kaduk
- Re: [Netconf] Benjamin Kaduk's Discuss on draft-i… Kent Watsen