Secure Zero Touch Provisioning (SZTP)
draft-ietf-netconf-zerotouch-29

[Ballot comment]
Thank you for the good discussion and resolution on both my Discuss points and the Comments,
as well as for this clear and considered document and design; it
really lays out the scenario of applicability and the functionality quite
well.

[Ballot discuss]
[editing to reflect changes in the -26]

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...

(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).  That is, is a 64-bit nonce actually
secure for what we are asking of it, or do we need 128 bits?  Do you have a pointer handy to
previous discussions 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.)

[Ballot comment]
[original comment section preserved even though changes were made in response to it]

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".

[Ballot comment]
Thank you for addressing my DISCUSS and comments!

One nit remains:
Also, "URI" deserve to be a Normative Reference, as it defines the generic syntax you are referring to.

[Ballot discuss]
* Section 8.1

This should be easy to fix but this text about the cardinality of the option

"Servers MUST NOT send more than one instance of the OPTION_V4_ZEROTOUCH_REDIRECT option."

is contradictory to the following recommendation to use RFC3396 for long URLs *which will certainly result* in multiple options being sent. I would like personally like this to be a qualified MUST NOT (e.g. MUST NOT except for the long URL case) but I leave it up to the authors and the sponsoring AD to figure out the best way forward.

[Ballot comment]
* Please update the DHCPv6 (RFC3315) references to correspond to RFC8415 (Section 18.2 mainly for the client behavior and Section 18.3 for the server behavior) as it has been obsoleted.

* Thanks for using the DHCPv6 option guidelines properly for the option formats and cardinality. Greatly appreciated.

[Ballot comment]
I support Adam's and Alexey's DISCUSS points.

§1.2: I have a bit of discomfort in how the manufacturer/owner business model is encoded into this. In particular, is there any possibility of anonymous owners? How about secondary markets (i.e. transfer of a device between owners) without mediation by the manufacturer.)? But I see this is actually mentioned in the security considerations, so I don't really expect a change.

§3.1, 4th paragraph: The first sentence is convoluted; please consider breaking it into multiple simpler sentences.

- 6th paragraph: The first sentence is even more convoluted.

§5.6, 10th paragraph: I'm not sure how to interpret "MUST try". That doesn't seem verifiable.
-- first bullet under "implementation notes": is "roll out of" the same things as "roll back"?

§9.8:
- 4th paragraph: Can the "best practices" be cited or described? Otherwise, the normative "RECOMMENDED" seems pretty vague. (Or are the next few sentences intended to define those practices?

-5th paragraph: Paragraph is hard to parse.

[Ballot discuss]
Thank you for a well written document, it was a pleasure to read.
I have a small list of issues that I would like to discuss before recommending approval of this document:

In Section 5.3:

  If the zero touch information artifact contains redirect information,
  the device MUST, within limits of how many recursive loops the device
  allows, process the redirect information as described in Section 5.5.
  This is the recursion step, it will cause the device to reenter this
  algorithm, but this time the data source will definitely be a
  bootstrap server, as that is all redirect information is able to
  redirect a device to.

I think you need to specify a "max redirect" value in order to prevent intentional or unintentional misconfigurations. Without such limit it is trivial to introduce denial-of-service attack on naive device implementations.

2)
10.3.  The SMI Security for S/MIME CMS Content Type Registry

  IANA is kindly requested to add two entries in the "SMI Security for
  S/MIME CMS Content Type" registry (1.2.840.113549.1.9.16.1), with
  values as follows:

  Decimal  Description                            References
  -------  --------------------------------------  ----------
  TBD1      id-ct-zerotouchInformationXML          [RFCXXXX]
  TBD2      id-ct-zerotouchInformationJSON        [RFCXXXX]

  id-ct-zerotouchInformationXML indicates that the "zerotouch-
  information" is encoded using XML.  id-ct-zerotouchInformationJSON
  indicates that the "zerotouch-information" is encoded using JSON.

