RFC 8572
Secure Zero Touch Provisioning (SZTP)
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.
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.
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
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
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.
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.
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.
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.
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.
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.
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
(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
(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.
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):
+---------------------+---------------+--------------+--------------+ | 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.
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).
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)
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].
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
[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.
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.
These RPCs use the authenticated RESTCONF username to isolate the execution of the RPC from other devices.
(page 22 continued on part 2)
