9.  Security Considerations

9.1.  Clock Sensitivity

   The solution in this document relies on TLS certificates, owner
   certificates, and ownership vouchers, all of which require an
   accurate clock in order to be processed correctly (e.g., to test
   validity dates and revocation status).  Implementations SHOULD ensure
   devices have an accurate clock when shipped from manufacturing
   facilities and take steps to prevent clock tampering.

   If it is not possible to ensure clock accuracy, it is RECOMMENDED
   that implementations disable the aspects of the solution having clock
   sensitivity.  In particular, such implementations should assume that
   TLS certificates, ownership vouchers, and owner certificates never
   expire and are not revocable.  From an ownership voucher perspective,
   manufacturers SHOULD issue a single ownership voucher for the
   lifetime of such devices.

   Implementations SHOULD NOT rely on NTP for time, as NTP is not a
   secure protocol at this time.  Note that there is an IETF document
   that focuses on securing NTP [NTS-NTP].

9.2.  Use of IDevID Certificates

   IDevID certificates, as defined in [Std-802.1AR], are RECOMMENDED,
   both for the TLS-level client certificate used by devices when
   connecting to a bootstrap server, as well as for the device identity
   certificate used by owners when encrypting the SZTP bootstrapping
   data artifacts.

9.3.  Immutable Storage for Trust Anchors

   Devices MUST ensure that all their trust anchor certificates,
   including those for connecting to bootstrap servers and verifying
   ownership vouchers, are protected from external modification.

   It may be necessary to update these certificates over time (e.g., the
   manufacturer wants to delegate trust to a new CA).  It is therefore
   expected that devices MAY update these trust anchors when needed
   through a verifiable process, such as a software upgrade using signed
   software images.

9.4.  Secure Storage for Long-Lived Private Keys

   Manufacturer-generated device identifiers may have very long
   lifetimes.  For instance, [Std-802.1AR] recommends using the
   "notAfter" value 99991231235959Z in IDevID certificates.  Given the
   long-lived nature of these private keys, it is paramount that they
   are stored so as to resist discovery, such as in a secure
   cryptographic processor (e.g., a trusted platform module (TPM) chip).

9.5.  Blindly Authenticating a Bootstrap Server

   This document allows a device to blindly authenticate a bootstrap
   server's TLS certificate.  It does so to allow for cases where the
   redirect information may be obtained in an unsecured manner, which is
   desirable to support in some cases.

   To compensate for this, this document requires that devices, when
   connected to an untrusted bootstrap server, assert that data
   downloaded from the server is signed.

9.6.  Disclosing Information to Untrusted Servers

   This document allows devices to establish connections to untrusted
   bootstrap servers.  However, since the bootstrap server is untrusted,
   it may be under the control of an adversary; therefore, devices
   SHOULD be cautious about the data they send to the bootstrap server
   in such cases.

   Devices send different data to bootstrap servers at each of the
   protocol layers: TCP, TLS, HTTP, and RESTCONF.

   At the TCP protocol layer, devices may relay their IP address,
   subject to network translations.  Disclosure of this information is
   not considered a security risk.

   At the TLS protocol layer, devices may use a client certificate to
   identify and authenticate themselves to untrusted bootstrap servers.
   At a minimum, the client certificate must disclose the device's
   serial number and may disclose additional information such as the
   device's manufacturer, hardware model, public key, etc.  Knowledge of
   this information may provide an adversary with details needed to
   launch an attack.  It is RECOMMENDED that secrecy of the network
   constituency not be relied on for security.

   At the HTTP protocol layer, devices may use an HTTP authentication
   scheme to identify and authenticate themselves to untrusted bootstrap
   servers.  At a minimum, the authentication scheme must disclose the
   device's serial number and, concerningly, may, depending on the
   authentication mechanism used, reveal a secret that is only supposed
   to be known to the device (e.g., a password).  Devices SHOULD NOT use
   an HTTP authentication scheme (e.g., HTTP Basic) with an untrusted
   bootstrap server that reveals a secret that is only supposed to be
   known to the device.

   At the RESTCONF protocol layer, devices use the "get-bootstrapping-
   data" RPC, but not the "report-progress" RPC, when connected to an
   untrusted bootstrap server.  The "get-bootstrapping-data" RPC allows
   additional input parameters to be passed to the bootstrap server
   (e.g., "os-name", "os-version", and "hw-model").  It is RECOMMENDED
   that devices only pass the "signed-data-preferred" input parameter to
   an untrusted bootstrap server.  While it is okay for a bootstrap
   server to immediately return signed onboarding information, it is
   RECOMMENDED that bootstrap servers instead promote the untrusted
   connection to a trusted connection, as described in Appendix B, thus
   enabling the device to use the "report-progress" RPC while processing
   the onboarding information.

