Tech-invite   3GPPspecs   RFCs   Search in Tech-invite

868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100IETF‑orgGroupsStats
in Index   Prev   Next

RFC 8572

Secure Zero Touch Provisioning (SZTP)

Pages: 87
Group: NETCONF
Proposed STD
Part 1 of 5 – Pages 1 to 22
None   None   Next

Top   ToC   RFC8572 - Page 1
Internet Engineering Task Force (IETF)                         K. Watsen
Request for Comments: 8572                               Watsen Networks
Category: Standards Track                                      I. Farrer
ISSN: 2070-1721                                      Deutsche Telekom AG
                                                          M. Abrahamsson
                                                               T-Systems
                                                              April 2019


                 Secure Zero Touch Provisioning (SZTP)

Abstract

   This document presents a technique to securely provision a networking
   device when it is booting in a factory-default state.  Variations in
   the solution enable 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.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8572.
Top   ToC   RFC8572 - Page 2
Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.
Top   ToC   RFC8572 - Page 3
Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   5
     1.1.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . .   5
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   6
     1.3.  Requirements Language . . . . . . . . . . . . . . . . . .   8
     1.4.  Tree Diagrams . . . . . . . . . . . . . . . . . . . . . .   8
   2.  Types of Conveyed Information . . . . . . . . . . . . . . . .   8
     2.1.  Redirect Information  . . . . . . . . . . . . . . . . . .   8
     2.2.  Onboarding Information  . . . . . . . . . . . . . . . . .   9
   3.  Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     3.1.  Conveyed Information  . . . . . . . . . . . . . . . . . .  10
     3.2.  Owner Certificate . . . . . . . . . . . . . . . . . . . .  12
     3.3.  Ownership Voucher . . . . . . . . . . . . . . . . . . . .  13
     3.4.  Artifact Encryption . . . . . . . . . . . . . . . . . . .  13
     3.5.  Artifact Groupings  . . . . . . . . . . . . . . . . . . .  14
   4.  Sources of Bootstrapping Data . . . . . . . . . . . . . . . .  15
     4.1.  Removable Storage . . . . . . . . . . . . . . . . . . . .  15
     4.2.  DNS Server  . . . . . . . . . . . . . . . . . . . . . . .  16
     4.3.  DHCP Server . . . . . . . . . . . . . . . . . . . . . . .  20
     4.4.  Bootstrap Server  . . . . . . . . . . . . . . . . . . . .  21
   5.  Device Details  . . . . . . . . . . . . . . . . . . . . . . .  22
     5.1.  Initial State . . . . . . . . . . . . . . . . . . . . . .  22
     5.2.  Boot Sequence . . . . . . . . . . . . . . . . . . . . . .  24
     5.3.  Processing a Source of Bootstrapping Data . . . . . . . .  25
     5.4.  Validating Signed Data  . . . . . . . . . . . . . . . . .  27
     5.5.  Processing Redirect Information . . . . . . . . . . . . .  28
     5.6.  Processing Onboarding Information . . . . . . . . . . . .  28
   6.  The Conveyed Information Data Model . . . . . . . . . . . . .  32
     6.1.  Data Model Overview . . . . . . . . . . . . . . . . . . .  32
     6.2.  Example Usage . . . . . . . . . . . . . . . . . . . . . .  32
     6.3.  YANG Module . . . . . . . . . . . . . . . . . . . . . . .  34
   7.  The SZTP Bootstrap Server API . . . . . . . . . . . . . . . .  41
     7.1.  API Overview  . . . . . . . . . . . . . . . . . . . . . .  41
     7.2.  Example Usage . . . . . . . . . . . . . . . . . . . . . .  42
     7.3.  YANG Module . . . . . . . . . . . . . . . . . . . . . . .  45
   8.  DHCP Options  . . . . . . . . . . . . . . . . . . . . . . . .  56
     8.1.  DHCPv4 SZTP Redirect Option . . . . . . . . . . . . . . .  56
     8.2.  DHCPv6 SZTP Redirect Option . . . . . . . . . . . . . . .  58
     8.3.  Common Field Encoding . . . . . . . . . . . . . . . . . .  59
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  59
     9.1.  Clock Sensitivity . . . . . . . . . . . . . . . . . . . .  59
     9.2.  Use of IDevID Certificates  . . . . . . . . . . . . . . .  60
     9.3.  Immutable Storage for Trust Anchors . . . . . . . . . . .  60
     9.4.  Secure Storage for Long-Lived Private Keys  . . . . . . .  60
     9.5.  Blindly Authenticating a Bootstrap Server . . . . . . . .  60
     9.6.  Disclosing Information to Untrusted Servers . . . . . . .  60
     9.7.  Sequencing Sources of Bootstrapping Data  . . . . . . . .  61
