From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8572.txt | 4875 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 4875 insertions(+) create mode 100644 doc/rfc/rfc8572.txt (limited to 'doc/rfc/rfc8572.txt') diff --git a/doc/rfc/rfc8572.txt b/doc/rfc/rfc8572.txt new file mode 100644 index 0000000..f22c531 --- /dev/null +++ b/doc/rfc/rfc8572.txt @@ -0,0 +1,4875 @@ + + + + + + +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. + + + + + + + + + + + + + + + +Watsen, et al. Standards Track [Page 1] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + +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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Watsen, et al. Standards Track [Page 2] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + +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 + + + +Watsen, et al. Standards Track [Page 3] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + 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 + + + + + + + + + + + + + + + + + +Watsen, et al. Standards Track [Page 4] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + +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. + + + + + + + + + + + +Watsen, et al. Standards Track [Page 5] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + 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. + + + + + + + +Watsen, et al. Standards Track [Page 6] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + 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. + + + + + + + + +Watsen, et al. Standards Track [Page 7] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + 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. + + + + + + + + + + + +Watsen, et al. Standards Track [Page 8] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + 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. + + + + + + + + + + + + + + +Watsen, et al. Standards Track [Page 9] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + 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. + + + +Watsen, et al. Standards Track [Page 10] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + 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 + + + +Watsen, et al. Standards Track [Page 11] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + (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 + + + +Watsen, et al. Standards Track [Page 12] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + (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. + + + +Watsen, et al. Standards Track [Page 13] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + 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): + + + +Watsen, et al. Standards Track [Page 14] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + +---------------------+---------------+--------------+--------------+ + | 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. + + + +Watsen, et al. Standards Track [Page 15] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + 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). + + + + + + + + + +Watsen, et al. Standards Track [Page 16] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + +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 "._sztp", where 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 ._sztp.local. (multicast) + TXT in ._sztp.. (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.. (unicast) + + + + + + + + + +Watsen, et al. Standards Track [Page 17] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + +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 "", the + domain is "example.com", and "" represents the binary + artifact: + + ._sztp.example.com. 3600 IN TXT "ci=" + ._sztp.example.com. 3600 IN TXT "oc=" + ._sztp.example.com. 3600 IN TXT "ov=" + + 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]. + + + + +Watsen, et al. Standards Track [Page 18] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + 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 + + + +Watsen, et al. Standards Track [Page 19] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + [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. + + + + + + + +Watsen, et al. Standards Track [Page 20] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + +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. + + + +Watsen, et al. Standards Track [Page 21] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + These RPCs use the authenticated RESTCONF username to isolate the + execution of the RPC from other devices. + +5. Device Details + + Devices supporting the bootstrapping strategy described in this + document MUST have the pre-configured state and bootstrapping logic + described in the following sections. + +5.1. Initial State + + +-------------------------------------------------------------+ + | | + | | + | +---------------------------------------------------------+ | + | | | | + | | | | + | | 1. flag to enable SZTP bootstrapping set to "true" | | + | +---------------------------------------------------------+ | + | | + | +---------------------------------------------------------+ | + | | | | + | | | | + | | 2. TLS client cert & related intermediate certificates | | + | | 3. list of trusted well-known bootstrap servers | | + | | 4. list of trust anchor certs for bootstrap servers | | + | | 5. list of trust anchor certs for ownership vouchers | | + | +---------------------------------------------------------+ | + | | + | +-----------------------------------------------------+ | + | | | | + | | | | + | | 6. private key for TLS client certificate | | + | | 7. private key for decrypting SZTP artifacts | | + | +-----------------------------------------------------+ | + | | + +-------------------------------------------------------------+ + + Each numbered item below corresponds to a numbered item in the + diagram above. + + 1. Devices MUST have a configurable variable that is used to enable/ + disable SZTP bootstrapping. This variable MUST be enabled by + default in order for SZTP bootstrapping to run when the device + first powers on. Because it is a goal that the configuration + installed by the bootstrapping process disables SZTP + bootstrapping, and because the configuration may be merged into + the existing configuration, using a configuration node that + + + +Watsen, et al. Standards Track [Page 22] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + relies on presence is NOT RECOMMENDED, as it cannot be removed by + the merging process. + + 2. Devices that support loading bootstrapping data from bootstrap + servers (see Section 4.4) SHOULD possess a TLS-level client + certificate and any intermediate certificates leading to the + certificate's well-known trust anchor. The well-known trust + anchor certificate may be an intermediate certificate or a self- + signed root certificate. To support devices not having a client + certificate, devices MAY, alternatively or in addition to, + identify and authenticate themselves to the bootstrap server + using an HTTP authentication scheme, as allowed by Section 2.5 of + [RFC8040]; however, this document does not define a mechanism for + operator input enabling, for example, the entering of a password. + + 3. Devices that support loading bootstrapping data from well-known + bootstrap servers MUST possess a list of the well-known bootstrap + servers. Consistent with redirect information (Section 2.1), + each bootstrap server can be identified by its hostname or IP + address and an optional port. + + 4. Devices that support loading bootstrapping data from well-known + bootstrap servers MUST also possess a list of trust anchor + certificates that can be used to authenticate the well-known + bootstrap servers. For each trust anchor certificate, if it is + not itself a self-signed root certificate, the device SHOULD also + possess the chain of intermediate certificates leading up to and + including the self-signed root certificate. + + 5. Devices that support loading signed data (see Section 1.2) MUST + possess the trust anchor certificates for validating ownership + vouchers. For each trust anchor certificate, if it is not itself + a self-signed root certificate, the device SHOULD also possess + the chain of intermediate certificates leading up to and + including the self-signed root certificate. + + 6. Devices that support using a TLS-level client certificate to + identify and authenticate themselves to a bootstrap server MUST + possess the private key that corresponds to the public key + encoded in the TLS-level client certificate. This private key + SHOULD be securely stored, ideally in a cryptographic processor, + such as a trusted platform module (TPM) chip. + + 7. Devices that support decrypting SZTP artifacts MUST posses the + private key that corresponds to the public key encoded in the + secure device identity certificate used when encrypting the + artifacts. This private key SHOULD be securely stored, ideally + in a cryptographic processor, such as a trusted platform module + + + +Watsen, et al. Standards Track [Page 23] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + (TPM) chip. This private key MAY be the same as the one + associated to the TLS-level client certificate used when + connecting to bootstrap servers. + + A YANG module representing this data is provided in Appendix A. + +5.2. Boot Sequence + + A device claiming to support the bootstrapping strategy defined in + this document MUST support the boot sequence described in this + section. + + Power On + | + v No + 1. SZTP bootstrapping configured ------> Boot normally + | + | Yes + v + 2. For each supported source of bootstrapping data, + try to load bootstrapping data from the source + | + | + v Yes + 3. Able to bootstrap from any source? -----> Run with new config + | + | No + v + 4. Loop back to Step 1 + + + Note: At any time, the device MAY be configured via an alternate + provisioning mechanism (e.g., command-line interface (CLI)). + + Each numbered item below corresponds to a numbered item in the + diagram above. + + 1. When the device powers on, it first checks to see if SZTP + bootstrapping is configured, as is expected to be the case for + the device's pre-configured initial state. If SZTP bootstrapping + is not configured, then the device boots normally. + + 2. The device iterates over its list of sources for bootstrapping + data (Section 4). Details for how to process a source of + bootstrapping data are provided in Section 5.3. + + + + + + +Watsen, et al. Standards Track [Page 24] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + 3. If the device is able to bootstrap itself from any of the sources + of bootstrapping data, it runs with the new bootstrapped + configuration. + + 4. Otherwise, the device MUST loop back through the list of + bootstrapping sources again. + + This document does not limit the simultaneous use of alternate + provisioning mechanisms. Such mechanisms may include, for instance, + a CLI, a web-based user interface, or even another bootstrapping + protocol. Regardless of how it is configured, the configuration + SHOULD unset the flag enabling SZTP bootstrapping as discussed in + Section 5.1. + +5.3. Processing a Source of Bootstrapping Data + + This section describes a recursive algorithm that devices can use to, + ultimately, obtain onboarding information. The algorithm is + recursive because sources of bootstrapping data may return redirect + information, which causes the algorithm to run again, for the newly + discovered sources of bootstrapping data. An expression that + captures all possible successful sequences of bootstrapping data is: + zero or more redirect information responses, followed by one + onboarding information response. + + An important aspect of the algorithm is knowing when data needs to be + signed or not. The following figure provides a summary of options: + + Untrusted Source Trusted Source + Kind of Bootstrapping Data Can Provide? Can Provide? + + Unsigned Redirect Info : Yes+ Yes + Signed Redirect Info : Yes Yes* + Unsigned Onboarding Info : No Yes + Signed Onboarding Info : Yes Yes* + + The '+' above denotes that the source redirected to MUST + return signed data or more unsigned redirect information. + + The '*' above denotes that, while possible, it is generally + unnecessary for a trusted source to return signed data. + + The recursive algorithm uses a conceptual globally scoped variable + called "trust-state". The trust-state variable is initialized to + FALSE. The ultimate goal of this algorithm is for the device to + process onboarding information (Section 2.2) while the trust-state + variable is TRUE. + + + + +Watsen, et al. Standards Track [Page 25] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + If the source of bootstrapping data (Section 4) is a bootstrap server + (Section 4.4), and the device is able to authenticate the bootstrap + server using X.509 certificate path validation ([RFC6125], Section 6) + to one of the device's pre-configured trust anchors, or to a trust + anchor that it learned from a previous step, then the device MUST set + trust-state to TRUE. + + When establishing a connection to a bootstrap server, whether trusted + or untrusted, the device MUST identify and authenticate itself to the + bootstrap server using a TLS-level client certificate and/or an HTTP + authentication scheme, per Section 2.5 of [RFC8040]. If both + authentication mechanisms are used, they MUST both identify the same + serial number. + + When sending a client certificate, the device MUST also send all of + the intermediate certificates leading up to, and optionally + including, the client certificate's well-known trust anchor + certificate. + + For any source of bootstrapping data (e.g., Section 4), if any + artifact obtained is encrypted, the device MUST first decrypt it + using the private key associated with the device certificate used to + encrypt the artifact. + + If the conveyed information artifact is signed, and the device is + able to validate the signed data using the algorithm described in + Section 5.4, then the device MUST set trust-state to TRUE; otherwise, + if the device is unable to validate the signed data, the device MUST + set trust-state to FALSE. Note that this is worded to cover the + special case when signed data is returned even from a trusted source + of bootstrapping data. + + If the conveyed information artifact contains redirect information, + the device MUST, within limits of how many recursive loops the device + allows, process the redirect information as described in Section 5.5. + Implementations MUST limit the maximum number of recursive redirects + allowed; the maximum number of recursive redirects allowed SHOULD be + no more than ten. This is the recursion step; it will cause the + device to reenter this algorithm, but this time the data source will + definitely be a bootstrap server, as redirect information is only + able to redirect devices to bootstrap servers. + + If the conveyed information artifact contains onboarding information, + and trust-state is FALSE, the device MUST exit the recursive + algorithm (as this is not allowed; see the figure above), returning + to the bootstrapping sequence described in Section 5.2. Otherwise, + the device MUST attempt to process the onboarding information as + described in Section 5.6. Whether the processing of the onboarding + + + +Watsen, et al. Standards Track [Page 26] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + information succeeds or fails, the device MUST exit the recursive + algorithm, returning to the bootstrapping sequence described in + Section 5.2; the only difference is how it responds to the "Able to + bootstrap from any source?" conditional described in the figure in + that section. + +5.4. Validating Signed Data + + Whenever a device is presented signed data, it MUST validate the + signed data as described in this section. This includes the case + where the signed data is provided by a trusted source. + + Whenever there is signed data, the device MUST also be provided an + ownership voucher and an owner certificate. How all the needed + artifacts are provided for each source of bootstrapping data is + described in Section 4. + + In order to validate signed data, the device MUST first authenticate + the ownership voucher by validating its signature to one of its pre- + configured trust anchors (see Section 5.1), which may entail using + additional intermediate certificates attached to the ownership + voucher. If the device has an accurate clock, it MUST verify that + the ownership voucher was created in the past (i.e., "created-on" < + now), and if the "expires-on" leaf is present, the device MUST verify + that the ownership voucher has not yet expired (i.e., now < "expires- + on"). The device MUST verify that the ownership voucher's + "assertion" value is acceptable (e.g., some devices may only accept + the assertion value "verified"). The device MUST verify that the + ownership voucher specifies the device's serial number in the + "serial-number" leaf. If the "idevid-issuer" leaf is present, the + device MUST verify that the value is set correctly. If the + authentication of the ownership voucher is successful, the device + extracts the "pinned-domain-cert" node, an X.509 certificate, that is + needed to verify the owner certificate in the next step. + + The device MUST next authenticate the owner certificate by performing + X.509 certificate path verification to the trusted certificate + extracted from the ownership voucher's "pinned-domain-cert" node. + This verification may entail using additional intermediate + certificates attached to the owner certificate artifact. If the + ownership voucher's "domain-cert-revocation-checks" node's value is + set to "true", the device MUST verify the revocation status of the + certificate chain used to sign the owner certificate, and if a + suitably fresh revocation status is unattainable or if it is + determined that a certificate has been revoked, the device MUST NOT + validate the owner certificate. + + + + + +Watsen, et al. Standards Track [Page 27] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + Finally, the device MUST verify that the conveyed information + artifact was signed by the validated owner certificate. + + If any of these steps fail, the device MUST invalidate the signed + data and not perform any subsequent steps. + +5.5. Processing Redirect Information + + In order to process redirect information (Section 2.1), the device + MUST follow the steps presented in this section. + + Processing redirect information is straightforward; the device + sequentially steps through the list of provided bootstrap servers + until it can find one it can bootstrap from. + + If a hostname is provided, and the hostname's DNS resolution is to + more than one IP address, the device MUST attempt to connect to all + of the DNS resolved addresses at least once, before moving on to the + next bootstrap server. If the device is able to obtain bootstrapping + data from any of the DNS resolved addresses, it MUST immediately + process that data, without attempting to connect to any of the other + DNS resolved addresses. + + If the redirect information is trusted (e.g., trust-state is TRUE), + and the bootstrap server entry contains a trust anchor certificate, + then the device MUST authenticate the specified bootstrap server's + TLS server certificate using X.509 certificate path validation + ([RFC6125], Section 6) to the specified trust anchor. If the + bootstrap server entry does not contain a trust anchor certificate + device, the device MUST establish a provisional connection to the + bootstrap server (i.e., by blindly accepting its server certificate) + and set trust-state to FALSE. + + If the redirect information is untrusted (e.g., trust-state is + FALSE), the device MUST discard any trust anchors provided by the + redirect information and establish a provisional connection to the + bootstrap server (i.e., by blindly accepting its TLS server + certificate). + +5.6. Processing Onboarding Information + + In order to process onboarding information (Section 2.2), the device + MUST follow the steps presented in this section. + + When processing onboarding information, the device MUST first process + the boot image information (if any), then execute the pre- + configuration script (if any), then commit the initial configuration + + + + +Watsen, et al. Standards Track [Page 28] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + (if any), and then execute the post-configuration script (if any), in + that order. + + When the onboarding information is obtained from a trusted bootstrap + server, the device MUST send the "bootstrap-initiated" progress + report and send a terminating "boot-image-installed-rebooting", + "bootstrap-complete", or error-specific progress report. If the + "reporting-level" node of the bootstrap server's "get-bootstrapping- + data" RPC-reply is the value "verbose", the device MUST additionally + send all appropriate non-terminating progress reports (e.g., + initiated, warning, complete, etc.). Regardless of the reporting + level requested by the bootstrap server, the device MAY send progress + reports beyond those required by the reporting level. + + When the onboarding information is obtained from an untrusted + bootstrap server, the device MUST NOT send any progress reports to + the bootstrap server, even though the onboarding information was, + necessarily, signed and authenticated. Please be aware that + bootstrap servers are recommended to promote untrusted connections to + trusted connections, in the last paragraph of Section 9.6, so as to, + in part, be able to collect progress reports from devices. + + If the device encounters an error at any step, it MUST stop + processing the onboarding information and return to the bootstrapping + sequence described in Section 5.2. In the context of a recursive + algorithm, the device MUST return to the enclosing loop, not back to + the very beginning. Some state MAY be retained from the + bootstrapping process (e.g., updated boot image, logs, remnants from + a script, etc.). However, the retained state MUST NOT be active in + any way (e.g., no new configuration or running of software) and MUST + NOT hinder the ability for the device to continue the bootstrapping + sequence (i.e., process onboarding information from another bootstrap + server). + + At this point, the specific ordered sequence of actions the device + MUST perform is described. + + If the onboarding information is obtained from a trusted bootstrap + server, the device MUST send a "bootstrap-initiated" progress report. + It is an error if the device does not receive back the "204 No + Content" HTTP status line. If an error occurs, the device MUST try + to send a "bootstrap-error" progress report before exiting. + + The device MUST parse the provided onboarding information document, + to extract values used in subsequent steps. Whether using a stream- + based parser or not, if there is an error when parsing the onboarding + + + + + +Watsen, et al. Standards Track [Page 29] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + information, and the device is connected to a trusted bootstrap + server, the device MUST try to send a "parsing-error" progress report + before exiting. + + If boot image criteria are specified, the device MUST first determine + if the boot image it is running satisfies the specified boot image + criteria. If the device is already running the specified boot image, + then it skips the remainder of this step. If the device is not + running the specified boot image, then it MUST download, verify, and + install, in that order, the specified boot image, and then reboot. + If connected to a trusted bootstrap server, the device MAY try to + send a "boot-image-mismatch" progress report. To download the boot + image, the device MUST only use the URIs supplied by the onboarding + information. To verify the boot image, the device MUST use either + one of the verification fingerprints supplied by the onboarding + information or a cryptographic signature embedded into the boot image + itself using a mechanism not described by this document. Before + rebooting, if connected to a trusted bootstrap server, the device + MUST try to send a "boot-image-installed-rebooting" progress report. + Upon rebooting, the bootstrapping process runs again, which will + eventually come to this step again, but then the device will be + running the specified boot image and thus will move to processing the + next step. If an error occurs at any step while the device is + connected to a trusted bootstrap server (i.e., before the reboot), + the device MUST try to send a "boot-image-error" progress report + before exiting. + + If a pre-configuration script has been specified, the device MUST + execute the script, capture any output emitted from the script, and + check if the script had any warnings or errors. If an error occurs + while the device is connected to a trusted bootstrap server, the + device MUST try to send a "pre-script-error" progress report before + exiting. + + If an initial configuration has been specified, the device MUST + atomically commit the provided initial configuration, using the + approach specified by the "configuration-handling" leaf. If an error + occurs while the device is connected to a trusted bootstrap server, + the device MUST try to send a "config-error" progress report before + exiting. + + If a post-configuration script has been specified, the device MUST + execute the script, capture any output emitted from the script, and + check if the script had any warnings or errors. If an error occurs + while the device is connected to a trusted bootstrap server, the + device MUST try to send a "post-script-error" progress report before + exiting. + + + + +Watsen, et al. Standards Track [Page 30] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + If the onboarding information was obtained from a trusted bootstrap + server, and the result of the bootstrapping process did not disable + the "flag to enable SZTP bootstrapping" described in Section 5.1, the + device SHOULD send an "bootstrap-warning" progress report. + + If the onboarding information was obtained from a trusted bootstrap + server, the device MUST send a "bootstrap-complete" progress report. + It is an error if the device does not receive back the "204 No + Content" HTTP status line. If an error occurs, the device MUST try + to send a "bootstrap-error" progress report before exiting. + + At this point, the device has completely processed the bootstrapping + data. + + The device is now running its initial configuration. Notably, if + NETCONF Call Home or RESTCONF Call Home [RFC8071] is configured, the + device initiates trying to establish the call home connections at + this time. + + Implementation Notes: + + Implementations may vary in how to ensure no unwanted state is + retained when an error occurs. + + If the implementation chooses to undo previous steps, the + following guidelines apply: + + * When an error occurs, the device must rollback the current step + and any previous steps. + + * Most steps are atomic. For example, the processing of a + configuration is atomic (as specified above), and the + processing of scripts is atomic (as specified in the "ietf- + sztp-conveyed-info" YANG module). + + * In case the error occurs after the initial configuration was + committed, the device must restore the configuration to the + configuration that existed prior to the configuration being + committed. + + * In case the error occurs after a script had executed + successfully, it may be helpful for the implementation to + define scripts as being able to take a conceptual input + parameter indicating that the script should remove its + previously set state. + + + + + + +Watsen, et al. Standards Track [Page 31] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + +6. The Conveyed Information Data Model + + This section defines a YANG 1.1 [RFC7950] module that is used to + define the data model for the conveyed information artifact described + in Section 3.1. This data model uses the "yang-data" extension + statement defined in [RFC8040]. Examples illustrating this data + model are provided in Section 6.2. + +6.1. Data Model Overview + + The following tree diagram provides an overview of the data model for + the conveyed information artifact. + + module: ietf-sztp-conveyed-info + + yang-data conveyed-information: + +-- (information-type) + +--:(redirect-information) + | +-- redirect-information + | +-- bootstrap-server* [address] + | +-- address inet:host + | +-- port? inet:port-number + | +-- trust-anchor? cms + +--:(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 + +6.2. Example Usage + + The following example illustrates how redirect information + (Section 2.1) can be encoded using JSON [RFC8259]. + + { + "ietf-sztp-conveyed-info:redirect-information" : { + "bootstrap-server" : [ + { + "address" : "sztp1.example.com", + "port" : 8443, + + + +Watsen, et al. Standards Track [Page 32] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + "trust-anchor" : "base64encodedvalue==" + }, + { + "address" : "sztp2.example.com", + "port" : 8443, + "trust-anchor" : "base64encodedvalue==" + }, + { + "address" : "sztp3.example.com", + "port" : 8443, + "trust-anchor" : "base64encodedvalue==" + } + ] + } + } + + The following example illustrates how onboarding information + (Section 2.2) can be encoded using JSON [RFC8259]. + + [Note: '\' line wrapping for formatting only] + + { + "ietf-sztp-conveyed-info:onboarding-information" : { + "boot-image" : { + "os-name" : "VendorOS", + "os-version" : "17.2R1.6", + "download-uri" : [ "https://example.com/path/to/image/file" ], + "image-verification" : [ + { + "hash-algorithm" : "ietf-sztp-conveyed-info:sha-256", + "hash-value" : "ba:ec:cf:a5:67:82:b4:10:77:c6:67:a6:22:ab:\ + 7d:50:04:a7:8b:8f:0e:db:02:8b:f4:75:55:fb:c1:13:b2:33" + } + ] + }, + "configuration-handling" : "merge", + "pre-configuration-script" : "base64encodedvalue==", + "configuration" : "base64encodedvalue==", + "post-configuration-script" : "base64encodedvalue==" + } + } + + + + + + + + + + +Watsen, et al. Standards Track [Page 33] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + +6.3. YANG Module + + The conveyed information data model is defined by the YANG module + presented in this section. + + This module uses data types defined in [RFC5280], [RFC5652], + [RFC6234], and [RFC6991]; an extension statement from [RFC8040]; and + an encoding defined in [ITU.X690.2015]. + + file "ietf-sztp-conveyed-info@2019-04-30.yang" + module ietf-sztp-conveyed-info { + yang-version 1.1; + namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-conveyed-info"; + prefix sztp-info; + + import ietf-yang-types { + prefix yang; + reference + "RFC 6991: Common YANG Data Types"; + } + import ietf-inet-types { + prefix inet; + reference + "RFC 6991: Common YANG Data Types"; + } + import ietf-restconf { + prefix rc; + reference + "RFC 8040: RESTCONF Protocol"; + } + + organization + "IETF NETCONF (Network Configuration) Working Group"; + contact + "WG Web: + WG List: + Author: Kent Watsen "; + description + "This module defines the data model for the conveyed + information artifact defined in RFC 8572 ('Secure Zero Touch + Provisioning (SZTP)'). + + 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 (RFC 2119) + (RFC 8174) when, and only when, they appear in all + capitals, as shown here. + + + +Watsen, et al. Standards Track [Page 34] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + Copyright (c) 2019 IETF Trust and the persons identified as + authors of the code. All rights reserved. + + Redistribution and use in source and binary forms, with or + without modification, is permitted pursuant to, and subject + to the license terms contained in, the Simplified BSD License + set forth in Section 4.c of the IETF Trust's Legal Provisions + Relating to IETF Documents + (https://trustee.ietf.org/license-info). + + This version of this YANG module is part of RFC 8572; see the + RFC itself for full legal notices."; + + revision 2019-04-30 { + description + "Initial version"; + reference + "RFC 8572: Secure Zero Touch Provisioning (SZTP)"; + } + + // identities + + identity hash-algorithm { + description + "A base identity for hash algorithm verification."; + } + + identity sha-256 { + base hash-algorithm; + description + "The SHA-256 algorithm."; + reference + "RFC 6234: US Secure Hash Algorithms"; + } + + // typedefs + + typedef cms { + type binary; + description + "A ContentInfo structure, as specified in RFC 5652, + encoded using ASN.1 distinguished encoding rules (DER), + as specified in ITU-T X.690."; + reference + "RFC 5652: + Cryptographic Message Syntax (CMS) + + + + + +Watsen, et al. Standards Track [Page 35] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + ITU-T X.690: + Information technology - ASN.1 encoding rules: + Specification of Basic Encoding Rules (BER), + Canonical Encoding Rules (CER) and Distinguished + Encoding Rules (DER)"; + } + + // yang-data + rc:yang-data conveyed-information { + choice information-type { + mandatory true; + description + "This choice statement ensures the response contains + redirect-information or onboarding-information."; + container redirect-information { + description + "Redirect information is described in Section 2.1 of + RFC 8572. Its purpose is to redirect a device to + another bootstrap server."; + reference + "RFC 8572: Secure Zero Touch Provisioning (SZTP)"; + list bootstrap-server { + key "address"; + min-elements 1; + description + "A bootstrap server entry."; + leaf address { + type inet:host; + mandatory true; + description + "The IP address or hostname of the bootstrap server the + device should redirect to."; + } + leaf port { + type inet:port-number; + default "443"; + description + "The port number the bootstrap server listens on. If no + port is specified, the IANA-assigned port for 'https' + (443) is used."; + } + leaf trust-anchor { + type cms; + description + "A CMS structure that MUST contain the chain of + X.509 certificates needed to authenticate the TLS + certificate presented by this bootstrap server. + + + + +Watsen, et al. Standards Track [Page 36] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + The CMS MUST only contain a single chain of + certificates. The bootstrap server MUST only + authenticate to last intermediate CA certificate + listed in the chain. + + In all cases, the chain MUST include a self-signed + root certificate. In the case where the root + certificate is itself the issuer of the bootstrap + server's TLS certificate, only one certificate + is present. + + If needed by the device, this CMS structure MAY + also contain suitably fresh revocation objects + with which the device can verify the revocation + status of the certificates. + + This CMS encodes the degenerate form of the SignedData + structure that is commonly used to disseminate X.509 + certificates and revocation objects (RFC 5280)."; + reference + "RFC 5280: + Internet X.509 Public Key Infrastructure Certificate + and Certificate Revocation List (CRL) Profile"; + } + } + } + container onboarding-information { + description + "Onboarding information is described in Section 2.2 of + RFC 8572. Its purpose is to provide the device everything + it needs to bootstrap itself."; + reference + "RFC 8572: Secure Zero Touch Provisioning (SZTP)"; + container boot-image { + description + "Specifies criteria for the boot image the device MUST + be running, as well as information enabling the device + to install the required boot image."; + leaf os-name { + type string; + description + "The name of the operating system software the device + MUST be running in order to not require a software + image upgrade (e.g., VendorOS)."; + } + leaf os-version { + type string; + + + + +Watsen, et al. Standards Track [Page 37] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + description + "The version of the operating system software the + device MUST be running in order to not require a + software image upgrade (e.g., 17.3R2.1)."; + } + leaf-list download-uri { + type inet:uri; + ordered-by user; + description + "An ordered list of URIs to where the same boot image + file may be obtained. How the URI schemes (http, ftp, + etc.) a device supports are known is vendor specific. + If a secure scheme (e.g., https) is provided, a device + MAY establish an untrusted connection to the remote + server, by blindly accepting the server's end-entity + certificate, to obtain the boot image."; + } + list image-verification { + must '../download-uri' { + description + "Download URIs must be provided if an image is to + be verified."; + } + key "hash-algorithm"; + description + "A list of hash values that a device can use to verify + boot image files with."; + leaf hash-algorithm { + type identityref { + base hash-algorithm; + } + description + "Identifies the hash algorithm used."; + } + leaf hash-value { + type yang:hex-string; + mandatory true; + description + "The hex-encoded value of the specified hash + algorithm over the contents of the boot image + file."; + } + } + } + leaf configuration-handling { + type enumeration { + enum merge { + + + + +Watsen, et al. Standards Track [Page 38] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + description + "Merge configuration into the running datastore."; + } + enum replace { + description + "Replace the existing running datastore with the + passed configuration."; + } + } + must '../configuration'; + description + "This enumeration indicates how the server should process + the provided configuration."; + } + leaf pre-configuration-script { + type script; + description + "A script that, when present, is executed before the + configuration has been processed."; + } + leaf configuration { + type binary; + must '../configuration-handling'; + description + "Any configuration known to the device. The use of + the 'binary' type enables content (e.g., XML) to be + embedded into a JSON document. The exact encoding + of the content, as with the scripts, is vendor + specific."; + } + leaf post-configuration-script { + type script; + description + "A script that, when present, is executed after the + configuration has been processed."; + } + } + } + } + + typedef script { + type binary; + description + "A device-specific script that enables the execution of + commands to perform actions not possible thru configuration + alone. + + + + + +Watsen, et al. Standards Track [Page 39] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + No attempt is made to standardize the contents, running + context, or programming language of the script, other than + that it can indicate if any warnings or errors occurred and + can emit output. The contents of the script are considered + specific to the vendor, product line, and/or model of the + device. + + If the script execution indicates that a warning occurred, + then the device MUST assume that the script had a soft error + that the script believes will not affect manageability. + + If the script execution indicates that an error occurred, + the device MUST assume the script had a hard error that the + script believes will affect manageability. In this case, + the script is required to gracefully exit, removing any + state that might hinder the device's ability to continue + the bootstrapping sequence (e.g., process onboarding + information obtained from another bootstrap server)."; + } + } + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Watsen, et al. Standards Track [Page 40] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + +7. The SZTP Bootstrap Server API + + This section defines the API for bootstrap servers. The API is + defined as that produced by a RESTCONF [RFC8040] server that supports + the YANG 1.1 [RFC7950] module defined in this section. + +7.1. API Overview + + The following tree diagram provides an overview for the bootstrap + server RESTCONF API. + + module: ietf-sztp-bootstrap-server + + rpcs: + +---x get-bootstrapping-data + | +---w input + | | +---w signed-data-preferred? empty + | | +---w hw-model? string + | | +---w os-name? string + | | +---w os-version? string + | | +---w nonce? binary + | +--ro output + | +--ro reporting-level? enumeration {onboarding-server}? + | +--ro conveyed-information cms + | +--ro owner-certificate? cms + | +--ro ownership-voucher? cms + +---x report-progress {onboarding-server}? + +---w input + +---w progress-type enumeration + +---w message? string + +---w ssh-host-keys + | +---w ssh-host-key* [] + | +---w algorithm string + | +---w key-data binary + +---w trust-anchor-certs + +---w trust-anchor-cert* cms + + + + + + + + + + + + + + + +Watsen, et al. Standards Track [Page 41] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + +7.2. Example Usage + + This section presents three examples illustrating the bootstrap + server's API. Two examples are provided for the "get-bootstrapping- + data" RPC (one to an untrusted bootstrap server and the other to a + trusted bootstrap server), and one example is provided for the + "report-progress" RPC. + + The following example illustrates a device using the API to fetch its + bootstrapping data from an untrusted bootstrap server. In this + example, the device sends the "signed-data-preferred" input parameter + and receives signed data in the response. + + REQUEST + + [Note: '\' line wrapping for formatting only] + + POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\ + ng-data HTTP/1.1 + HOST: example.com + Content-Type: application/yang.data+xml + + + + + + RESPONSE + + HTTP/1.1 200 OK + Date: Sat, 31 Oct 2015 17:02:40 GMT + Server: example-server + Content-Type: application/yang.data+xml + + + base64encodedvalue== + base64encodedvalue== + base64encodedvalue== + + + + + + + + + + + + +Watsen, et al. Standards Track [Page 42] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + The following example illustrates a device using the API to fetch its + bootstrapping data from a trusted bootstrap server. In this example, + the device sends additional input parameters to the bootstrap server, + which it may use when formulating its response to the device. + + REQUEST + + [Note: '\' line wrapping for formatting only] + + POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\ + ng-data HTTP/1.1 + HOST: example.com + Content-Type: application/yang.data+xml + + + model-x + vendor-os + 17.3R2.1 + extralongbase64encodedvalue= + + + RESPONSE + + HTTP/1.1 200 OK + Date: Sat, 31 Oct 2015 17:02:40 GMT + Server: example-server + Content-Type: application/yang.data+xml + + + verbose + base64encodedvalue== + + + + + + + + + + + + + + + + + + +Watsen, et al. Standards Track [Page 43] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + The following example illustrates a device using the API to post a + progress report to a bootstrap server. Illustrated below is the + "bootstrap-complete" message, but the device may send other progress + reports to the server while bootstrapping. In this example, the + device is sending both its SSH host keys and a TLS server + certificate, which the bootstrap server may, for example, pass to an + NMS, as discussed in Appendix C.3. + + REQUEST + + [Note: '\' line wrapping for formatting only] + + POST /restconf/operations/ietf-sztp-bootstrap-server:report-progress\ + HTTP/1.1 + HOST: example.com + Content-Type: application/yang.data+xml + + + bootstrap-complete + example message + + + ssh-rsa + base64encodedvalue== + + + rsa-sha2-256 + base64encodedvalue== + + + + base64encodedvalue== + + + + RESPONSE + + HTTP/1.1 204 No Content + Date: Sat, 31 Oct 2015 17:02:40 GMT + Server: example-server + + + + + + + + + + +Watsen, et al. Standards Track [Page 44] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + +7.3. YANG Module + + The bootstrap server's device-facing API is normatively defined by + the YANG module defined in this section. + + This module uses data types defined in [RFC4253], [RFC5652], + [RFC5280], and [RFC8366]; uses an encoding defined in + [ITU.X690.2015]; and makes a reference to [RFC4250], [RFC6187], and + [Std-802.1AR]. + + file "ietf-sztp-bootstrap-server@2019-04-30.yang" + module ietf-sztp-bootstrap-server { + yang-version 1.1; + namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server"; + prefix sztp-svr; + + organization + "IETF NETCONF (Network Configuration) Working Group"; + contact + "WG Web: + WG List: + Author: Kent Watsen "; + description + "This module defines an interface for bootstrap servers, as + defined by RFC 8572 ('Secure Zero Touch Provisioning (SZTP)'). + + 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 (RFC 2119) + (RFC 8174) when, and only when, they appear in all + capitals, as shown here. + + Copyright (c) 2019 IETF Trust and the persons identified as + authors of the code. All rights reserved. + + Redistribution and use in source and binary forms, with or + without modification, is permitted pursuant to, and subject + to the license terms contained in, the Simplified BSD License + set forth in Section 4.c of the IETF Trust's Legal Provisions + Relating to IETF Documents + (https://trustee.ietf.org/license-info). + + This version of this YANG module is part of RFC 8572; see the + RFC itself for full legal notices."; + + revision 2019-04-30 { + description + + + +Watsen, et al. Standards Track [Page 45] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + "Initial version"; + reference + "RFC 8572: Secure Zero Touch Provisioning (SZTP)"; + } + + // features + + feature redirect-server { + description + "The server supports being a 'redirect server'."; + } + + feature onboarding-server { + description + "The server supports being an 'onboarding server'."; + } + + // typedefs + + typedef cms { + type binary; + description + "A CMS structure, as specified in RFC 5652, encoded using + ASN.1 distinguished encoding rules (DER), as specified in + ITU-T X.690."; + reference + "RFC 5652: + Cryptographic Message Syntax (CMS) + ITU-T X.690: + Information technology - ASN.1 encoding rules: + Specification of Basic Encoding Rules (BER), + Canonical Encoding Rules (CER) and Distinguished + Encoding Rules (DER)"; + } + + // RPCs + + rpc get-bootstrapping-data { + description + "This RPC enables a device, as identified by the RESTCONF + username, to obtain bootstrapping data that has been made + available for it."; + input { + leaf signed-data-preferred { + type empty; + description + "This optional input parameter enables a device to + communicate to the bootstrap server that it prefers + + + +Watsen, et al. Standards Track [Page 46] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + to receive signed data. Devices SHOULD always send + this parameter when the bootstrap server is untrusted. + Upon receiving this input parameter, the bootstrap + server MUST return either signed data or unsigned + redirect information; the bootstrap server MUST NOT + return unsigned onboarding information."; + } + leaf hw-model { + type string; + description + "This optional input parameter enables a device to + communicate to the bootstrap server its vendor-specific + hardware model number. This parameter may be needed, + for instance, when a device's IDevID certificate does + not include the 'hardwareModelName' value in its + subjectAltName field, as is allowed by 802.1AR."; + reference + "IEEE 802.1AR: IEEE Standard for Local and + metropolitan area networks - Secure + Device Identity"; + } + leaf os-name { + type string; + description + "This optional input parameter enables a device to + communicate to the bootstrap server the name of its + operating system. This parameter may be useful if + the device, as identified by its serial number, can + run more than one type of operating system (e.g., + on a white-box system."; + } + leaf os-version { + type string; + description + "This optional input parameter enables a device to + communicate to the bootstrap server the version of its + operating system. This parameter may be used by a + bootstrap server to return an operating-system-specific + response to the device, thus negating the need for a + potentially expensive boot image update."; + } + leaf nonce { + type binary { + length "16..32"; + } + description + "This optional input parameter enables a device to + communicate to the bootstrap server a nonce value. + + + +Watsen, et al. Standards Track [Page 47] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + This may be especially useful for devices lacking + an accurate clock, as then the bootstrap server + can dynamically obtain from the manufacturer a + voucher with the nonce value in it, as described + in RFC 8366."; + reference + "RFC 8366: + A Voucher Artifact for Bootstrapping Protocols"; + } + } + output { + leaf reporting-level { + if-feature "onboarding-server"; + type enumeration { + enum minimal { + description + "Send just the progress reports required by RFC 8572."; + reference + "RFC 8572: Secure Zero Touch Provisioning (SZTP)"; + } + enum verbose { + description + "Send additional progress reports that might help + troubleshooting an SZTP bootstrapping issue."; + } + } + default "minimal"; + description + "Specifies the reporting level for progress reports the + bootstrap server would like to receive when processing + onboarding information. Progress reports are not sent + when processing redirect information or when the + bootstrap server is untrusted (e.g., device sent the + '' input parameter)."; + } + leaf conveyed-information { + type cms; + mandatory true; + description + "An SZTP conveyed information artifact, as described in + Section 3.1 of RFC 8572."; + reference + "RFC 8572: Secure Zero Touch Provisioning (SZTP)"; + } + leaf owner-certificate { + type cms; + must '../ownership-voucher' { + description + + + +Watsen, et al. Standards Track [Page 48] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + "An ownership voucher must be present whenever an owner + certificate is presented."; + } + description + "An owner certificate artifact, as described in Section + 3.2 of RFC 8572. This leaf is optional because it is + only needed when the conveyed information artifact is + signed."; + reference + "RFC 8572: Secure Zero Touch Provisioning (SZTP)"; + } + leaf ownership-voucher { + type cms; + must '../owner-certificate' { + description + "An owner certificate must be present whenever an + ownership voucher is presented."; + } + description + "An ownership voucher artifact, as described by Section + 3.3 of RFC 8572. This leaf is optional because it is + only needed when the conveyed information artifact is + signed."; + reference + "RFC 8572: Secure Zero Touch Provisioning (SZTP)"; + } + } + } + + rpc report-progress { + if-feature "onboarding-server"; + description + "This RPC enables a device, as identified by the RESTCONF + username, to report its bootstrapping progress to the + bootstrap server. This RPC is expected to be used when + the device obtains onboarding-information from a trusted + bootstrap server."; + input { + leaf progress-type { + type enumeration { + enum bootstrap-initiated { + description + "Indicates that the device just used the + 'get-bootstrapping-data' RPC. The 'message' node + below MAY contain any additional information that + the manufacturer thinks might be useful."; + } + enum parsing-initiated { + + + +Watsen, et al. Standards Track [Page 49] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + description + "Indicates that the device is about to start parsing + the onboarding information. This progress type is + only for when parsing is implemented as a distinct + step."; + } + enum parsing-warning { + description + "Indicates that the device had a non-fatal error when + parsing the response from the bootstrap server. The + 'message' node below SHOULD indicate the specific + warning that occurred."; + } + enum parsing-error { + description + "Indicates that the device encountered a fatal error + when parsing the response from the bootstrap server. + For instance, this could be due to malformed encoding, + the device expecting signed data when only unsigned + data is provided, the ownership voucher not listing + the device's serial number, or because the signature + didn't match. The 'message' node below SHOULD + indicate the specific error. This progress type + also indicates that the device has abandoned trying + to bootstrap off this bootstrap server."; + } + enum parsing-complete { + description + "Indicates that the device successfully completed + parsing the onboarding information. This progress + type is only for when parsing is implemented as a + distinct step."; + } + enum boot-image-initiated { + description + "Indicates that the device is about to start + processing the boot image information."; + } + enum boot-image-warning { + description + "Indicates that the device encountered a non-fatal + error condition when trying to install a boot image. + A possible reason might include a need to reformat a + partition causing loss of data. The 'message' node + below SHOULD indicate any warning messages that were + generated."; + } + enum boot-image-error { + + + +Watsen, et al. Standards Track [Page 50] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + description + "Indicates that the device encountered an error when + trying to install a boot image, which could be for + reasons such as a file server being unreachable, + file not found, signature mismatch, etc. The + 'message' node SHOULD indicate the specific error + that occurred. This progress type also indicates + that the device has abandoned trying to bootstrap + off this bootstrap server."; + } + enum boot-image-mismatch { + description + "Indicates that the device has determined that + it is not running the correct boot image. This + message SHOULD precipitate trying to download + a boot image."; + } + enum boot-image-installed-rebooting { + description + "Indicates that the device successfully installed + a new boot image and is about to reboot. After + sending this progress type, the device is not + expected to access the bootstrap server again + for this bootstrapping attempt."; + } + enum boot-image-complete { + description + "Indicates that the device believes that it is + running the correct boot image."; + } + enum pre-script-initiated { + description + "Indicates that the device is about to execute the + 'pre-configuration-script'."; + } + enum pre-script-warning { + description + "Indicates that the device obtained a warning from the + 'pre-configuration-script' when it was executed. The + 'message' node below SHOULD capture any output the + script produces."; + } + enum pre-script-error { + description + "Indicates that the device obtained an error from the + 'pre-configuration-script' when it was executed. The + 'message' node below SHOULD capture any output the + script produces. This progress type also indicates + + + +Watsen, et al. Standards Track [Page 51] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + that the device has abandoned trying to bootstrap + off this bootstrap server."; + } + enum pre-script-complete { + description + "Indicates that the device successfully executed the + 'pre-configuration-script'."; + } + enum config-initiated { + description + "Indicates that the device is about to commit the + initial configuration."; + } + enum config-warning { + description + "Indicates that the device obtained warning messages + when it committed the initial configuration. The + 'message' node below SHOULD indicate any warning + messages that were generated."; + } + enum config-error { + description + "Indicates that the device obtained error messages + when it committed the initial configuration. The + 'message' node below SHOULD indicate the error + messages that were generated. This progress type + also indicates that the device has abandoned trying + to bootstrap off this bootstrap server."; + } + enum config-complete { + description + "Indicates that the device successfully committed + the initial configuration."; + } + enum post-script-initiated { + description + "Indicates that the device is about to execute the + 'post-configuration-script'."; + } + enum post-script-warning { + description + "Indicates that the device obtained a warning from the + 'post-configuration-script' when it was executed. The + 'message' node below SHOULD capture any output the + script produces."; + } + enum post-script-error { + description + + + +Watsen, et al. Standards Track [Page 52] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + "Indicates that the device obtained an error from the + 'post-configuration-script' when it was executed. The + 'message' node below SHOULD capture any output the + script produces. This progress type also indicates + that the device has abandoned trying to bootstrap + off this bootstrap server."; + } + enum post-script-complete { + description + "Indicates that the device successfully executed the + 'post-configuration-script'."; + } + enum bootstrap-warning { + description + "Indicates that a warning condition occurred for which + no other 'progress-type' enumeration is deemed + suitable. The 'message' node below SHOULD describe + the warning."; + } + enum bootstrap-error { + description + "Indicates that an error condition occurred for which + no other 'progress-type' enumeration is deemed + suitable. The 'message' node below SHOULD describe + the error. This progress type also indicates that + the device has abandoned trying to bootstrap off + this bootstrap server."; + } + enum bootstrap-complete { + description + "Indicates that the device successfully processed + all 'onboarding-information' provided and that it + is ready to be managed. The 'message' node below + MAY contain any additional information that the + manufacturer thinks might be useful. After sending + this progress type, the device is not expected to + access the bootstrap server again."; + } + enum informational { + description + "Indicates any additional information not captured + by any of the other progress types. For instance, + a message indicating that the device is about to + reboot after having installed a boot image could + be provided. The 'message' node below SHOULD + contain information that the manufacturer thinks + might be useful."; + } + + + +Watsen, et al. Standards Track [Page 53] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + } + mandatory true; + description + "The type of progress report provided."; + } + leaf message { + type string; + description + "An optional arbitrary value."; + } + container ssh-host-keys { + when "../progress-type = 'bootstrap-complete'" { + description + "SSH host keys are only sent when the progress type + is 'bootstrap-complete'."; + } + description + "A list of SSH host keys an NMS may use to authenticate + subsequent SSH-based connections to this device (e.g., + netconf-ssh, netconf-ch-ssh)."; + list ssh-host-key { + description + "An SSH host key an NMS may use to authenticate + subsequent SSH-based connections to this device + (e.g., netconf-ssh and netconf-ch-ssh)."; + reference + "RFC 4253: The Secure Shell (SSH) Transport Layer + Protocol"; + leaf algorithm { + type string; + mandatory true; + description + "The public key algorithm name for this SSH key. + + Valid values are listed in the 'Public Key Algorithm + Names' subregistry of the 'Secure Shell (SSH) Protocol + Parameters' registry maintained by IANA."; + reference + "RFC 4250: The Secure Shell (SSH) Protocol Assigned + Numbers + IANA URL: + ('\\' added for formatting reasons)"; + } + leaf key-data { + type binary; + mandatory true; + description + + + +Watsen, et al. Standards Track [Page 54] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + "The binary public key data for this SSH key, as + specified by RFC 4253, Section 6.6; that is: + + string certificate or public key format + identifier + byte[n] key/certificate data."; + reference + "RFC 4253: The Secure Shell (SSH) Transport Layer + Protocol"; + } + } + } + container trust-anchor-certs { + when "../progress-type = 'bootstrap-complete'" { + description + "Trust anchors are only sent when the progress type + is 'bootstrap-complete'."; + } + description + "A list of trust anchor certificates an NMS may use to + authenticate subsequent certificate-based connections + to this device (e.g., restconf-tls, netconf-tls, or + even netconf-ssh with X.509 support from RFC 6187). + In practice, trust anchors for IDevID certificates do + not need to be conveyed using this mechanism."; + reference + "RFC 6187: X.509v3 Certificates for Secure Shell + Authentication"; + leaf-list trust-anchor-cert { + type cms; + description + "A CMS structure whose topmost content type MUST be the + signed-data content type, as described by Section 5 of + RFC 5652. + + The CMS MUST contain the chain of X.509 certificates + needed to authenticate the certificate presented by + the device. + + The CMS MUST contain only a single chain of + certificates. The last certificate in the chain + MUST be the issuer for the device's end-entity + certificate. + + In all cases, the chain MUST include a self-signed + root certificate. In the case where the root + certificate is itself the issuer of the device's + end-entity certificate, only one certificate is + + + +Watsen, et al. Standards Track [Page 55] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + present. + + This CMS encodes the degenerate form of the SignedData + structure that is commonly used to disseminate X.509 + certificates and revocation objects (RFC 5280)."; + reference + "RFC 5280: Internet X.509 Public Key Infrastructure + Certificate and Certificate Revocation List + (CRL) Profile + RFC 5652: Cryptographic Message Syntax (CMS)"; + } + } + } + } + } + + +8. DHCP Options + + This section defines two DHCP options: one for DHCPv4 and one for + DHCPv6. These two options are semantically the same, though + syntactically different. + +8.1. DHCPv4 SZTP Redirect Option + + The DHCPv4 SZTP Redirect Option is used to provision the client with + one or more URIs for bootstrap servers that can be contacted to + attempt further configuration. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | option-code (143) | option-length | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + . . + . bootstrap-server-list (variable length) . + . . + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + * option-code: OPTION_V4_SZTP_REDIRECT (143) + * option-length: The option length in octets. + * bootstrap-server-list: A list of servers for the + client to attempt contacting, in order to obtain + further bootstrapping data, in the format shown + in Section 8.3. + + DHCPv4 SZTP Redirect Option + + + + +Watsen, et al. Standards Track [Page 56] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + DHCPv4 Client Behavior + + Clients MAY request the OPTION_V4_SZTP_REDIRECT option by including + its option code in the Parameter Request List (55) in DHCP request + messages. + + On receipt of a DHCPv4 Reply message that contains the + OPTION_V4_SZTP_REDIRECT option, the client processes the response + according to Section 5.5, with the understanding that the "address" + and "port" values are encoded in the URIs. + + Any invalid URI entries received in the uri-data field are ignored by + the client. If the received OPTION_V4_SZTP_REDIRECT option does not + contain at least one valid URI entry in the uri-data field, then the + client MUST discard the option. + + As the list of URIs may exceed the maximum allowed length of a single + DHCPv4 option (255 octets), the client MUST implement the decoding + agent behavior described in [RFC3396], to correctly process a URI + list split across a number of received OPTION_V4_SZTP_REDIRECT option + instances. + + DHCPv4 Server Behavior + + The DHCPv4 server MAY include a single instance of the + OPTION_V4_SZTP_REDIRECT option in DHCP messages it sends. Servers + MUST NOT send more than one instance of the OPTION_V4_SZTP_REDIRECT + option. + + The server's DHCP message MUST contain only a single instance of the + OPTION_V4_SZTP_REDIRECT's 'bootstrap-server-list' field. However, + the list of URIs in this field may exceed the maximum allowed length + of a single DHCPv4 option (per [RFC3396]). + + If the length of 'bootstrap-server-list' is small enough to fit into + a single instance of OPTION_V4_SZTP_REDIRECT, the server MUST NOT + send more than one instance of this option. + + If the length of the 'bootstrap-server-list' field is too large to + fit into a single option, then OPTION_V4_SZTP_REDIRECT MUST be split + into multiple instances of the option according to the process + described in [RFC3396]. + + + + + + + + + +Watsen, et al. Standards Track [Page 57] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + +8.2. DHCPv6 SZTP Redirect Option + + The DHCPv6 SZTP Redirect Option is used to provision the client with + one or more URIs for bootstrap servers that can be contacted to + attempt further configuration. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | option-code (136) | option-length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . bootstrap-server-list (variable length) . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + * option-code: OPTION_V6_SZTP_REDIRECT (136) + * option-length: The option length in octets. + * bootstrap-server-list: A list of servers for the client to + attempt contacting, in order to obtain further bootstrapping + data, in the format shown in Section 8.3. + + DHCPv6 SZTP Redirect Option + + DHCPv6 Client Behavior + + Clients MAY request OPTION_V6_SZTP_REDIRECT using the process defined + in [RFC8415], Sections 18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, and + 21.7. As a convenience to the reader, we mention here that the + client includes requested option codes in the Option Request option. + + On receipt of a DHCPv6 Reply message that contains the + OPTION_V6_SZTP_REDIRECT option, the client processes the response + according to Section 5.5, with the understanding that the "address" + and "port" values are encoded in the URIs. + + Any invalid URI entries received in the uri-data field are ignored by + the client. If the received OPTION_V6_SZTP_REDIRECT option does not + contain at least one valid URI entry in the uri-data field, then the + client MUST discard the option. + + DHCPv6 Server Behavior + + Section 18.3 of [RFC8415] governs server operation in regard to + option assignment. As a convenience to the reader, we mention here + that the server will send a particular option code only if configured + with specific values for that option code and if the client requested + it. + + + + + +Watsen, et al. Standards Track [Page 58] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + The OPTION_V6_SZTP_REDIRECT option is a singleton. Servers MUST NOT + send more than one instance of this option. + +8.3. Common Field Encoding + + Both of the DHCPv4 and DHCPv6 options defined in this section encode + a list of bootstrap server URIs. The "URI" structure is a DHCP + option that can contain multiple URIs (see [RFC7227], Section 5.7). + Each URI entry in the bootstrap-server-list is structured as follows: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ + | uri-length | URI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ + + * uri-length: 2 octets long; specifies the length of the URI data. + * URI: URI of the SZTP bootstrap server. + + The URI of the SZTP bootstrap server MUST use the "https" URI scheme + defined in Section 2.7.2 of [RFC7230], and it MUST be in form + "https://[:]". + +9. Security Considerations + +9.1. Clock Sensitivity + + The solution in this document relies on TLS certificates, owner + certificates, and ownership vouchers, all of which require an + accurate clock in order to be processed correctly (e.g., to test + validity dates and revocation status). Implementations SHOULD ensure + devices have an accurate clock when shipped from manufacturing + facilities and take steps to prevent clock tampering. + + If it is not possible to ensure clock accuracy, it is RECOMMENDED + that implementations disable the aspects of the solution having clock + sensitivity. In particular, such implementations should assume that + TLS certificates, ownership vouchers, and owner certificates never + expire and are not revocable. From an ownership voucher perspective, + manufacturers SHOULD issue a single ownership voucher for the + lifetime of such devices. + + Implementations SHOULD NOT rely on NTP for time, as NTP is not a + secure protocol at this time. Note that there is an IETF document + that focuses on securing NTP [NTS-NTP]. + + + + + + + + +Watsen, et al. Standards Track [Page 59] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + +9.2. Use of IDevID Certificates + + IDevID certificates, as defined in [Std-802.1AR], are RECOMMENDED, + both for the TLS-level client certificate used by devices when + connecting to a bootstrap server, as well as for the device identity + certificate used by owners when encrypting the SZTP bootstrapping + data artifacts. + +9.3. Immutable Storage for Trust Anchors + + Devices MUST ensure that all their trust anchor certificates, + including those for connecting to bootstrap servers and verifying + ownership vouchers, are protected from external modification. + + It may be necessary to update these certificates over time (e.g., the + manufacturer wants to delegate trust to a new CA). It is therefore + expected that devices MAY update these trust anchors when needed + through a verifiable process, such as a software upgrade using signed + software images. + +9.4. Secure Storage for Long-Lived Private Keys + + Manufacturer-generated device identifiers may have very long + lifetimes. For instance, [Std-802.1AR] recommends using the + "notAfter" value 99991231235959Z in IDevID certificates. Given the + long-lived nature of these private keys, it is paramount that they + are stored so as to resist discovery, such as in a secure + cryptographic processor (e.g., a trusted platform module (TPM) chip). + +9.5. Blindly Authenticating a Bootstrap Server + + This document allows a device to blindly authenticate a bootstrap + server's TLS certificate. It does so to allow for cases where the + redirect information may be obtained in an unsecured manner, which is + desirable to support in some cases. + + To compensate for this, this document requires that devices, when + connected to an untrusted bootstrap server, assert that data + downloaded from the server is signed. + +9.6. Disclosing Information to Untrusted Servers + + This document allows devices to establish connections to untrusted + bootstrap servers. However, since the bootstrap server is untrusted, + it may be under the control of an adversary; therefore, devices + SHOULD be cautious about the data they send to the bootstrap server + in such cases. + + + + +Watsen, et al. Standards Track [Page 60] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + Devices send different data to bootstrap servers at each of the + protocol layers: TCP, TLS, HTTP, and RESTCONF. + + At the TCP protocol layer, devices may relay their IP address, + subject to network translations. Disclosure of this information is + not considered a security risk. + + At the TLS protocol layer, devices may use a client certificate to + identify and authenticate themselves to untrusted bootstrap servers. + At a minimum, the client certificate must disclose the device's + serial number and may disclose additional information such as the + device's manufacturer, hardware model, public key, etc. Knowledge of + this information may provide an adversary with details needed to + launch an attack. It is RECOMMENDED that secrecy of the network + constituency not be relied on for security. + + At the HTTP protocol layer, devices may use an HTTP authentication + scheme to identify and authenticate themselves to untrusted bootstrap + servers. At a minimum, the authentication scheme must disclose the + device's serial number and, concerningly, may, depending on the + authentication mechanism used, reveal a secret that is only supposed + to be known to the device (e.g., a password). Devices SHOULD NOT use + an HTTP authentication scheme (e.g., HTTP Basic) with an untrusted + bootstrap server that reveals a secret that is only supposed to be + known to the device. + + At the RESTCONF protocol layer, devices use the "get-bootstrapping- + data" RPC, but not the "report-progress" RPC, when connected to an + untrusted bootstrap server. The "get-bootstrapping-data" RPC allows + additional input parameters to be passed to the bootstrap server + (e.g., "os-name", "os-version", and "hw-model"). It is RECOMMENDED + that devices only pass the "signed-data-preferred" input parameter to + an untrusted bootstrap server. While it is okay for a bootstrap + server to immediately return signed onboarding information, it is + RECOMMENDED that bootstrap servers instead promote the untrusted + connection to a trusted connection, as described in Appendix B, thus + enabling the device to use the "report-progress" RPC while processing + the onboarding information. + +9.7. Sequencing Sources of Bootstrapping Data + + For devices supporting more than one source for bootstrapping data, + no particular sequencing order has to be observed for security + reasons, as the solution for each source is considered equally + secure. However, from a privacy perspective, it is RECOMMENDED that + devices access local sources before accessing remote sources. + + + + + +Watsen, et al. Standards Track [Page 61] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + +9.8. Safety of Private Keys Used for Trust + + The solution presented in this document enables bootstrapping data to + be trusted in two ways: through either transport-level security or + the signing of artifacts. + + When transport-level security (i.e., a trusted bootstrap server) is + used, the private key for the end-entity certificate must be online + in order to establish the TLS connection. + + When artifacts are signed, the signing key is required to be online + only when the bootstrap server is returning a dynamically generated + signed-data response. For instance, a bootstrap server, upon + receiving the "signed-data-preferred" input parameter to the + "get-bootstrapping-data" RPC, may dynamically generate a response + that is signed. + + Bootstrap server administrators are RECOMMENDED to follow best + practices to protect the private key used for any online operation. + For instance, use of a hardware security module (HSM) is RECOMMENDED. + If an HSM is not used, frequent private key refreshes are + RECOMMENDED, assuming all bootstrapping devices have an accurate + clock (see Section 9.1). + + For best security, it is RECOMMENDED that owners only provide + bootstrapping data that has been signed (using a protected private + key) and encrypted (using the device's public key from its secure + device identity certificate). + +9.9. Increased Reliance on Manufacturers + + The SZTP bootstrapping protocol presented in this document shifts + some control of initial configuration away from the rightful owner of + the device and towards the manufacturer and its delegates. + + The manufacturer maintains the list of well-known bootstrap servers + its devices will trust. By design, if no bootstrapping data is found + via other methods first, the device will try to reach out to the + well-known bootstrap servers. There is no mechanism to prevent this + from occurring other than by using an external firewall to block such + connections. Concerns related to trusted bootstrap servers are + discussed in Section 9.10. + + Similarly, the manufacturer maintains the list of voucher-signing + authorities its devices will trust. The voucher-signing authorities + issue the vouchers that enable a device to trust an owner's domain + + + + + +Watsen, et al. Standards Track [Page 62] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + certificate. It is vital that manufacturers ensure the integrity of + these voucher-signing authorities, so as to avoid incorrect + assignments. + + Operators should be aware that this system assumes that they trust + all the pre-configured bootstrap servers and voucher-signing + authorities designated by the manufacturers. While operators may use + points in the network to block access to the well-known bootstrap + servers, operators cannot prevent voucher-signing authorities from + generating vouchers for their devices. + +9.10. Concerns with Trusted Bootstrap Servers + + Trusted bootstrap servers, whether well-known or discovered, have the + potential to cause problems, such as the following. + + o A trusted bootstrap server that has been compromised may be + modified to return unsigned data of any sort. For instance, a + bootstrap server that is only supposed to return redirect + information might be modified to return onboarding information. + Similarly, a bootstrap server that is only supposed to return + signed data may be modified to return unsigned data. In both + cases, the device will accept the response, unaware that it wasn't + supposed to be any different. It is RECOMMENDED that maintainers + of trusted bootstrap servers ensure that their systems are not + easily compromised and, in case of compromise, have mechanisms in + place to detect and remediate the compromise as expediently as + possible. + + o A trusted bootstrap server hosting data that is either unsigned or + signed but not encrypted may disclose information to unwanted + parties (e.g., an administrator of the bootstrap server). This is + a privacy issue only, but it could reveal information that might + be used in a subsequent attack. Disclosure of redirect + information has limited exposure (it is just a list of bootstrap + servers), whereas disclosure of onboarding information could be + highly revealing (e.g., network topology, firewall policies, + etc.). It is RECOMMENDED that operators encrypt the bootstrapping + data when its contents are considered sensitive, even to the point + of hiding it from the administrators of the bootstrap server, + which may be maintained by a third party. + +9.11. Validity Period for Conveyed Information + + The conveyed information artifact does not specify a validity period. + For instance, neither redirect information nor onboarding information + enable "not-before" or "not-after" values to be specified, and + neither artifact alone can be revoked. + + + +Watsen, et al. Standards Track [Page 63] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + For unsigned data provided by an untrusted source of bootstrapping + data, it is not meaningful to discuss its validity period when the + information itself has no authenticity and may have come from + anywhere. + + For unsigned data provided by a trusted source of bootstrapping data + (i.e., a bootstrap server), the availability of the data is the only + measure of it being current. Since the untrusted data comes from a + trusted source, its current availability is meaningful, and since + bootstrap servers use TLS, the contents of the exchange cannot be + modified or replayed. + + For signed data, whether provided by an untrusted or trusted source + of bootstrapping data, the validity is constrained by the validity of + both the ownership voucher and owner certificate used to authenticate + it. + + The ownership voucher's validity is primarily constrained by the + ownership voucher's "created-on" and "expires-on" nodes. While + [RFC8366] recommends short-lived vouchers (see Section 6.1), the + "expires-on" node may be set to any point in the future or omitted + altogether to indicate that the voucher never expires. The ownership + voucher's validity is secondarily constrained by the manufacturer's + PKI used to sign the voucher; whilst an ownership voucher cannot be + revoked directly, the PKI used to sign it may be. + + The owner certificate's validity is primarily constrained by the + X.509's validity field, the "notBefore" and "notAfter" values, as + specified by the certificate authority that signed it. The owner + certificate's validity is secondarily constrained by the validity of + the PKI used to sign the voucher. Owner certificates may be revoked + directly. + + For owners that wish to have maximum flexibility in their ability to + specify and constrain the validity of signed data, it is RECOMMENDED + that a unique owner certificate be created for each signed artifact. + Not only does this enable a validity period to be specified, for each + artifact, but it also enables the validity of each artifact to be + revoked. + +9.12. Cascading Trust via Redirects + + Redirect information (Section 2.1), by design, instructs a + bootstrapping device to initiate an HTTPS connection to the specified + bootstrap servers. + + When the redirect information is trusted, the redirect information + can encode a trust anchor certificate used by the device to + + + +Watsen, et al. Standards Track [Page 64] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + authenticate the TLS end-entity certificate presented by each + bootstrap server. + + As a result, any compromise in an interaction providing redirect + information may result in compromise of all subsequent interactions. + +9.13. Possible Reuse of Private Keys + + This document describes two uses for secure device identity + certificates. + + The primary use is for when the device authenticates itself to a + bootstrap server, using its private key for TLS-level client- + certificate-based authentication. + + A secondary use is for when the device needs to decrypt provided + bootstrapping artifacts, using its private key to decrypt the data + or, more precisely, per Section 6 of [RFC5652], decrypt a symmetric + key used to decrypt the data. + + Section 3.4 of this document allows for the possibility that the same + secure device identity certificate is utilized for both uses, as + [Std-802.1AR] states that a DevID certificate MAY have the + "keyEncipherment" KeyUsage bit, in addition to the "digitalSignature" + KeyUsage bit, set. + + While it is understood that it is generally frowned upon to reuse + private keys, this document views such reuse acceptable as there are + not any known ways to cause a signature made in one context to be + (mis)interpreted as valid in the other context. + +9.14. Non-issue with Encrypting Signed Artifacts + + This document specifies the encryption of signed objects, as opposed + to the signing of encrypted objects, as might be expected given well- + publicized oracle attacks (e.g., the padding oracle attack). + + This document does not view such attacks as feasible in the context + of the solution because the decrypted text never leaves the device. + +9.15. The "ietf-sztp-conveyed-info" YANG Module + + The "ietf-sztp-conveyed-info" module defined in this document defines + a data structure that is always wrapped by a CMS structure. When + accessed by a secure mechanism (e.g., protected by TLS), then the CMS + structure may be unsigned. However, when accessed by an insecure + mechanism (e.g., a removable storage device), the CMS structure must + be signed, in order for the device to trust it. + + + +Watsen, et al. Standards Track [Page 65] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + Implementations should be aware that signed bootstrapping data only + protects the data from modification and that the content is still + visible to others. This doesn't affect security so much as privacy. + That the contents may be read by unintended parties when accessed by + insecure mechanisms is considered next. + + The "ietf-sztp-conveyed-info" module defines a top-level "choice" + statement that declares the content is either redirect-information or + onboarding-information. Each of these two cases are now considered. + + When the content of the CMS structure is redirect-information, an + observer can learn about the bootstrap servers the device is being + directed to, their IP addresses or hostnames, ports, and trust anchor + certificates. Knowledge of this information could provide an + observer some insight into a network's inner structure. + + When the content of the CMS structure is onboarding-information, an + observer could learn considerable information about how the device is + to be provisioned. This information includes the operating system + version, initial configuration, and script contents. This + information should be considered sensitive, and precautions should be + taken to protect it (e.g., encrypt the artifact using the device's + public key). + +9.16. The "ietf-sztp-bootstrap-server" YANG Module + + The "ietf-sztp-bootstrap-server" module defined in this document + specifies an API for a RESTCONF [RFC8040]. The lowest RESTCONF layer + is HTTPS, and the mandatory-to-implement secure transport is TLS + [RFC8446]. + + The NETCONF Access Control Model (NACM) [RFC8341] provides the means + to restrict access for particular users to a pre-configured subset of + all available protocol operations and content. + + This module presents no data nodes (only RPCs). There is no need to + discuss the sensitivity of data nodes. + + This module defines two RPC operations that may be considered + sensitive in some network environments. These are the operations and + their sensitivity/vulnerability: + + get-bootstrapping-data: This RPC is used by devices to obtain their + bootstrapping data. By design, each device, as identified by its + authentication credentials (e.g., client certificate), can only + obtain its own data. NACM is not needed to further constrain + access to this RPC. + + + + +Watsen, et al. Standards Track [Page 66] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + report-progress: This RPC is used by devices to report their + bootstrapping progress. By design, each device, as identified by + its authentication credentials (e.g., client certificate), can + only report data for itself. NACM is not needed to further + constrain access to this RPC. + +10. IANA Considerations + +10.1. The IETF XML Registry + + IANA has registered two URIs in the "ns" subregistry of the "IETF XML + Registry" [RFC3688] maintained at . The following registrations have been made per the + format in [RFC3688]: + + URI: urn:ietf:params:xml:ns:yang:ietf-sztp-conveyed-info + Registrant Contact: The NETCONF WG of the IETF. + XML: N/A, the requested URI is an XML namespace. + + URI: urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server + Registrant Contact: The NETCONF WG of the IETF. + XML: N/A, the requested URI is an XML namespace. + +10.2. The YANG Module Names Registry + + IANA has registered two YANG modules in the "YANG Module Names" + registry [RFC6020] maintained at . The following registrations have been made per the + format in [RFC6020]: + + name: ietf-sztp-conveyed-info + namespace: urn:ietf:params:xml:ns:yang:ietf-sztp-conveyed-info + prefix: sztp-info + reference: RFC 8572 + + name: ietf-sztp-bootstrap-server + namespace: urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server + prefix: sztp-svr + reference: RFC 8572 + + + + + + + + + + + + +Watsen, et al. Standards Track [Page 67] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + +10.3. The SMI Security for S/MIME CMS Content Type Registry + + IANA has registered two subordinate object identifiers in the "SMI + Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" + registry maintained at . The following registrations have been made per the + format in Section 3.4 of [RFC7107]: + + Decimal Description References + ------- -------------------------- ---------- + 42 id-ct-sztpConveyedInfoXML RFC 8572 + 43 id-ct-sztpConveyedInfoJSON RFC 8572 + + id-ct-sztpConveyedInfoXML indicates that the "conveyed-information" + is encoded using XML. id-ct-sztpConveyedInfoJSON indicates that the + "conveyed-information" is encoded using JSON. + +10.4. The BOOTP Vendor Extensions and DHCP Options Registry + + IANA has registered one DHCP code point in the "BOOTP Vendor + Extensions and DHCP Options" registry maintained at + : + + Tag: 143 + Name: OPTION_V4_SZTP_REDIRECT + Data Length: N + Meaning: This option provides a list of URIs + for SZTP bootstrap servers + Reference: RFC 8572 + +10.5. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) + Registry + + IANA has registered one DHCP code point in the "Option Codes" + subregistry of the "Dynamic Host Configuration Protocol for IPv6 + (DHCPv6)" registry maintained at : + + Value: 136 + Description: OPTION_V6_SZTP_REDIRECT + Client ORO: Yes + Singleton Option: Yes + Reference: RFC 8572 + + + + + + + + +Watsen, et al. Standards Track [Page 68] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + +10.6. The Service Name and Transport Protocol Port Number Registry + + IANA has registered one service name in the "Service Name and + Transport Protocol Port Number Registry" [RFC6335] maintained at + . The + following registration has been made per the format in Section 8.1.1 + of [RFC6335]: + + Service Name: sztp + Transport Protocol(s): TCP + Assignee: IESG + Contact: IETF Chair + Description: This service name is used to construct the + SRV service label "_sztp" for discovering + SZTP bootstrap servers. + Reference: RFC 8572 + Port Number: N/A + Service Code: N/A + Known Unauthorized Uses: N/A + Assignment Notes: This protocol uses HTTPS as a substrate. + +10.7. The Underscored and Globally Scoped DNS Node Names Registry + + IANA has registered one service name in the "Underscored and Globally + Scoped DNS Node Names" subregistry [RFC8552] of the "Domain Name + System (DNS) Parameters" registry maintained at + . The following + registration has been made per the format in Section 3 of [RFC8552]: + + RR Type: TXT + _NODE NAME: _sztp + Reference: RFC 8572 + +11. References + +11.1. Normative References + + [ITU.X690.2015] + International Telecommunication Union, "Information + Technology - ASN.1 encoding rules: Specification of Basic + Encoding Rules (BER), Canonical Encoding Rules (CER) and + Distinguished Encoding Rules (DER)", ITU-T Recommendation + X.690, ISO/IEC 8825-1, August 2015, + . + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, + November 1987, . + + + +Watsen, et al. Standards Track [Page 69] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + DOI 10.17487/RFC2782, February 2000, + . + + [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the + Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, + DOI 10.17487/RFC3396, November 2002, + . + + [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) + Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, + January 2006, . + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, + . + + [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, + RFC 5652, DOI 10.17487/RFC5652, September 2009, + . + + [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for + the Network Configuration Protocol (NETCONF)", RFC 6020, + DOI 10.17487/RFC6020, October 2010, + . + + [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and + Verification of Domain-Based Application Service Identity + within Internet Public Key Infrastructure Using X.509 + (PKIX) Certificates in the Context of Transport Layer + Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March + 2011, . + + [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, + DOI 10.17487/RFC6762, February 2013, + . + + [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", + RFC 6991, DOI 10.17487/RFC6991, July 2013, + . + + + +Watsen, et al. Standards Track [Page 70] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and + S. Krishnan, "Guidelines for Creating New DHCPv6 Options", + BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, + . + + [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, DOI 10.17487/RFC7230, June 2014, + . + + [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", + RFC 7950, DOI 10.17487/RFC7950, August 2016, + . + + [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF + Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, + "A Voucher Artifact for Bootstrapping Protocols", + RFC 8366, DOI 10.17487/RFC8366, May 2018, + . + + [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., + Richardson, M., Jiang, S., Lemon, T., and T. Winters, + "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", + RFC 8415, DOI 10.17487/RFC8415, November 2018, + . + + [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource + Records through "Underscored" Naming of Attribute Leaves", + BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, + . + + [Std-802.1AR] + IEEE, "IEEE Standard for Local and metropolitan area + networks - Secure Device Identity", IEEE 802.1AR. + +11.2. Informative References + + [NTS-NTP] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and + R. Sundblad, "Network Time Security for the Network Time + Protocol", Work in Progress, draft-ietf-ntp-using-nts-for- + ntp-18, April 2019. + + + +Watsen, et al. Standards Track [Page 71] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + DOI 10.17487/RFC3688, January 2004, + . + + [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) + Protocol Assigned Numbers", RFC 4250, + DOI 10.17487/RFC4250, January 2006, + . + + [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure + Shell Authentication", RFC 6187, DOI 10.17487/RFC6187, + March 2011, . + + [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms + (SHA and SHA-based HMAC and HKDF)", RFC 6234, + DOI 10.17487/RFC6234, May 2011, + . + + [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., + and A. Bierman, Ed., "Network Configuration Protocol + (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, + . + + [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and + S. Cheshire, "Internet Assigned Numbers Authority (IANA) + Procedures for the Management of the Service Name and + Transport Protocol Port Number Registry", BCP 165, + RFC 6335, DOI 10.17487/RFC6335, August 2011, + . + + [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication + of Named Entities (DANE) Transport Layer Security (TLS) + Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August + 2012, . + + [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service + Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, + . + + [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms + for DNS (EDNS(0))", STD 75, RFC 6891, + DOI 10.17487/RFC6891, April 2013, + . + + + + + + + + +Watsen, et al. Standards Track [Page 72] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., + Galperin, S., and C. Adams, "X.509 Internet Public Key + Infrastructure Online Certificate Status Protocol - OCSP", + RFC 6960, DOI 10.17487/RFC6960, June 2013, + . + + [RFC7107] Housley, R., "Object Identifier Registry for the S/MIME + Mail Security Working Group", RFC 7107, + DOI 10.17487/RFC7107, January 2014, + . + + [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and + D. Wessels, "DNS Transport over TCP - Implementation + Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, + . + + [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", + RFC 8071, DOI 10.17487/RFC8071, February 2017, + . + + [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data + Interchange Format", STD 90, RFC 8259, + DOI 10.17487/RFC8259, December 2017, + . + + [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", + BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, + . + + [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration + Access Control Model", STD 91, RFC 8341, + DOI 10.17487/RFC8341, March 2018, + . + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + . + + [YANG-CRYPTO-TYPES] + Watsen, K. and H. Wang, "Common YANG Data Types for + Cryptography", Work in Progress, draft-ietf-netconf- + crypto-types-05, March 2019. + + [YANG-TRUST-ANCHORS] + Watsen, K., "YANG Data Model for Global Trust Anchors", + Work in Progress, draft-ietf-netconf-trust-anchors-03, + March 2019. + + + + +Watsen, et al. Standards Track [Page 73] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + +Appendix A. Example Device Data Model + + This section defines a non-normative data model that enables the + configuration of SZTP bootstrapping and the discovery of what + parameters are used by a device's bootstrapping logic. + +A.1. Data Model Overview + + The following tree diagram provides an overview for the SZTP device + data model. + + module: example-device-data-model + +--rw sztp + +--rw enabled? boolean + +--ro idevid-certificate? ct:end-entity-cert-cms + | {bootstrap-servers}? + +--ro bootstrap-servers {bootstrap-servers}? + | +--ro bootstrap-server* [address] + | +--ro address inet:host + | +--ro port? inet:port-number + +--ro bootstrap-server-trust-anchors {bootstrap-servers}? + | +--ro reference* ta:pinned-certificates-ref + +--ro voucher-trust-anchors {signed-data}? + +--ro reference* ta:pinned-certificates-ref + + In the above diagram, notice that there is only one configurable + node: "enabled". The expectation is that this node would be set to + "true" in the device's factory default configuration and that it + would be either set to "false" or deleted when the SZTP bootstrapping + is longer needed. + + + + + + + + + + + + + + + + + + + + + +Watsen, et al. Standards Track [Page 74] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + +A.2. Example Usage + + Following is an instance example for this data model. + + + true + base64encodedvalue== + + +
sztp1.example.com
+ 8443 + + +
sztp2.example.com
+ 8443 + + +
sztp3.example.com
+ 8443 + + + + manufacturers-root-ca-certs + + + manufacturers-root-ca-certs + + + +A.3. YANG Module + + The device model is defined by the YANG module defined in this + section. + + This module references [Std-802.1AR] and uses data types defined in + [RFC6991], [YANG-CRYPTO-TYPES], and [YANG-TRUST-ANCHORS]. + + module example-device-data-model { + yang-version 1.1; + namespace "https://example.com/sztp-device-data-model"; + prefix sztp-ddm; + + import ietf-inet-types { + prefix inet; + reference "RFC 6991: Common YANG Data Types"; + } + + import ietf-crypto-types { + + + +Watsen, et al. Standards Track [Page 75] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + prefix ct; + revision-date 2019-03-09; + description + "ietf-crypto-types is defined in + draft-ietf-netconf-crypto-types"; + reference + "draft-ietf-netconf-crypto-types-05: + Common YANG Data Types for Cryptography"; + } + + import ietf-trust-anchors { + prefix ta; + revision-date 2019-03-09; + description + "ietf-trust-anchors is defined in + draft-ietf-netconf-trust-anchors."; + reference + "draft-ietf-netconf-trust-anchors-03: + YANG Data Model for Global Trust Anchors"; + } + + organization + "Example Corporation"; + + contact + "Author: Bootstrap Admin "; + + description + "This module defines a data model to enable SZTP + bootstrapping and discover what parameters are used. + This module assumes the use of an IDevID certificate, + as opposed to any other client certificate, or the + use of an HTTP-based client authentication scheme."; + + revision 2019-04-30 { + description + "Initial version"; + reference + "RFC 8572: Secure Zero Touch Provisioning (SZTP)"; + } + + // features + + feature bootstrap-servers { + description + "The device supports bootstrapping off bootstrap servers."; + } + + + + +Watsen, et al. Standards Track [Page 76] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + feature signed-data { + description + "The device supports bootstrapping off signed data."; + } + + // protocol accessible nodes + + container sztp { + description + "Top-level container for the SZTP data model."; + leaf enabled { + type boolean; + default false; + description + "The 'enabled' leaf controls if SZTP bootstrapping is + enabled or disabled. The default is 'false' so that, when + not enabled, which is most of the time, no configuration + is needed."; + } + leaf idevid-certificate { + if-feature bootstrap-servers; + type ct:end-entity-cert-cms; + config false; + description + "This CMS structure contains the IEEE 802.1AR + IDevID certificate itself and all intermediate + certificates leading up to, and optionally including, + the manufacturer's well-known trust anchor certificate + for IDevID certificates. The well-known trust anchor + does not have to be a self-signed certificate."; + reference + "IEEE 802.1AR: + IEEE Standard for Local and metropolitan area + networks - Secure Device Identity"; + } + container bootstrap-servers { + if-feature bootstrap-servers; + config false; + description + "List of bootstrap servers this device will attempt + to reach out to when bootstrapping."; + list bootstrap-server { + key "address"; + description + "A bootstrap server entry."; + leaf address { + type inet:host; + mandatory true; + + + +Watsen, et al. Standards Track [Page 77] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + description + "The IP address or hostname of the bootstrap server the + device should redirect to."; + } + leaf port { + type inet:port-number; + default "443"; + description + "The port number the bootstrap server listens on. If no + port is specified, the IANA-assigned port for 'https' + (443) is used."; + } + } + } + container bootstrap-server-trust-anchors { + if-feature bootstrap-servers; + config false; + description "Container for a list of trust anchor references."; + leaf-list reference { + type ta:pinned-certificates-ref; + description + "A reference to a list of pinned certificate authority (CA) + certificates that the device uses to validate bootstrap + servers with."; + } + } + container voucher-trust-anchors { + if-feature signed-data; + config false; + description "Container for a list of trust anchor references."; + leaf-list reference { + type ta:pinned-certificates-ref; + description + "A reference to a list of pinned certificate authority (CA) + certificates that the device uses to validate ownership + vouchers with."; + } + } + } + } + + + + + + + + + + + +Watsen, et al. Standards Track [Page 78] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + +Appendix B. Promoting a Connection from Untrusted to Trusted + + The following diagram illustrates a sequence of bootstrapping + activities that promote an untrusted connection to a bootstrap server + to a trusted connection to the same bootstrap server. This enables a + device to limit the amount of information it might disclose to an + adversary hosting an untrusted bootstrap server. + + +-----------+ + |Deployment-| + | Specific | + +------+ | Bootstrap | + |Device| | Server | + +------+ +-----------+ + | | + | 1. "HTTPS" Request ("signed-data-preferred", nonce) | + |------------------------------------------------------->| + | 2. "HTTPS" Response (signed redirect information) | + |<-------------------------------------------------------| + | | + | | + | 3. HTTPS Request (os-name=xyz, os-version=123, etc.) | + |------------------------------------------------------->| + | 4. HTTPS Response (unsigned onboarding information | + |<-------------------------------------------------------| + | | + + The interactions in the above diagram are described below. + + 1. The device initiates an untrusted connection to a bootstrap + server, as is indicated by putting "HTTPS" in double quotes + above. It is still an HTTPS connection, but the device is unable + to authenticate the bootstrap server's TLS certificate. Because + the device is unable to trust the bootstrap server, it sends the + "signed-data-preferred" input parameter, and optionally also the + "nonce" input parameter, in the "get-bootstrapping-data" RPC. + The "signed-data-preferred" parameter informs the bootstrap + server that the device does not trust it and may be holding back + some additional input parameters from the server (e.g., other + input parameters, progress reports, etc.). The "nonce" input + parameter enables the bootstrap server to dynamically obtain an + ownership voucher from a Manufacturer Authorized Signing + Authority (MASA), which may be important for devices that do not + have a reliable clock. + + + + + + + +Watsen, et al. Standards Track [Page 79] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + 2. The bootstrap server, seeing the "signed-data-preferred" input + parameter, knows that it can send either unsigned redirect + information or signed data of any type. But, in this case, the + bootstrap server has the ability to sign data and chooses to + respond with signed redirect information, not signed onboarding + information as might be expected, securely redirecting the device + back to it again. Not displayed but, if the "nonce" input + parameter was passed, the bootstrap server could dynamically + connect to a MASA and download a voucher having the nonce value + in it. Details regarding a protocol enabling this integration is + outside the scope of this document. + + 3. Upon validating the signed redirect information, the device + establishes a secure connection to the bootstrap server. + Unbeknownst to the device, it is the same bootstrap server it was + connected to previously, but because the device is able to + authenticate the bootstrap server this time, it sends its normal + "get-bootstrapping-data" request (i.e., with additional input + parameters) as well as its progress reports (not depicted). + + 4. This time, because the "signed-data-preferred" parameter was not + passed, having access to all of the device's input parameters, + the bootstrap server returns, in this example, unsigned + onboarding information to the device. Note also that, because + the bootstrap server is now trusted, the device will send + progress reports to the server. + +Appendix C. Workflow Overview + + The solution presented in this document is conceptualized to be + composed of the non-normative workflows described in this section. + Implementation details are expected to vary. Each diagram is + followed by a detailed description of the steps presented in the + diagram, with further explanation on how implementations may vary. + +C.1. Enrollment and Ordering Devices + + The following diagram illustrates key interactions that may occur + from when a prospective owner enrolls in a manufacturer's SZTP + program to when the manufacturer ships devices for an order placed by + the prospective owner. + + + + + + + + + + +Watsen, et al. Standards Track [Page 80] + +RFC 8572 Secure Zero Touch Provisioning (SZTP) April 2019 + + + +-----------+ + +------------+ |Prospective| +---+ + |Manufacturer| | Owner | |NMS| + +------------+ +-----------+ +---+ + | | | + | | | + | 1. initiate enrollment | | + #<-----------------------------| | + # | | + # | | + # IDevID trust anchor | | + #-----------------------------># set IDevID trust anchor | + # #--------------------------->| + # | | + # bootstrap server | | + # account credentials | | + #-----------------------------># set credentials | + | #--------------------------->| + | | | + | | | + | 2. set owner certificate trust anchor | + |<----------------------------------------------------------| + | | | + | | | + | 3. place device order | | + |<-----------------------------# model devices | + | #--------------------------->| + | | | + | 4. ship devices and send | | + | device identifiers and | | + | ownership vouchers | | + |-----------------------------># set device identifiers | + | # and ownership vouchers | + | #--------------------------->| + | | | + + Each numbered item below corresponds to a numbered item in the + diagram above. + + 1. A prospective owner of a manufacturer's devices initiates an + enrollment process with the manufacturer. This process includes + the following: + + * Regardless of how the prospective owner intends to bootstrap + their devices, they will always obtain from the manufacturer + the trust anchor certificate for the IDevID certificates. + This certificate is installed on the prospective owner's NMS + + + + +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] + -- cgit v1.2.3