You define these values, but they are not used anywhere in the document.

It looks like you intended for this to be used in several places, for example:

3.1.  Zero Touch Information

  When the zero touch information artifact is unsigned, as it might be
  when communicated over trusted channels, the CMS structure's top-most
  content type MUST be one of the OIDs described in Section 10.3, or
  the OID id-data (1.2.840.113549.1.7.1), in which case the encoding
  (JSON, XML, etc.)  SHOULD be communicated externally.  In either

Did you intend to use the above OIDs here?

  case, the associated content is an octet string containing
  "zerotouch-information" data in the expected encoding.

[Ballot comment]
4.2.  DNS Server

  To use a DNS server as a source of bootstrapping data, a device MAY
  perform a multicast DNS [RFC6762] query searching for the service
  "_zerotouch._tcp.local.".  Alternatively the device MAY perform DNS-
  SD [RFC6763] via normal DNS operation, using the domain returned to
  it from the DHCP server; for example, searching for the service
  "_zerotouch._tcp.example.com".

I agree with Adam that "zerotouch" much be a registered as service name,
see

  Artifact to Resource Record Mapping:

      Zero Touch Information:  Mapped to a TXT record called "zt-info"
        containing the base64-encoding of the binary artifact described
        in Section 3.1.

      Owner Certificate:  Mapped to a TXT record called "zt-cert"
        containing the base64-encoding of the binary artifact described
        in Section 3.2.

      Ownership Voucher:  Mapped to a TXT record called "zt-voucher"
        containing the base64-encoding of the binary artifact described
        in Section 3.3.

So just to double check, these would be zt-info._zerotouch._tcp.example.com, etc?


8.1.  DHCPv4 Zero Touch Option

      o bootstrap-server-list: A list of servers for the
        client to attempt contacting, in order to obtain
        further bootstrapping data, in the format shown
        in [common-field-encoding].

[common-field-encoding] in this and subsequent sections looks like a reference to Section 8.3. Please fix before publication, as this looks like an undefined reference.


8.3.  Common Field Encoding

  Both of the DHCPv4 and DHCPv6 options defined in this section encode
  a list of bootstrap server URIs.  The "URI" structure is an option
  that can contain multiple URIs (see [RFC7227], Section 5.7).

    bootstrap-server-list:

This is confusing, because I believe the following is a single entry in the list, not the whole list syntax:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
    |      uri-length              |          URI                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+

    o uri-length: 2 octets long, specifies the length of the URI data.

    o URI: URI of zerotouch bootstrap server, using the HTTPS URI
      scheme defined in Section 2.7.2 of RFC7230.  URI MUST be in
      form "https://[:]".

So if I am correct above, please clarify this by changing "bootstrap-server-list:" to "bootstrap-server-list is a list of 1 or more items, each with the following syntax:" (Or something like this.)

Also, "URI" deserve to be a Normative Reference, as it defines the generic syntax you are referring to.

