[要約] RFC 8572は、セキュアなゼロタッチプロビジョニング（SZTP）の要約と目的を提供します。SZTPは、ネットワークデバイスの自動設定とセキュアな初期化を可能にするためのプロトコルです。
Internet Engineering Task Force (IETF) K. Watsen
Request for Comments: 8572 Watsen Networks
Category: Standards Track I. Farrer
ISSN: 2070-1721 Deutsche Telekom AG
M. Abrahamsson
T-Systems
April 2019
Secure Zero Touch Provisioning (SZTP)
セキュアゼロタッチプロビジョニング（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.
このドキュメントでは、ネットワークデバイスが工場出荷時のデフォルト状態で起動しているときに、ネットワークデバイスを安全にプロビジョニングする手法について説明します。ソリューションのバリエーションにより、パブリックネットワークとプライベートネットワークの両方で使用できます。プロビジョニング手順では、ブートイメージを更新し、初期構成をコミットし、補助的なニーズに対処するために任意のスクリプトを実行できます。その後、更新されたデバイスは他のシステムとの安全な接続を確立できます。たとえば、デバイスは、展開固有のネットワーク管理システムとのNETCONF（RFC 6241）および/またはRESTCONF（RFC 8040）接続を確立できます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
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.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8572で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 8
1.4. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 8
2. Types of Conveyed Information . . . . . . . . . . . . . . . . 8
2.1. Redirect Information . . . . . . . . . . . . . . . . . . 8
2.2. Onboarding Information . . . . . . . . . . . . . . . . . 9
3. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Conveyed Information . . . . . . . . . . . . . . . . . . 10
3.2. Owner Certificate . . . . . . . . . . . . . . . . . . . . 12
3.3. Ownership Voucher . . . . . . . . . . . . . . . . . . . . 13
3.4. Artifact Encryption . . . . . . . . . . . . . . . . . . . 13
3.5. Artifact Groupings . . . . . . . . . . . . . . . . . . . 14
4. Sources of Bootstrapping Data . . . . . . . . . . . . . . . . 15
4.1. Removable Storage . . . . . . . . . . . . . . . . . . . . 15
4.2. DNS Server . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. DHCP Server . . . . . . . . . . . . . . . . . . . . . . . 20
4.4. Bootstrap Server . . . . . . . . . . . . . . . . . . . . 21
5. Device Details . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Initial State . . . . . . . . . . . . . . . . . . . . . . 22
5.2. Boot Sequence . . . . . . . . . . . . . . . . . . . . . . 24
5.3. Processing a Source of Bootstrapping Data . . . . . . . . 25
5.4. Validating Signed Data . . . . . . . . . . . . . . . . . 27
5.5. Processing Redirect Information . . . . . . . . . . . . . 28
5.6. Processing Onboarding Information . . . . . . . . . . . . 28
6. The Conveyed Information Data Model . . . . . . . . . . . . . 32
6.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 32
6.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 32
6.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 34
7. The SZTP Bootstrap Server API . . . . . . . . . . . . . . . . 41
7.1. API Overview . . . . . . . . . . . . . . . . . . . . . . 41
7.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 42
7.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 45
8. DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . 56
8.1. DHCPv4 SZTP Redirect Option . . . . . . . . . . . . . . . 56
8.2. DHCPv6 SZTP Redirect Option . . . . . . . . . . . . . . . 58
8.3. Common Field Encoding . . . . . . . . . . . . . . . . . . 59
9. Security Considerations . . . . . . . . . . . . . . . . . . . 59
9.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 59
9.2. Use of IDevID Certificates . . . . . . . . . . . . . . . 60
9.3. Immutable Storage for Trust Anchors . . . . . . . . . . . 60
9.4. Secure Storage for Long-Lived Private Keys . . . . . . . 60
9.5. Blindly Authenticating a Bootstrap Server . . . . . . . . 60
9.6. Disclosing Information to Untrusted Servers . . . . . . . 60
9.7. Sequencing Sources of Bootstrapping Data . . . . . . . . 61
9.8. Safety of Private Keys Used for Trust . . . . . . . . . . 62
9.9. Increased Reliance on Manufacturers . . . . . . . . . . . 62
9.10. Concerns with Trusted Bootstrap Servers . . . . . . . . . 63
9.11. Validity Period for Conveyed Information . . . . . . . . 63
9.12. Cascading Trust via Redirects . . . . . . . . . . . . . . 64
9.13. Possible Reuse of Private Keys . . . . . . . . . . . . . 65
9.14. Non-issue with Encrypting Signed Artifacts . . . . . . . 65
9.15. The "ietf-sztp-conveyed-info" YANG Module . . . . . . . . 65
9.16. The "ietf-sztp-bootstrap-server" YANG Module . . . . . . 66
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67
10.1. The IETF XML Registry . . . . . . . . . . . . . . . . . 67
10.2. The YANG Module Names Registry . . . . . . . . . . . . . 67
10.3. The SMI Security for S/MIME CMS Content Type Registry . 68
10.4. The BOOTP Vendor Extensions and DHCP Options Registry . 68
10.5. The Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Registry . . . . . . . . . . . . . . . . . . . 68
10.6. The Service Name and Transport Protocol Port Number
Registry . . . . . . . . . . . . . . . . . . . . . . . . 69
10.7. The Underscored and Globally Scoped DNS Node Names
Registry . . . . . . . . . . . . . . . . . . . . . . . . 69
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 69
11.1. Normative References . . . . . . . . . . . . . . . . . . 69
11.2. Informative References . . . . . . . . . . . . . . . . . 71
Appendix A. Example Device Data Model . . . . . . . . . . . . . 74
A.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 74
A.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 75
A.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 75
Appendix B. Promoting a Connection from Untrusted to Trusted . . 79
Appendix C. Workflow Overview . . . . . . . . . . . . . . . . . 80
C.1. Enrollment and Ordering Devices . . . . . . . . . . . . . 80
C.2. Owner Stages the Network for Bootstrap . . . . . . . . . 83
C.3. Device Powers On . . . . . . . . . . . . . . . . . . . . 85
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 87
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 87
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.
このドキュメントでは、セキュアゼロタッチプロビジョニング（SZTP）を定義しています。これは、デバイスが物理的な配置とネットワークおよび電源ケーブルの接続以外にインストーラーアクションなしでブートストラップデータを安全に取得できるようにするブートストラップ戦略です。このように、SZTPを使用すると、技術者ではない担当者でも、オペレーターの入力を必要とせずに、離れた場所にあるデバイスを起動できます。
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.
SZTPソリューションには、ブートイメージの更新、初期構成のコミット、および補助的なニーズに対処するための任意のスクリプトの実行が含まれます。その後、更新されたデバイスは他のシステムとの安全な接続を確立できます。たとえば、デバイスは、展開固有のネットワーク管理システムとのNETCONF [RFC6241]および/またはRESTCONF [RFC8040]接続を確立できます。
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.
このドキュメントは主に物理デバイスに関するもので、デバイスの初期状態の設定（セクション5.1で説明）はデバイスの製造プロセス中に発生します。 SZTPソリューションは、仮想マシンまたはその他のそのような論理構造をサポートするように拡張できますが、これを実現する方法の詳細は将来の作業に残します。
o Device connecting to a remotely administered network
o リモートで管理されているネットワークに接続しているデバイス
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.
この使用例には、リモートブランチオフィスやコンビニエンスストアなどのシナリオが含まれ、デバイスがアクセスゲートウェイとしてISPのネットワークに接続します。ブートストラップサポートを提供するためにISPのネットワークをカスタマイズすることは不可能であり、近くに他に利用できるデバイスがない場合、デバイスには手段がなく、ブートストラップするインターネットベースのブートストラップサーバーにアクセスする必要があります。
o Device connecting to a locally administered network
o ローカルに管理されているネットワークに接続するデバイス
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.
SZTPの展開方法の概念的なワークフローについては、付録Cを参照してください。
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.
アーティファクト：「アーティファクト」という用語は、このドキュメント全体で、セクション3で定義された3つのアーティファクト（伝達される情報、所有権バウチャー、および所有者証明書）のいずれかを表すために使用されます。これらのアーティファクトは、デバイスが使用するすべてのブートストラップデータをまとめて提供します。
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).
ブートストラップデータ：「ブートストラップデータ」という用語は、このドキュメント全体で、ブートストラッププロセス中にデバイスが取得する可能性のあるデータのコレクションを指すために使用されます。具体的には、セクション3で定義された3つの成果物（伝達される情報、所有者の証明書、および所有権のバウチャー）を指します。
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.
ブートストラップサーバー：このドキュメントでは、「ブートストラップサーバー」という用語は、セクション7.3で定義されているYANGモジュールを実装するRESTCONFサーバーを意味します。
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.
伝達される情報：「伝達される情報」という用語は、リダイレクト情報またはオンボーディング情報のいずれかを指すために本明細書で使用されます。伝達される情報は、セクション3で説明する3つのブートストラップアーティファクトの1つです。
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.
デバイス：「デバイス」という用語は、このドキュメント全体で、ブートストラップが必要なネットワーク要素を指すために使用されています。デバイスの詳細については、セクション5を参照してください。
Manufacturer: The term "manufacturer" is used herein to refer to the manufacturer of a device or a delegate of the manufacturer.
製造元：「製造元」という用語は、デバイスの製造元または製造元の代理人を指すために本明細書で使用されます。
Network Management System (NMS): The acronym "NMS" is used throughout this document to refer to the deployment-specific management system that the bootstrapping process is responsible for introducing devices to. From a device's perspective, when the bootstrapping process has completed, the NMS is a NETCONF or RESTCONF client.
ネットワーク管理システム（NMS）：このドキュメント全体で頭字語「NMS」を使用して、ブートストラッププロセスがデバイスの導入を担当する展開固有の管理システムを指します。デバイスの観点から見ると、ブートストラッププロセスが完了すると、NMSはNETCONFまたはRESTCONFクライアントになります。
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.
オンボーディング情報：「オンボーディング情報」という用語は、本書で定義されている2種類の「伝達情報」の1つを指し、もう1つは「リダイレクト情報」です。オンボーディング情報は、セクション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.
所有者証明書：このドキュメントでは、「所有者証明書」という用語は、所有者のIDを公開鍵にバインドするX.509証明書を表すために使用され、デバイスは、伝達された情報アーティファクトの署名を検証するために使用できます。所有者証明書は、既知のトラストアンカーに至る中間証明書のチェーンと一緒に通信できます。所有者証明書は、セクション3で説明されている3つのブートストラップアーティファクトの1つです。
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.
所有権バウチャー：「所有権バウチャー」という用語は、このドキュメントでは、[RFC8366]で定義されているバウチャーアーティファクトを表すために使用されています。所有権バウチャーは、デバイスを所有者に割り当てるために使用されます。所有権バウチャーは、セクション3で説明する3つのブートストラップアーティファクトの1つです。
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.
リダイレクト情報：「リダイレクト情報」という用語は、本書で定義されている2つのタイプの「伝達情報」の1つを指し、もう1つは「オンボーディング情報」です。リダイレクト情報は、セクション6.3の「伝達情報」ヤンデータ構造内の「リダイレクト情報」コンテナによって正式に定義されています。
Redirect Server: The term "redirect server" is used to refer to a bootstrap server that only returns redirect information. A redirect server is particularly useful when hosted by a manufacturer, as a well-known (e.g., Internet-based) resource to redirect devices to deployment-specific bootstrap servers.
リダイレクトサーバー：「リダイレクトサーバー」という用語は、リダイレクト情報のみを返すブートストラップサーバーを指すために使用されます。リダイレクトサーバーは、デバイスを展開固有のブートストラップサーバーにリダイレクトするためのよく知られている（インターネットベースなど）リソースとして、製造元によってホストされている場合に特に便利です。
Signed Data: The term "signed data" is used throughout to mean conveyed information that has been signed, specifically by a private key possessed by a device's owner.
署名されたデータ：「署名されたデータ」という用語は、特にデバイスの所有者が所有する秘密鍵によって署名された伝達情報を意味するために全体にわたって使用されます。
Unsigned Data: The term "unsigned data" is used throughout to mean conveyed information that has not been signed.
署名されていないデータ：「署名されていないデータ」という用語は、署名されていない伝達情報を意味するために使用されています。
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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Tree diagrams used in this document follow the notation defined in [RFC8340].
このドキュメントで使用されるツリー図は、[RFC8340]で定義された表記に従います。
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種類の伝達情報を定義しています。これらの伝達される情報タイプについては、このセクションで説明します。例はセクション6.2に記載されています。
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.
リダイレクト情報は、デバイスを別のブートストラップサーバーにリダイレクトします。リダイレクト情報はブートストラップサーバーのリストをエンコードし、それぞれがブートストラップサーバーのホスト名（またはIPアドレス）、オプションのポート、およびデバイスがブートストラップサーバーの認証に使用できるオプションのトラストアンカー証明書を指定します。
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.
リダイレクト情報は、セクション6.3に示すYANGモジュールの「リダイレクト情報」コンテナによって正式に定義されたYANGモデルのデータです。このコンテナには、次のツリー図があります。
+--:(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.
デバイスがリダイレクト情報を処理する方法については、セクション5.5で説明しています。
Onboarding information provides data necessary for a device to bootstrap itself and establish secure connections with other systems. As defined in this document, onboarding information can specify details about the boot image a device must be running, an initial configuration the device must commit, and scripts that the device must successfully execute.
オンボーディング情報は、デバイスがそれ自体をブートストラップし、他のシステムとの安全な接続を確立するために必要なデータを提供します。このドキュメントで定義されているように、オンボーディング情報は、デバイスが実行している必要があるブートイメージ、デバイスがコミットする必要がある初期構成、およびデバイスが正常に実行する必要があるスクリプトに関する詳細を指定できます。
Onboarding information is YANG-modeled data formally defined by the "onboarding-information" container in the YANG module presented in Section 6.3. This container has the tree diagram shown below.
オンボーディング情報は、セクション6.3に示すYANGモジュールの「onboarding-information」コンテナによって正式に定義されたYANGモデルのデータです。このコンテナには、次のツリー図があります。
+--:(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.
デバイスがオンボーディング情報を処理する方法については、セクション5.6で説明します。
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つのアーティファクトを定義します。ブートストラップデータの各ソースは、このセクションで定義されたアーティファクトを提供する方法を指定します（セクション4を参照）。
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.
伝達された情報アーティファクトは、デバイスの重要なブートストラップデータをエンコードします。このアーティファクトは、セクション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.
伝達される情報アーティファクトは、[RFC5652]で説明されているように、ITU-T X.690 [ITU.X690.2015]で指定されているASN.1識別エンコーディングルール（DER）を使用してエンコードされた暗号メッセージ構文（CMS）構造です。 CMS構造には、セクション6.3で指定されているYANGモジュールに準拠するコンテンツが含まれている必要があります。
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.
伝達される情報のCMS構造は、署名付きまたは署名なしのブートストラップデータをエンコードできます。ブートストラップデータが署名されている場合、それも暗号化される可能性がありますが、用語の観点からは、「署名されたデータ」のままです。セクション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.
伝達された情報アーティファクトが署名されておらず、暗号化されていない場合、信頼できるチャネルを介して通信される場合のように、CMS構造の最上位のコンテンツタイプは、セクション10.3で説明されているOID（つまり、id-ct-sztpConveyedInfoXMLまたはid-ct-sztpConveyedInfoJSON）の1つである必要があります。 ）またはOID id-data（1.2.840.113549.1.7.1）。 OID id-dataを使用する場合、エンコーディング（JSON、XMLなど）は外部に通信する必要があります（SHOULD）。どちらの場合でも、関連するコンテンツは、予想されるエンコードでの「伝達情報」データを含むオクテット文字列です。
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.
伝達された情報アーティファクトが署名されておらず暗号化されている場合、信頼できるチャネルを介して通信される場合と同様ですが、何らかの理由で、オペレーターのみがデバイスがコンテンツを表示できることを確認したい場合、CMS構造の最上位コンテンツタイプはOID id-envelopedData（1.2.840.113549.1.7.3）。さらに、encryptedContentInfoのコンテンツタイプは、セクション10.3で説明されているOID（つまり、id-ct-sztpConveyedInfoXMLまたはid-ct-sztpConveyedInfoJSON）またはOID id-data（1.2.840.113549.1.7.1）のいずれかである必要があります。 OID id-dataを使用する場合、エンコーディング（JSON、XMLなど）は外部に通信する必要があります（SHOULD）。どちらの場合でも、関連するコンテンツは、予想されるエンコードでの「伝達情報」データを含むオクテット文字列です。
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.
伝達された情報アーティファクトが署名され暗号化されていない場合、信頼できないチャネルを介して通信する場合のように、CMS構造の最上位のコンテンツタイプはOID id-signedData（1.2.840.113549.1.7.2）でなければなりません。さらに、内部のeContentTypeは、セクション10.3で説明されているOID（つまり、id-ct-sztpConveyedInfoXMLまたはid-ct-sztpConveyedInfoJSON）またはOID id-data（1.2.840.113549.1.7.1）のいずれかである必要があります。 OID id-dataを使用する場合、エンコーディング（JSON、XMLなど）は外部に通信する必要があります（SHOULD）。どちらの場合も、関連付けられたコンテンツまたはeContentは、予想されるエンコードで「伝達された情報」データを含むオクテット文字列です。
When the conveyed information artifact is signed and encrypted, as it might be when communicated over untrusted channels and privacy is important, the CMS structure's topmost content type MUST be the OID id-envelopedData (1.2.840.113549.1.7.3). Furthermore, the encryptedContentInfo's content type MUST be the OID id-signedData (1.2.840.113549.1.7.2), whose eContentType MUST be one of the OIDs described in Section 10.3 (i.e., id-ct-sztpConveyedInfoXML or id-ct-sztpConveyedInfoJSON), or the OID id-data (1.2.840.113549.1.7.1). When the OID id-data is used, the encoding (JSON, XML, etc.) SHOULD be communicated externally. In either case, the associated content or eContent is an octet string containing "conveyed-information" data in the expected encoding.
伝達された情報アーティファクトが署名および暗号化される場合、信頼できないチャネルを介して通信される場合やプライバシーが重要である場合など、CMS構造の最上位のコンテンツタイプはOID id-envelopedData（1.2.840.113549.1.7.3）でなければなりません。さらに、encryptedContentInfoのコンテンツタイプはOID id-signedData（1.2.840.113549.1.7.2）でなければならず、そのeContentTypeはセクション10.3で説明されているOIDの1つでなければなりません（つまり、id-ct-sztpConveyedInfoXMLまたはid-ct-sztpConveyedInfoJSON）。 、またはOID id-data（1.2.840.113549.1.7.1）。 OID id-dataを使用する場合、エンコーディング（JSON、XMLなど）は外部に通信する必要があります（SHOULD）。どちらの場合も、関連付けられたコンテンツまたはeContentは、予想されるエンコードで「伝達された情報」データを含むオクテット文字列です。
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.
所有者証明書のアーティファクトは、「所有者」（組織など）を識別するために使用されるX.509証明書[RFC5280]です。所有者証明書は、任意の認証局（CA）によって署名できます。所有者証明書にはキー使用法が指定されていないか、またはキー使用法は少なくとも「digitalSignature」ビットを設定する必要があります。所有者証明書の「subject」や「subjectAltName」の値は、このドキュメントでは制限されていません。
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.
所有者証明書は、セクション3.5で説明されているように、デバイスが受信する必要がある伝達された情報アーティファクト（セクション3.1）の署名を検証するためにデバイスによって使用されます。特に、デバイスは、所有者証明書の公開鍵を使用して、伝達された情報アーティファクトに含まれるコンテンツに対して署名を検証します。
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].
所有者証明書のアーティファクトは、[RFC5652]で指定されているように、ITU-T X.690 [ITU.X690.2015]で指定されているように、ASN.1 DERを使用してエンコードされた正式なCMS構造です。
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.
所有者証明書のCMS構造には、所有者証明書自体と、所有権バウチャーで指定された「ピン留めドメイン証明書」証明書につながるすべての中間証明書が含まれている必要があります。所有者証明書アーティファクトには、オプションで「固定ドメイン証明書」も含めることができます。
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.
プライベートネットワーク上に展開されたデバイスをサポートするために、所有者証明書のCMS構造には、ローカルポリシー、失効オブジェクト（証明書失効リスト（CRL）[RFC5280]およびOCSP応答[RFC6960]など）によって決定されるように、適切に新しいものも含まれる場合があります。これらの失効オブジェクトを所有者の証明書にホチキス止めすると、CRL配布ポイントまたは関連する証明書で指定されたオンライン証明書ステータスプロトコル（OCSP）レスポンダーを使用して、デバイスがオブジェクトを動的にダウンロードする必要がなくなります。
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.
暗号化されていない場合、所有者証明書のアーティファクトのCMS構造の最上位のコンテンツタイプは、OID id-signedData（1.2.840.113549.1.7.2）でなければなりません。内部のSignedData構造は、証明書と失効オブジェクトを広めるために一般的に使用される署名者が存在しない、縮退した形式です。
When encrypted, the topmost content type of the owner certificate artifact's CMS structure MUST be the OID id-envelopedData (1.2.840.113549.1.7.3), and the encryptedContentInfo's content type MUST be the OID id-signedData (1.2.840.113549.1.7.2), whereby the inner SignedData structure is the degenerate form that has no signers commonly used to disseminate certificates and revocation objects.
暗号化される場合、所有者証明書アーティファクトのCMS構造の最上位のコンテンツタイプはOID id-envelopedData（1.2.840.113549.1.7.3）でなければならず、encryptedContentInfoのコンテンツタイプはOID id-signedData（1.2.840.113549.1.7。 2）これにより、内部のSignedData構造は、証明書と失効オブジェクトを広めるために一般的に使用される署名者を持たない退化した形式になります。
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.
所有権バウチャーは、セクション3.5で説明されているように、デバイスが受信する必要がある所有者証明書（セクション3.2）を確認するために使用されます。特に、デバイスは、所有者の証明書が、所有権バウチャーに含まれる信頼できる証明書（「ピン留めドメイン証明書」）につながる信頼チェーンを持っていることを確認します。この関係は、所有者の証明書が自己署名証明書であるため、固定ドメイン証明書でもあることに注意してください。
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.
暗号化されていない場合、所有権バウチャーアーティファクトは[RFC8366]で定義されています。説明したように、これは最上位のコンテンツタイプがOID id-signedData（1.2.840.113549.1.7.2）でなければならず、eContentTypeがOID id-ct-animaJSONVoucher（1.2.840.113549.1.9.16.1）でなければならないCMS構造です。またはOID id-data（1.2.840.113549.1.7.1）。 OID id-dataを使用する場合、エンコーディング（JSON、XMLなど）は外部に通信する必要があります（SHOULD）。どちらの場合でも、関連付けられているコンテンツは、予想されるエンコーディングのietf-voucherデータを含むオクテット文字列です。
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.
暗号化される場合、所有権バウチャーアーティファクトのCMS構造の最上位のコンテンツタイプはOID id-envelopedData（1.2.840.113549.1.7.3）である必要があり、encryptedContentInfoのコンテンツタイプはOID id-signedData（1.2.840.113549.1.7。 2）、eContentTypeはOID id-ct-animaJSONVoucher（1.2.840.113549.1.9.16.1）、またはOID id-data（1.2.840.113549.1.7.1）でなければなりません。 OID id-dataを使用する場合、エンコーディング（JSON、XMLなど）は外部に通信する必要があります（SHOULD）。どちらの場合でも、関連付けられているコンテンツは、予想されるエンコーディングのietf-voucherデータを含むオクテット文字列です。
Each of the three artifacts MAY be individually encrypted. Encryption may be important in some environments where the content is considered sensitive.
3つのアーティファクトはそれぞれ個別に暗号化される場合があります。コンテンツが機密と見なされる一部の環境では、暗号化が重要になる場合があります。
Each of the three artifacts are encrypted in the same way, by the unencrypted form being encapsulated inside a CMS EnvelopedData type.
3つのアーティファクトのそれぞれは、暗号化されていないフォームがCMS EnvelopedDataタイプ内にカプセル化されることにより、同じ方法で暗号化されます。
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.
暗号化する場合、CMSはデバイスの安全なデバイスID証明書を使用して暗号化する必要があります。この証明書は、デバイスがブートストラップサーバーに接続するときに使用するTLSレベルのクライアント証明書と同じである場合があります。所有者は、データを暗号化するときにデバイスのID証明書を所有している必要があります。所有者がこの目的でデバイスのID証明書を所有する方法は、このドキュメントの範囲外です。
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).
署名されていないデータ：この成果物グループは、トランスポートレベルのセキュリティを使用して信頼を伝えることができる場合（HTTPSなど）、または伝えられた情報を暫定的な方法で処理できる場合（署名されていないリダイレクト情報など）に役立ちます。
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):
各アーティファクトの存在と識別特性は、以下の表の各アーティファクトグループで識別されます（「yes」と「no」は、アーティファクトがアーティファクトグループに存在するかどうかを示します）。
+---------------------+---------------+--------------+--------------+
| 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 |
+---------------------+---------------+--------------+--------------+
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.
このセクションで定義されているブートストラップデータの各ソースについて、セクション3にリストされている3つのアーティファクトがどのように提供されるかについて詳しく説明します。
A directly attached removable storage device (e.g., a USB flash drive) MAY be used as a source of SZTP bootstrapping data.
直接接続されたリムーバブルストレージデバイス（USBフラッシュドライブなど）は、SZTPブートストラップデータのソースとして使用できます。
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.
アーティファクトの観点から見ると、リムーバブルストレージデバイスはファイルシステムとして提示されるため、ブートストラップアーティファクトはファイルとして提示する必要があります。セクション3で定義された3つの成果物は、以下のファイルにマップされます。
Artifact to File Mapping:
アーティファクトからファイルへのマッピング：
Conveyed Information: Mapped to a file containing the binary artifact described in Section 3.1 (e.g., conveyed-information.cms).
伝達された情報：セクション3.1で説明されているバイナリアーティファクトを含むファイルにマッピングされます（たとえば、伝達された情報.cms）。
Owner Certificate: Mapped to a file containing the binary artifact described in Section 3.2 (e.g., owner-certificate.cms).
所有者証明書：セクション3.2で説明されているバイナリアーティファクトを含むファイルにマッピングされます（例：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).
所有権のバウチャー：セクション3.3で説明されているバイナリアーティファクトを含むファイルにマッピングされます（たとえば、ownership-voucher.cmsまたは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.
リムーバブルストレージデバイスのファイルシステムの形式とファイルの名前は、このドキュメントの範囲外です。ただし、相互運用性を促進するために、デバイスがオープンおよび/または標準ベースのファイルシステムをサポートすることが推奨されます。また、デバイスは、リムーバブルストレージデバイス上にブートストラップデータの複数のインスタンス（つまり、異なるデバイス用）が存在できるようにするファイル命名規則を想定していることもお勧めします。ファイルの命名規則は、複数の製造元からのブートストラップデータをリムーバブルストレージデバイスに存在させるために、さらに製造元に固有である必要があります（SHOULD）。
A DNS server MAY be used as a source of SZTP bootstrapping data.
DNSサーバーは、SZTPブートストラップデータのソースとして使用できます。
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サーバーを使用すると、サードパーティがホストするインターネットベースのリソースの利用を伴わないタッチレスブートストラップオプションが有効になるため、既存のDNSインフラストラクチャを備えた展開にとって魅力的なオプションになる場合があります。
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).
DNSは、ブートストラップデータの信頼できないソースです。 DNSSEC [RFC6698]を使用してさまざまなDNSリソースレコード（A、AAAA、CERT、TXT、TLSAなど）を認証しても、デバイスは、DHCPサーバーなどからドメインが返されたことを確認できません。その正当な所有者に。つまり、DNSレコードに格納されている情報は、署名されている必要があります（このドキュメントではDNSSECではなく）、または暫定的に処理できる情報でなければなりません（たとえば、署名されていないリダイレクト情報）。
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.
DNSをブートストラップデータのソースとしてサポートしていると主張するデバイスは、最初にデバイス固有のDNSレコードを照会する必要があり、次に、そうすることでブートストラップが成功しない場合にのみ、デバイスに依存しないDNSレコードを照会する必要があります。
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].
デバイス固有のクエリとデバイスに依存しないクエリのそれぞれについて、デバイスは最初にマルチキャストDNS [RFC6762]を使用してクエリを実行する必要があります。次に、クエリを実行してもブートストラップが成功しない場合のみ、ユニキャストDNS [RFC1035] [RFC7766]を使用して再度クエリを実行する必要があります。 。これは、[RFC6763]のセクション11で説明されているのと同様の手法を使用しているなど、DNSサーバーのアドレスが既知であることを前提としています。
When querying for device-specific DNS records, devices MUST query for TXT records [RFC1035] under "<serial-number>._sztp", where <serial-number> is the device's serial number (the same value as in the device's secure device identity certificate), and "_sztp" is the globally scoped DNS attribute registered per this document (see Section 10.7).
デバイス固有のDNSレコードをクエリする場合、デバイスは "<serial-number> ._ sztp"の下のTXTレコード[RFC1035]をクエリする必要があります。ここで、<serial-number>はデバイスのシリアル番号です（デバイスのセキュアデバイスと同じ値） ID証明書）、および「_sztp」は、このドキュメントに従って登録されたグローバルスコープのDNS属性です（セクション10.7を参照）。
Example device-specific DNS record queries:
デバイス固有のDNSレコードクエリの例：
TXT in <serial-number>._sztp.local. (multicast)
TXT in <serial-number>._sztp.<domain>. (unicast)
When querying for device-independent DNS records, devices MUST query for SRV records [RFC2782] under "_sztp._tcp", where "_sztp" is the service name registered per this document (see Section 10.6), and "_tcp" is the globally scoped DNS attribute registered per [RFC8552].
デバイスに依存しないDNSレコードをクエリする場合、デバイスは「_sztp._tcp」の下のSRVレコード[RFC2782]をクエリする必要があります。「_ sztp」はこのドキュメントに従って登録されたサービス名（10.6を参照）、「_ tcp」はグローバルです[RFC8552]に従って登録されたスコープ付きDNS属性。
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.
署名されたデータはデバイス固有の所有権バウチャーの使用を必要とするため、デバイスに依存しない応答はいずれにしても署名されていないデータのみをエンコードできることに注意してください。 SRVレコードを使用すると、既存のDNS標準を最大限に活用できます。複数のSRVレコードを含む応答は、署名されていないリダイレクト情報のブートストラップサーバーのリストに相当します。
Example device-independent DNS record queries:
デバイスに依存しないDNSレコードクエリの例：
SRV in _sztp._tcp.local. (multicast) SRV in _sztp._tcp.<domain>. (unicast)
_sztp._tcp.localのSRV。 （マルチキャスト）_sztp._tcp。<ドメイン>内のSRV。 （ユニキャスト）
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].
デバイス固有のクエリの場合、セクション3で定義された3つのブートストラップアーティファクトは、[RFC6763]のセクション6.3で説明されている手法と同様に、キーと値のペアを使用してTXTレコードにエンコードされます。
Artifact to TXT Record Mapping:
TXTレコードマッピングへのアーティファクト：
Conveyed Information: Mapped to a TXT record having the key "ci" and the value being the binary artifact described in Section 3.1.
伝達される情報：キー「ci」と値がセクション3.1で説明されているバイナリアーティファクトであるTXTレコードにマッピングされます。
Owner Certificate: Mapped to a TXT record having the key "oc" and the value being the binary artifact described in Section 3.2.
所有者証明書：セクション3.2で説明されているキー「oc」とバイナリアーティファクトである値を持つTXTレコードにマッピングされます。
Ownership Voucher: Mapped to a TXT record having the key "ov" and the value being the binary artifact described in Section 3.3.
所有権バウチャー：セクション3.3で説明されているキー「ov」と値がバイナリアーティファクトであるTXTレコードにマッピングされます。
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.
名前にかかわらず、TXTレコードはバイナリデータをエンコードでき、SHOULD（[RFC6763]のセクション6.5に従って）であることに注意してください。
Following is an example of a device-specific response, as it might be presented by a user agent, containing signed data. This example assumes that the device's serial number is "<serial-number>", the domain is "example.com", and "<binary data>" represents the binary artifact:
以下は、署名されたデータを含む、ユーザーエージェントによって提示される可能性がある、デバイス固有の応答の例です。この例では、デバイスのシリアル番号が「<serial-number>」、ドメインが「example.com」、「<binary data>」がバイナリアーティファクトを表すと想定しています。
<serial-number>._sztp.example.com. 3600 IN TXT "ci=<binary data>"
<serial-number>._sztp.example.com. 3600 IN TXT "oc=<binary data>"
<serial-number>._sztp.example.com. 3600 IN TXT "ov=<binary data>"
Note that, in the case that "ci" encodes unsigned data, the "oc" and "ov" keys would not be present in the response.
「ci」が符号なしデータをエンコードする場合、「oc」および「ov」キーは応答に存在しないことに注意してください。
For device-independent queries, the three bootstrapping artifacts defined in Section 3 are encoded into the SVR records as follows.
デバイスに依存しないクエリの場合、セクション3で定義された3つのブートストラップアーティファクトは、次のようにSVRレコードにエンコードされます。
Artifact to SRV Record Mapping:
アーティファクトとSRVレコードのマッピング：
Conveyed Information: This artifact is not supported directly. Instead, the essence of unsigned redirect information is mapped to SVR records per [RFC2782].
伝達される情報：このアーティファクトは直接サポートされていません。代わりに、署名されていないリダイレクト情報の本質は、[RFC2782]に従ってSVRレコードにマッピングされます。
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]":
以下は、4つのブートストラップサーバーへの（事実上）署名されていないリダイレクト情報を含む、ユーザーエージェントによって提示される可能性がある、デバイスに依存しない応答の例です。この例では、ドメインが「example.com」であり、4つのブートストラップサーバー「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.
_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.
この例では、「sztp3」と「sztp4」の優先度が等しいため、クラスター化されたブートストラップサーバーのペアを効果的に表していることに注意してください。 「sztp1」と「sztp2」にはそれぞれ1つのSRVレコードしかありませんが、レコードがブートストラップサーバーのクラスターの前にあるロードバランサーを指している場合があります。
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.
このドキュメントではDNS-SD [RFC6763]を使用していませんが、そのRFCのセクション12.2に従って、マルチキャストDNS（mDNS）応答には、SRV rdataで指定されたすべてのアドレスレコード（タイプ "A"および "AAAA"）も含める必要があります（SHOULD）。
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.
署名されたデータアーティファクトは、DNS規則によって大きくなります。最小の設置面積のシナリオでは、それぞれ数キロバイトのサイズです。ただし、オンボーディング情報のサイズは数キロバイトになりやすく、数キロバイトになる可能性があります。
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.
「RDLENGTH」は16ビットのフィールドであるため、TXTレコードを含むすべてのリソースレコードの上限サイズは65535バイトです（[RFC1035]のセクション3.2.1）。この制限を超えるオンボーディング情報をエンコードしたい場合は、返されるDNSレコードでリダイレクト情報をエンコードして、オンボーディング情報を取得できるブートストラップサーバーにデバイスを転送する必要があります。
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
TXTレコードの予想されるサイズを考えると、DNSの拡張メカニズム（EDNS（0））拡張[RFC6891]が有効になっていても、署名付きデータがUDPベースのDNSパケットに収まる可能性は低いです。コンテンツによっては、署名されたデータがマルチキャストDNSパケットに適合しない場合があります。マルチキャストDNSパケットは、セクション17に従ってサイズを9000バイトに制限します。
[RFC6762]. Thus, it is expected that DNS Transport over TCP [RFC7766] will be required in order to return signed data.
[RFC6762]。したがって、署名されたデータを返すには、TCP [RFC7766]を介したDNSトランスポートが必要になることが予想されます。
A DHCP server MAY be used as a source of SZTP bootstrapping data.
DHCPサーバーは、SZTPブートストラップデータのソースとして使用できます。
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.
DHCPサーバーを使用すると、サードパーティがホストするインターネットベースのリソースの利用を伴わないタッチレスブートストラップオプションが有効になるため、既存のDHCPインフラストラクチャを備えた展開にとって魅力的なオプションになる場合があります。
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).
DHCPサーバーは、ブートストラップデータの信頼できないソースです。したがって、DHCPサーバーに格納されている情報は、署名されているか、暫定的に処理できる情報でなければなりません（たとえば、署名されていないリダイレクト情報）。
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.
ただし、このドキュメントで説明されている他のブートストラップデータソースとは異なり、DHCPプロトコル（特にIPv4のDHCP）は、署名されたデータが通信できない範囲で、伝達できるデータ量が非常に制限されています。これは、署名されていないリダイレクト情報のみが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.
リダイレクト情報は署名されていないため、DHCPメッセージのスペースを占有し、デバイスはとにかくそれを破棄する必要があるため、オプションのトラストアンカー証明書を含めないでください。このため、セクション8で定義されているDHCPオプションでは、トラストアンカー証明書をエンコードできません。
From an artifact perspective, the three artifacts defined in Section 3 are mapped to the DHCP fields specified in Section 8 as follows.
アーティファクトの観点から、セクション3で定義された3つのアーティファクトは、セクション8で指定されたDHCPフィールドに次のようにマップされます。
Artifact to DHCP Option Fields Mapping:
アーティファクトからDHCPオプションフィールドへのマッピング：
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.
伝達される情報：このアーティファクトは直接サポートされていません。代わりに、署名されていないリダイレクト情報の本質は、セクション8で説明されているDHCPオプションにマッピングされます。
Owner Certificate: Not supported. There is not enough space in the DHCP packet to hold an owner certificate artifact.
所有者証明書：サポートされていません。 DHCPパケットに、所有者証明書のアーティファクトを保持するのに十分なスペースがありません。
Ownership Voucher: Not supported. There is not enough space in the DHCP packet to hold an ownership voucher artifact.
所有権バウチャー：サポートされていません。 DHCPパケットに、所有権バウチャーアーティファクトを保持するのに十分なスペースがありません。
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.
ブートストラップサーバーは、SZTPブートストラップデータのソースとして使用できます。ブートストラップサーバーは、セクション7で提供されているYANGモジュールを実装するRESTCONF [RFC8040]サーバーとして定義されています。
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).
このドキュメントで説明されている他のブートストラップデータソースとは異なり、ブートストラップサーバーはデータのソースであるだけでなく、セクションで提供されているYANGモジュールで定義されているYANG定義の「レポート進行」RPCを使用してデバイスからデータを受信することもできます。 7.3。 「レポート進行」RPCは、ブートストラッププロセス（警告やエラーなど）を可視化し、完了時に潜在的に役立つ情報（デバイスのセキュアシェル（SSH）ホストキーやTLSトラストアンカー証明書など）を提供します。
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.
アーティファクトの観点から見ると、ブートストラップサーバーはYANGデータモデルに準拠したデータを提供するため、ブートストラップアーティファクトをYANGノードにマップする必要があります。セクション3で定義された3つのアーティファクトは、セクション7.3で定義された「get-bootstrapping-data」RPCの「出力」ノードにマップされます。
Artifact to Bootstrap Server Mapping:
アーティファクトとブートストラップサーバーのマッピング：
Conveyed Information: Mapped to the "conveyed-information" leaf in the output of the "get-bootstrapping-data" RPC.
伝達された情報：「get-bootstrapping-data」RPCの出力で「伝達された情報」リーフにマッピングされます。
Owner Certificate: Mapped to the "owner-certificate" leaf in the output of the "get-bootstrapping-data" RPC.
所有者証明書：「get-bootstrapping-data」RPCの出力で「所有者証明書」リーフにマッピングされます。
Ownership Voucher: Mapped to the "ownership-voucher" leaf in the output of the "get-bootstrapping-data" RPC.
所有権バウチャー：「get-bootstrapping-data」RPCの出力で「ownership-voucher」リーフにマッピングされます。
SZTP bootstrap servers have only two endpoints: one for the "get-bootstrapping-data" RPC and one for the "report-progress" RPC.
SZTPブートストラップサーバーには、「get-bootstrapping-data」RPC用と「report-progress」RPC用の2つのエンドポイントしかありません。
These RPCs use the authenticated RESTCONF username to isolate the execution of the RPC from other devices.
これらのRPCは、認証されたRESTCONFユーザー名を使用して、RPCの実行を他のデバイスから分離します。
Devices supporting the bootstrapping strategy described in this document MUST have the pre-configured state and bootstrapping logic described in the following sections.
このドキュメントで説明するブートストラップ戦略をサポートするデバイスには、次のセクションで説明する事前構成済みの状態とブートストラップロジックが必要です。
+-------------------------------------------------------------+
| <device> |
| |
| +---------------------------------------------------------+ |
| | <read/write storage> | |
| | | |
| | 1. flag to enable SZTP bootstrapping set to "true" | |
| +---------------------------------------------------------+ |
| |
| +---------------------------------------------------------+ |
| | <read-only storage> | |
| | | |
| | 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 | |
| +---------------------------------------------------------+ |
| |
| +-----------------------------------------------------+ |
| | <secure storage> | |
| | | |
| | 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 relies on presence is NOT RECOMMENDED, as it cannot be removed by the merging process.
1.デバイスには、SZTPブートストラップを有効/無効にするために使用される設定可能な変数が必要です。デバイスの最初の電源投入時にSZTPブートストラップを実行するには、この変数をデフォルトで有効にする必要があります。ブートストラッププロセスによってインストールされた構成がSZTPブートストラップを無効にすることが目標であり、構成が既存の構成にマージされる可能性があるため、存在に依存する構成ノードの使用はマージプロセスで削除できないためお勧めできません。
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.
2. ブートストラップサーバーからのブートストラップデータのロードをサポートするデバイス（セクション4.4を参照）は、TLSレベルのクライアント証明書と、証明書の既知のトラストアンカーにつながる中間証明書を所有する必要があります（SHOULD）。既知のトラストアンカー証明書は、中間証明書または自己署名ルート証明書の場合があります。 [RFC8040]のセクション2.5で許可されているように、クライアント証明書を持たないデバイスをサポートするために、デバイスは、代替または追加として、HTTP認証スキームを使用してブートストラップサーバーに対して自身を識別および認証することができます。ただし、このドキュメントでは、パスワードの入力など、オペレーター入力を可能にするメカニズムを定義していません。
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.
3. 既知のブートストラップサーバーからのブートストラップデータの読み込みをサポートするデバイスは、既知のブートストラップサーバーのリストを所有している必要があります。リダイレクト情報（セクション2.1）と一致して、各ブートストラップサーバーは、ホスト名またはIPアドレスとオプションのポートで識別できます。
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.
4. 既知のブートストラップサーバーからのブートストラップデータの読み込みをサポートするデバイスは、既知のブートストラップサーバーの認証に使用できるトラストアンカー証明書のリストも所有している必要があります。各トラストアンカー証明書について、それ自体が自己署名ルート証明書ではない場合、デバイスは、自己署名ルート証明書に至るまでの中間証明書のチェーンも所有する必要があります（SHOULD）。
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.
5. 署名済みデータのロードをサポートするデバイス（セクション1.2を参照）は、所有権バウチャーを検証するためのトラストアンカー証明書を所有している必要があります。各トラストアンカー証明書について、それ自体が自己署名ルート証明書ではない場合、デバイスは、自己署名ルート証明書に至るまでの中間証明書のチェーンも所有する必要があります（SHOULD）。
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.
6. TLSレベルのクライアント証明書を使用したブートストラップサーバーへの識別と認証をサポートするデバイスは、TLSレベルのクライアント証明書でエンコードされた公開キーに対応する秘密キーを所有している必要があります。この秘密鍵は、理想的にはトラステッドプラットフォームモジュール（TPM）チップなどの暗号化プロセッサに安全に格納する必要があります（SHOULD）。
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 (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.
7. SZTPアーティファクトの復号化をサポートするデバイスは、アーティファクトを暗号化するときに使用される安全なデバイスID証明書でエンコードされた公開鍵に対応する秘密鍵を所有している必要があります。この秘密鍵は、理想的にはトラステッドプラットフォームモジュール（TPM）チップなどの暗号化プロセッサに安全に格納する必要があります（SHOULD）。この秘密鍵は、ブートストラップサーバーへの接続時に使用されるTLSレベルのクライアント証明書に関連付けられているものと同じである場合があります。
A YANG module representing this data is provided in Appendix A.
このデータを表すYANGモジュールは、付録Aにあります。
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)).
注：デバイスはいつでも、代替プロビジョニングメカニズム（コマンドラインインターフェース（CLI）など）を介して構成できます（MAY）。
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.
1. デバイスの電源がオンになると、まず、デバイスの事前構成された初期状態の場合と同様に、SZTPブートストラップが構成されているかどうかを確認します。 SZTPブートストラップが構成されていない場合、デバイスは正常に起動します。
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.
2. デバイスは、ソースのリストを反復処理してデータをブートストラップします（セクション4）。ブートストラップデータのソースを処理する方法の詳細については、セクション5.3を参照してください。
3. If the device is able to bootstrap itself from any of the sources of bootstrapping data, it runs with the new bootstrapped configuration.
3. デバイスがブートストラップデータのソースからブートストラップできる場合、デバイスは新しいブートストラップ構成で実行されます。
4. Otherwise, the device MUST loop back through the list of bootstrapping sources again.
4. それ以外の場合、デバイスは再度ブートストラップソースのリストをループバックする必要があります。
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.
このドキュメントは、代替プロビジョニングメカニズムの同時使用を制限しません。このようなメカニズムには、たとえば、CLI、Webベースのユーザーインターフェイス、または別のブートストラッププロトコルなどがあります。セクション5.1で説明したように、構成方法に関係なく、構成はSZTPブートストラップを有効にするフラグの設定を解除する必要があります（SHOULD）。
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.
このセクションでは、デバイスが最終的にオンボーディング情報を取得するために使用できる再帰アルゴリズムについて説明します。ブートストラップデータのソースがリダイレクト情報を返す可能性があるため、アルゴリズムは再帰的です。これにより、新たに検出されたブートストラップデータのソースに対して、アルゴリズムが再度実行されます。ブートストラップデータの可能なすべての成功したシーケンスをキャプチャする式は次のとおりです。0個以上のリダイレクト情報応答と、それに続く1つのオンボーディング情報応答。
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.
再帰的アルゴリズムは、「信頼状態」と呼ばれる概念的なグローバルスコープ変数を使用します。信頼状態変数はFALSEに初期化されます。このアルゴリズムの最終的な目標は、信頼状態変数がTRUEのときにデバイスがオンボーディング情報（セクション2.2）を処理することです。
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.
ブートストラップデータのソース（セクション4）がブートストラップサーバー（セクション4.4）であり、デバイスがX.509証明書パス検証（[RFC6125]、セクション6）を使用してデバイスの事前のいずれかに対してブートストラップサーバーを認証できる場合-構成されたトラストアンカー、または前のステップから学習したトラストアンカーに、デバイスは信頼状態を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.
ブートストラップサーバーへの接続を確立する場合、デバイスは、信頼されているかどうかに関係なく、[RFC8040]のセクション2.5に従って、TLSレベルのクライアント証明書またはHTTP認証スキーム、あるいはその両方を使用して、ブートストラップサーバーに対して自身を識別および認証する必要があります。両方の認証メカニズムを使用する場合、それらは両方とも同じシリアル番号を識別する必要があります。
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.
ブートストラップデータのソース（セクション4など）の場合、取得したアーティファクトが暗号化されている場合、デバイスは、アーティファクトの暗号化に使用されたデバイス証明書に関連付けられた秘密鍵を使用して、まずそれを復号化する必要があります。
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.
伝達された情報アーティファクトが署名されており、デバイスがセクション5.4で説明されているアルゴリズムを使用して署名されたデータを検証できる場合、デバイスは信頼状態をTRUEに設定する必要があります。それ以外の場合、デバイスが署名付きデータを検証できない場合、デバイスは信頼状態をFALSEに設定する必要があります。これは、ブートストラップデータの信頼できるソースからも署名されたデータが返された場合の特殊なケースをカバーするために使用されていることに注意してください。
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.
伝達された情報アーティファクトにリダイレクト情報が含まれている場合、デバイスは、デバイスが許可する再帰ループの数の制限内で、セクション5.5で説明されているようにリダイレクト情報を処理する必要があります。実装では、許可される再帰リダイレクトの最大数を制限する必要があります。許可される再帰リダイレクトの最大数は、10以下である必要があります。これは再帰ステップです。リダイレクト情報はデバイスをブートストラップサーバーにリダイレクトすることしかできないため、この場合、デバイスはこのアルゴリズムに再度入りますが、今回はデータソースが間違いなくブートストラップサーバーになります。
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
伝達された情報アーティファクトにオンボーディング情報が含まれ、trust-stateがFALSEの場合、デバイスは再帰アルゴリズムを終了する必要があります（これは許可されないため、上の図を参照）。セクション5.2で説明されているブートストラップシーケンスに戻ります。それ以外の場合、デバイスは、セクション5.6で説明されているオンボーディング情報の処理を試行する必要があります。オンボーディングの処理かどうか
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.2で説明されているブートストラップシーケンスに戻る必要があります。唯一の違いは、「任意のソースからブートストラップできるか」に対する応答です。そのセクションの図で条件付きで説明されています。
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.
署名されたデータがある場合は常に、デバイスに所有権バウチャーと所有者証明書も提供する必要があります。ブートストラップデータの各ソースに必要なすべてのアーティファクトがどのように提供されるかについては、セクション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.
署名されたデータを検証するために、デバイスは最初に、事前に構成されたトラストアンカー（セクション5.1を参照）の1つに対する署名を検証することにより、所有権バウチャーを認証する必要があります。デバイスに正確なクロックがある場合、所有権バウチャーが過去に作成されたことを確認する必要があります（つまり、「created-on」<現在）。「expires-on」リーフが存在する場合、デバイスは、所有権バウチャーはまだ有効期限が切れていません（つまり、現在<"expires-on"）。デバイスは、所有権バウチャーの「アサーション」値が受け入れ可能であることを確認する必要があります（たとえば、一部のデバイスは「確認済み」のアサーション値のみを受け入れる場合があります）。デバイスは、所有権バウチャーが「シリアル番号」リーフでデバイスのシリアル番号を指定していることを確認する必要があります。 「idevid-issuer」リーフが存在する場合、デバイスは値が正しく設定されていることを確認する必要があります。所有権バウチャーの認証が成功した場合、デバイスは、次のステップで所有者証明書を検証するために必要なX.509証明書である「ピン留めドメイン証明書」ノードを抽出します。
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.
次に、デバイスは、所有権バウチャーの「ピン留めドメイン証明書」ノードから抽出された信頼できる証明書に対してX.509証明書パス検証を実行することにより、所有者証明書を認証する必要があります。この検証では、所有者証明書のアーティファクトに添付されている追加の中間証明書を使用する必要がある場合があります。所有権バウチャーの「domain-cert-revocation-checks」ノードの値が「true」に設定されている場合、デバイスは、所有者証明書の署名に使用される証明書チェーンの失効ステータスを検証する必要があり、適切に新しい失効ステータスが取得できないか、証明書が取り消されたと判断された場合、デバイスは所有者の証明書を検証してはなりません。
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.
これらのステップのいずれかが失敗した場合、デバイスは署名されたデータを無効にし、後続のステップを実行してはなりません（MUST）。
In order to process redirect information (Section 2.1), the device MUST follow the steps presented in this section.
リダイレクト情報（セクション2.1）を処理するために、デバイスはこのセクションに示されている手順に従う必要があります。
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.
ホスト名が指定されていて、ホスト名のDNS解決が複数のIPアドレスに対するものである場合、デバイスは、次のブートストラップサーバーに進む前に、少なくとも1回はすべてのDNS解決アドレスへの接続を試行する必要があります。デバイスがDNS解決アドレスのいずれかからブートストラップデータを取得できる場合、他のDNS解決アドレスのいずれにも接続しようとせずに、そのデータをすぐに処理する必要があります。
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.
リダイレクト情報が信頼されていて（たとえば、trust-stateがTRUE）、ブートストラップサーバーエントリにトラストアンカー証明書が含まれている場合、デバイスは、X.509証明書パス検証（[RFC6125]を使用して、指定されたブートストラップサーバーのTLSサーバー証明書を認証する必要があります。 、セクション6）を指定されたトラストアンカーに。ブートストラップサーバーエントリにトラストアンカー証明書デバイスが含まれていない場合、デバイスはブートストラップサーバーへの仮接続を確立し（つまり、サーバー証明書を盲目的に受け入れることにより）、信頼状態を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).
リダイレクト情報が信頼できない場合（たとえば、trust-stateがFALSEの場合）、デバイスはリダイレクト情報によって提供されたトラストアンカーを破棄し、ブートストラップサーバーへの仮接続を確立する必要があります（つまり、TLSサーバー証明書を盲目的に受け入れることによって）。
In order to process onboarding information (Section 2.2), the device MUST follow the steps presented in this section.
オンボーディング情報（セクション2.2）を処理するために、デバイスはこのセクションに示されている手順に従う必要があります。
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 (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.
オンボーディング情報が信頼できるブートストラップサーバーから取得されると、デバイスは「ブートストラップ開始」進行レポートを送信し、終了する「ブートイメージインストール済み再起動」、「ブートストラップ完了」、またはエラー固有の進行レポートを送信する必要があります。ブートストラップサーバーの "get-bootstrapping-data" RPC-replyの "reporting-level"ノードが値 "verbose"である場合、デバイスは、適切なすべての非終了進捗レポート（たとえば、開始、警告、完了、等。）。ブートストラップサーバーによって要求されたレポートレベルに関係なく、デバイスは、レポートレベルで必要なレポートレベルを超えて進捗レポートを送信できます（MAY）。
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.
オンボーディング情報が信頼されていないブートストラップサーバーから取得される場合、オンボーディング情報が必ず署名および認証されていても、デバイスはブートストラップサーバーに進行状況レポートを送信してはなりません（MUST NOT）。部分的にデバイスから進捗レポートを収集できるように、セクション9.6の最後の段落で、信頼できない接続を信頼できる接続に昇格させるには、ブートストラップサーバーが推奨されることに注意してください。
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).
デバイスがいずれかのステップでエラーを検出した場合、デバイスはオンボーディング情報の処理を停止し、セクション5.2で説明されているブートストラップシーケンスに戻る必要があります。再帰アルゴリズムのコンテキストでは、デバイスは最初に戻るのではなく、囲んでいるループに戻る必要があります。一部の状態は、ブートストラッププロセスから保持される場合があります（たとえば、更新されたブートイメージ、ログ、スクリプトの残りなど）。ただし、保持された状態はいかなる方法でもアクティブであってはならず（たとえば、新しい構成やソフトウェアの実行がない）、デバイスがブートストラップシーケンスを続行する機能（つまり、別のブートストラップサーバーからのオンボーディング情報の処理）を妨げてはなりません。
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.
オンボーディング情報が信頼できるブートストラップサーバーから取得された場合、デバイスは「ブートストラップで開始された」進行状況レポートを送信する必要があります。デバイスが "204 No Content" HTTPステータス行を受信しない場合、エラーになります。エラーが発生した場合、デバイスは終了する前に「ブートストラップエラー」の進捗レポートを送信する必要があります。
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 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.
ブートイメージの条件が指定されている場合、デバイスは、実行中のブートイメージが指定されたブートイメージの条件を満たしているかどうかを最初に判断する必要があります。デバイスが指定されたブートイメージを既に実行している場合、この手順の残りの部分はスキップされます。デバイスが指定されたブートイメージを実行していない場合は、指定されたブートイメージをこの順序でダウンロード、確認、およびインストールしてから再起動する必要があります。信頼できるブートストラップサーバーに接続されている場合、デバイスは「boot-image-mismatch」進捗レポートを送信しようとする場合があります。ブートイメージをダウンロードするには、デバイスはオンボーディング情報によって提供されるURIのみを使用する必要があります。ブートイメージを検証するには、デバイスは、オンボーディング情報によって提供される検証フィンガープリントのいずれか、またはこのドキュメントで説明されていないメカニズムを使用してブートイメージ自体に埋め込まれた暗号署名を使用する必要があります。再起動する前に、信頼できるブートストラップサーバーに接続されている場合、デバイスは「boot-image-installed-rebooting」の進捗レポートを送信する必要があります。再起動すると、ブートストラッププロセスが再度実行され、最終的にこのステップに戻りますが、デバイスは指定されたブートイメージを実行しているため、次のステップの処理に移ります。デバイスが信頼できるブートストラップサーバーに接続されている間（つまり、再起動前）にエラーが発生した場合、デバイスは終了する前に「boot-image-error」進行レポートを送信する必要があります。
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.
事前設定スクリプトが指定されている場合、デバイスはスクリプトを実行し、スクリプトから出力された出力をキャプチャし、スクリプトに警告またはエラーがあったかどうかを確認する必要があります。デバイスが信頼できるブートストラップサーバーに接続されているときにエラーが発生した場合、デバイスは終了する前に「pre-script-error」進行レポートの送信を試行する必要があります。
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.
初期構成が指定されている場合、デバイスは、「構成処理」リーフで指定されたアプローチを使用して、提供された初期構成をアトミックにコミットする必要があります。デバイスが信頼できるブートストラップサーバーに接続されているときにエラーが発生した場合、デバイスは終了する前に「config-error」進行レポートを送信する必要があります。
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.
構成後のスクリプトが指定されている場合、デバイスはスクリプトを実行し、スクリプトから出力された出力をキャプチャし、スクリプトに警告またはエラーがあったかどうかを確認する必要があります。デバイスが信頼できるブートストラップサーバーに接続されているときにエラーが発生した場合、デバイスは終了する前に「post-script-error」進行レポートを送信する必要があります。
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.
オンボーディング情報が信頼できるブートストラップサーバーから取得され、ブートストラッププロセスの結果がセクション5.1で説明されている「SZTPブートストラップを有効にするフラグ」を無効にしていない場合、デバイスは「ブートストラップ警告」進捗レポートを送信する必要があります（SHOULD）。
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.
オンボーディング情報が信頼できるブートストラップサーバーから取得された場合、デバイスは「ブートストラップ完了」の進捗レポートを送信する必要があります。デバイスが "204 No Content" HTTPステータス行を受信しない場合、エラーになります。エラーが発生した場合、デバイスは終了する前に「ブートストラップエラー」の進捗レポートを送信する必要があります。
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.
これで、デバイスは初期構成を実行しています。特に、NETCONF Call HomeまたはRESTCONF Call Home [RFC8071]が設定されている場合、デバイスはこの時点でCall Home接続の確立を試みます。
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).
* ほとんどのステップはアトミックです。たとえば、構成の処理はアトミック（上記で指定）であり、スクリプトの処理はアトミック（ "ietf-sztp-conveyed-info" YANGモジュールで指定）です。
* 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.
* スクリプトが正常に実行された後でエラーが発生した場合、スクリプトが以前に設定された状態を削除する必要があることを示す概念的な入力パラメーターを受け取ることができるようにスクリプトを定義すると、実装に役立つ場合があります。
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.
このセクションでは、セクション3.1で説明されている情報アーティファクトのデータモデルを定義するために使用されるYANG 1.1 [RFC7950]モジュールを定義します。このデータモデルは、[RFC8040]で定義されている "yang-data"拡張ステートメントを使用します。このデータモデルの例は、セクション6.2にあります。
The following tree diagram provides an overview of the data model for the conveyed information artifact.
次のツリー図は、伝達された情報アーティファクトのデータモデルの概要を示しています。
module: ietf-sztp-conveyed-info
モジュール：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
The following example illustrates how redirect information (Section 2.1) can be encoded using JSON [RFC8259].
次の例は、JSON [RFC8259]を使用してリダイレクト情報（セクション2.1）をエンコードする方法を示しています。
{
"ietf-sztp-conveyed-info:redirect-information" : {
"bootstrap-server" : [
{
"address" : "sztp1.example.com",
"port" : 8443,
"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].
次の例は、JSON [RFC8259]を使用してオンボーディング情報（セクション2.2）をエンコードする方法を示しています。
[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=="
}
}
The conveyed information data model is defined by the YANG module presented in this section.
伝達される情報データモデルは、このセクションで説明するYANGモジュールによって定義されます。
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].
このモジュールは、[RFC5280]、[RFC5652]、[RFC6234]、および[RFC6991]で定義されているデータ型を使用します。 [RFC8040]からの拡張ステートメント。 [ITU.X690.2015]で定義されているエンコーディング。
<CODE BEGINS> 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: <https://datatracker.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
Author: Kent Watsen <mailto:kent+ietf@watsen.net>";
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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの 'は、ここに示すように、BCP 14（RFC 2119）（RFC 8174）で説明されているように解釈されます。
Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2019 IETF Trustおよびコードの作成者として識別された人物。全著作権所有。
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).
ソースおよびバイナリ形式での再配布および使用は、変更の有無にかかわらず、IETFドキュメントに関連するIETFトラストの法的規定のセクション4.cに記載されているSimplified BSD Licenseに準拠し、それに含まれるライセンス条項に従って許可されます（ 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.";
このYANGモジュールのこのバージョンはRFC 8572の一部です。完全な法的通知については、RFC自体を参照してください。 ";
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
// 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)
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.
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.
CMSには、単一の証明書チェーンのみを含める必要があります。ブートストラップサーバーは、チェーンにリストされている最後の中間CA証明書に対してのみ認証する必要があります。
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.
すべてのケースで、チェーンには自己署名ルート証明書を含める必要があります。ルート証明書自体がブートストラップサーバーのTLS証明書の発行者である場合、証明書は1つだけ存在します。
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.
デバイスで必要な場合、このCMS構造には、デバイスが証明書の失効ステータスを確認できる適切に新しい失効オブジェクトも含まれる場合があります。
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;
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 {
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.
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).";
}
}
<CODE ENDS>
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.
このセクションでは、ブートストラップサーバーのAPIを定義します。 APIは、このセクションで定義されているYANG 1.1 [RFC7950]モジュールをサポートするRESTCONF [RFC8040]サーバーによって生成されるものとして定義されます。
The following tree diagram provides an overview for the bootstrap server RESTCONF API.
次のツリー図は、ブートストラップサーバーRESTCONF APIの概要を示しています。
module: ietf-sztp-bootstrap-server
モジュール：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
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.
このセクションでは、ブートストラップサーバーのAPIを示す3つの例を示します。 「get-bootstrapping-data」RPCには2つの例が提供され（1つは信頼できないブートストラップサーバーに、もう1つは信頼できるブートストラップサーバーに）、1つの例は「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.
次の例は、APIを使用して、信頼できないブートストラップサーバーからブートストラップデータをフェッチするデバイスを示しています。この例では、デバイスは「signed-data-preferred」入力パラメーターを送信し、応答で署名済みデータを受信します。
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
<input
xmlns="urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server">
<signed-data-preferred/>
</input>
RESPONSE
応答
HTTP/1.1 200 OK
Date: Sat, 31 Oct 2015 17:02:40 GMT
Server: example-server
Content-Type: application/yang.data+xml
<output xmlns="urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server"> <conveyed-information>base64encodedvalue==</conveyed-information> <owner-certificate>base64encodedvalue==</owner-certificate> <ownership-voucher>base64encodedvalue==</ownership-voucher> </output> 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.
<output xmlns = "urn：ietf：params：xml：ns：yang：ietf-sztp-bootstrap-server"> <conveyed-information> base64encodedvalue == </ conveyed-information> <owner-certificate> base64encodedvalue == </ owner-certificate> <ownership-voucher> base64encodedvalue == </ ownership-voucher> </ output>次の例は、APIを使用して、信頼できるブートストラップサーバーからブートストラップデータをフェッチするデバイスを示しています。この例では、デバイスはブートストラップサーバーに追加の入力パラメーターを送信します。これは、デバイスへの応答を作成するときに使用できます。
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
<input
xmlns="urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server">
<hw-model>model-x</hw-model>
<os-name>vendor-os</os-name>
<os-version>17.3R2.1</os-version>
<nonce>extralongbase64encodedvalue=</nonce>
</input>
RESPONSE
応答
HTTP/1.1 200 OK
Date: Sat, 31 Oct 2015 17:02:40 GMT
Server: example-server
Content-Type: application/yang.data+xml
<output xmlns="urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server"> <reporting-level>verbose</reporting-level> <conveyed-information>base64encodedvalue==</conveyed-information> </output> 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.
<output xmlns = "urn：ietf：params：xml：ns：yang：ietf-sztp-bootstrap-server"> <reporting-level> verbose </ reporting-level> <conveyed-information> base64encodedvalue == </ conveyed- information> </ output>次の例は、APIを使用して、進行状況レポートをブートストラップサーバーに送信するデバイスを示しています。以下に示すのは「ブートストラップ完了」メッセージですが、デバイスはブートストラップ中に他の進行状況レポートをサーバーに送信する場合があります。この例では、デバイスは、SSHホストキーとTLSサーバー証明書の両方を送信しています。これは、たとえば、付録C.3で説明するように、ブートストラップサーバーがNMSに渡す場合があります。
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
<input
xmlns="urn:ietf:params:xml:ns:yang:ietf-sztp-bootstrap-server">
<progress-type>bootstrap-complete</progress-type>
<message>example message</message>
<ssh-host-keys>
<ssh-host-key>
<algorithm>ssh-rsa</algorithm>
<key-data>base64encodedvalue==</key-data>
</ssh-host-key>
<ssh-host-key>
<algorithm>rsa-sha2-256</algorithm>
<key-data>base64encodedvalue==</key-data>
</ssh-host-key>
</ssh-host-keys>
<trust-anchor-certs>
<trust-anchor-cert>base64encodedvalue==</trust-anchor-cert>
</trust-anchor-certs>
</input>
RESPONSE
応答
HTTP/1.1 204 No Content
Date: Sat, 31 Oct 2015 17:02:40 GMT
Server: example-server
The bootstrap server's device-facing API is normatively defined by the YANG module defined in this section.
ブートストラップサーバーのデバイス向けAPIは、このセクションで定義されているYANGモジュールによって規範的に定義されています。
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].
<CODE BEGINS> 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: <https://datatracker.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
Author: Kent Watsen <mailto:kent+ietf@watsen.net>";
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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの 'は、ここに示すように、BCP 14（RFC 2119）（RFC 8174）で説明されているように解釈されます。
Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2019 IETF Trustおよびコードの作成者として識別された人物。全著作権所有。
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).
ソースおよびバイナリ形式での再配布および使用は、変更の有無にかかわらず、IETFドキュメントに関連するIETFトラストの法的規定のセクション4.cに記載されているSimplified BSD Licenseに準拠し、それに含まれるライセンス条項に従って許可されます（ 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.";
このYANGモジュールのこのバージョンはRFC 8572の一部です。完全な法的通知については、RFC自体を参照してください。 ";
revision 2019-04-30 { description
改訂2019-04-30 {説明
"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
// 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
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
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.
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
'<signed-data-preferred>' 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
"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 {
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 {
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
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
"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.";
}
}
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: <https://www.iana.org/assignments/ssh-para\\
meters>
('\\' added for formatting reasons)";
}
leaf key-data {
type binary;
mandatory true;
description
"The binary public key data for this SSH key, as specified by RFC 4253, Section 6.6; that is:
「RFC 4253のセクション6.6で指定されている、このSSH鍵のバイナリ公開鍵データ。つまり、次のとおりです。
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.
CMSには、デバイスによって提示された証明書を認証するために必要なX.509証明書のチェーンが含まれている必要があります。
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.
CMSには、証明書のチェーンが1つだけ含まれている必要があります。チェーンの最後の証明書は、デバイスのエンドエンティティ証明書の発行者である必要があります。
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 present.
すべてのケースで、チェーンには自己署名ルート証明書を含める必要があります。ルート証明書自体がデバイスのエンドエンティティ証明書の発行者である場合、証明書は1つだけ存在します。
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)";
}
}
}
}
}
<CODE ENDS>
This section defines two DHCP options: one for DHCPv4 and one for DHCPv6. These two options are semantically the same, though syntactically different.
このセクションでは、DHCPv4用とDHCPv6用の2つのDHCPオプションを定義します。これら2つのオプションは、構文的には異なりますが、意味的には同じです。
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.
DHCPv4 SZTPリダイレクトオプションは、接続してさらに構成を試行できるブートストラップサーバー用の1つ以上のURIをクライアントにプロビジョニングするために使用されます。
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.
* option-code：OPTION_V4_SZTP_REDIRECT（143）* option-length：オクテット単位のオプションの長さ。 * bootstrap-server-list：クライアントが接続を試みるサーバーのリスト。セクション8.3に示す形式で、さらにブートストラップデータを取得します。
DHCPv4 SZTP Redirect Option
DHCPv4 SZTPリダイレクトオプション
DHCPv4 Client Behavior
DHCPv4クライアントの動作
Clients MAY request the OPTION_V4_SZTP_REDIRECT option by including its option code in the Parameter Request List (55) in DHCP request messages.
クライアントは、DHCPリクエストメッセージのパラメータリクエストリスト（55）にオプションコードを含めることで、OPTION_V4_SZTP_REDIRECTオプションをリクエストできます。
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.
OPTION_V4_SZTP_REDIRECTオプションを含むDHCPv4応答メッセージを受信すると、クライアントはセクション5.5に従って応答を処理します。「アドレス」と「ポート」の値はURIにエンコードされていることを理解しています。
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.
uri-dataフィールドで受信した無効なURIエントリは、クライアントによって無視されます。受信したOPTION_V4_SZTP_REDIRECTオプションのuri-dataフィールドに少なくとも1つの有効なURIエントリが含まれていない場合、クライアントはオプションを破棄する必要があります。
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.
URIのリストが単一のDHCPv4オプションの最大許容長（255オクテット）を超える可能性があるため、クライアントは、[RFC3396]で説明されているデコードエージェントの動作を実装して、受信した多数のOPTION_V4_SZTP_REDIRECTオプションインスタンスにまたがるURIリストを正しく処理する必要があります。 。
DHCPv4 Server Behavior
DHCPv4サーバーの動作
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.
DHCPv4サーバーは、送信するDHCPメッセージにOPTION_V4_SZTP_REDIRECTオプションの単一インスタンスを含めることができます（MAY）。サーバーは、OPTION_V4_SZTP_REDIRECTオプションの複数のインスタンスを送信してはなりません（MUST NOT）。
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]).
サーバーのDHCPメッセージには、OPTION_V4_SZTP_REDIRECTの「bootstrap-server-list」フィールドのインスタンスが1つだけ含まれている必要があります。ただし、このフィールドのURIのリストは、単一のDHCPv4オプション（[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.
「bootstrap-server-list」の長さがOPTION_V4_SZTP_REDIRECTの単一のインスタンスに収まるほど短い場合、サーバーはこのオプションの複数のインスタンスを送信してはなりません（MUST NOT）。
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].
「bootstrap-server-list」フィールドの長さが長すぎて単一のオプションに収まらない場合は、[RFC3396]で説明されているプロセスに従って、OPTION_V4_SZTP_REDIRECTをオプションの複数のインスタンスに分割する必要があります。
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.
DHCPv6 SZTPリダイレクトオプションを使用して、接続してさらに構成を試行できるブートストラップサーバー用の1つ以上のURIをクライアントにプロビジョニングします。
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.
* option-code：OPTION_V6_SZTP_REDIRECT（136）* option-length：オクテット単位のオプションの長さ。 * bootstrap-server-list：クライアントが接続を試みるサーバーのリスト。セクション8.3に示す形式で、さらにブートストラップデータを取得します。
DHCPv6 SZTP Redirect Option
DHCPv6 SZTPリダイレクトオプション
DHCPv6 Client Behavior
DHCPv6クライアントの動作
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.
クライアントは、[RFC8415]、セクション18.2.1、18.2.2、18.2.4、18.2.5、18.2.6、および21.7で定義されたプロセスを使用して、OPTION_V6_SZTP_REDIRECTを要求できます（MAY）。読者の便宜のために、ここではクライアントがオプション要求オプションに要求されたオプションコードを含めることを述べます。
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.
OPTION_V6_SZTP_REDIRECTオプションを含むDHCPv6応答メッセージを受信すると、クライアントはセクション5.5に従って応答を処理します。「アドレス」と「ポート」の値はURIにエンコードされていることを理解しています。
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.
uri-dataフィールドで受信した無効なURIエントリは、クライアントによって無視されます。受信したOPTION_V6_SZTP_REDIRECTオプションのuri-dataフィールドに少なくとも1つの有効なURIエントリが含まれていない場合、クライアントはオプションを破棄する必要があります。
DHCPv6 Server Behavior
DHCPv6サーバーの動作
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.
[RFC8415]のセクション18.3は、オプションの割り当てに関するサーバーの動作を規定しています。読者の便宜のために、サーバーが特定のオプションコードを送信するのは、そのオプションコードに特定の値が設定されていて、クライアントが要求した場合のみであることをここで述べます。
The OPTION_V6_SZTP_REDIRECT option is a singleton. Servers MUST NOT send more than one instance of this option.
OPTION_V6_SZTP_REDIRECTオプションはシングルトンです。サーバーは、このオプションの複数のインスタンスを送信してはなりません（MUST NOT）。
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:
このセクションで定義されているDHCPv4およびDHCPv6オプションは、どちらもブートストラップサーバーURIのリストをエンコードします。 「URI」構造は、複数のURIを含めることができるDHCPオプションです（[RFC7227]、セクション5.7を参照）。 bootstrap-server-listの各URIエントリは、次のように構成されています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| uri-length | URI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
* uri-length: 2 octets long; specifies the length of the URI data. * URI: URI of the SZTP bootstrap server.
* uri-length：2オクテット長。 URIデータの長さを指定します。 * URI：SZTPブートストラップサーバーのURI。
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://<ip-address-or-hostname>[:<port>]".
SZTPブートストラップサーバーのURIは、[RFC7230]のセクション2.7.2で定義された「https」URIスキームを使用する必要があり、「https：// <ip-address-or-hostname> [：<port >] "。
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.
このドキュメントのソリューションは、TLS証明書、所有者証明書、所有権バウチャーに依存しています。これらはすべて、正しく処理されるために正確なクロックを必要とします（たとえば、有効期限と失効ステータスをテストするため）。実装は、製造施設から出荷されるときにデバイスが正確なクロックを備えていることを保証し、クロックの改ざんを防ぐための措置を講じるべきです。
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.
クロックの正確性を保証できない場合は、実装がクロック感度を持つソリューションの側面を無効にすることをお勧めします。特に、そのような実装では、TLS証明書、所有権バウチャー、および所有者証明書が期限切れになることはなく、取り消しもできないと想定する必要があります。所有権バウチャーの観点から、メーカーはそのようなデバイスの寿命の間に単一の所有権バウチャーを発行する必要があります。
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].
現時点ではNTPは安全なプロトコルではないため、実装ではNTPを時間に依存しないでください。 NTPの保護[NTS-NTP]に焦点を当てたIETFドキュメントがあることに注意してください。
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.
[Std-802.1AR]で定義されているIDevID証明書は、ブートストラップサーバーに接続するときにデバイスが使用するTLSレベルのクライアント証明書と、SZTPブートストラップを暗号化するときに所有者が使用するデバイスID証明書の両方に対して推奨されますデータアーティファクト。
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.
時間の経過とともにこれらの証明書を更新する必要がある場合があります（たとえば、製造元が信頼を新しいCAに委任したい場合）。したがって、デバイスは、署名されたソフトウェアイメージを使用したソフトウェアアップグレードなどの検証可能なプロセスを介して、必要なときにこれらのトラストアンカーを更新することが期待されます。
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).
製造元が生成したデバイス識別子は、寿命が非常に長い場合があります。たとえば、[Std-802.1AR]は、IDevID証明書で「notAfter」値99991231235959Zを使用することを推奨しています。これらの秘密鍵は長持ちする性質があるため、安全な暗号化プロセッサ（信頼できるプラットフォームモジュール（TPM）チップなど）内など、発見に抵抗するために格納されることが最も重要です。
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.
このドキュメントにより、デバイスはブートストラップサーバーのTLS証明書を盲目的に認証できます。これは、リダイレクト情報が安全でない方法で取得される可能性がある場合に対応するために行われます。
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.
これを補うために、このドキュメントでは、デバイスが信頼できないブートストラップサーバーに接続されている場合、サーバーからダウンロードされたデータが署名されていることを表明する必要があります。
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.
このドキュメントにより、デバイスは信頼できないブートストラップサーバーへの接続を確立できます。ただし、ブートストラップサーバーは信頼されていないため、攻撃者の制御下にある可能性があります。したがって、デバイスは、このような場合にブートストラップサーバーに送信するデータに注意する必要があります。
Devices send different data to bootstrap servers at each of the protocol layers: TCP, TLS, HTTP, and RESTCONF.
デバイスは、プロトコルレイヤー（TCP、TLS、HTTP、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.
TCPプロトコルレイヤーでは、デバイスはネットワーク変換の対象となり、IPアドレスをリレーする場合があります。この情報の開示は、セキュリティリスクとは見なされません。
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.
TLSプロトコルレイヤーでは、デバイスはクライアント証明書を使用して、信頼できないブートストラップサーバーに対してデバイスを識別および認証できます。少なくとも、クライアント証明書はデバイスのシリアル番号を開示する必要があり、デバイスの製造元、ハードウェアモデル、公開鍵などの追加情報を開示する可能性があります。この情報の知識は、攻撃者に攻撃を開始するために必要な詳細を提供する可能性があります。ネットワークの支持者の秘密をセキュリティに依存しないようにすることをお勧めします。
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.
HTTPプロトコルレイヤーでは、デバイスはHTTP認証スキームを使用して、信頼されていないブートストラップサーバーに対してデバイスを識別および認証できます。少なくとも、認証スキームはデバイスのシリアル番号を開示する必要があり、関連するのは、使用される認証メカニズムに応じて、デバイスにのみ知られているはずのシークレット（パスワードなど）を明らかにすることです。デバイスは、デバイスにのみ知られているはずの秘密を明らかにする信頼できないブートストラップサーバーでHTTP認証スキーム（HTTP Basicなど）を使用してはなりません（SHOULD NOT）。
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.
RESTCONFプロトコルレイヤーでは、信頼されていないブートストラップサーバーに接続されている場合、デバイスは「get-bootstrapping-data」RPCを使用しますが、「report-progress」RPCは使用しません。 「get-bootstrapping-data」RPCを使用すると、追加の入力パラメーターをブートストラップサーバーに渡すことができます（「os-name」、「os-version」、「hw-model」など）。デバイスは、「signed-data-preferred」入力パラメーターのみを信頼できないブートストラップサーバーに渡すことをお勧めします。ブートストラップサーバーが署名されたオンボーディング情報をすぐに返すことは問題ありませんが、付録Bで説明されているように、ブートストラップサーバーが信頼できない接続を信頼できる接続に昇格させることをお勧めします。これにより、デバイスは「レポート進行」RPCを使用できるようになりますオンボーディング情報の処理中。
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.
データをブートストラップするために複数のソースをサポートするデバイスの場合、各ソースのソリューションは同等に安全であると見なされるため、セキュリティ上の理由から特定の順序付けの順序を守る必要はありません。ただし、プライバシーの観点から、デバイスがリモートソースにアクセスする前にローカルソースにアクセスすることをお勧めします。
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.
このドキュメントで紹介するソリューションでは、トランスポートレベルのセキュリティまたはアーティファクトの署名の2つの方法で、ブートストラップデータを信頼できます。
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.
トランスポートレベルのセキュリティ（つまり、信頼できるブートストラップサーバー）を使用する場合、TLS接続を確立するには、エンドエンティティ証明書の秘密キーがオンラインである必要があります。
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.
アーティファクトが署名されている場合、ブートストラップサーバーが動的に生成された署名済みデータの応答を返す場合にのみ、署名鍵がオンラインである必要があります。たとえば、ブートストラップサーバーは、「get-bootstrapping-data」RPCへの「signed-data-preferred」入力パラメーターを受け取ると、署名された応答を動的に生成します。
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).
ブートストラップサーバーの管理者は、オンライン操作に使用される秘密キーを保護するためのベストプラクティスに従うことをお勧めします。たとえば、ハードウェアセキュリティモジュール（HSM）の使用が推奨されます。 HSMを使用しない場合は、すべてのブートストラップデバイスに正確なクロックがあると想定して、頻繁に秘密鍵を更新することをお勧めします（セクション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).
最高のセキュリティのために、所有者は署名された（保護された秘密キーを使用して）暗号化された（デバイスの安全なデバイスID証明書の公開キーを使用して）ブートストラップデータのみを提供することをお勧めします。
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.
このドキュメントで説明するSZTPブートストラッププロトコルは、初期構成の一部の制御を、デバイスの正当な所有者から、製造元とその代理人に移します。
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.
製造元は、デバイスが信頼する有名なブートストラップサーバーのリストを保持しています。設計上、最初に他の方法でブートストラップデータが見つからない場合、デバイスは既知のブートストラップサーバーに到達しようとします。外部ファイアウォールを使用してこのような接続をブロックする以外に、これを防ぐメカニズムはありません。信頼できるブートストラップサーバーに関連する問題については、セクション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 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.
オペレーターは、このシステムが、メーカーによって指定されたすべての事前構成されたブートストラップサーバーとバウチャー署名機関を信頼していると想定していることを認識しておく必要があります。オペレーターはネットワーク内のポイントを使用して、有名なブートストラップサーバーへのアクセスをブロックすることができますが、オペレーターは、デバイスにバウチャーを生成するバウチャー署名機関を防ぐことはできません。
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 侵害された信頼できるブートストラップサーバーは、あらゆる種類の未署名のデータを返すように変更される可能性があります。たとえば、リダイレクト情報のみを返すことになっているブートストラップサーバーは、オンボーディング情報を返すように変更される場合があります。同様に、署名されたデータのみを返すことになっているブートストラップサーバーは、署名されていないデータを返すように変更できます。どちらの場合も、デバイスは違いがないことに気付かずに、応答を受け入れます。信頼できるブートストラップサーバーの管理者は、システムが簡単に侵害されないことを保証し、侵害が発生した場合に、侵害を可能な限り適切に検出して修正するメカニズムを用意することをお勧めします。
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.
o 署名されていないか、署名されているが暗号化されていないデータをホストする信頼できるブートストラップサーバーは、不要な関係者（ブートストラップサーバーの管理者など）に情報を開示する可能性があります。これはプライバシーの問題のみですが、その後の攻撃で使用される可能性のある情報を明らかにする可能性があります。リダイレクト情報の開示は限定された公開（これはブートストラップサーバーの単なるリストです）ですが、オンボーディング情報の開示は非常に明らかになる可能性があります（ネットワークトポロジ、ファイアウォールポリシーなど）。オペレーターがブートストラップデータを暗号化することをお勧めします。その内容が機密であると考えられる場合は、第三者が管理するブートストラップサーバーの管理者からデータを隠すところまでです。
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.
伝達された情報アーティファクトは有効期間を指定しません。たとえば、リダイレクト情報もオンボーディング情報も「not-before」または「not-after」の値を指定できず、アーチファクトのみを取り消すことはできません。
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.
ブートストラップデータの信頼できるソース（つまり、ブートストラップサーバー）によって提供される署名されていないデータの場合、データの可用性は、それが最新であることの唯一の指標です。信頼できないデータは信頼できるソースからのものであるため、現在の可用性は意味があり、ブートストラップサーバーはTLSを使用するため、交換の内容を変更または再生することはできません。
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.
所有権バウチャーの有効性は、主に所有権バウチャーの「作成日」ノードと「期限切れ日」ノードによって制約されます。 [RFC8366]は有効期間の短いバウチャー（セクション6.1を参照）を推奨していますが、「expires-on」ノードは将来の任意の時点に設定されるか、完全に省略されて、バウチャーが無期限になることを示します。所有権バウチャーの有効性は、バウチャーへの署名に使用される製造元のPKIによって二次的に制約されます。所有権バウチャーを直接取り消すことはできませんが、署名に使用されたPKIは取り消すことができます。
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.
所有者証明書の有効性は、主に、X.509の有効性フィールドである「notBefore」および「notAfter」の値によって制約され、それに署名した認証局によって指定されています。所有者証明書の有効性は、バウチャーへの署名に使用されるPKIの有効性によって二次的に制約されます。所有者の証明書は直接取り消される場合があります。
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.
署名されたデータの有効性を指定および制約する能力に最大限の柔軟性を持たせたい所有者の場合、署名されたアーティファクトごとに一意の所有者証明書を作成することをお勧めします。これにより、各アーチファクトの有効期間を指定できるだけでなく、各アーチファクトの有効性を取り消すこともできます。
Redirect information (Section 2.1), by design, instructs a bootstrapping device to initiate an HTTPS connection to the specified bootstrap servers.
リダイレクト情報（セクション2.1）は、仕様により、指定されたブートストラップサーバーへのHTTPS接続を開始するようにブートストラップデバイスに指示します。
When the redirect information is trusted, the redirect information can encode a trust anchor certificate used by the device to authenticate the TLS end-entity certificate presented by each bootstrap server.
リダイレクト情報が信頼できる場合、リダイレクト情報は、各ブートストラップサーバーによって提示されるTLSエンドエンティティ証明書を認証するためにデバイスが使用するトラストアンカー証明書をエンコードできます。
As a result, any compromise in an interaction providing redirect information may result in compromise of all subsequent interactions.
結果として、リダイレクト情報を提供する対話の妥協は、その後のすべての対話の妥協につながる可能性があります。
This document describes two uses for secure device identity certificates.
このドキュメントでは、安全なデバイスID証明書の2つの使用法について説明します。
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.
主な用途は、デバイスがTLSレベルのクライアント証明書ベースの認証に秘密鍵を使用して、ブートストラップサーバーに対して自身を認証する場合です。
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.
2番目の用途は、デバイスが提供されたブートストラップアーティファクトを復号化する必要がある場合です。その秘密鍵を使用してデータを復号化するか、より正確には、[RFC5652]のセクション6に従って、データの復号化に使用される対称鍵を復号化します。
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.
[Std-802.1AR]では、DevID証明書には「digitalSignature」に加えて「keyEncipherment」KeyUsageビットが含まれる場合があると記載されているため、このドキュメントのセクション3.4では、同じ安全なデバイスID証明書が両方の用途に使用される可能性があります。 KeyUsageビット、セット。
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.
秘密鍵を再利用することは一般に嫌われていることは理解されていますが、このドキュメントでは、あるコンテキストで作成された署名を他のコンテキストで有効であると（誤って）解釈させる既知の方法がないため、このような再利用は受け入れられると考えています。
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.
このドキュメントでは、解読されたテキストがデバイスから出ることはないため、このような攻撃はソリューションのコンテキストでは実行可能であるとは考えていません。
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.
このドキュメントで定義されている「ietf-sztp-conveyed-info」モジュールは、CMS構造によって常にラップされるデータ構造を定義します。安全なメカニズム（TLSで保護されているなど）でアクセスすると、CMS構造は署名されない場合があります。ただし、安全でないメカニズム（リムーバブルストレージデバイスなど）からアクセスする場合、デバイスが信頼できるようにするには、CMS構造に署名する必要があります。
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.
「ietf-sztp-conveyed-info」モジュールは、コンテンツがリダイレクト情報またはオンボーディング情報であることを宣言するトップレベルの「選択」ステートメントを定義します。これら2つのケースのそれぞれが検討されます。
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.
CMS構造のコンテンツがリダイレクト情報である場合、オブザーバーは、デバイスが向けられているブートストラップサーバー、IPアドレスまたはホスト名、ポート、トラストアンカー証明書について知ることができます。この情報についての知識は、オブザーバーにネットワークの内部構造への洞察を提供することができます。
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).
CMS構造のコンテンツがオンボーディング情報である場合、オブザーバーはデバイスのプロビジョニング方法に関するかなりの情報を知ることができます。この情報には、オペレーティングシステムのバージョン、初期構成、スクリプトの内容が含まれます。この情報は機密情報と見なされ、それを保護するための予防策を講じる必要があります（たとえば、デバイスの公開鍵を使用してアーティファクトを暗号化するなど）。
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].
このドキュメントで定義されている「ietf-sztp-bootstrap-server」モジュールは、RESTCONF [RFC8040]のAPIを指定しています。最下位のRESTCONFレイヤーはHTTPSであり、実装に必須のセキュアなトランスポートは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.
NETCONFアクセスコントロールモデル（NACM）[RFC8341]は、特定のユーザーのアクセスを、利用可能なすべてのプロトコル操作とコンテンツの事前構成済みサブセットに制限する手段を提供します。
This module presents no data nodes (only RPCs). There is no need to discuss the sensitivity of data nodes.
このモジュールはデータノードを提示しません（RPCのみ）。データノードの機密性について説明する必要はありません。
This module defines two RPC operations that may be considered sensitive in some network environments. These are the operations and their sensitivity/vulnerability:
このモジュールは、一部のネットワーク環境で機密と見なされる可能性がある2つのRPC操作を定義します。これらは操作とその感度/脆弱性です：
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.
get-bootstrapping-data：このRPCは、デバイスがブートストラップデータを取得するために使用します。設計上、認証クレデンシャル（クライアント証明書など）で識別される各デバイスは、独自のデータのみを取得できます。 NACMは、このRPCへのアクセスをさらに制限する必要はありません。
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.
report-progress：このRPCは、デバイスがブートストラップの進行状況を報告するために使用します。設計上、認証資格情報（クライアント証明書など）によって識別される各デバイスは、それ自体のデータのみをレポートできます。 NACMは、このRPCへのアクセスをさらに制限する必要はありません。
IANA has registered two URIs in the "ns" subregistry of the "IETF XML Registry" [RFC3688] maintained at <https://www.iana.org/assignments/ xml-registry>. The following registrations have been made per the format in [RFC3688]:
IANAは、<https://www.iana.org/assignments/ xml-registry>で管理される「IETF XMLレジストリ」[RFC3688]の「ns」サブレジストリに2つのURIを登録しました。 [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-conveyed-info登録者の連絡先：IETFのNETCONF WG。 XML：N / A、要求されたURIはXML名前空間です。
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.
URI：urn：ietf：params：xml：ns：yang：ietf-sztp-bootstrap-server登録者の連絡先：IETFのNETCONF WG。 XML：N / A、要求されたURIはXML名前空間です。
IANA has registered two YANG modules in the "YANG Module Names" registry [RFC6020] maintained at <https://www.iana.org/assignments/ yang-parameters>. The following registrations have been made per the format in [RFC6020]:
IANAは、<https://www.iana.org/assignments/ yang-parameters>で管理されている「YANG Module Names」レジストリ[RFC6020]に2つのYANGモジュールを登録しました。 [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
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 <https://www.iana.org/assignments/ smi-numbers>. The following registrations have been made per the format in Section 3.4 of [RFC7107]:
IANAは、<https://www.iana.org/assignments/ smi-numbers>で管理されている「SMI Security for S / MIME CMS Content Type（1.2.840.113549.1.9.16.1）」レジストリに2つの下位オブジェクト識別子を登録しました。 [RFC7107]のセクション3.4の形式に従って、次の登録が行われました。
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.
id-ct-sztpConveyedInfoXMLは、「conveyed-information」がXMLを使用してエンコードされていることを示します。 id-ct-sztpConveyedInfoJSONは、「conveyed-information」がJSONを使用してエンコードされていることを示します。
IANA has registered one DHCP code point in the "BOOTP Vendor Extensions and DHCP Options" registry maintained at <https://www.iana.org/assignments/bootp-dhcp-parameters>:
IANAは、<https://www.iana.org/assignments/bootp-dhcp-parameters>で管理されている「BOOTP Vendor Extensions and DHCP Options」レジストリに1つのDHCPコードポイントを登録しました。
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
タグ：143名前：OPTION_V4_SZTP_REDIRECTデータ長：N意味：このオプションは、SZTPブートストラップサーバーのURIのリストを提供します参照：RFC 8572
10.5. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Registry
10.5. IPv6の動的ホスト構成プロトコル（DHCPv6）レジストリ
IANA has registered one DHCP code point in the "Option Codes" subregistry of the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry maintained at <https://www.iana.org/assignments/ dhcpv6-parameters>:
IANA has registered one DHCP code point in the "Option Codes" subregistry of the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry maintained at <https://www.iana.org/assignments/ dhcpv6-parameters>:
Value: 136 Description: OPTION_V6_SZTP_REDIRECT Client ORO: Yes Singleton Option: Yes Reference: RFC 8572
Value: 136 Description: OPTION_V6_SZTP_REDIRECT Client ORO: Yes Singleton Option: Yes Reference: RFC 8572
IANA has registered one service name in the "Service Name and Transport Protocol Port Number Registry" [RFC6335] maintained at <https://www.iana.org/assignments/service-names-port-numbers>. The following registration has been made per the format in Section 8.1.1 of [RFC6335]:
IANAは、<https://www.iana.org/assignments/service-names-port-numbers>で管理されている「サービス名とトランスポートプロトコルのポート番号レジストリ」[RFC6335]に1つのサービス名を登録しています。 [RFC6335]のセクション8.1.1の形式に従って、次の登録が行われました。
Service Name: sztp Transport Protocol(s): TCP Assignee: IESG <iesg@ietf.org> Contact: IETF Chair <chair@ietf.org> 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.
サービス名：sztpトランスポートプロトコル：TCP割り当て先：IESG <iesg@ietf.org>連絡先：IETF議長<chair@ietf.org>説明：このサービス名は、SRVサービスラベル "_sztp"を構築して検出するために使用されますSZTPブートストラップサーバー。参照：RFC 8572ポート番号：N / Aサービスコード：N / A既知の不正使用：N / A割り当て注：このプロトコルは、基質としてHTTPSを使用します。
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 <https://www.iana.org/assignments/dns-parameters>. The following registration has been made per the format in Section 3 of [RFC8552]:
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 <https://www.iana.org/assignments/dns-parameters>. The following registration has been made per the format in Section 3 of [RFC8552]:
RR Type: TXT _NODE NAME: _sztp Reference: RFC 8572
RRタイプ：TXT _NODE NAME：_sztpリファレンス：RFC 8572
[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, <https://www.itu.int/rec/T-REC-X.690/>.
[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勧告X .690、ISO / IEC 8825-1、2015年8月、<https://www.itu.int/rec/T-REC-X.690/>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<https://www.rfc-editor.org/info/rfc1035>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[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, <https://www.rfc-editor.org/info/rfc2782>.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、DOI 10.17487 / RFC2782、2000年2月、<https：// www.rfc-editor.org/info/rfc2782>。
[RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, DOI 10.17487/RFC3396, November 2002, <https://www.rfc-editor.org/info/rfc3396>.
[RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, DOI 10.17487/RFC3396, November 2002, <https://www.rfc-editor.org/info/rfc3396>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC4253] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Transport Layer Protocol」、RFC 4253、DOI 10.17487 / RFC4253、2006年1月、<https://www.rfc-editor.org / info / rfc4253>。
[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, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[RFC5652] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、DOI 10.17487 / RFC5652、2009年9月、<https://www.rfc-editor.org/info/rfc5652>。
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.
[RFC6020] Bjorklund、M。、編、「YANG-ネットワーク構成プロトコル（NETCONF）のデータモデリング言語」、RFC 6020、DOI 10.17487 / RFC6020、2010年10月、<https：//www.rfc-editor。 org / info / rfc6020>。
[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, <https://www.rfc-editor.org/info/rfc6125>.
[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, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.
[RFC6762]チェシャーS.およびM.クロマル、「マルチキャストDNS」、RFC 6762、DOI 10.17487 / RFC6762、2013年2月、<https://www.rfc-editor.org/info/rfc6762>。
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.
[RFC6991] Schoenwaelder、J。、編、「Common YANG Data Types」、RFC 6991、DOI 10.17487 / RFC6991、2013年7月、<https://www.rfc-editor.org/info/rfc6991>。
[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, <https://www.rfc-editor.org/info/rfc7227>.
[RFC7227] Hankins、D.、Mrugalski、T.、Siodelski、M.、Jiang、S。、およびS. Krishnan、「新しいDHCPv6オプションを作成するためのガイドライン」、BCP 187、RFC 7227、DOI 10.17487 / RFC7227、2014年5月、<https://www.rfc-editor.org/info/rfc7227>。
[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, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<https://www.rfc-editor.org/info/ rfc7230>。
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC7950] Bjorklund、M。、編、「The YANG 1.1 Data Modeling Language」、RFC 7950、DOI 10.17487 / RFC7950、2016年8月、<https://www.rfc-editor.org/info/rfc7950>。
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8040] Bierman、A.、Bjorklund、M。、およびK. Watsen、「RESTCONFプロトコル」、RFC 8040、DOI 10.17487 / RFC8040、2017年1月、<https://www.rfc-editor.org/info/rfc8040 >。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, "A Voucher Artifact for Bootstrapping Protocols", RFC 8366, DOI 10.17487/RFC8366, May 2018, <https://www.rfc-editor.org/info/rfc8366>.
[RFC8366]ワトセン、K。、リチャードソン、M。、プリティキン、M。、およびT.エカート、「ブートストラッププロトコルのバウチャーアーティファクト」、RFC 8366、DOI 10.17487 / RFC8366、2018年5月、<https：// www。 rfc-editor.org/info/rfc8366>。
[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, <https://www.rfc-editor.org/info/rfc8415>.
[RFC8415] Mrugalski、T.、Siodelski、M.、Volz、B.、Yourtchenko、A.、Richardson、M.、Jiang、S.、Lemon、T。、およびT. Winters、「IPv6の動的ホスト構成プロトコル（DHCPv6）」、RFC 8415、DOI 10.17487 / RFC8415、2018年11月、<https://www.rfc-editor.org/info/rfc8415>。
[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, <https://www.rfc-editor.org/info/rfc8552>.
[RFC8552] Crocker、D。、「属性リーフの「アンダースコア付き」命名によるDNSリソースレコードのスコープ付き解釈」、BCP 222、RFC 8552、DOI 10.17487 / RFC8552、2019年3月、<https：//www.rfc-editor。 org / info / rfc8552>。
[Std-802.1AR] IEEE, "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", IEEE 802.1AR.
[Std-802.1AR] IEEE、「IEEE Standard for Local and Metropolitan Area Network-Secure Device Identity」、IEEE 802.1AR。
[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.
[NTS-NTP] Franke、D.、Sibold、D.、Teichel、K.、Dansarie、M.、R。Sundblad、「Network Time Security for the Network Time Protocol」、Work in Progress、draft-ietf-ntp -using-nts-for-ntp-18、2019年4月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC3688] Mealling、M。、「The IETF XML Registry」、BCP 81、RFC 3688、DOI 10.17487 / RFC3688、2004年1月、<https://www.rfc-editor.org/info/rfc3688>。
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, DOI 10.17487/RFC4250, January 2006, <https://www.rfc-editor.org/info/rfc4250>.
[RFC4250] Lehtinen、S。およびC. Lonvick、編、「Secure Shell（SSH）Protocol Assigned Numbers」、RFC 4250、DOI 10.17487 / RFC4250、2006年1月、<https://www.rfc-editor.org / info / rfc4250>。
[RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure Shell Authentication", RFC 6187, DOI 10.17487/RFC6187, March 2011, <https://www.rfc-editor.org/info/rfc6187>.
[RFC6187] Igoe、K。およびD. Stebila、「Secure Shell AuthenticationのX.509v3証明書」、RFC 6187、DOI 10.17487 / RFC6187、2011年3月、<https://www.rfc-editor.org/info/rfc6187 >。
[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, <https://www.rfc-editor.org/info/rfc6234>.
[RFC6234] Eastlake 3rd、D。およびT. Hansen、「US Secure Hash Algorithms（SHA and SHA-based HMAC and HKDF）」、RFC 6234、DOI 10.17487 / RFC6234、2011年5月、<https：//www.rfc- editor.org/info/rfc6234>。
[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, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、およびA. Bierman、編、「Network Configuration Protocol（NETCONF）」、RFC 6241、DOI 10.17487 / RFC6241、2011年6月、<https://www.rfc-editor.org/info/rfc6241>。
[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, <https://www.rfc-editor.org/info/rfc6335>.
[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, <https://www.rfc-editor.org/info/rfc6335>.
[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, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6698] Hoffman、P。およびJ. Schlyter、「DNSベースの名前付きエンティティ（DANE）トランスポート層セキュリティ（TLS）プロトコルの認証：TLSA」、RFC 6698、DOI 10.17487 / RFC6698、2012年8月、<https：/ /www.rfc-editor.org/info/rfc6698>。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>.
[RFC6763] Cheshire、S。およびM. Krochmal、「DNSベースのサービスディスカバリ」、RFC 6763、DOI 10.17487 / RFC6763、2013年2月、<https://www.rfc-editor.org/info/rfc6763>。
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <https://www.rfc-editor.org/info/rfc6891>.
[RFC6891] Damas、J.、Graff、M。、およびP. Vixie、「DNSの拡張メカニズム（EDNS（0））」、STD 75、RFC 6891、DOI 10.17487 / RFC6891、2013年4月、<https：// www.rfc-editor.org/info/rfc6891>。
[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, <https://www.rfc-editor.org/info/rfc6960>.
[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、2013年6月、<https://www.rfc-editor.org/info/rfc6960>。
[RFC7107] Housley, R., "Object Identifier Registry for the S/MIME Mail Security Working Group", RFC 7107, DOI 10.17487/RFC7107, January 2014, <https://www.rfc-editor.org/info/rfc7107>.
[RFC7107] Housley、R。、「S / MIMEメールセキュリティワーキンググループのオブジェクトIDレジストリ」、RFC 7107、DOI 10.17487 / RFC7107、2014年1月、<https://www.rfc-editor.org/info/rfc7107 >。
[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, <https://www.rfc-editor.org/info/rfc7766>.
[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, <https://www.rfc-editor.org/info/rfc7766>.
[RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", RFC 8071, DOI 10.17487/RFC8071, February 2017, <https://www.rfc-editor.org/info/rfc8071>.
[RFC8071] Watsen、K。、「NETCONF Call Home and RESTCONF Call Home」、RFC 8071、DOI 10.17487 / RFC8071、2017年2月、<https://www.rfc-editor.org/info/rfc8071>。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259] Bray、T。、編、「JavaScript Object Notation（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https://www.rfc-editor.org / info / rfc8259>。
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.
[RFC8340] Bjorklund、M。およびL. Berger、編、「YANGツリー図」、BCP 215、RFC 8340、DOI 10.17487 / RFC8340、2018年3月、<https://www.rfc-editor.org/info/ rfc8340>。
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.
[RFC8341] Bierman、A。およびM. Bjorklund、「Network Configuration Access Control Model」、STD 91、RFC 8341、DOI 10.17487 / RFC8341、2018年3月、<https://www.rfc-editor.org/info/rfc8341 >。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] Rescorla、E。、「The Transport Layer Security（TLS）Protocol Version 1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。
[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-CRYPTO-TYPES] Watsen、K。、およびH. Wang、「暗号化のための一般的なYANGデータタイプ」、Work in Progress、draft-ietf-netconf-crypto-types-05、2019年3月。
[YANG-TRUST-ANCHORS] Watsen, K., "YANG Data Model for Global Trust Anchors", Work in Progress, draft-ietf-netconf-trust-anchors-03, March 2019.
[YANG-TRUST-ANCHORS] Watsen、K。、「YANG Data Model for Global Trust Anchors」、Work in Progress、draft-ietf-netconf-trust-anchors-03、2019年3月。
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.
このセクションでは、SZTPブートストラップの構成と、デバイスのブートストラップロジックで使用されるパラメーターの検出を可能にする非規範的なデータモデルを定義します。
The following tree diagram provides an overview for the SZTP device data model.
次のツリー図は、SZTPデバイスデータモデルの概要を示しています。
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.
上の図では、構成可能なノードが1つしかありません。「有効」です。このノードは、デバイスの工場出荷時のデフォルト構成で「true」に設定され、SZTPブートストラップが必要になると「false」に設定されるか削除されることが予想されます。
Following is an instance example for this data model.
以下は、このデータモデルのインスタンスの例です。
<sztp xmlns="https://example.com/sztp-device-data-model">
<enabled>true</enabled>
<idevid-certificate>base64encodedvalue==</idevid-certificate>
<bootstrap-servers>
<bootstrap-server>
<address>sztp1.example.com</address>
<port>8443</port>
</bootstrap-server>
<bootstrap-server>
<address>sztp2.example.com</address>
<port>8443</port>
</bootstrap-server>
<bootstrap-server>
<address>sztp3.example.com</address>
<port>8443</port>
</bootstrap-server>
</bootstrap-servers>
<bootstrap-server-trust-anchors>
<reference>manufacturers-root-ca-certs</reference>
</bootstrap-server-trust-anchors>
<voucher-trust-anchors>
<reference>manufacturers-root-ca-certs</reference>
</voucher-trust-anchors>
</sztp>
The device model is defined by the YANG module defined in this section.
デバイスモデルは、このセクションで定義されているYANGモジュールによって定義されます。
This module references [Std-802.1AR] and uses data types defined in [RFC6991], [YANG-CRYPTO-TYPES], and [YANG-TRUST-ANCHORS].
このモジュールは[Std-802.1AR]を参照し、[RFC6991]、[YANG-CRYPTO-TYPES]、および[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 {
import ietf-crypto-types {
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";
「Example Corporation」の組織。
contact
"Author: Bootstrap Admin <mailto:admin@example.com>";
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.";
説明「このモジュールは、SZTPブートストラップを有効にし、使用されるパラメーターを検出するためのデータモデルを定義します。このモジュールは、他のクライアント証明書ではなく、IDevID証明書の使用、またはHTTPベースのクライアント認証スキームの使用を想定しています。」 ;
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.";
}
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;
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.";
}
}
}
}
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.
1. 上記の「HTTPS」を二重引用符で囲んで示すように、デバイスはブートストラップサーバーへの信頼できない接続を開始します。それはまだHTTPS接続ですが、デバイスはブートストラップサーバーのTLS証明書を認証できません。デバイスはブートストラップサーバーを信頼できないため、「get-bootstrapping-data」RPCで「signed-data-preferred」入力パラメーターを送信し、オプションで「nonce」入力パラメーターも送信します。 「signed-data-preferred」パラメーターは、デバイスがそれを信頼せず、サーバーからの追加の入力パラメーター（他の入力パラメーター、進行状況レポートなど）を保持していない可能性があることをブートストラップサーバーに通知します。 「nonce」入力パラメーターを使用すると、ブートストラップサーバーは、製造元の承認された署名機関（MASA）から所有権バウチャーを動的に取得できます。これは、信頼できるクロックを持たないデバイスにとって重要な場合があります。
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.
2. ブートストラップサーバーは、「signed-data-preferred」入力パラメーターを確認すると、未署名のリダイレクト情報または任意のタイプの署名付きデータのいずれかを送信できることを認識しています。ただし、この場合、ブートストラップサーバーはデータに署名する機能を備えており、期待どおりに署名されたオンボーディング情報ではなく、署名されたリダイレクト情報で応答することを選択し、デバイスを安全に再度リダイレクトします。表示されませんが、「nonce」入力パラメーターが渡された場合、ブートストラップサーバーはMASAに動的に接続し、nonce値を含むバウチャーをダウンロードできます。この統合を可能にするプロトコルに関する詳細は、このドキュメントの範囲外です。
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).
3. 署名されたリダイレクト情報を検証すると、デバイスはブートストラップサーバーへの安全な接続を確立します。デバイスに認識されていないため、以前に接続されたブートストラップサーバーと同じですが、今回はデバイスがブートストラップサーバーを認証できるため、通常の「get-bootstrapping-data」リクエストを送信します（つまり、追加の入力パラメーターを使用） ）およびその進行状況レポート（図には示されていません）。
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.
4. 今回は、「signed-data-preferred」パラメーターが渡されなかったため、デバイスのすべての入力パラメーターにアクセスできるため、ブートストラップサーバーは、この例では、署名されていないオンボーディング情報をデバイスに返します。また、ブートストラップサーバーが信頼されているため、デバイスは進行状況レポートをサーバーに送信します。
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.
このドキュメントで紹介するソリューションは、このセクションで説明する非規範的なワークフローで構成されるように概念化されています。実装の詳細は異なると予想されます。各図の後に、図に示されているステップの詳細な説明が続き、実装がどのように変化するかについてさらに説明します。
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.
次の図は、見込み所有者が製造元のSZTPプログラムに登録してから、見込み所有者が発注したデバイスを製造元が出荷するまでの主要なやり取りを示しています。
+-----------+
+------------+ |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:
1. 製造元のデバイスの見込み所有者は、製造元との登録プロセスを開始します。このプロセスには以下が含まれます。
* 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 so that the NMS can authenticate the IDevID certificates when they are presented to subsequent steps.
*見込み所有者がデバイスをブートストラップする方法に関係なく、IDevID証明書のトラストアンカー証明書は常に製造元から取得します。この証明書は見込み所有者のNMSにインストールされるため、NMSはIDevID証明書を後続のステップに提示するときに認証できるようになります。
* 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.
* 製造元がセクション4.4で説明されているようなインターネットベースのブートストラップサーバー（リダイレクトサーバーなど）をホストしている場合、ブートストラップサーバーの構成に必要な資格情報が見込み所有者に提供されます。ブートストラップサーバーがAPI（このドキュメントの範囲外）を介して構成可能である場合、NMSが後で製造元がホストするブートストラップサーバーを直接構成できるように、資格情報が見込み所有者のNMSにインストールされる可能性があります。
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.
2. 製造元のデバイスが署名済みデータを検証できる場合（セクション5.4）、所有者候補のNMSがブートストラップデータ自体を準備して署名できると想定すると、所有者候補のNMSは、製造元のブートストラップサーバーにトラストアンカー証明書を設定します。前のステップで提供された資格情報。この証明書は、将来の所有者が製造業者が生成する所有権バウチャーに入れて、デバイスが所有者の所有者証明書を信頼できるようにするトラストアンカー証明書です。このトラストアンカー証明書を使用して、デバイスが署名済みのブートストラップデータを検証できるようにする方法については、セクション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.
3. しばらくして、見込み所有者が製造業者に注文を出します。おそらく、SZTPの処理について特別なフラグがチェックされています。この時点で、またはおそらく注文する前に、所有者はNMSでデバイスをモデル化し、実際のデバイスの関連付けがないデバイス用の仮想オブジェクトを作成できます。たとえば、モデルを使用して、ネットワーク内のデバイスの場所と、完全に動作しているときに必要な構成をシミュレートできます。
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.
4. 製造元が注文を満たし、デバイスを目的の場所に配送するときに、デバイスのシリアル番号と配送先を所有者に通知します。所有者は、デバイスの電源投入時にネットワークをステージングするために使用できます。さらに、製造元は1つ以上の所有権バウチャーを送信し、それらのデバイスの所有権を所有者に暗号で割り当てることができます。所有者はNMSにこの情報を設定し、おそらく特定のモデル化されたデバイスをシリアル番号と所有権バウチャーにバインドします。
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 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.
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 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.
2. 展開固有のブートストラップサーバーを使用する場合は、特定のデバイスのブートストラップデータを提供するように構成する必要があります。ブートストラップサーバーの構成は、このドキュメントで定義されていないプログラムAPIを介して行われる場合があります。ここでは外部コンポーネントとして示していますが、ブートストラップサーバーはNMS自体の内部コンポーネントとして実装できます。
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.
3. 製造元がホストするブートストラップサーバーを使用する場合は、特定のデバイスのブートストラップデータを提供するように構成する必要があります。構成は、リダイレクトまたはオンボーディング情報である必要があります。つまり、製造元がホストするブートストラップサーバーは、デバイスを別のブートストラップサーバーにリダイレクトするか、デバイスにオンボーディング情報自体を提供します。製造元がホストするブートストラップサーバーがサポートするブートストラップデータのタイプは、実装によって異なる場合があります。実装によっては、リダイレクト情報またはオンボーディング情報のみをサポートする場合と、リダイレクト情報とオンボーディング情報の両方をサポートする場合があります。ブートストラップサーバーの構成は、このドキュメントで定義されていないプログラムAPIを介して行われる場合があります。
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.
4. DNSサーバーを使用してブートストラップデータを提供する場合は、DNSサーバーを構成する必要があります。マルチキャストDNSが必要な場合、DNSサーバーはローカルネットワーク上に存在する必要があります。そうしないと、DNSサーバーがリモートネットワーク上に存在する可能性があります。 DNSサーバーの構成方法の詳細については、セクション4.2を参照してください。 DNSサーバーの構成は、このドキュメントで定義されていないプログラムAPIを介して行われる場合があります。
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.
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.
6. リムーバブルストレージデバイス（USBフラッシュドライブなど）を使用してブートストラップデータを提供する場合は、データをそのデバイスに配置する必要があります。リムーバブルストレージデバイスを構成する方法の詳細については、セクション4.1を参照してください。
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 bootstrapping is not configured, then the bootstrapping logic exits and none of the following interactions occur.
1.電源が投入されると、デバイスはSZTPブートストラップが構成されているかどうかを確認します。たとえば、「工場出荷時のデフォルト」構成を実行している場合などです。 SZTPブートストラップが構成されていない場合、ブートストラップロジックは終了し、以下の相互作用は発生しません。
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.
2. デバイスがサポートするブートストラップデータのソースごとに、できればデバイスに近い順に（たとえば、インターネットベースのサーバーより前のリムーバブルストレージ）、デバイスはそこにブートストラップデータがあるかどうかを確認します。
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.
3. オンボーディング情報が見つかった場合、デバイスはそれ自体を初期化します（たとえば、ブートイメージをインストールして初期構成をコミットします）。ソースがブートストラップサーバーであり、ブートストラップサーバーが信頼できる場合（TLSレベルの認証など）、デバイスは進行状況レポートもブートストラップサーバーに送信します。
* 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).
* 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.
* ブートストラップサーバーが外部システムへのデバイス進行レポートの転送をサポートしている場合（たとえば、Webhookを介して）、「ブートストラップ完了」進行レポート（セクション7.3）は、外部システムに、たとえば、端末。このシナリオをさらにサポートするために、「ブートストラップ完了」の進行状況レポートは、デバイスのSSHホストキーやTLS証明書をリレーすることもできます。外部システムは、デバイスへの後続の接続を認証するために使用できます。
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.
4. それ以外の場合、リダイレクト情報が見つかると、デバイスは指定されたブートストラップサーバーのリストを反復処理し、ブートストラップサーバーにデバイスのブートストラップデータがあるかどうかを確認します。ブートストラップサーバーがより多くのリダイレクト情報を返す場合、デバイスはそれを再帰的に処理します。それ以外の場合、ブートストラップサーバーがオンボーディング情報を返すと、デバイスは上記の（3）で提供された説明に従って処理します。
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, 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.
5.サポートされているブートストラップデータのすべてのソースを試した後、デバイスはすべてのソースを再試行するか、手動構成（CLI、HTTP、NETCONFなど）の管理インターフェイスを提供します。手動構成が許可されていて、そのような構成が提供されている場合は、ブートストラップの必要がなくなるため、構成でSZTPブートストラップサービスも無効にする必要があります。
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.
リストおよびホールでの活発なディスカッション（姓順）について、著者は次のことを感謝します。MichaelBehringer、Martin Bjorklund、Dean Bogdanovic、Joe Clarke、Dave Crocker、Toerless Eckert、Stephen Farrell、Stephen Hanna、Wes Hardaker 、デビッド・ハリントン、ベンジャミン・カドゥック、ラデック・クレイチ、スレシュ・クリシュナン、ミルハ・キュールウィンド、デビッド・マンデルバーグ、アレクセイ・メルニコフ、ラス・マンディ、レイナルド・ペンノ、ランディ・プレスーン、マックス・プリティキン、マイケル・リチャードソン、アダム・ローチ、ユルゲン・シェーンヴェルダー、フィル・シェイファー。
Special thanks goes to Steve Hanna, Russ Mundy, and Wes Hardaker for brainstorming the original solution during the IETF 87 meeting in Berlin.
ベルリンで開催されたIETF 87会議で元のソリューションについてブレインストーミングを行ってくれたSteve Hanna、Russ Mundy、およびWes Hardakerに特に感謝します。
Authors' Addresses
著者のアドレス
Kent Watsen Watsen Networks
Kent Watsen Watsen Networks
Email: kent+ietf@watsen.net
Ian Farrer Deutsche Telekom AG
Ian Farrer Deutsche Telekom AG
Email: ian.farrer@telekom.de
Mikael Abrahamsson T-Systems
ミカエルアブラハムソンTシステム
Email: mikael.abrahamsson@t-systems.se