9.7.  Sequencing Sources of Bootstrapping Data

   For devices supporting more than one source for bootstrapping data,
   no particular sequencing order has to be observed for security
   reasons, as the solution for each source is considered equally
   secure.  However, from a privacy perspective, it is RECOMMENDED that
   devices access local sources before accessing remote sources.

9.8.  Safety of Private Keys Used for Trust

   The solution presented in this document enables bootstrapping data to
   be trusted in two ways: through either transport-level security or
   the signing of artifacts.

   When transport-level security (i.e., a trusted bootstrap server) is
   used, the private key for the end-entity certificate must be online
   in order to establish the TLS connection.

   When artifacts are signed, the signing key is required to be online
   only when the bootstrap server is returning a dynamically generated
   signed-data response.  For instance, a bootstrap server, upon
   receiving the "signed-data-preferred" input parameter to the
   "get-bootstrapping-data" RPC, may dynamically generate a response
   that is signed.

   Bootstrap server administrators are RECOMMENDED to follow best
   practices to protect the private key used for any online operation.
   For instance, use of a hardware security module (HSM) is RECOMMENDED.
   If an HSM is not used, frequent private key refreshes are
   RECOMMENDED, assuming all bootstrapping devices have an accurate
   clock (see Section 9.1).

   For best security, it is RECOMMENDED that owners only provide
   bootstrapping data that has been signed (using a protected private
   key) and encrypted (using the device's public key from its secure
   device identity certificate).

9.9.  Increased Reliance on Manufacturers

   The SZTP bootstrapping protocol presented in this document shifts
   some control of initial configuration away from the rightful owner of
   the device and towards the manufacturer and its delegates.

   The manufacturer maintains the list of well-known bootstrap servers
   its devices will trust.  By design, if no bootstrapping data is found
   via other methods first, the device will try to reach out to the
   well-known bootstrap servers.  There is no mechanism to prevent this
   from occurring other than by using an external firewall to block such
   connections.  Concerns related to trusted bootstrap servers are
   discussed in Section 9.10.

   Similarly, the manufacturer maintains the list of voucher-signing
   authorities its devices will trust.  The voucher-signing authorities
   issue the vouchers that enable a device to trust an owner's domain

   certificate.  It is vital that manufacturers ensure the integrity of
   these voucher-signing authorities, so as to avoid incorrect
   assignments.

   Operators should be aware that this system assumes that they trust
   all the pre-configured bootstrap servers and voucher-signing
   authorities designated by the manufacturers.  While operators may use
   points in the network to block access to the well-known bootstrap
   servers, operators cannot prevent voucher-signing authorities from
   generating vouchers for their devices.

9.10.  Concerns with Trusted Bootstrap Servers

   Trusted bootstrap servers, whether well-known or discovered, have the
   potential to cause problems, such as the following.

   o  A trusted bootstrap server that has been compromised may be
      modified to return unsigned data of any sort.  For instance, a
      bootstrap server that is only supposed to return redirect
      information might be modified to return onboarding information.
      Similarly, a bootstrap server that is only supposed to return
      signed data may be modified to return unsigned data.  In both
      cases, the device will accept the response, unaware that it wasn't
      supposed to be any different.  It is RECOMMENDED that maintainers
      of trusted bootstrap servers ensure that their systems are not
      easily compromised and, in case of compromise, have mechanisms in
      place to detect and remediate the compromise as expediently as
      possible.

   o  A trusted bootstrap server hosting data that is either unsigned or
      signed but not encrypted may disclose information to unwanted
      parties (e.g., an administrator of the bootstrap server).  This is
      a privacy issue only, but it could reveal information that might
      be used in a subsequent attack.  Disclosure of redirect
      information has limited exposure (it is just a list of bootstrap
      servers), whereas disclosure of onboarding information could be
      highly 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 point
      of hiding it from the administrators of the bootstrap server,
      which may be maintained by a third party.