Top   ToC   RFC8572 - Page 4
     9.8.  Safety of Private Keys Used for Trust . . . . . . . . . .  62
     9.9.  Increased Reliance on Manufacturers . . . . . . . . . . .  62
     9.10. Concerns with Trusted Bootstrap Servers . . . . . . . . .  63
     9.11. Validity Period for Conveyed Information  . . . . . . . .  63
     9.12. Cascading Trust via Redirects . . . . . . . . . . . . . .  64
     9.13. Possible Reuse of Private Keys  . . . . . . . . . . . . .  65
     9.14. Non-issue with Encrypting Signed Artifacts  . . . . . . .  65
     9.15. The "ietf-sztp-conveyed-info" YANG Module . . . . . . . .  65
     9.16. The "ietf-sztp-bootstrap-server" YANG Module  . . . . . .  66
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  67
     10.1.  The IETF XML Registry  . . . . . . . . . . . . . . . . .  67
     10.2.  The YANG Module Names Registry . . . . . . . . . . . . .  67
     10.3.  The SMI Security for S/MIME CMS Content Type Registry  .  68
     10.4.  The BOOTP Vendor Extensions and DHCP Options Registry  .  68
     10.5.  The Dynamic Host Configuration Protocol for IPv6
            (DHCPv6) Registry  . . . . . . . . . . . . . . . . . . .  68
     10.6.  The Service Name and Transport Protocol Port Number
            Registry . . . . . . . . . . . . . . . . . . . . . . . .  69
     10.7.  The Underscored and Globally Scoped DNS Node Names
            Registry . . . . . . . . . . . . . . . . . . . . . . . .  69
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  69
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  69
     11.2.  Informative References . . . . . . . . . . . . . . . . .  71
   Appendix A.  Example Device Data Model  . . . . . . . . . . . . .  74
     A.1.  Data Model Overview . . . . . . . . . . . . . . . . . . .  74
     A.2.  Example Usage . . . . . . . . . . . . . . . . . . . . . .  75
     A.3.  YANG Module . . . . . . . . . . . . . . . . . . . . . . .  75
   Appendix B.  Promoting a Connection from Untrusted to Trusted . .  79
   Appendix C.  Workflow Overview  . . . . . . . . . . . . . . . . .  80
     C.1.  Enrollment and Ordering Devices . . . . . . . . . . . . .  80
     C.2.  Owner Stages the Network for Bootstrap  . . . . . . . . .  83
     C.3.  Device Powers On  . . . . . . . . . . . . . . . . . . . .  85
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  87
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  87
Top   ToC   RFC8572 - Page 5
1.  Introduction

   A fundamental business requirement for any network operator is to
   reduce costs where possible.  For network operators, deploying
   devices to many locations can be a significant cost, as sending
   trained specialists to each site for installations is both cost
   prohibitive and does not scale.

   This document defines Secure Zero Touch Provisioning (SZTP), a
   bootstrapping strategy enabling devices to securely obtain
   bootstrapping data with no installer action beyond physical placement
   and connecting network and power cables.  As such, SZTP enables non-
   technical personnel to bring up devices in remote locations without
   the need for any operator input.

   The SZTP solution includes updating the boot image, committing an
   initial configuration, and executing 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 [RFC6241] and/or RESTCONF [RFC8040]
   connections with deployment-specific network management systems.

   This document primarily regards physical devices, where the setting
   of the device's initial state (described in Section 5.1) occurs
   during the device's manufacturing process.  The SZTP solution may be
   extended to support virtual machines or other such logical
   constructs, but details for how this can be accomplished is left for
   future work.

1.1.  Use Cases

   o  Device connecting to a remotely administered network

         This use case involves scenarios, such as a remote branch
         office or convenience store, whereby a device connects as an
         access gateway to an ISP's network.  Assuming it is not
         possible to customize the ISP's network to provide any
         bootstrapping support, and with no other nearby device to
         leverage, the device has no recourse but to reach out to an
         Internet-based bootstrap server to bootstrap from.
Top   ToC   RFC8572 - Page 6
   o  Device connecting to a locally administered network

         This use case covers all other scenarios and differs only in
         that the device may additionally leverage nearby devices, which
         may direct it to use a local service to bootstrap from.  If no
         such information is available, or the device is unable to use
         the information provided, it can then reach out to the network
         just as it would for the remotely administered network use
         case.

   Conceptual workflows for how SZTP might be deployed are provided in
   Appendix C.

1.2.  Terminology

   This document uses the following terms (sorted alphabetically):

   Artifact:  The term "artifact" is used throughout this document to
       represent any of the three artifacts defined in Section 3
       (conveyed information, ownership voucher, and owner certificate).
       These artifacts collectively provide all the bootstrapping data a
       device may use.

   Bootstrapping Data:  The term "bootstrapping data" is used throughout
       this document to refer to the collection of data that a device
       may obtain during the bootstrapping process.  Specifically, it
       refers to the three artifacts defined in Section 3 (conveyed
       information, owner certificate, and ownership voucher).

   Bootstrap Server:  The term "bootstrap server" is used within this
       document to mean any RESTCONF server implementing the YANG module
       defined in Section 7.3.

   Conveyed Information:  The term "conveyed information" is used herein
       to refer to either redirect information or onboarding
       information.  Conveyed information is one of the three
       bootstrapping artifacts described in Section 3.

   Device:  The term "device" is used throughout this document to refer
       to a network element that needs to be bootstrapped.  See
       Section 5 for more information about devices.

   Manufacturer:  The term "manufacturer" is used herein to refer to the
       manufacturer of a device or a delegate of the manufacturer.