[Ballot 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?

[Ballot 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".

[Ballot comment]
Thanks for this well-written doc.

One quick question which wasn't fully clear to me from the text in the doc:
If onboarding fails at some point, is the device supposed to iterate over another bootstrapping source or stop completely?

One minor comment:
Maybe spell out TPM and provide a reference.

[Ballot discuss]
Thanks to everyone who worked on this document. I have one concern that I'd like
to discuss before the document is published. It's possible that I'm mistaken
about the way this is intended to work -- don't be shy about telling me I'm
wrong.

§4.2:

>  To use a DNS server as a source of bootstrapping data, a device MAY
>  perform a multicast DNS [RFC6762] query searching for the service
>  "_zerotouch._tcp.local.".  Alternatively the device MAY perform DNS-
>  SD [RFC6763] via normal DNS operation, using the domain returned to
>  it from the DHCP server; for example, searching for the service
>  "_zerotouch._tcp.example.com".

RFC 6763 §4.1.2 defers to RFC 2782 for the structure of DNS-SD records; and RFC
2782 indicates that these are of the format "_service._proto.name". In this
case, "service" is one of the services registered with IANA at
https://www.iana.org/assignments/service-names-port-numbers/
The service "zerotouch" is not registered in that registry, nor does this
document register it there.

Unless I'm confused about the way SRV records are intended to work, this
document needs to register "zerotouch" in the service name table indicated
above.

[Ballot discuss]
to discuss before the document is published. It's possible that I'm mistaken
about the way this is intended to work -- don't be shy about telling me I'm
wrong.

§4.2:

>  To use a DNS server as a source of bootstrapping data, a device MAY
>  perform a multicast DNS [RFC6762] query searching for the service
>  "_zerotouch._tcp.local.".  Alternatively the device MAY perform DNS-
>  SD [RFC6763] via normal DNS operation, using the domain returned to
>  it from the DHCP server; for example, searching for the service
>  "_zerotouch._tcp.example.com".

RFC 6763 §4.1.2 defers to RFC 2782 for the structure of DNS-SD records; and RFC
2782 indicates that these are of the format "_service._proto.name". In this
case, "service" is one of the services registered with IANA at
https://www.iana.org/assignments/service-names-port-numbers/
The service "zerotouch" is not registered in that registry, nor does this
document register it there.

Unless I'm confused about the way SRV records are intended to work, this
document needs to register "zerotouch" in the service name table indicated
above.

[Ballot comment]
§4.2:

>  Please see
>  Section 3.1.3 in RFC4408 for how a TXT record can achieve this size.

Please make this a citation instead of merely a mention of RFC 4408.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-netconf-zerotouch-25. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are five actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

two new namespaces will be registered as follows:

ID: yang:ietf-zerotouch-information
URI: urn:ietf:params:xml:ns:yang:ietf-zerotouch-information
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-zerotouch-bootstrap-server
URI: uurn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

two new YANG modules will be registered as follows:

Name: ietf-zerotouch-information
File: [ TBD-at-Registration ]
Maintained by IANA?
Namespace: urn:ietf:params:xml:ns:yang:ietf-zerotouch-information
Prefix: zti
Module:
Reference: [ RFC-to-be ]

Name: ietf-zerotouch-bootstrap-server
File: [ TBD-at-Registration ]
Maintained by IANA?
Namespace: urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server
Prefix: ztbs
Module:
Reference: [ RFC-to-be ]

IANA Question --> What should be the entry for the registry value "Maintained by IANA?" for these new YANG modules?

While the YANG module names will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

Third, in the SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) registry on the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry page located at:

https://www.iana.org/assignments/smi-numbers/

two, new registrations are to be made as follows:

Decimal: [ TBD-at-Registration ]
Description: id-ct-zerotouchInformationXML
Reference: [ RFC-to-be ]

Decimal: [ TBD-at-Registration ]
Description: id-ct-zerotouchInformationJSON
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Fourth, in the BOOTP Vendor Extensions and DHCP Options registry on the Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry page located at:

https://www.iana.org/assignments/bootp-dhcp-parameters/

the existing TEMPORARY registration for tag 143:

Tag: 143
Name: OPTION_V4_ZEROTOUCH_REDIRECT
Description: This option provides a list of URIs for zerotouch bootstrap servers

will be made permanent and its reference will be changed to [ RFC-to-be ].

Fifth, in the Option Codes registry on the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry page located at:

https://www.iana.org/assignments/dhcpv6-parameters/

the existing TEMPORARY registration for value 136:

Value: 136
Description: OPTION_V6_ZEROTOUCH_REDIRECT
Client ORO: Yes
Singleton Option: Yes

will be made permanent and its reference will be changed to [ RFC-to-be ].

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-10-22):

From: The IESG
To: IETF-Announce
CC: ibagdona@gmail.com, Bert Wijnen , Mahesh Jethanandani , draft-ietf-netconf-zerotouch@ietf.org, netconf@ietf.org, Bert Wijnen , mjethanandani@gmail.com, netconf-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Zero Touch Provisioning for Networking Devices) to Proposed Standard