9.11.  Validity Period for Conveyed Information

   The conveyed information artifact does not specify a validity period.
   For instance, neither redirect information nor onboarding information
   enable "not-before" or "not-after" values to be specified, and
   neither artifact alone can be revoked.

   For unsigned data provided by an untrusted source of bootstrapping
   data, it is not meaningful to discuss its validity period when the
   information itself has no authenticity and may have come from
   anywhere.

   For unsigned data provided by a trusted source of bootstrapping data
   (i.e., a bootstrap server), the availability of the data is the only
   measure of it being current.  Since the untrusted data comes from a
   trusted source, its current availability is meaningful, and since
   bootstrap servers use TLS, the contents of the exchange cannot be
   modified or replayed.

   For signed data, whether provided by an untrusted or trusted source
   of bootstrapping data, the validity is constrained by the validity of
   both the ownership voucher and owner certificate used to authenticate
   it.

   The ownership voucher's validity is primarily constrained by the
   ownership voucher's "created-on" and "expires-on" nodes.  While
   [RFC8366] recommends short-lived vouchers (see Section 6.1), the
   "expires-on" node may be set to any point in the future or omitted
   altogether to indicate that the voucher never expires.  The ownership
   voucher's validity is secondarily constrained by the manufacturer's
   PKI used to sign the voucher; whilst an ownership voucher cannot be
   revoked directly, the PKI used to sign it may be.

   The owner certificate's validity is primarily constrained by the
   X.509's validity field, the "notBefore" and "notAfter" values, as
   specified by the certificate authority that signed it.  The owner
   certificate's validity is secondarily constrained by the validity of
   the PKI used to sign the voucher.  Owner certificates may be revoked
   directly.

   For owners that wish to have maximum flexibility in their ability to
   specify and constrain the validity of signed data, it is RECOMMENDED
   that a unique owner certificate be created for each signed artifact.
   Not only does this enable a validity period to be specified, for each
   artifact, but it also enables the validity of each artifact to be
   revoked.

9.12.  Cascading Trust via Redirects

   Redirect information (Section 2.1), by design, instructs a
   bootstrapping device to initiate an HTTPS connection to the specified
   bootstrap servers.

   When the redirect information is trusted, the redirect information
   can encode a trust anchor certificate used by the device to

   authenticate the TLS end-entity certificate presented by each
   bootstrap server.

   As a result, any compromise in an interaction providing redirect
   information may result in compromise of all subsequent interactions.

9.13.  Possible Reuse of Private Keys

   This document describes two uses for secure device identity
   certificates.

   The primary use is for when the device authenticates itself to a
   bootstrap server, using its private key for TLS-level client-
   certificate-based authentication.

   A secondary use is for when the device needs to decrypt provided
   bootstrapping artifacts, using its private key to decrypt the data
   or, more precisely, per Section 6 of [RFC5652], decrypt a symmetric
   key used to decrypt the data.

   Section 3.4 of this document allows for the possibility that the same
   secure device identity certificate is utilized for both uses, as
   [Std-802.1AR] states that a DevID certificate MAY have the
   "keyEncipherment" KeyUsage bit, in addition to the "digitalSignature"
   KeyUsage bit, set.

   While it is understood that it is generally frowned upon to reuse
   private keys, this document views such reuse acceptable as there are
   not any known ways to cause a signature made in one context to be
   (mis)interpreted as valid in the other context.

9.14.  Non-issue with Encrypting Signed Artifacts

   This document specifies the encryption of signed objects, as opposed
   to the signing of encrypted objects, as might be expected given well-
   publicized oracle attacks (e.g., the padding oracle attack).

   This document does not view such attacks as feasible in the context
   of the solution because the decrypted text never leaves the device.

9.15.  The "ietf-sztp-conveyed-info" YANG Module

   The "ietf-sztp-conveyed-info" module defined in this document defines
   a data structure that is always wrapped by a CMS structure.  When
   accessed by a secure mechanism (e.g., protected by TLS), then the CMS
   structure may be unsigned.  However, when accessed by an insecure
   mechanism (e.g., a removable storage device), the CMS structure must
   be signed, in order for the device to trust it.

   Implementations should be aware that signed bootstrapping data only
   protects the data from modification and that the content is still
   visible to others.  This doesn't affect security so much as privacy.
   That the contents may be read by unintended parties when accessed by
   insecure mechanisms is considered next.

   The "ietf-sztp-conveyed-info" module defines a top-level "choice"
   statement that declares the content is either redirect-information or
   onboarding-information.  Each of these two cases are now considered.

   When the content of the CMS structure is redirect-information, an
   observer can learn about the bootstrap servers the device is being
   directed to, their IP addresses or hostnames, ports, and trust anchor
   certificates.  Knowledge of this information could provide an
   observer some insight into a network's inner structure.

   When the content of the CMS structure is onboarding-information, an
   observer could learn considerable information about how the device is
   to be provisioned.  This information includes the operating system
   version, initial configuration, and script contents.  This
   information should be considered sensitive, and precautions should be
   taken to protect it (e.g., encrypt the artifact using the device's
   public key).