Top   ToC   RFC8572 - Page 7
   Network Management System (NMS):  The acronym "NMS" is used
       throughout this document to refer to the deployment-specific
       management system that the bootstrapping process is responsible
       for introducing devices to.  From a device's perspective, when
       the bootstrapping process has completed, the NMS is a NETCONF or
       RESTCONF client.

   Onboarding Information:  The term "onboarding information" is used
       herein to refer to one of the two types of "conveyed information"
       defined in this document, the other being "redirect information".
       Onboarding information is formally defined by the "onboarding-
       information" container within the "conveyed-information" yang-
       data structure in Section 6.3.

   Onboarding Server:  The term "onboarding server" is used herein to
       refer to a bootstrap server that only returns onboarding
       information.

   Owner:  The term "owner" is used throughout this document to refer to
       the person or organization that purchased or otherwise owns a
       device.

   Owner Certificate:  The term "owner certificate" is used in this
       document to represent an X.509 certificate that binds an owner
       identity to a public key, which a device can use to validate a
       signature over the conveyed information artifact.  The owner
       certificate may be communicated along with its chain of
       intermediate certificates leading up to a known trust anchor.
       The owner certificate is one of the three bootstrapping artifacts
       described in Section 3.

   Ownership Voucher:  The term "ownership voucher" is used in this
       document to represent the voucher artifact defined in [RFC8366].
       The ownership voucher is used to assign a device to an owner.
       The ownership voucher is one of the three bootstrapping artifacts
       described in Section 3.

   Redirect Information:  The term "redirect information" is used herein
       to refer to one of the two types of "conveyed information"
       defined in this document, the other being "onboarding
       information".  Redirect information is formally defined by the
       "redirect-information" container within the "conveyed-
       information" yang-data structure in Section 6.3.
Top   ToC   RFC8572 - Page 8
   Redirect Server:  The term "redirect server" is used to refer to a
       bootstrap server that only returns redirect information.  A
       redirect server is particularly useful when hosted by a
       manufacturer, as a well-known (e.g., Internet-based) resource to
       redirect devices to deployment-specific bootstrap servers.

   Signed Data:  The term "signed data" is used throughout to mean
       conveyed information that has been signed, specifically by a
       private key possessed by a device's owner.

   Unsigned Data:  The term "unsigned data" is used throughout to mean
       conveyed information that has not been signed.

1.3.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.4.  Tree Diagrams

   Tree diagrams used in this document follow the notation defined in
   [RFC8340].

2.  Types of Conveyed Information

   This document defines two types of conveyed information that devices
   can access during the bootstrapping process.  These conveyed
   information types are described in this section.  Examples are
   provided in Section 6.2.

2.1.  Redirect Information

   Redirect information redirects a device to another bootstrap server.
   Redirect information encodes a list of bootstrap servers, each
   specifying the bootstrap server's hostname (or IP address), an
   optional port, and an optional trust anchor certificate that the
   device can use to authenticate the bootstrap server with.
Top   ToC   RFC8572 - Page 9
   Redirect information is YANG-modeled data formally defined by the
   "redirect-information" container in the YANG module presented in
   Section 6.3.  This container has the tree diagram shown below.

               +--:(redirect-information)
                  +-- redirect-information
                     +-- bootstrap-server* [address]
                        +-- address         inet:host
                        +-- port?           inet:port-number
                        +-- trust-anchor?   cms

   Redirect information may be trusted or untrusted.  The redirect
   information is trusted whenever it is obtained via a secure
   connection to a trusted bootstrap server or whenever it is signed by
   the device's owner.  In all other cases, the redirect information is
   untrusted.

   Trusted redirect information is useful for enabling a device to
   establish a secure connection to a specified bootstrap server, which
   is possible when the redirect information includes the bootstrap
   server's trust anchor certificate.

   Untrusted redirect information is useful for directing a device to a
   bootstrap server where signed data has been staged for it to obtain.
   Note that, when the redirect information is untrusted, devices
   discard any potentially included trust anchor certificates.

   How devices process redirect information is described in Section 5.5.

2.2.  Onboarding Information

   Onboarding information provides data necessary for a device to
   bootstrap itself and establish secure connections with other systems.
   As defined in this document, onboarding information can specify
   details about the boot image a device must be running, an initial
   configuration the device must commit, and scripts that the device
   must successfully execute.
