Subject: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-16.txt

From: [email-masked]
Date: Tue, 29 Aug 2017 16:56:50 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration WG of the IETF.

        Title           : Zero Touch Provisioning for NETCONF or RESTCONF based Management
        Authors         : Kent Watsen
                          Mikael Abrahamsson
                          Ian Farrer
	Filename        : draft-ietf-netconf-zerotouch-16.txt
	Pages           : 65
	Date            : 2017-08-29

Abstract:
   This draft presents a secure technique for establishing a NETCONF or
   RESTCONF connection between a newly deployed device, configured with
   just its preconfigured initial state (e.g., factory default
   settings), and its deployment specific network management system
   (NMS).

Editorial Note (To be removed by RFC Editor)

   This draft contains many placeholder values that need to be replaced
   with finalized values at the time of publication.  This note
   summarizes all of the substitutions that are needed.  Please note
   that no other RFC Editor instructions are specified anywhere else in
   this document.

   Artwork in the IANA Considerations section contains placeholder
   values for DHCP options pending IANA assignment.  Please apply the
   following replacements:

   o  "OPTION_V4_ZEROTOUCH_REDIRECT" --> the option code assigned for
      the "DHCPv4 Zero Touch Option" option

   o  "OPTION_V6_ZEROTOUCH_REDIRECT" --> the option code assigned for
      the "DHCPv6 Zero Touch Option" option

   Artwork in this document contains shorthand references to drafts in
   progress.  Please apply the following replacements:

   o  "XXXX" --> the assigned RFC value for this draft

   Artwork in this document contains placeholder values for the date of
   publication of this draft.  Please apply the following replacement:

   o  "2017-08-29" --> the publication date of this draft
   Please update the following references to reflect their final RFC
   assignments:

   o  I-D.ieft-netconf-netconf-client-server

   The following one Appendix section is to be removed prior to
   publication:

   o  Appendix A.  Change Log

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-16
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-zerotouch-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-zerotouch-16

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Kent Watsen <[email-masked]>
Date: Wed, 30 Aug 2017 00:16:06 +0000

Hey Folks,

This update addresses most of the comments that have been received to date.  Please review the change log for details:  https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-16#appendix-B.17.

If you posted comments before, please review to see if all your issues have been addressed.  If you've been out on PTO for a while and have been waiting for a good version to review, before another/final LC begins, this is it.

Regarding what's left, the issues are:
 - supporting white boxes (raised by Dean and Radek)  
 - privacy issue when sending URL to an untrusted server (raised by Kent)
 - potential further tightening of text, or is it enough now? (raised by Rob)

Thanks,
Kent  // contributor

---

From: Kent Watsen <[email-masked]>
Date: Thu, 31 Aug 2017 01:20:49 +0000

Below are my proposals for the two remaining issues identified in my previous
email:
  1) supporting white boxes (raised by Dean and Radek)  
  2) privacy issues when connected to an untrusted server (raised by Kent)

For (1) my recommendation is to add a couple query parameters to the URL used
by devices when connecting to bootstrap servers:

  The "os-name" Query Parameter

   The "os-name" query parameter indicates the name of the operating system
   the device is running.  This parameter is only needed if it is possible 
   for the device, as identified by its <unique-id>, can run more than one
   type of operating system. This query parameter MUST be supported by
   servers needing to support such devices.

  The "os-version" Query Parameter

   The "os-version" query parameter indicates the version of the operating 
   system the device is running.  This parameter enables the server to
   dynamically generate an optimal response for the device negating,
   for instance, the need for a potentially expensive boot-image update.
   This query parameter MUST be supported by servers wanting to support
   such use-cases.

  PS: to be symmetric with these, we may want to add an "/onboarding-
      information/boot-image/version" leaf, to go along with the
      "/onboarding-information/boot-image/name" leaf.  Currently, it's
      assumed that both these values are somehow munged into the 'name'
      leaf (i.e., the boot-image's filename).

For (2), my recommendation is to add to the Security Considerations a
subsection called something like "Disclosing Information to Untrusted
Servers" as follows:

  This document enables devices to establish provisional connections to
  untrusted bootstrap servers, in order for the server to provide signed
  data to the device.  However, since the server is untrusted, it may be
  under the control of an adversary, and therefore devices should be
  cautious about the data they send in such cases.

  Already this document prevents devices from sending either their IDevID
  certificate or sending progress updates to untrusted servers, however
  potentially identifying values (e.g., unique-id, os-name, os-version)
  are still potentially encoded in the HTTP request sent to the servers.
  This information could be used by an adversary to mount an attack against
  the device.

  Device concerned about such disclosures should, when connected to an
  untrusted server, 1) use a 'unique-id' value that is not easily 
  associated to the type of device it is (e.g., salted-hash of its
  serial-number) and 2) be very selective about which of the optional
  query parameters it sends (ideally none).

  Building on top of the recursive nature of the solution presented in
  this document, a server seeing that a device is following the previous
  paragraph's recommendation, should return signed redirect information,
  not signed onboarding information, as would normally be expected.  The
  redirect information should point the device back to the same server 
  but, because the signed redirect information contained the trust anchor
  certificate for the server, the device would then establish a trusted
  connection to the server, and thereby be able to freely send data to
  the server, including its IDevID certificate, unique-id, query 
  parameters, and various progress updates.

Thoughts?  If no objections are raised in a few days, I'll proceed with
these updates.

Kent  // contributor