Secure Zero Touch Provisioning (SZTP)
RFC 8572
| Document | Type | RFC - Proposed Standard (April 2019) Errata | |
|---|---|---|---|
| Authors | Kent Watsen , Mikael Abrahamsson , Ian Farrer | ||
| Last updated | 2021-06-22 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Ignas Bagdonas | |
| Send notices to | (None) |
RFC 8572
Watsen, et al. Standards Track [Page 81] RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 so that the NMS can authenticate the IDevID certificates when they are presented to subsequent steps. * If the manufacturer hosts an Internet-based bootstrap server (e.g., a redirect server) such as described in Section 4.4, then credentials necessary to configure the bootstrap server would be provided to the prospective owner. If the bootstrap server is configurable through an API (outside the scope of this document), then the credentials might be installed on the prospective owner's NMS so that the NMS can subsequently configure the manufacturer-hosted bootstrap server directly. 2. If the manufacturer's devices are able to validate signed data (Section 5.4), and assuming that the prospective owner's NMS is able to prepare and sign the bootstrapping data itself, the prospective owner's NMS might set a trust anchor certificate onto the manufacturer's bootstrap server, using the credentials provided in the previous step. This certificate is the trust anchor certificate that the prospective owner would like the manufacturer to place into the ownership vouchers it generates, thereby enabling devices to trust the owner's owner certificate. How this trust anchor certificate is used to enable devices to validate signed bootstrapping data is described in Section 5.4. 3. Some time later, the prospective owner places an order with the manufacturer, perhaps with a special flag checked for SZTP handling. At this time, or perhaps before placing the order, the owner may model the devices in their NMS, creating virtual objects for the devices with no real-world device associations. For instance, the model can be used to simulate the device's location in the network and the configuration it should have when fully operational. 4. When the manufacturer fulfills the order, shipping the devices to their intended locations, they may notify the owner of the devices' serial numbers and shipping destinations, which the owner may use to stage the network for when the devices power on. Additionally, the manufacturer may send one or more ownership vouchers, cryptographically assigning ownership of those devices to the owner. The owner may set this information on their NMS, perhaps binding specific modeled devices to the serial numbers and ownership vouchers. Watsen, et al. Standards Track [Page 82] RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 C.2. Owner Stages the Network for Bootstrap The following diagram illustrates how an owner might stage the network for bootstrapping devices. +-----------+ +-------------+ |Deployment-| |Manufacturer-| +------+ +------+ | Specific | | Hosted | | Local| | Local| +---------+ +---+ | Bootstrap | | Bootstrap | | DNS | | DHCP | |Removable| |NMS| | Server | | Server | |Server| |Server| | Storage | +---+ +-----------+ +-------------+ +------+ +------+ +---------+ | | | | | | 1. | | | | | | activate| | | | | | modeled | | | | | | device | | | | | | ------->| | | | | | | 2. (optional) | | | | | configure | | | | | bootstrap | | | | | server | | | | |------->| | | | | | | | | | | | 3. (optional) configure | | | | bootstrap server | | | | |--------------------->| | | | | | | | | | | | | | | | | 4. (optional) configure DNS server| | | |---------------------------------->| | | | | | | | | | | | | | | | 5. (optional) configure DHCP server | | |------------------------------------------->| | | | | | | | | | | | | | | 6. (optional) store bootstrapping artifacts on media | |----------------------------------------------------->| | | | | | | | | | | | | Each numbered item below corresponds to a numbered item in the diagram above. 1. Having previously modeled the devices, including setting their fully operational configurations and associating device serial numbers and (optionally) ownership vouchers, the owner might "activate" one or more modeled devices. That is, the owner tells Watsen, et al. Standards Track [Page 83] RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 the NMS to perform the steps necessary to prepare for when the real-world devices power up and initiate the bootstrapping process. Note that, in some deployments, this step might be combined with the last step from the previous workflow. Here, it is depicted that an NMS performs the steps, but they may be performed manually or through some other mechanism. 2. If it is desired to use a deployment-specific bootstrap server, it must be configured to provide the bootstrapping data for the specific devices. Configuring the bootstrap server may occur via a programmatic API not defined by this document. Illustrated here as an external component, the bootstrap server may be implemented as an internal component of the NMS itself. 3. If it is desired to use a manufacturer-hosted bootstrap server, it must be configured to provide the bootstrapping data for the specific devices. The configuration must be either redirect or onboarding information. That is, the manufacturer-hosted bootstrap server will either redirect the device to another bootstrap server or provide the device with the onboarding information itself. The types of bootstrapping data the manufacturer-hosted bootstrap server supports may vary by implementation; some implementations may support only redirect information or only onboarding information, while others may support both redirect and onboarding information. Configuring the bootstrap server may occur via a programmatic API not defined by this document. 4. If it is desired to use a DNS server to supply bootstrapping data, a DNS server needs to be configured. If multicast DNS is desired, then the DNS server must reside on the local network; otherwise, the DNS server may reside on a remote network. Please see Section 4.2 for more information about how to configure DNS servers. Configuring the DNS server may occur via a programmatic API not defined by this document. 5. If it is desired to use a DHCP server to supply bootstrapping data, a DHCP server needs to be configured. The DHCP server may be accessed directly or via a DHCP relay. Please see Section 4.3 for more information about how to configure DHCP servers. Configuring the DHCP server may occur via a programmatic API not defined by this document. 6. If it is desired to use a removable storage device (e.g., a USB flash drive) to supply bootstrapping data, the data would need to be placed onto it. Please see Section 4.1 for more information about how to configure a removable storage device. Watsen, et al. Standards Track [Page 84] RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 C.3. Device Powers On The following diagram illustrates the sequence of activities that occur when a device powers on. +-----------+ +-----------+ |Deployment-| | Source of | | Specific | +------+ | Bootstrap | | Bootstrap | +---+ |Device| | Data | | Server | |NMS| +------+ +-----------+ +-----------+ +---+ | | | | | | | | | 1. if SZTP bootstrap service | | | | is not enabled, then exit. | | | | | | | | 2. for each source supported, check | | | | for bootstrapping data. | | | |------------------------------------>| | | | | | | | 3. if onboarding information is | | | | found, initialize self and, only | | | | if source is a trusted bootstrap | | | | server, send progress reports. | | | |------------------------------------># | | | # webhook | | | #------------------------>| | | | | 4. else, if redirect information is found, for | | | each bootstrap server specified, check for data.| | |-+------------------------------------------------->| | | | | | | | if more redirect information is found, recurse | | | | (not depicted); else, if onboarding information | | | | is found, initialize self and post progress | | | | reports. | | | +-------------------------------------------------># | | # webhook | | #--------->| | | 5. retry sources and/or wait for manual provisioning. | The interactions in the above diagram are described below. 1. Upon power being applied, the device checks to see if SZTP bootstrapping is configured, such as must be the case when running its "factory default" configuration. If SZTP Watsen, et al. Standards Track [Page 85] RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 bootstrapping is not configured, then the bootstrapping logic exits and none of the following interactions occur. 2. For each source of bootstrapping data the device supports, preferably in order of closeness to the device (e.g., removable storage before Internet-based servers), the device checks to see if there is any bootstrapping data for it there. 3. If onboarding information is found, the device initializes itself accordingly (e.g., installing a boot image and committing an initial configuration). If the source is a bootstrap server, and the bootstrap server can be trusted (i.e., TLS-level authentication), the device also sends progress reports to the bootstrap server. * The contents of the initial configuration should configure an administrator account on the device (e.g., username, SSH public key, etc.), should configure the device to either listen for NETCONF or RESTCONF connections or initiate call home connections [RFC8071], and should disable the SZTP bootstrapping service (e.g., the "enabled" leaf in data model presented in Appendix A). * If the bootstrap server supports forwarding device progress reports to external systems (e.g., via a webhook), a "bootstrap-complete" progress report (Section 7.3) informs the external system to know when it can, for instance, initiate a connection to the device. To support this scenario further, the "bootstrap-complete" progress report may also relay the device's SSH host keys and/or TLS certificates, which the external system can use to authenticate subsequent connections to the device. If the device successfully completes the bootstrapping process, it exits the bootstrapping logic without considering any additional sources of bootstrapping data. 4. Otherwise, if redirect information is found, the device iterates through the list of specified bootstrap servers, checking to see if the bootstrap server has bootstrapping data for the device. If the bootstrap server returns more redirect information, then the device processes it recursively. Otherwise, if the bootstrap server returns onboarding information, the device processes it following the description provided in (3) above. 5. After having tried all supported sources of bootstrapping data, the device may retry again all the sources and/or provide manageability interfaces for manual configuration (e.g., CLI, Watsen, et al. Standards Track [Page 86] RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 HTTP, NETCONF, etc.). If manual configuration is allowed, and such configuration is provided, the configuration should also disable the SZTP bootstrapping service, as the need for bootstrapping would no longer be present. Acknowledgements The authors would like to thank the following for lively discussions on list and in the halls (ordered by last name): Michael Behringer, Martin Bjorklund, Dean Bogdanovic, Joe Clarke, Dave Crocker, Toerless Eckert, Stephen Farrell, Stephen Hanna, Wes Hardaker, David Harrington, Benjamin Kaduk, Radek Krejci, Suresh Krishnan, Mirja Kuehlewind, David Mandelberg, Alexey Melnikov, Russ Mundy, Reinaldo Penno, Randy Presuhn, Max Pritikin, Michael Richardson, Adam Roach, Juergen Schoenwaelder, and Phil Shafer. Special thanks goes to Steve Hanna, Russ Mundy, and Wes Hardaker for brainstorming the original solution during the IETF 87 meeting in Berlin. Authors' Addresses Kent Watsen Watsen Networks Email: kent+ietf@watsen.net Ian Farrer Deutsche Telekom AG Email: ian.farrer@telekom.de Mikael Abrahamsson T-Systems Email: mikael.abrahamsson@t-systems.se Watsen, et al. Standards Track [Page 87]