Top   ToC   RFC8572 - Page 10
   Onboarding information is YANG-modeled data formally defined by the
   "onboarding-information" container in the YANG module presented in
   Section 6.3.  This container has the tree diagram shown below.

            +--:(onboarding-information)
               +-- onboarding-information
                  +-- boot-image
                  |  +-- os-name?              string
                  |  +-- os-version?           string
                  |  +-- download-uri*         inet:uri
                  |  +-- image-verification* [hash-algorithm]
                  |     +-- hash-algorithm    identityref
                  |     +-- hash-value        yang:hex-string
                  +-- configuration-handling?      enumeration
                  +-- pre-configuration-script?    script
                  +-- configuration?               binary
                  +-- post-configuration-script?   script

   Onboarding information must be trusted for it to be of any use to a
   device.  There is no option for a device to process untrusted
   onboarding information.

   Onboarding information is trusted whenever it is obtained via a
   secure connection to a trusted bootstrap server or whenever it is
   signed by the device's owner.  In all other cases, the onboarding
   information is untrusted.

   How devices process onboarding information is described in
   Section 5.6.

3.  Artifacts

   This document defines three artifacts that can be made available to
   devices while they are bootstrapping.  Each source of bootstrapping
   data specifies how it provides the artifacts defined in this section
   (see Section 4).

3.1.  Conveyed Information

   The conveyed information artifact encodes the essential bootstrapping
   data for the device.  This artifact is used to encode the redirect
   information and onboarding information types discussed in Section 2.

   The conveyed information artifact is a Cryptographic Message Syntax
   (CMS) structure, as described in [RFC5652], encoded using ASN.1
   distinguished encoding rules (DER), as specified in ITU-T X.690
   [ITU.X690.2015].  The CMS structure MUST contain content conforming
   to the YANG module specified in Section 6.3.
Top   ToC   RFC8572 - Page 11
   The conveyed information CMS structure may encode signed or unsigned
   bootstrapping data.  When the bootstrapping data is signed, it may
   also be encrypted, but from a terminology perspective, it is still
   "signed data"; see Section 1.2.

   When the conveyed information artifact is unsigned and unencrypted,
   as it might be when communicated over trusted channels, the CMS
   structure's topmost content type MUST be one of the OIDs described in
   Section 10.3 (i.e., id-ct-sztpConveyedInfoXML or
   id-ct-sztpConveyedInfoJSON) or the OID id-data
   (1.2.840.113549.1.7.1).  When the OID id-data is used, the encoding
   (JSON, XML, etc.) SHOULD be communicated externally.  In either case,
   the associated content is an octet string containing
   "conveyed-information" data in the expected encoding.

   When the conveyed information artifact is unsigned and encrypted, as
   it might be when communicated over trusted channels but, for some
   reason, the operator wants to ensure that only the device is able to
   see the contents, the CMS structure's topmost content type MUST be
   the OID id-envelopedData (1.2.840.113549.1.7.3).  Furthermore, the
   encryptedContentInfo's content type MUST be one of the OIDs described
   in Section 10.3 (i.e., id-ct-sztpConveyedInfoXML or
   id-ct-sztpConveyedInfoJSON) or the OID id-data
   (1.2.840.113549.1.7.1).  When the OID id-data is used, the encoding
   (JSON, XML, etc.)  SHOULD be communicated externally.  In either
   case, the associated content is an octet string containing
   "conveyed-information" data in the expected encoding.

   When the conveyed information artifact is signed and unencrypted, as
   it might be when communicated over untrusted channels, the CMS
   structure's topmost content type MUST be the OID id-signedData
   (1.2.840.113549.1.7.2).  Furthermore, the inner eContentType MUST be
   one of the OIDs described in Section 10.3 (i.e.,
   id-ct-sztpConveyedInfoXML or id-ct-sztpConveyedInfoJSON) or the OID
   id-data (1.2.840.113549.1.7.1).  When the OID id-data is used, the
   encoding (JSON, XML, etc.)  SHOULD be communicated externally.  In
   either case, the associated content or eContent is an octet string
   containing "conveyed-information" data in the expected encoding.

   When the conveyed information artifact is signed and encrypted, as it
   might be when communicated over untrusted channels and privacy is
   important, the CMS structure's topmost content type MUST be the OID
   id-envelopedData (1.2.840.113549.1.7.3).  Furthermore, the
   encryptedContentInfo's content type MUST be the OID id-signedData
   (1.2.840.113549.1.7.2), whose eContentType MUST be one of the OIDs
   described in Section 10.3 (i.e., id-ct-sztpConveyedInfoXML or
   id-ct-sztpConveyedInfoJSON), or the OID id-data
   (1.2.840.113549.1.7.1).  When the OID id-data is used, the encoding
Top   ToC   RFC8572 - Page 12
   (JSON, XML, etc.) SHOULD be communicated externally.  In either case,
   the associated content or eContent is an octet string containing
   "conveyed-information" data in the expected encoding.

