Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8572

Secure Zero Touch Provisioning (SZTP)

Pages: 87
Proposed Standard
Errata
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