The IESG has received a request from the Network Configuration WG (netconf)
to consider the following document: - 'Zero Touch Provisioning for Networking
Devices'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-10-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This draft presents a technique to securely provision a networking
  device when it is booting in a factory-default state.  Variations in
  the solution enables it to be used on both public and private
  networks.  The provisioning steps are able to update the boot image,
  commit an initial configuration, and execute arbitrary scripts to
  address auxiliary needs.  The updated device is subsequently able to
  establish secure connections with other systems.  For instance, a
  device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040)
  connections with deployment-specific network management systems.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2581/



The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-netmod-yang-data-ext: YANG Data Extensions (None - IETF stream)

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The RFC being requested in a Proposed Standard, and is indicated as such on the title page header. It is a Proposed Standard, as the document defines how a device can securely boot when placed in a private or a public network.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This draft presents a technique to securely provision a networking device when it is booting in a factory-default state. Variations in the solution enables it to be used on both public and private networks. The provisioning steps are able to update the boot image, commit an initial configuration, and execute arbitrary scripts to address auxiliary needs.  The updated device is subsequently able to establish secure connections with other systems.  For instance, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connections with deployment-specific network management systems.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

There was nothing about the draft and the discussions around it that are particularly contentious or controversial. The author(s) were fairly deliberate with their discussions and the decisions, making sure that the WG was comfortable with what was being proposed.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

A couple of vendors have indicated a desire to implement if not implemented them. The document has been reviewed extensively by Martin Bjorklund, and changes suggested by him have been incorporated into the draft.

The draft was reviewed by YANG doctors, and the comments from that review were also incorporated into the draft.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

The Document Shepherd is Mahesh Jethanandani and the Responsible AD is Ignas Bagdonas.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The Document Shepherd has reviewed this document, posted the comments from that review on the WG mailing list, and the comments from that review were incorporated in the -24 version of the draft. The Document Shepherd believes the document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The Document Shepherd has no concerns about the depth or breath of reviews. Plenty of people have reviewed and provided detailed comments on the draft.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The document has been reviewed by SecDir and comments from that review have been incorporated into the document.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The Document Shepherd has no concerns or issues with the document.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Each one of the authors have confirmed all appropriate IPR disclosures.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

An IPR disclosure has been filed that references this document. There was no discussion regarding the IPR disclosure.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is broad consensus within the WG for this document. The draft has been discussed and updates provided over a three year period, with several people reviewing and commenting on the draft.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No one has threatened, appealed or otherwise indicated extreme discontent with the draft.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

A run of idnits did not reveal anything that was concerning. The 6 warnings and 3 comments are expected, and have to do with the inclusion of the YANG model tree diagram.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

The document was submitted and reviewed by a YANG doctor.

(13) Have all references within this document been identified as either normative or informative?

Yes, all the references in the document have been identified as normative or informative.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

There is one normative reference to draft-ietf-netmod-yang-data-ext that is "work in progress". The NETMOD WG has not indicated a firm date of when it thinks the document would be completed.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Idnits indicates that one of the documents is downref, but it is a Non-RFC.

Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X690.2015'

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No, the publication of this document will not the change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The IANA considerations section has been well written with four different IANA requests. All the requests are well documented and registries and their references pointed out.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

There are no new IANA registries being requested by the document. All the requests are for existing registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

The Document Shepherd has run tools like pyang for validating the models and idnits for validating the draft itself.

Notification list changed to Bert Wijnen <bwijnen@bwijnen.net>, Bert Wijnen <bwietf@bwijnen.net>, Mahesh Jethanandani <mjethanandani@gmail.com> from Bert Wijnen <bwijnen@bwijnen.net>, Bert Wijnen <bwietf@bwijnen.net>

The document needs to address issues raised during LC, including the question of why a top level choice statement with containers underneath it flags an error.