3.2.  Owner Certificate

   The owner certificate artifact is an X.509 certificate [RFC5280] that
   is used to identify an "owner" (e.g., an organization).  The owner
   certificate can be signed by any certificate authority (CA).  The
   owner certificate MUST have no Key Usage specified, or the Key Usage
   MUST, at a minimum, set the "digitalSignature" bit.  The values for
   the owner certificate's "subject" and/or "subjectAltName" are not
   constrained by this document.

   The owner certificate is used by a device to verify the signature
   over the conveyed information artifact (Section 3.1) that the device
   should have also received, as described in Section 3.5.  In
   particular, the device verifies the signature using the public key in
   the owner certificate over the content contained within the conveyed
   information artifact.

   The owner certificate artifact is formally a CMS structure, as
   specified by [RFC5652], encoded using ASN.1 DER, as specified in
   ITU-T X.690 [ITU.X690.2015].

   The owner certificate CMS structure MUST contain the owner
   certificate itself, as well as all intermediate certificates leading
   to the "pinned-domain-cert" certificate specified in the ownership
   voucher.  The owner certificate artifact MAY optionally include the
   "pinned-domain-cert" as well.

   In order to support devices deployed on private networks, the owner
   certificate CMS structure MAY also contain suitably fresh, as
   determined by local policy, revocation objects (e.g., Certificate
   Revocation Lists (CRLs) [RFC5280] and OCSP Responses [RFC6960]).
   Having these revocation objects stapled to the owner certificate may
   obviate the need for the device to have to download them dynamically
   using the CRL distribution point or an Online Certificate Status
   Protocol (OCSP) responder specified in the associated certificates.

   When unencrypted, the topmost content type of the owner certificate
   artifact's CMS structure MUST be the OID id-signedData
   (1.2.840.113549.1.7.2).  The inner SignedData structure is the
   degenerate form, whereby there are no signers, that is commonly used
   to disseminate certificates and revocation objects.

   When encrypted, the topmost content type of the owner certificate
   artifact's CMS structure MUST be the OID id-envelopedData
Top   ToC   RFC8572 - Page 13
   (1.2.840.113549.1.7.3), and the encryptedContentInfo's content type
   MUST be the OID id-signedData (1.2.840.113549.1.7.2), whereby the
   inner SignedData structure is the degenerate form that has no signers
   commonly used to disseminate certificates and revocation objects.

3.3.  Ownership Voucher

   The ownership voucher artifact is used to securely identify a
   device's owner, as it is known to the manufacturer.  The ownership
   voucher is signed by the device's manufacturer.

   The ownership voucher is used to verify the owner certificate
   (Section 3.2) that the device should have also received, as described
   in Section 3.5.  In particular, the device verifies that the owner
   certificate has a chain of trust leading to the trusted certificate
   included in the ownership voucher ("pinned-domain-cert").  Note that
   this relationship holds even when the owner certificate is a self-
   signed certificate and hence also the pinned-domain-cert.

   When unencrypted, the ownership voucher artifact is as defined in
   [RFC8366].  As described, it is a CMS structure whose topmost content
   type MUST be the OID id-signedData (1.2.840.113549.1.7.2), whose
   eContentType MUST be OID id-ct-animaJSONVoucher
   (1.2.840.113549.1.9.16.1), or the OID id-data (1.2.840.113549.1.7.1).
   When the OID id-data is used, the encoding (JSON, XML, etc.) SHOULD
   be communicated externally.  In either case, the associated content
   is an octet string containing ietf-voucher data in the expected
   encoding.

   When encrypted, the topmost content type of the ownership voucher
   artifact's CMS structure MUST be the OID id-envelopedData
   (1.2.840.113549.1.7.3), and the encryptedContentInfo's content type
   MUST be the OID id-signedData (1.2.840.113549.1.7.2), whose
   eContentType MUST be OID id-ct-animaJSONVoucher
   (1.2.840.113549.1.9.16.1), or the OID id-data (1.2.840.113549.1.7.1).
   When the OID id-data is used, the encoding (JSON, XML, etc.) SHOULD
   be communicated externally.  In either case, the associated content
   is an octet string containing ietf-voucher data in the expected
   encoding.

3.4.  Artifact Encryption

   Each of the three artifacts MAY be individually encrypted.
   Encryption may be important in some environments where the content is
   considered sensitive.

   Each of the three artifacts are encrypted in the same way, by the
   unencrypted form being encapsulated inside a CMS EnvelopedData type.
Top   ToC   RFC8572 - Page 14
   As a consequence, both the conveyed information and ownership voucher
   artifacts are signed and then encrypted; they are never encrypted and
   then signed.

   This sequencing has the following advantages: shrouding the signer's
   certificate and ensuring that the owner knows the content being
   signed.  This sequencing further enables the owner to inspect an
   unencrypted voucher obtained from a manufacturer and then encrypt the
   voucher later themselves, perhaps while also stapling in current
   revocation objects, when ready to place the artifact in an unsafe
   location.

   When encrypted, the CMS MUST be encrypted using a secure device
   identity certificate for the device.  This certificate MAY be the
   same as the TLS-level client certificate the device uses when
   connecting to bootstrap servers.  The owner must possess the device's
   identity certificate at the time of encrypting the data.  How the
   owner comes to posses the device's identity certificate for this
   purpose is outside the scope of this document.

