Secure Zero Touch Provisioning (SZTP)
updated by
- rfc-9646 — Conveying a Certificate Signing Request (CSR) in a Secure Zero-Touch Provisioning (SZTP) Bootstrapping Request
Extracted elements (30)
Artifacts are always signed and then encrypted (never encrypted then signed). This ensures the signer's certificate is shrouded, the owner knows what content is being signed, and the owner can inspect an unencrypted voucher obtained from a manufacturer and then encrypt it later themselves, possibly while also stapling fresh revocation objects.
DHCP is restricted to conveying only unsigned redirect information because DHCPv4 in particular is severely limited in payload capacity, making it impossible to carry signed data artifacts (owner certificate, ownership voucher, signed conveyed information). Including a trust anchor in DHCP redirect options is deliberately unsupported since the device would discard it anyway as untrusted data.
Signed SZTP bootstrapping artifacts are large by DNS conventions (several to many kilobytes). Because mDNS bounds responses to 9000 bytes and UDP DNS is limited even with EDNS(0), DNS Transport over TCP (RFC 7766) is expected to be required whenever signed data is returned via DNS. If onboarding information exceeds the 65535-byte TXT record limit, redirect information should be used instead.
Devices MUST have a configurable variable to enable/disable SZTP bootstrapping, and it MUST be enabled by default so bootstrapping runs on first power-on. Using a presence-based configuration node is NOT RECOMMENDED because it cannot be removed by a merge operation.
For DNS-based bootstrapping, devices MUST first query device-specific TXT records under '<serial-number>._sztp', and only if that fails MUST query device-independent SRV records under '_sztp._tcp'. Within each category, multicast DNS (mDNS) MUST be tried before unicast DNS.
Implementations MUST limit the maximum number of recursive redirects; the limit SHOULD be no more than ten. Redirect information can only redirect devices to bootstrap servers, so each redirect re-enters the processing algorithm with a bootstrap server as the source.
Removable storage is an untrusted source; information stored on it MUST be signed or MUST be information processable provisionally (e.g., unsigned redirect information). Onboarding information from removable storage must therefore always be signed.
To validate signed data, the device MUST first authenticate the ownership voucher to a pre-configured trust anchor, verify its serial number field, optionally verify timestamps and expiry, extract the pinned-domain-cert, then authenticate the owner certificate chain to that pinned-domain-cert, and finally verify the conveyed information was signed by the validated owner certificate. Failure at any step MUST invalidate the signed data.
When establishing a connection to any bootstrap server (trusted or untrusted), the device MUST identify and authenticate itself using a TLS-level client certificate and/or an HTTP authentication scheme per RFC 8040 Section 2.5. If both mechanisms are used, they MUST both identify the same serial number.
When processing onboarding information, the device MUST execute steps in strict order: (1) process boot image, (2) execute pre-configuration script, (3) commit initial configuration, (4) execute post-configuration script. If any step fails, the device MUST stop and return to the bootstrapping sequence.
When processing redirect information from a trusted source that includes a trust anchor certificate for a bootstrap server, the device MUST authenticate the bootstrap server's TLS certificate using X.509 path validation to that anchor. If no trust anchor is included, the device MUST establish a provisional (blind) TLS connection and set trust-state to FALSE.
When the onboarding information is obtained from a trusted bootstrap server, the device MUST send a 'bootstrap-initiated' progress report and MUST send a terminating progress report ('boot-image-installed-rebooting', 'bootstrap-complete', or an error-specific report). When obtained from an untrusted bootstrap server, the device MUST NOT send any progress reports.
The bootstrap server API is a RESTCONF (RFC 8040) server exposing exactly two RPCs: 'get-bootstrapping-data' (returns conveyed-information, owner-certificate, and ownership-voucher leaves) and 'report-progress' (receives device progress events). The authenticated RESTCONF username isolates execution per device.
The conveyed information artifact is a CMS structure (RFC 5652) DER-encoded using ASN.1 (ITU-T X.690) that carries either redirect information or onboarding information. It may be unsigned/unencrypted, unsigned/encrypted, signed/unencrypted, or signed/encrypted, with the CMS topmost OID indicating which combination is used.
The 'ietf-sztp-conveyed-info' YANG 1.1 module defines a yang-data structure 'conveyed-information' with a mandatory choice between 'redirect-information' (list of bootstrap servers with address, optional port defaulting to 443, optional trust-anchor CMS) and 'onboarding-information' (boot-image, configuration-handling, pre/post-configuration scripts, configuration).
The owner certificate artifact is an X.509 certificate (RFC 5280) identifying the device owner, wrapped in a degenerate CMS SignedData structure with no signers. It MUST contain all intermediate certificates up to the 'pinned-domain-cert' from the ownership voucher, and MAY include stapled CRLs or OCSP responses for offline revocation checking.
The ownership voucher artifact is defined by RFC 8366 and is a manufacturer-signed CMS structure whose eContentType is id-ct-animaJSONVoucher. It binds a device (by serial number) to an owner by including a 'pinned-domain-cert' X.509 certificate that anchors the owner certificate chain.
A new DHCPv4 option is registered in the BOOTP Vendor Extensions and DHCP Options Registry for the SZTP Redirect Option (Section 8.1), and a new DHCPv6 option is registered in the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Registry (Section 8.2) for the SZTP Redirect Option.
The service name '_sztp' is registered in the Service Name and Transport Protocol Port Number Registry for SZTP bootstrap server discovery via DNS SRV records. The DNS node name '_sztp' is also registered in the Underscored and Globally Scoped DNS Node Names Registry per RFC 8552 for use in device-specific TXT record queries.
Two new OIDs are registered in the SMI Security for S/MIME CMS Content Type Registry: id-ct-sztpConveyedInfoXML (for XML-encoded conveyed information) and id-ct-sztpConveyedInfoJSON (for JSON-encoded conveyed information). These OIDs are used as the CMS content type for the conveyed information artifact.
Two YANG modules are registered in the YANG Module Names Registry: 'ietf-sztp-conveyed-info' (namespace urn:ietf:params:xml:ns:yang:ietf-sztp-conveyed-info) defining the conveyed information data model, and 'ietf-sztp-bootstrap-server' defining the bootstrap server RESTCONF API.
Certificate validity checking in ownership voucher validation requires an accurate clock. If a device has an inaccurate or no clock, it cannot verify 'created-on' and 'expires-on' timestamps, potentially accepting expired or future-dated vouchers. Devices with accurate clocks MUST perform these timestamp checks.
Redirect chains can cascade trust: each redirect can specify a new trust anchor for the next bootstrap server. An operator must understand that trusting the first redirect server implicitly trusts all subsequent redirects in the chain. Implementations MUST cap recursive redirects (SHOULD be no more than ten) to prevent redirect loops or abuse.
Trust anchor certificates and IDevID private keys MUST be stored in read-only or secure (ideally hardware-backed, e.g., TPM) storage on the device. Compromise of the IDevID private key would allow impersonation of the device; compromise of trust anchor certificates would allow a rogue manufacturer or CA to redirect or onboard the device maliciously.
When a device blindly authenticates a bootstrap server (provisional connection), it discloses its IDevID certificate serial number and other identity information to a potentially untrusted server. Operators should be aware that this exposes device inventory data; bootstrap servers are recommended to promote untrusted connections to trusted ones to mitigate this.
A conceptual globally scoped 'trust-state' variable, initialized to FALSE, governs what bootstrapping data a device may accept. Trust-state is set to TRUE when the device authenticates a bootstrap server to a pre-configured trust anchor or when it successfully validates signed data per Section 5.4. Onboarding information MUST NOT be processed when trust-state is FALSE.
The device boot sequence defines four states: (1) check if SZTP bootstrapping is configured, (2) iterate over sources of bootstrapping data, (3) if bootstrapped successfully run with new config, (4) otherwise loop back to step 1. The trigger to exit the loop is a successful bootstrap from any source.
For DNS device-independent queries, bootstrapping data is encoded as SRV records under '_sztp._tcp', where each SRV record encodes priority, weight, port, and target hostname of a bootstrap server, effectively representing unsigned redirect information without support for signed data or trust anchor certificates.
For DNS device-specific queries, bootstrapping artifacts are encoded as key/value pairs in TXT records: 'ci' carries the conveyed-information binary CMS artifact, 'oc' carries the owner-certificate binary artifact, and 'ov' carries the ownership-voucher binary artifact. All DNS TXT records are capped at 65535 bytes (16-bit RDLENGTH field).
The DHCPv4 SZTP Redirect Option (Section 8.1) and DHCPv6 SZTP Redirect Option (Section 8.2) encode only unsigned redirect information (a list of bootstrap server host/port pairs) because DHCP packet size constraints preclude carrying signed artifacts. The trust anchor certificate field is intentionally omitted from the DHCP option encoding.