9.16.  The "ietf-sztp-bootstrap-server" YANG Module

   The "ietf-sztp-bootstrap-server" module defined in this document
   specifies an API for a RESTCONF [RFC8040].  The lowest RESTCONF layer
   is HTTPS, and the mandatory-to-implement secure transport is TLS
   [RFC8446].

   The NETCONF Access Control Model (NACM) [RFC8341] provides the means
   to restrict access for particular users to a pre-configured subset of
   all available protocol operations and content.

   This module presents no data nodes (only RPCs).  There is no need to
   discuss the sensitivity of data nodes.

   This module defines two RPC operations that may be considered
   sensitive in some network environments.  These are the operations and
   their sensitivity/vulnerability:

   get-bootstrapping-data:  This RPC is used by devices to obtain their
       bootstrapping data.  By design, each device, as identified by its
       authentication credentials (e.g., client certificate), can only
       obtain its own data.  NACM is not needed to further constrain
       access to this RPC.

   report-progress:  This RPC is used by devices to report their
       bootstrapping progress.  By design, each device, as identified by
       its authentication credentials (e.g., client certificate), can
       only report data for itself.  NACM is not needed to further
       constrain access to this RPC.

10.  IANA Considerations

10.1.  The IETF XML Registry

   IANA has registered two URIs in the "ns" subregistry of the "IETF XML
   Registry" [RFC3688] maintained at <https://www.iana.org/assignments/
   xml-registry>.  The following registrations have been made per the
   format in [RFC3688]:

      URI: urn:ietf:params:xml:ns:yang:ietf-sztp-conveyed-info
      Registrant Contact: The NETCONF WG of the IETF.
      XML: N/A, the requested URI is an XML namespace.

      URI: urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server
      Registrant Contact: The NETCONF WG of the IETF.
      XML: N/A, the requested URI is an XML namespace.

10.2.  The YANG Module Names Registry

   IANA has registered two YANG modules in the "YANG Module Names"
   registry [RFC6020] maintained at <https://www.iana.org/assignments/
   yang-parameters>.  The following registrations have been made per the
   format in [RFC6020]:

      name:      ietf-sztp-conveyed-info
      namespace: urn:ietf:params:xml:ns:yang:ietf-sztp-conveyed-info
      prefix:    sztp-info
      reference: RFC 8572

      name:      ietf-sztp-bootstrap-server
      namespace: urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server
      prefix:    sztp-svr
      reference: RFC 8572

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

   IANA has registered two subordinate object identifiers in the "SMI
   Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)"
   registry maintained at <https://www.iana.org/assignments/
   smi-numbers>.  The following registrations have been made per the
   format in Section 3.4 of [RFC7107]:

      Decimal   Description                  References
      -------   --------------------------   ----------
      42        id-ct-sztpConveyedInfoXML    RFC 8572
      43        id-ct-sztpConveyedInfoJSON   RFC 8572

   id-ct-sztpConveyedInfoXML indicates that the "conveyed-information"
   is encoded using XML.  id-ct-sztpConveyedInfoJSON indicates that the
   "conveyed-information" is encoded using JSON.

10.4.  The BOOTP Vendor Extensions and DHCP Options Registry

   IANA has registered one DHCP code point in the "BOOTP Vendor
   Extensions and DHCP Options" registry maintained at
   <https://www.iana.org/assignments/bootp-dhcp-parameters>:

      Tag:         143
      Name:        OPTION_V4_SZTP_REDIRECT
      Data Length: N
      Meaning:     This option provides a list of URIs
                   for SZTP bootstrap servers
      Reference:   RFC 8572

10.5.  The Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
       Registry

   IANA has registered one DHCP code point in the "Option Codes"
   subregistry of the "Dynamic Host Configuration Protocol for IPv6
   (DHCPv6)" registry maintained at <https://www.iana.org/assignments/
   dhcpv6-parameters>:

      Value:            136
      Description:      OPTION_V6_SZTP_REDIRECT
      Client ORO:       Yes
      Singleton Option: Yes
      Reference:        RFC 8572

10.6.  The Service Name and Transport Protocol Port Number Registry

   IANA has registered one service name in the "Service Name and
   Transport Protocol Port Number Registry" [RFC6335] maintained at
   <https://www.iana.org/assignments/service-names-port-numbers>.  The
   following registration has been made per the format in Section 8.1.1
   of [RFC6335]:

     Service Name:            sztp
     Transport Protocol(s):   TCP
     Assignee:                IESG <iesg@ietf.org>
     Contact:                 IETF Chair <chair@ietf.org>
     Description:             This service name is used to construct the
                              SRV service label "_sztp" for discovering
                              SZTP bootstrap servers.
     Reference:               RFC 8572
     Port Number:             N/A
     Service Code:            N/A
     Known Unauthorized Uses: N/A
     Assignment Notes:        This protocol uses HTTPS as a substrate.

10.7.  The Underscored and Globally Scoped DNS Node Names Registry

   IANA has registered one service name in the "Underscored and Globally
   Scoped DNS Node Names" subregistry [RFC8552] of the "Domain Name
   System (DNS) Parameters" registry maintained at
   <https://www.iana.org/assignments/dns-parameters>.  The following
   registration has been made per the format in Section 3 of [RFC8552]:

      RR Type:            TXT
      _NODE NAME:         _sztp
      Reference:          RFC 8572