3.5.  Artifact Groupings

   The previous sections discussed the bootstrapping artifacts, but only
   certain groupings of these artifacts make sense to return in the
   various bootstrapping situations described in this document.  These
   groupings are:

      Unsigned Data:  This artifact grouping is useful for cases when
         transport-level security can be used to convey trust (e.g.,
         HTTPS) or when the conveyed information can be processed in a
         provisional manner (i.e., unsigned redirect information).

      Signed Data, without revocations:  This artifact grouping is
         useful when signed data is needed (i.e., because the data is
         obtained from an untrusted source and it cannot be processed
         provisionally) and revocations either are not needed or can be
         obtained dynamically.

      Signed Data, with revocations:  This artifact grouping is useful
         when signed data is needed (i.e., because the data is obtained
         from an untrusted source and it cannot be processed
         provisionally) and when revocations are needed but the
         revocations cannot be obtained dynamically.

   The presence of each artifact and any distinguishing characteristics
   are identified for each artifact grouping in the table below ("yes"
   and "no" indicate whether or not the artifact is present in the
   artifact grouping):
Top   ToC   RFC8572 - Page 15
   +---------------------+---------------+--------------+--------------+
   | Artifact            | Conveyed      | Ownership    | Owner        |
   | Grouping            | Information   | Voucher      | Certificate  |
   +=====================+===============+==============+==============+
   | Unsigned Data       | Yes, no sig   | No           | No           |
   +---------------------+---------------+--------------+--------------+
   | Signed Data,        | Yes, with sig | Yes, without | Yes, without |
   | without revocations |               | revocations  | revocations  |
   +---------------------+---------------+--------------+--------------+
   | Signed Data,        | Yes, with sig | Yes, with    | Yes, with    |
   | with revocations    |               | revocations  | revocations  |
   +---------------------+---------------+--------------+--------------+

4.  Sources of Bootstrapping Data

   This section defines some sources for bootstrapping data that a
   device can access.  The list of sources defined here is not meant to
   be exhaustive.  It is left to future documents to define additional
   sources for obtaining bootstrapping data.

   For each source of bootstrapping data defined in this section,
   details are given for how the three artifacts listed in Section 3 are
   provided.

4.1.  Removable Storage

   A directly attached removable storage device (e.g., a USB flash
   drive) MAY be used as a source of SZTP bootstrapping data.

   Use of a removable storage device is compelling, as it does not
   require any external infrastructure to work.  It is notable that the
   raw boot image file can also be located on the removable storage
   device, enabling a removable storage device to be a fully self-
   standing bootstrapping solution.

   To use a removable storage device as a source of bootstrapping data,
   a device need only detect if the removable storage device is plugged
   in and mount its filesystem.

   A removable storage device is an untrusted source of bootstrapping
   data.  This means that the information stored on the removable
   storage device either MUST be signed or MUST be information that can
   be processed provisionally (e.g., unsigned redirect information).

   From an artifact perspective, since a removable storage device
   presents itself as a filesystem, the bootstrapping artifacts need to
   be presented as files.  The three artifacts defined in Section 3 are
   mapped to files below.
Top   ToC   RFC8572 - Page 16
   Artifact to File Mapping:

      Conveyed Information:  Mapped to a file containing the binary
         artifact described in Section 3.1 (e.g., conveyed-
         information.cms).

      Owner Certificate:  Mapped to a file containing the binary
         artifact described in Section 3.2 (e.g., owner-
         certificate.cms).

      Ownership Voucher:  Mapped to a file containing the binary
         artifact described in Section 3.3 (e.g., ownership-voucher.cms
         or ownership-voucher.vcj).

   The format of the removable storage device's filesystem and the
   naming of the files are outside the scope of this document.  However,
   in order to facilitate interoperability, it is RECOMMENDED that
   devices support open and/or standards-based filesystems.  It is also
   RECOMMENDED that devices assume a file naming convention that enables
   more than one instance of bootstrapping data (i.e., for different
   devices) to exist on a removable storage device.  The file naming
   convention SHOULD additionally be unique to the manufacturer, in
   order to enable bootstrapping data from multiple manufacturers to
   exist on a removable storage device.

4.2.  DNS Server

   A DNS server MAY be used as a source of SZTP bootstrapping data.

   Using a DNS server may be a compelling option for deployments having
   existing DNS infrastructure, as it enables a touchless bootstrapping
   option that does not entail utilizing an Internet-based resource
   hosted by a third party.

   DNS is an untrusted source of bootstrapping data.  Even if DNSSEC
   [RFC6698] is used to authenticate the various DNS resource records
   (e.g., A, AAAA, CERT, TXT, and TLSA), the device cannot be sure that
   the domain returned to it, e.g., from a DHCP server, belongs to its
   rightful owner.  This means that the information stored in the DNS
   records either MUST be signed (per this document, not DNSSEC) or MUST
   be information that can be processed provisionally (e.g., unsigned
   redirect information).
