Re: [Netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)
ianfarrer@gmx.com Fri, 07 December 2018 14:36 UTC
Return-Path: <ianfarrer@gmx.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48510128CF2; Fri, 7 Dec 2018 06:36:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 mX0eDbsA-fz0; Fri, 7 Dec 2018 06:36:03 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F17D1252B7; Fri, 7 Dec 2018 06:36:03 -0800 (PST)
Received: from [192.168.1.228] ([80.159.240.8]) by mail.gmx.com (mrgmx101 [212.227.17.174]) with ESMTPSA (Nemesis) id 0LcWSI-1hDifd38uE-00jrjs; Fri, 07 Dec 2018 15:35:55 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: ianfarrer@gmx.com
In-Reply-To: <154390493154.31734.13025584839857369253.idtracker@ietfa.amsl.com>
Date: Fri, 07 Dec 2018 15:35:53 +0100
Cc: The IESG <iesg@ietf.org>, netconf-chairs@ietf.org, draft-ietf-netconf-zerotouch@ietf.org, Bert Wijnen <bwijnen@bwijnen.net>, netconf@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <959B684C-27AF-49FA-93F0-5ED675EC0D66@gmx.com>
References: <154390493154.31734.13025584839857369253.idtracker@ietfa.amsl.com>
To: Benjamin Kaduk <kaduk@mit.edu>
X-Mailer: Apple Mail (2.3445.101.1)
X-Provags-ID: V03:K1:jYMPq4ObG/0FqjOBvBYXUxPVB3MK3mtxtaM5rqfw8mNfr3wRVn3 qTeebSBmbFL8XaIlku6oqZsl1kMnbZ50WZuoXQtlXpntCUZ6mI0fpA+zYb51e+MW7fFyiyE sfEGKupvobEwxe7SVVMVh+bYQedMAxG8UPlFw5GJJwWo2Y5EuwBcn8zBfC6eJeMo/vgJpEO 3umQSN4Ss+D+9N8JMorfQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:QDdQNOlj9iI=:nHxAvaW9VWaoMoEXKy3jcu 474TUI/WjWgoCMvJ/nnVaoC8GGkJ22N9D9IxyG+lpUd4mGdM3ShZz2xondGZh6HyM4eXnNXTX esS8QuyYObh9atXvjGAcIWlAfUBuPu2qyWWFq6AAjjFicpNgjvcyRObRP+DDAzJMo8+PMl+y3 C2pcDyv46Pip+EOVt9hj5G0qTY65GJF87z+Z//SmxR8TOlpxRn47tyycUTqvBLeB4YjZNlM3t AljXPkwwRpRPGCvMgkvi6erYdw28MjqTZs5oVmcdMJGuNQsfPY3ADwljCB13H4oRUZlm8bXmD 7OYHH/H/wVKHQSXGvLfhU+0O2wb3uouY4IvHPUynfligqpladJOJUzcLZ+SlDqqZiBzhWSXyX mIOwB7ON/vvjHSakGU67F2nWBFMgPaS9el7Mbfwujh6yErHsUlZBxCL/XbY76HruzD6iS2w5b Ls+VGLAe68a7WzihUK/2KXl2yThHKVGXgQU6fQLIPVYLv+0C9cJXWMDxFBs9Z4ONhMktSt54q lKnr07tvf0Z3t1lo17BrVBU1uBuIho4adXWAJ63Pb4U8l794tfD7N06enBixP2QHH0Lyx4E3i EfyWBNGARxtCl8n5PRKmyDSwb+It7yR19QzNgcPlrPzYD3rerCPw4lp/X//FHhS4jXBDT+nuw vp4pqv9REinzAOkYE07TnEsU0t8NlkhWyTeUwM5pl5q1YETgx5Kbr9E15keIWf7FFUaKzx9K0 KHrHQ6IheQdYnIsGUzn9EecvsmlI8Jx9stvwOMa4OIT2X6IT5cgpHQH1rvy96ogtNun44sDSq yhntpgjPMC4VZtKZfoFMXzfQRkpkyE6qzzFgT+c8ktqToVc9Hkomt+1KpaTPMQ7EBzAUQlmXo dBGfGf9xs/uUWMTCkRgMnZYB5k2OyVWXL1h8nhddmejLyRJ17jsPCeifbEl+ki
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/NiVv4Av1L9hSqEq8YAR9VDJgD9Y>
Subject: Re: [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
Precedence: list
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: Fri, 07 Dec 2018 14:36:07 -0000
Hi Ben, Thanks for the comments. Please see below, specifically regarding your point on the DHCP section (8.1). Thanks, Ian > On 4. Dec 2018, at 07:28, Benjamin Kaduk <kaduk@mit.edu> wrote: > > 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? > [if - Yes, the current text is not consistent between client and server. I propose replacing the server paragraph with the following: The server’s DHCP message MUST contain only a single instance of the OPTION_V4_ZEROTOUCH_REDIRECT’s 'bootstrap-server-list’ field. However, the list of URIs in this field may exceed the maximum allowed length of a single DHCPv4 option (per [RFC3396]). If the length of 'bootstrap-server-list’ is small enough to fit into a single instance of OPTION_V4_ZEROTOUCH_REDIRECT, the server MUST NOT send more than one instance of this option. If the length of the 'bootstrap-server-list’ field is too large to fit into a single option, then OPTION_V4_ZEROTOUCH_REDIRECT MUST be split into multiple instances of the option according to the process described in [RFC3396]. ] > ---------------------------------------------------------------------- > 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 mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf
- [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