Top   ToC   RFC8572 - Page 17
4.2.1.  DNS Queries

   Devices claiming to support DNS as a source of bootstrapping data
   MUST first query for device-specific DNS records and then, only if
   doing so does not result in a successful bootstrap, MUST query for
   device-independent DNS records.

   For each of the device-specific and device-independent queries,
   devices MUST first query using multicast DNS [RFC6762] and then, only
   if doing so does not result in a successful bootstrap, MUST query
   again using unicast DNS [RFC1035] [RFC7766].  This assumes the
   address of a DNS server is known, such as it may be using techniques
   similar to those described in Section 11 of [RFC6763].

   When querying for device-specific DNS records, devices MUST query for
   TXT records [RFC1035] under "<serial-number>._sztp", where <serial-
   number> is the device's serial number (the same value as in the
   device's secure device identity certificate), and "_sztp" is the
   globally scoped DNS attribute registered per this document (see
   Section 10.7).

   Example device-specific DNS record queries:

      TXT in <serial-number>._sztp.local.  (multicast)
      TXT in <serial-number>._sztp.<domain>.  (unicast)

   When querying for device-independent DNS records, devices MUST query
   for SRV records [RFC2782] under "_sztp._tcp", where "_sztp" is the
   service name registered per this document (see Section 10.6), and
   "_tcp" is the globally scoped DNS attribute registered per [RFC8552].

   Note that a device-independent response is only able to encode
   unsigned data anyway, since signed data necessitates the use of a
   device-specific ownership voucher.  Use of SRV records maximumly
   leverages existing DNS standards.  A response containing multiple SRV
   records is comparable to an unsigned redirect information's list of
   bootstrap servers.

   Example device-independent DNS record queries:

      SRV in _sztp._tcp.local.  (multicast)
      SRV in _sztp._tcp.<domain>.  (unicast)
Top   ToC   RFC8572 - Page 18
4.2.2.  DNS Response for Device-Specific Queries

   For device-specific queries, the three bootstrapping artifacts
   defined in Section 3 are encoded into the TXT records using key/value
   pairs, similar to the technique described in Section 6.3 of
   [RFC6763].

   Artifact to TXT Record Mapping:

      Conveyed Information:  Mapped to a TXT record having the key "ci"
         and the value being the binary artifact described in
         Section 3.1.

      Owner Certificate:  Mapped to a TXT record having the key "oc" and
         the value being the binary artifact described in Section 3.2.

      Ownership Voucher:  Mapped to a TXT record having the key "ov" and
         the value being the binary artifact described in Section 3.3.

   Devices MUST ignore any other keys that may be returned.

   Note that, despite the name, TXT records can and SHOULD (per
   Section 6.5 of [RFC6763]) encode binary data.

   Following is an example of a device-specific response, as it might be
   presented by a user agent, containing signed data.  This example
   assumes that the device's serial number is "<serial-number>", the
   domain is "example.com", and "<binary data>" represents the binary
   artifact:

     <serial-number>._sztp.example.com. 3600 IN TXT "ci=<binary data>"
     <serial-number>._sztp.example.com. 3600 IN TXT "oc=<binary data>"
     <serial-number>._sztp.example.com. 3600 IN TXT "ov=<binary data>"

   Note that, in the case that "ci" encodes unsigned data, the "oc" and
   "ov" keys would not be present in the response.

4.2.3.  DNS Response for Device-Independent Queries

   For device-independent queries, the three bootstrapping artifacts
   defined in Section 3 are encoded into the SVR records as follows.

   Artifact to SRV Record Mapping:

      Conveyed Information:  This artifact is not supported directly.
         Instead, the essence of unsigned redirect information is mapped
         to SVR records per [RFC2782].
Top   ToC   RFC8572 - Page 19
      Owner Certificate:  Not supported.  Device-independent responses
         never encode signed data; hence, there is no need for an owner
         certificate artifact.

      Ownership Voucher:  Not supported.  Device-independent responses
         never encode signed data; hence, there is no need for an
         ownership voucher artifact.

   Following is an example of a device-independent response, as it might
   be presented by a user agent, containing (effectively) unsigned
   redirect information to four bootstrap servers.  This example assumes
   that the domain is "example.com" and that there are four bootstrap
   servers "sztp[1-4]":

      _sztp._tcp.example.com. 1800 IN SRV 0 0 443 sztp1.example.com.
      _sztp._tcp.example.com. 1800 IN SRV 1 0 443 sztp2.example.com.
      _sztp._tcp.example.com. 1800 IN SRV 2 0 443 sztp3.example.com.
      _sztp._tcp.example.com. 1800 IN SRV 2 0 443 sztp4.example.com.

   Note that, in this example, "sztp3" and "sztp4" have equal priority
   and hence effectively represent a clustered pair of bootstrap
   servers.  While "sztp1" and "sztp2" only have a single SRV record
   each, it may be that the record points to a load balancer fronting a
   cluster of bootstrap servers.

   While this document does not use DNS-SD [RFC6763], per Section 12.2
   of that RFC, Multicast DNS (mDNS) responses SHOULD also include all
   address records (type "A" and "AAAA") named in the SRV rdata.

4.2.4.  Size of Signed Data

   The signed data artifacts are large by DNS conventions.  In the
   smallest-footprint scenario, they are each a few kilobytes in size.
   However, onboarding information can easily be several kilobytes in
   size and has the potential to be many kilobytes in size.

   All resource records, including TXT records, have an upper size limit
   of 65535 bytes, since "RDLENGTH" is a 16-bit field (Section 3.2.1 of
   [RFC1035]).  If it is ever desired to encode onboarding information
   that exceeds this limit, the DNS records returned should instead
   encode redirect information, to direct the device to a bootstrap
   server from which the onboarding information can be obtained.

   Given the expected size of the TXT records, it is unlikely that
   signed data will fit into a UDP-based DNS packet, even with the
   Extension Mechanisms for DNS (EDNS(0)) extensions [RFC6891] enabled.
   Depending on content, signed data may also not fit into a multicast
   DNS packet, which bounds the size to 9000 bytes, per Section 17 of
Top   ToC   RFC8572 - Page 20
   [RFC6762].  Thus, it is expected that DNS Transport over TCP
   [RFC7766] will be required in order to return signed data.

4.3.  DHCP Server

   A DHCP server MAY be used as a source of SZTP bootstrapping data.

   Using a DHCP server may be a compelling option for deployments having
   existing DHCP infrastructure, as it enables a touchless bootstrapping
   option that does not entail utilizing an Internet-based resource
   hosted by a third party.

   A DHCP server is an untrusted source of bootstrapping data.  Thus,
   the information stored on the DHCP server either MUST be signed or
   MUST be information that can be processed provisionally (e.g.,
   unsigned redirect information).

   However, unlike other sources of bootstrapping data described in this
   document, the DHCP protocol (especially DHCP for IPv4) is very
   limited in the amount of data that can be conveyed, to the extent
   that signed data cannot be communicated.  This means that only
   unsigned redirect information can be conveyed via DHCP.

   Since the redirect information is unsigned, it SHOULD NOT include the
   optional trust anchor certificate, as it takes up space in the DHCP
   message, and the device would have to discard it anyway.  For this
   reason, the DHCP options defined in Section 8 do not enable the trust
   anchor certificate to be encoded.

   From an artifact perspective, the three artifacts defined in
   Section 3 are mapped to the DHCP fields specified in Section 8 as
   follows.

   Artifact to DHCP Option Fields Mapping:

      Conveyed Information:  This artifact is not supported directly.
         Instead, the essence of unsigned redirect information is mapped
         to the DHCP options described in Section 8.

      Owner Certificate:  Not supported.  There is not enough space in
         the DHCP packet to hold an owner certificate artifact.

      Ownership Voucher:  Not supported.  There is not enough space in
         the DHCP packet to hold an ownership voucher artifact.
Top   ToC   RFC8572 - Page 21
4.4.  Bootstrap Server

   A bootstrap server MAY be used as a source of SZTP bootstrapping
   data.  A bootstrap server is defined as a RESTCONF [RFC8040] server
   implementing the YANG module provided in Section 7.

   Using a bootstrap server as a source of bootstrapping data is a
   compelling option as it MAY use transport-level security, obviating
   the need for signed data, which may be easier to deploy in some
   situations.

   Unlike any other source of bootstrapping data described in this
   document, a bootstrap server is not only a source of data, but it can
   also receive data from devices using the YANG-defined "report-
   progress" RPC defined in the YANG module provided in Section 7.3.
   The "report-progress" RPC enables visibility into the bootstrapping
   process (e.g., warnings and errors) and provides potentially useful
   information upon completion (e.g., the device's Secure Shell (SSH)
   host keys and/or TLS trust anchor certificates).

   A bootstrap server may be a trusted or an untrusted source of
   bootstrapping data, depending on if the device learned about the
   bootstrap server's trust anchor from a trusted source.  When a
   bootstrap server is trusted, the conveyed information returned from
   it MAY be signed.  When the bootstrap server is untrusted, the
   conveyed information either MUST be signed or MUST be information
   that can be processed provisionally (e.g., unsigned redirect
   information).

   From an artifact perspective, since a bootstrap server presents data
   conforming to a YANG data model, the bootstrapping artifacts need to
   be mapped to YANG nodes.  The three artifacts defined in Section 3
   are mapped to "output" nodes of the "get-bootstrapping-data" RPC
   defined in Section 7.3.

   Artifact to Bootstrap Server Mapping:

      Conveyed Information:  Mapped to the "conveyed-information" leaf
         in the output of the "get-bootstrapping-data" RPC.

      Owner Certificate:  Mapped to the "owner-certificate" leaf in the
         output of the "get-bootstrapping-data" RPC.

      Ownership Voucher:  Mapped to the "ownership-voucher" leaf in the
         output of the "get-bootstrapping-data" RPC.

   SZTP bootstrap servers have only two endpoints: one for the
   "get-bootstrapping-data" RPC and one for the "report-progress" RPC.
Top   ToC   RFC8572 - Page 22
   These RPCs use the authenticated RESTCONF username to isolate the
   execution of the RPC from other devices.



(page 22 continued on part 2)

Next Section