Internet Research Task Force (IRTF) S. Symington
Request for Comments: 6257 The MITRE Corporation
Category: Experimental S. Farrell
ISSN: 2070-1721 Trinity College Dublin
H. Weiss
P. Lovell
SPARTA, Inc.
May 2011
Bundle Security Protocol Specification
Abstract
抽象
This document defines the bundle security protocol, which provides data integrity and confidentiality services for the Bundle Protocol. Separate capabilities are provided to protect the bundle payload and additional data that may be included within the bundle. We also describe various security considerations including some policy options.
この文書では、バンドルプロトコルのためのデータの整合性と機密性サービスを提供し、バンドルセキュリティプロトコルを定義します。別々の機能がバンドルペイロードとバンドル内に含めることができる追加データを保護するために設けられています。我々はまた、いくつかの政策オプションを含むさまざまなセキュリティ上の考慮事項について説明します。
This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised.
この文書では、遅延耐性ネットワーク研究グループの製品であり、そのグループによって検討されています。 RFCとしての公表に異議を提起しませんでした。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Delay-Tolerant Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。この文書はインターネットResearch Task Force（IRTF）の製品です。 IRTFはインターネット関連の研究開発活動の成果を公表しています。これらの結果は、展開に適していない可能性があります。このRFCはインターネットリサーチタスクフォースの遅延耐性ネットワーク研究グループ（IRTF）のコンセンサスを表しています。 IRSGによって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6257.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6257で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Related Documents ..........................................4
1.2. Terminology ................................................5
2. Security Blocks .................................................8
2.1. Abstract Security Block ....................................9
2.2. Bundle Authentication Block ...............................13
2.3. Payload Integrity Block ...................................15
2.4. Payload Confidentiality Block .............................16
2.5. Extension Security Block ..................................20
2.6. Parameters and Result Fields ..............................21
2.7. Key Transport .............................................23
2.8. PIB and PCB Combinations ..................................24
3. Security Processing ............................................25
3.1. Nodes as Policy Enforcement Points ........................26
3.2. Processing Order of Security Blocks .......................26
3.3. Security Regions ..........................................29
3.4. Canonicalization of Bundles ...............................31
3.5. Endpoint ID Confidentiality ...............................37
3.6. Bundles Received from Other Nodes .........................38
3.7. The At-Most-Once-Delivery Option ..........................39
3.8. Bundle Fragmentation and Reassembly .......................40
3.9. Reactive Fragmentation ....................................41
3.10. Attack Model .............................................42
4. Mandatory Ciphersuites .........................................42
4.1. BAB-HMAC ..................................................42
4.2. PIB-RSA-SHA256 ............................................43
4.3. PCB-RSA-AES128-PAYLOAD-PIB-PCB ............................44
4.4. ESB-RSA-AES128-EXT ........................................48
5. Key Management .................................................51
6. Default Security Policy ........................................51
7. Security Considerations ........................................53
8. Conformance ....................................................55
9. IANA Considerations ............................................56
9.1. Bundle Block Types ........................................56
9.2. Ciphersuite Numbers .......................................56
9.3. Ciphersuite Flags .........................................56
9.4. Parameters and Results ....................................57
10. References ....................................................58
10.1. Normative References .....................................58
10.2. Informative References ...................................59
This document defines security features for the Bundle Protocol [DTNBP] intended for use in delay-tolerant networks, in order to provide Delay-Tolerant Networking (DTN) security services.
この文書では、遅延耐性ネットワーク（DTN）セキュリティサービスを提供するために、遅延トレラント・ネットワークでの使用を目的とバンドルプロトコル[DTNBP]のためのセキュリティ機能を定義します。
The Bundle Protocol is used in DTNs that overlay multiple networks, some of which may be challenged by limitations such as intermittent and possibly unpredictable loss of connectivity, long or variable delay, asymmetric data rates, and high error rates. The purpose of the Bundle Protocol is to support interoperability across such stressed networks. The Bundle Protocol is layered on top of underlay-network-specific convergence layers, on top of network-specific lower layers, to enable an application in one network to communicate with an application in another network, both of which are spanned by the DTN.
バンドルプロトコルは、接続の断続及び恐らくは予測不可能な損失、長い又は可変遅延、非対称データ転送速度、および高いエラー率などの制限により、挑戦することができるいくつかは複数のネットワークをオーバーレイDTNsに使用されます。バンドル議定書の目的は、そのようなストレスを受けたネットワーク間での相互運用性をサポートすることです。バンドルプロトコルはDTNによって張られる両方とも別のネットワーク内のアプリケーションと通信するために、1つのネットワーク内のアプリケーションを可能にするために、ネットワーク固有の下位層の上に、アンダーレイ・ネットワーク固有の収束層の上に積層されています。
Security will be important for the Bundle Protocol. The stressed environment of the underlying networks over which the Bundle Protocol will operate makes it important for the DTN to be protected from unauthorized use, and this stressed environment poses unique challenges for the mechanisms needed to secure the Bundle Protocol. Furthermore, DTNs may very likely be deployed in environments where a portion of the network might become compromised, posing the usual security challenges related to confidentiality, integrity, and availability.
セキュリティがバンドル議定書のために重要となります。バンドルプロトコルが動作する上で基盤となるネットワークの強調環境は、それが重要なDTNは、不正使用から保護されるようになり、これを強調した環境は、バンドルプロトコルを確保するために必要なメカニズムのための固有の課題を提起します。さらに、DTNsは非常に可能性の高いネットワークの一部は機密性、完全性、可用性に関連する一般的なセキュリティ上の課題を装った、危険にさらされるようになるかもしれない環境に展開することができます。
Different security processing applies to the payload and extension blocks that may accompany it in a bundle, and different rules apply to various extension blocks.
異なるセキュリティ処理は、バンドルでそれを伴うことペイロードと拡張ブロックに適用され、異なるルールは、さまざまな拡張ブロックに適用されます。
This document describes both the base Bundle Security Protocol (BSP) and a set of mandatory ciphersuites. A ciphersuite is a specific collection of various cryptographic algorithms and implementation rules that are used together to provide certain security services.
このドキュメントでは、基本バンドルセキュリティプロトコル（BSP）と必須の暗号スイートのセットの両方を説明しています。暗号スイートは、特定のセキュリティサービスを提供するために一緒に使用される様々な暗号化アルゴリズムと実装ルールの具体的なコレクションです。
The Bundle Security Protocol applies, by definition, only to those nodes that implement it, known as "security-aware" nodes. There MAY be other nodes in the DTN that do not implement BSP. All nodes can interoperate with the exception that BSP security operations can only happen at security-aware nodes.
バンドルセキュリティプロトコルは、「セキュリティ対応」ノードとして知られている、唯一それを実装するノードに、定義によって、適用されます。 BSPを実装していないDTN内の他のノードがある可能性があります。すべてのノードは、BSPのセキュリティ操作のみがセキュリティ対応のノードで発生する可能性がありますことを除いて、相互運用することができます。
This document is best read and understood within the context of the following other DTN documents:
この文書では、最高の読み、以下の他のDTN文書の文脈の中で理解されています。
"Delay-Tolerant Networking Architecture" [DTNarch] defines the architecture for delay-tolerant networks, but does not discuss security at any length.
「遅延耐性ネットワークアーキテクチャ」[DTNarch]は、遅延トレラント・ネットワークのためのアーキテクチャを定義しますが、任意の長さでのセキュリティについては説明しません。
The DTN Bundle Protocol [DTNBP] defines the format and processing of the blocks used to implement the Bundle Protocol, excluding the security-specific blocks defined here.
DTNバンドルプロトコル[DTNBP]ここで定義されたセキュリティ特定のブロックを除く、バンドルプロトコルを実装するために使用されるブロックのフォーマット処理を定義します。
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 [RFC2119].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "推奨NOT"、および「OPTIONAL 「本書では[RFC2119]で説明されるように解釈されるべきです。
We introduce the following terminology for purposes of clarity:
私たちは、明確にする目的のために以下の用語を紹介します：
source - the bundle node from which a bundle originates
ソース - バンドルの発信元からバンドルノード
destination - the bundle node to which a bundle is ultimately destined
先 - 束が最終的に宛先とされたバンドルノード
forwarder - the bundle node that forwarded the bundle on its most recent hop
フォワーダ - その最も最近のホップにバンドルを転送バンドルノード
intermediate receiver or "next hop" - the neighboring bundle node to which a forwarder forwards a bundle.
中間レシーバまたは「次のホップ」 - 転送フォワーダ束に隣接バンドルノード。
path - the ordered sequence of nodes through which a bundle passes on its way from source to destination
パス - バンドルは、ソースから宛先への途中で通過するノードの順序付けられたシーケンス
In the figure below, which is adapted from figure 1 in the Bundle Protocol Specification [DTNBP], four bundle nodes (denoted BN1, BN2, BN3, and BN4) reside above some transport layer(s). Three distinct transport and network protocols (denoted T1/N1, T2/N2, and T3/N3) are also shown.
バンドルプロトコル仕様[DTNBP]の図1から適応される以下の図には、4つのバンドルノード（BN1、BN2、BN3、BN4とを表記）は、いくつかのトランスポート層（複数可）上に常駐します。三つの異なるトランスポート及びネットワークプロトコル（示さT1 / N1、T2 / N2およびT3 / N3）も示されています。
+---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+
| BN1 v | | ^ BN2 v | | ^ BN3 v | | ^ BN4 |
+---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+
| T1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ T3 |
+---------v-+ +-^---------v-+ +-^---------v + +-^---------+
| N1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ N3 |
+---------v-+ +-^---------v + +-^---------v-+ +-^---------+
| >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ |
+-----------+ +------------+ +-------------+ +-----------+
| | | |
|<-- An Internet --->| |<--- An Internet --->|
| | | |
BN = "Bundle Node" as defined in the Bundle Protocol Specification
BN =「バンドルノード」バンドルプロトコル仕様で定義されています
Figure 1: Bundle Nodes Sit at the Application Layer
of the Internet Model
Bundle node BN1 originates a bundle that it forwards to BN2. BN2 forwards the bundle to BN3, and BN3 forwards the bundle to BN4. BN1 is the source of the bundle and BN4 is the destination of the bundle. BN1 is the first forwarder, and BN2 is the first intermediate receiver; BN2 then becomes the forwarder, and BN3 the intermediate receiver; BN3 then becomes the last forwarder, and BN4 the last intermediate receiver, as well as the destination.
バンドルノードBN1は、それがBN2に転送することをバンドルを発信します。 BN2はBN3にバンドルを転送し、BN3はBN4にバンドルを転送します。 BN1は、バンドルの源であり、BN4は、バンドルの宛先です。 BN1は最初フォワーダであり、BN2は、第一中間受信機です。 BN2は、その後、フォワーダ、およびBN3中間レシーバなります。 BN3は最後フォワーダ、およびBN4最後の中間受信機、並びに先となります。
If node BN2 originates a bundle (for example, a bundle status report or a custodial signal), which is then forwarded on to BN3, and then to BN4, then BN2 is the source of the bundle (as well as being the first forwarder of the bundle) and BN4 is the destination of the bundle (as well as being the final intermediate receiver).
ノードBN2がBN4に次いでBN3に転送されるバンドル（例えば、バンドルステータスレポートまたは保管信号）を、発信、および場合、BN2、バンドルの供給源である（同様の最初のフォワーダでありますバンドル）とBN4バンドル（ならびに最終的な中間体受信機である）の宛先です。
We introduce the following security-specific DTN terminology:
私たちは、次のセキュリティ固有のDTNの用語を紹介します：
security-source - a bundle node that adds a security block to a bundle
セキュリティ・ソース - バンドルにセキュリティブロックを追加し、バンドルノード
security-destination - a bundle node that processes a security block of a bundle
セキュリティ先 - バンドルのセキュリティブロックを処理バンドルノード
security path - the ordered sequence of security-aware nodes through which a bundle passes on its way from the security-source to the security-destination
セキュリティパス - バンドルはセキュリティ先にセキュリティ・ソースから、その途中に通過するセキュリティ対応ノードの順序付けられたシーケンス
Referring to Figure 1 again:
再び図1を参照します。
If the bundle that originates at BN1 is given a security block by BN1, then BN1 is the security-source of this bundle with respect to that security block, as well as being the source of the bundle.
BN1で発生束はBN1によってセキュリティブロックが与えられる場合、BN1は、セキュリティブロックに対して、ならびに束の源であるとこのバンドルのセキュリティ・ソースです。
If the bundle that originates at BN1 is given a security block by BN2, then BN2 is the security-source of this bundle with respect to that security block, even though BN1 is the source.
BN1で発生束はBN2によりセキュリティブロックが与えられた場合、BN2はBN1はソースであっても、そのセキュリティブロックに対するこのバンドルのセキュリティ・ソースです。
If the bundle that originates at BN1 is given a security block by BN1 that is intended to be processed by BN3, then BN1 is the security-source and BN3 is the security-destination with respect to this security block. The security path for this block is BN1 to BN3.
BN1で発生束はBN3によって処理されることが意図されるBN1によってセキュリティブロックが与えられる場合、BN1は、セキュリティソースであり、BN3、このセキュリティブロックに対するセキュリティ先です。このブロックのセキュリティパスはBN3にBN1です。
A bundle MAY have multiple security blocks. The security-source of a bundle, with respect to a given security block in the bundle, MAY be the same as or different from the security-source of the bundle with respect to a different security block in the bundle. Similarly, the security-destination of a bundle, with respect to each of that bundle's security blocks, MAY be the same or different. Therefore, the security paths for various blocks MAY be, and often will be, different.
バンドルには、複数のセキュリティ・ブロックを持っているかもしれません。バンドルのセキュリティ・ソースは、バンドル内の特定のセキュリティブロックに対して、バンドル内の異なるセキュリティ・ブロックに対する束のセキュリティ・ソースと同じでも異なっていてもよいです。同様に、バンドルのセキュリティ先は、そのバンドルのセキュリティ・ブロックのそれぞれに対して、同一または異なっていてもよいです。そのため、様々なブロックのセキュリティパスがあってもよく、多くの場合、異なるものになります。
If the bundle that originates at BN1 is given a security block by BN1 that is intended to be processed by BN3, and BN2 adds a security block with security-destination BN4, the security paths for the two blocks overlap but not completely. This problem is discussed further in Section 3.3.
BN1で発生束はBN3によって処理されることが意図されるBN1によってセキュリティブロックを与えられ、BN2セキュリティ先BN4とセキュリティブロックを追加した場合、二つのブロックのセキュリティパスはなく、完全に重なります。この問題は、3.3節で詳しく説明されています。
As required in [DTNBP], forwarding nodes MUST transmit blocks in a bundle in the same order in which they were received. This requirement applies to all DTN nodes, not just ones that implement security processing. Blocks in a bundle MAY be added or deleted according to the applicable specification, but those blocks that are both received and transmitted MUST be transmitted in the same order that they were received.
【DTNBP]で必要に応じて、転送ノードは、それらが受信されたと同じ順序で、バンドル内のブロックを送信しなければなりません。この要件は、すべてのDTNノード、セキュリティ処理を実装していないものだけに適用されます。バンドル内のブロックを追加または削除該当仕様に従って、両方の受信および送信されるそれらのブロックは、それらが受信されたのと同じ順序で送信されなければならないかもしれません。
If a node is not security-aware, then it forwards the security blocks in the bundle unchanged unless the bundle's block processing flags specify otherwise. If a network has some nodes that are not security-aware, then the block processing flags SHOULD be set such that security blocks are not discarded at those nodes solely because they cannot be processed there. Except for this, the non-security-aware nodes are transparent relay points and are invisible as far as security processing is concerned.
ノードは、セキュリティを意識していない場合は、バンドルのブロック処理フラグが特に指定しない限り、それは変わらず、バンドル内のセキュリティブロックを転送します。ネットワークがセキュリティを意識していないいくつかのノードがある場合、ブロック処理フラグは、彼らがそこに処理することができないため、セキュリティ・ブロックは、単にそれらのノードで廃棄されないように設定されるべきです。これ以外、非セキュリティ対応ノードは、透明中継点であり、限りセキュリティ処理に関しては見えません。
The block sequence also indicates the order in which certain significant actions have affected the bundle, and therefore the sequence in which actions MUST occur in order to produce the bundle at its destination.
ブロック配列はまた、特定の重要なアクションが束に影響を与え、従ってアクションがその宛先にバンドルを生成するために発生しなければならない順序た順序を示しています。
There are four types of security blocks that MAY be included in a bundle. These are the Bundle Authentication Block (BAB), the Payload Integrity Block (PIB), the Payload Confidentiality Block (PCB), and the Extension Security Block (ESB).
バンドルに含まれるかもしれませセキュリティ・ブロックの4つのタイプがあります。これらは、バンドル認証ブロック（BAB）、ペイロード整合性ブロック（PIB）、ペイロードの機密性ブロック（PCB）、および拡張セキュリティブロック（ESB）です。
The BAB is used to ensure the authenticity and integrity of the bundle along a single hop from forwarder to intermediate receiver. Since security blocks are only processed at security-aware nodes, a "single hop" from a security-aware forwarder to the next security-aware intermediate receiver might be more than one actual hop. This situation is discussed further in Section 2.2.
BABはフォワーダから中間受信機への単一のホップに沿った束の真正性および完全性を保証するために使用されます。セキュリティブロックのみセキュリティ対応ノードで処理されているので、次のセキュリティ対応の中間レシーバにセキュリティ対応フォワーダから「単一ホップ」は、複数の実際のホップであるかもしれません。この状況は、2.2節で詳しく説明されています。
The PIB is used to ensure the authenticity and integrity of the payload from the PIB security-source, which creates the PIB, to the PIB security-destination, which verifies the PIB authenticator. The authentication information in the PIB MAY (if the ciphersuite allows) be verified by any node in between the PIB security-source and the PIB security-destination that has access to the cryptographic keys and revocation status information required to do so.
PIBは、PIBオーセンティケータを検証PIBセキュリティ先に、PIBを作成PIBセキュリティ・ソースからペイロードの真正性および完全性を保証するために使用されます。 （暗号スイートが許す場合）PIB内の認証情報は、PIBセキュリティソース及びこれを行うために必要な暗号鍵失効ステータス情報へのアクセスを有するPIBセキュリティ先との間の任意のノードによって検証することができます。
Since a BAB protects a bundle on a "hop-by-hop" basis and other security blocks MAY be protecting over several hops or end-to-end, whenever both are present, the BAB MUST form the "outer" layer of protection -- that is, the BAB MUST always be calculated and added to the bundle after all other security blocks have been calculated and added to the bundle.
BABが「ホップバイホップ」に基づいてバンドルを保護し、他のセキュリティブロックは、いくつかのホップまたはエンド・ツー・エンドの上に保護できるので、両方が存在するときはいつでも、BABは保護の「外側」層を形成しなければなりません - - つまり、BABは常に計算され、他のすべてのセキュリティブロックが計算され、バンドルに追加された後のバンドルに追加する必要があります。
The PCB indicates that the payload has been encrypted, in whole or in part, at the PCB security-source in order to protect the bundle content while in transit to the PCB security-destination.
PCBは、ペイロードは、PCBセキュリティ先に輸送中ながらバンドルコンテンツを保護するためにPCBのセキュリティ・ソースで、全体的または部分的に、暗号化されていることを示しています。
PIB and PCB protect the payload and are regarded as "payload-related" for purposes of the security discussion in this document. Other blocks are regarded as "non-payload" blocks. Of course, the primary block is unique and has separate rules.
PIBとPCBは、ペイロードを保護し、「ペイロード関連」このドキュメントのセキュリティの議論の目的のためにと考えています。他のブロックは、「非ペイロード」ブロックとみなされています。もちろん、主ブロックは一意で、別のルールがあります。
The ESB provides security for non-payload blocks in a bundle. Therefore, ESB is not applied to PIBs or PCBs and, of course, is not appropriate for either the payload block or primary block.
ESBは、バンドル内の非ペイロードブロックのセキュリティを提供します。したがって、ESBは、もちろん、ペイロード・ブロック又は一次のブロックのいずれかのために適切ではない、のPIB又はプリント基板に塗布していません。
Each of the security blocks uses the Canonical Bundle Block Format as defined in the Bundle Protocol Specification. That is, each security block is comprised of the following elements:
バンドルプロトコル仕様で定義されたセキュリティ・ブロックのそれぞれは、標準バンドルブロックフォーマットを使用しています。これは、各セキュリティブロックは、以下の要素で構成されています。
o Block-type code
Oブロック型コード
o Block processing control flags
Oブロック処理制御フラグ
o Block EID-reference list (OPTIONAL)
OブロックEID-参照リスト（オプション）
o Block data length
Oブロックのデータ長
o Block-type-specific data fields
Oブロック型固有のデータ・フィールド
Since the four security blocks have most fields in common, we can shorten the description of the Block-type-specific data fields of each security block if we first define an abstract security block (ASB) and then specify each of the real blocks in terms of the fields that are present/absent in an ASB. Note that no bundle ever contains an actual ASB, which is simply a specification artifact.
4つのセキュリティブロックが共通でほとんどのフィールドを持っているので、我々は最初の抽象セキュリティブロック（ASB）を定義した場合、各セキュリティブロックのブロック型固有のデータ・フィールドの説明を短くし、その後面で本当の各ブロックを指定することができますASBには存在しない/存在するフィールド。何のバンドルが今まで単に仕様のアーティファクトで実際のASBを、含まれていないことに注意してください。
Many of the fields below use the "SDNV" type defined in [DTNBP]. SDNV stands for Self-Delimiting Numeric Value.
以下のフィールドの多くは、[DTNBP]で定義された「SDNV」タイプを使用します。 SDNVは自己区切る数値を表します。
An ASB consists of the following mandatory and optional fields:
ASBは、次の必須およびオプションのフィールドで構成されています。
o Block-type code (one byte) - as in all bundle protocol blocks except the primary bundle block. The block-type codes for the security blocks are:
Oブロックタイプのコード（1バイト） - 一次バンドルブロックを除くすべてのバンドルプロトコルブロックです。セキュリティブロックのブロックタイプのコードは次のとおりです。
BundleAuthenticationBlock - BAB: 0x02
BundleAuthenticationBlock - BAB：0x02の
PayloadIntegrityBlock - PIB: 0x03
PayloadIntegrityBlock - START：0×03
PayloadConfidentialityBlock - PCB: 0x04
PayloadConfidentialityBlock - PCB：0x04を
ExtensionSecurityBlock - ESB: 0x09
ExtensionSecurityBlock - ESB：0x09の
o Block processing control flags (SDNV) - defined as in all bundle protocol blocks except the primary bundle block (as described in the Bundle Protocol Specification [DTNBP]). SDNV encoding is described in the Bundle Protocol. There are no general constraints on the use of the block processing control flags, and some specific requirements are discussed later.
Oブロック処理制御フラグ（SDNV） - （バンドルプロトコル仕様[DTNBP]に記載されているように）一次バンドルブロックを除くすべてのバンドルプロトコルブロックで定義した通り。 SDNV符号化はバンドルプロトコルに記載されています。そこブロック処理制御フラグの使用には一般的な制約はありませんし、いくつかの特定の要件については後述されています。
o EID-references - composite field defined in [DTNBP] containing references to one or two endpoint identifiers (EIDs). Presence of the EID-reference field is indicated by the setting of the "Block contains an EID-reference field" (EID_REF) bit of the block processing control flags. If one or more references are present, flags in the ciphersuite ID field, described below, specify which.
EID-参照O - 一つまたは二つのエンドポイント識別子（のEID）に[DTNBP]を含む参考文献に定義された複合フィールド。 EID-参照フィールドの存在は、ブロック処理制御フラグの「ブロックがEID-参照フィールドを含む」（EID_REF）ビットの設定によって示されています。一つ以上の参照が存在する場合、以下に説明する暗号スイートIDフィールドのフラグは、その指定します。
If no EID fields are present, then the composite field itself MUST be omitted entirely and the EID_REF bit MUST be unset. A count field of zero is not permitted.
何EIDフィールドが存在しない場合は、複合フィールド自体が完全に省略されなければならないとEID_REFビットが未設定でなければなりません。ゼロのカウント・フィールドが許可されていません。
o The possible EIDs are:
O可能性のEIDは、次のとおりです。
* (OPTIONAL) Security-source - specifies the security-source for the block. If this is omitted, then the source of the bundle is assumed to be the security-source unless otherwise indicated.
*（オプション）セキュリティ・ソース - ブロックのためのセキュリティ・ソースを指定します。これが省略されている場合、特に明記しない限り、その後バンドルのソースは、セキュリティ・ソースであると仮定されます。
* (OPTIONAL) Security-destination - specifies the security-destination for the block. If this is omitted, then the destination of the bundle is assumed to be the security-destination unless otherwise indicated.
*（オプション）セキュリティ先 - ブロックのためのセキュリティの宛先を指定します。これが省略された場合、その後、束の先は、特に断らない限りセキュリティ先であると仮定されます。
If two EIDs are present, security-source is first and security-destination comes second.
2つのEIDが存在する場合、セキュリティ・ソースは、第1およびセキュリティ先である第二付属しています。
o Block data length (SDNV) - as in all bundle protocol blocks except the primary bundle block. SDNV encoding is described in the Bundle Protocol.
Oブロックのデータ長（SDNV） - 一次バンドルブロックを除くすべてのバンドルプロトコルブロックです。 SDNV符号化はバンドルプロトコルに記載されています。
o Block-type-specific data fields as follows:
Oブロック型固有のデータ・フィールドを次のように：
* Ciphersuite ID (SDNV)
*たciphersuite ID（SDNV）
* Ciphersuite flags (SDNV)
*たciphersuiteフラグ（SDNV）
* (OPTIONAL) Correlator - when more than one related block is inserted, then this field MUST have the same value in each related block instance. This is encoded as an SDNV. See the note in Section 3.8 with regard to correlator values in bundle fragments.
*（オプション）相関 - 複数の関連するブロックが挿入されたときに、このフィールドは、各関連のブロックインスタンスで同じ値を持たなければなりません。これはSDNVとしてエンコードされます。バンドル断片における相関値に関しては3.8節で注意を参照してください。
* (OPTIONAL) Ciphersuite-parameters - compound field of the next two items
*（オプション）も、Ciphersuiteパラメータ - 次の二つのアイテムの化合フィールド
+ Ciphersuite-parameters length - specifies the length of the following Ciphersuite-parameters data field and is encoded as an SDNV.
+も、Ciphersuiteパラメータの長さ - 以下も、Ciphersuiteパラメータデータフィールドの長さを指定し、SDNVとして符号化されます。
+ Ciphersuite-parameters data - parameters to be used with the ciphersuite in use, e.g., a key identifier or initialization vector (IV). See Section 2.6 for a list of potential parameters and their encoding rules. The particular set of parameters that is included in this field is defined as part of the ciphersuite specification.
+も、Ciphersuiteパラメータデータ - パラメータ使用中暗号の組み合わせで使用される、例えば、キー識別子または初期化ベクトル（IV）。潜在的なパラメータとその符号化規則のリストについては、2.6節を参照してください。このフィールドに含まれるパラメータの特定のセットは、暗号スイート仕様の一部として定義されます。
* (OPTIONAL) Security-result - compound field of the next two items
*（オプション）セキュリティ-結果 - 次の2つの項目の化合物分野
+ Security-result length - contains the length of the next field and is encoded as an SDNV.
+セキュリティ結果の長さは - 次のフィールドの長さを含み、SDNVとして符号化されます。
+ Security-result data - contains the results of the appropriate ciphersuite-specific calculation (e.g., a signature, Message Authentication Code (MAC), or ciphertext block key).
+セキュリティ結果データは、 - 適切な暗号の固有の計算の結果を含む（例えば、署名、メッセージ認証コード（MAC）、または暗号文ブロックキー）。
Although the diagram hints at a 32-bit layout, this is purely for the purpose of exposition. Except for the "type" field, all fields are variable in length.
図は、32ビットのレイアウトを示唆しているが、これは説明の目的のために純粋です。 「タイプ」フィールドを除き、すべてのフィールドの長さは可変です。
+----------------+----------------+----------------+----------------+
| type | flags (SDNV) | EID-ref list(comp) |
+----------------+----------------+----------------+----------------+
| length (SDNV) | ciphersuite (SDNV) |
+----------------+----------------+----------------+----------------+
| ciphersuite flags (SDNV) | correlator (SDNV) |
+----------------+----------------+----------------+----------------+
|params len(SDNV)| ciphersuite params data |
+----------------+----------------+----------------+----------------+
|res-len (SDNV) | security-result data |
+----------------+----------------+----------------+----------------+
Figure 2: Abstract Security Block Structure
図2：抽象セキュリティブロック構造
Some ciphersuites are specified in Section 4, which also specifies the rules that MUST be satisfied by ciphersuite specifications. Additional ciphersuites MAY be defined in separate specifications. Ciphersuite IDs not specified are reserved. Implementations of the Bundle Security Protocol decide which ciphersuites to support, subject to the requirements of Section 4. It is RECOMMENDED that implementations that allow additional ciphersuites permit ciphersuite ID values at least up to and including 127, and they MAY decline to allow larger ID values.
いくつかの暗号スイートは、暗号スイートの仕様が満たさなければならないルールを指定する第4節で指定されています。追加の暗号スイートは、別の仕様で定義されてもよいです。指定されていない暗号スイートIDが予約されています。第4項の要件に従うバンドルセキュリティプロトコルの実装をサポートする暗号スイートかを決める、追加の暗号スイートを許可する実装が127を含む少なくともに、最大暗号スイートIDの値を許可し、彼らはより大きなID値を許可するように断るかもしれないことを推奨します。
The structure of the ciphersuite flags field is shown in Figure 3. In each case, the presence of an optional field is indicated by setting the value of the corresponding flag to one. A value of zero indicates the corresponding optional field is missing. Presently, there are five flags defined for the field; for convenience, these are shown as they would be extracted from a single-byte SDNV. Future additions may cause the field to grow to the left so, as with the flags fields defined in [DTNBP], the description below numbers the bit positions from the right rather than the standard RFC definition, which numbers bits from the left.
暗号スイートフラグフィールドの構造は、任意のフィールドの存在は、1つに対応するフラグの値を設定することによって示され、それぞれの場合において、図3に示されています。ゼロの値は、対応するオプションフィールドが欠落していることを示します。現在、フィールドに定義されている5つのフラグがあります。彼らはシングルバイトSDNVから抽出されるよう便宜のために、これらを示しています。将来の追加フィールドは、左から数ビット数右からビット位置ではなく、標準RFC定義、以下の説明、[DTNBP]で定義されたフラグフィールドと同様なので、左に成長させてもよいです。
src - bit 4 indicates whether the EID-reference field of the ASB contains the optional reference to the security-source.
SRC - ビット4は、ASBのEID-参照フィールドは、セキュリティ・ソースへの任意の参照を含むかどうかを示します。
dest - bit 3 indicates whether the EID-reference field of the ASB contains the optional reference to the security-destination.
DEST - ビット3は、ASBのEID-参照フィールドは、セキュリティ目的地までの任意の参照を含むかどうかを示します。
parm - bit 2 indicates whether or not the ciphersuite-parameters length and ciphersuite-parameters data fields are present.
PARM - ビット2は、暗号のパラメータの長さと暗号スイートパラメータデータフィールドが存在するか否かを示します。
corr - bit 1 indicates whether or not the ASB contains an optional correlator.
CORR - ビット1は、ASBは、オプションの相関器が含まれているか否かを示します。
res - bit 0 indicates whether or not the ASB contains the security-result length and security-result data fields.
RES - ビット0は、ASBがセキュリティ結果の長さとセキュリティ結果データフィールドが含まれているか否かを示します。
bits 5-6 are reserved for future use.
ビット5-6は、将来の使用のために予約されています。
Bit Bit Bit Bit Bit Bit Bit
6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+
| reserved | src |dest |parm |corr |res |
+-----+-----+-----+-----+-----+-----+-----+
Figure 3: Ciphersuite Flags
図3：も、Ciphersuite国旗
A little bit more terminology: if the block is a PIB, when we refer to the PIB-source, we mean the security-source for the PIB as represented by the EID-reference in the EID-reference field. Similarly, we may refer to the "PCB-dest", meaning the security-destination of the PCB, again as represented by an EID reference. For example, referring to Figure 1 again, if the bundle that originates at BN1 is given a Payload Confidentiality Block (PCB) by BN1 that is protected using a key held by BN3, and it is given a Payload Integrity Block (PIB) by BN1, then BN1 is both the PCB-source and the PIB-source of the bundle, and BN3 is the PCB-destination of the bundle.
もう少し用語：ブロックPIBある場合、我々はPIBソースを参照する場合、我々はEID-参照フィールドにおけるEID参照によって表されるようなPIBのセキュリティ・ソースを意味します。 EID参照によって表されるように、同様に、我々は再び、PCBのセキュリティ先を意味する、「PCB-DEST」を指すことができます。 BN1で発生束はBN3によって保持された鍵を使用して保護されているBN1によってペイロード機密性ブロック（PCB）を与えられ、それはBN1によってペイロード整合ブロック（PIB）が与えられた場合、例えば、再び図1を参照すると、その後、BN1はPCB-ソースおよびバンドルのPIB-源でもあり、そしてBN3は、バンドルのPCB-先です。
The correlator field is used to associate several related instances of a security block. This can be used to place a BAB that contains the ciphersuite information at the "front" of a (probably large) bundle, and another correlated BAB that contains the security-result at the "end" of the bundle. This allows even very memory-constrained nodes to be able to process the bundle and verify the BAB. There are similar use cases for multiple related instances of PIB and PCB as will be seen below.
相関フィールドは、セキュリティブロックのいくつかの関連インスタンスを関連付けるために使用されます。これは、（おそらく大）バンドルの「前」の暗号スイートの情報が含まれていBAB、およびバンドルの「終わり」のセキュリティ・結果を含む別の相関BABを配置するために使用することができます。これは、非常にメモリ制約ノードは、バンドルを処理し、BABを検証できるようにすることができます。以下に見られるようPIBおよびPCBの複数の関連インスタンスの同様のユースケースがあります。
The ciphersuite specification MUST make it clear whether or not multiple block instances are allowed, and if so, under what conditions. Some ciphersuites can, of course, leave flexibility to the implementation, whereas others might mandate a fixed number of instances.
暗号スイート仕様では、複数のブロック・インスタンスが許可されているかどうか、それを明確にし、もしそうなら、どのような条件の下でなければなりません。他の人がインスタンスの固定数を義務付ける可能性があるのに対し、いくつかの暗号スイートは、もちろん、実装に柔軟性を残すことができます。
For convenience, we use the term "first block" to refer to the initial block in a group of correlated blocks or to the single block if there are no others in the set. Obviously, there can be several unrelated groups in a bundle, each containing only one block or more than one, and each having its own "first block".
便宜のために、我々は、セットには他の人が存在しない場合、用語「第一のブロックは」相関ブロックのグループまたは単一のブロックへの最初のブロックを参照するために使用します。明らかに、それぞれが一つのブロックまたは複数を含む、それぞれが独自の「最初のブロック」を有する、バンドル内のいくつかの無関係のグループが存在することができます。
In this section, we describe typical BAB field values for two scenarios -- where a single instance of the BAB contains all the information and where two related instances are used, one "up front", which contains the ciphersuite, and another following the payload, which contains the security-result (e.g., a MAC).
このセクションでは、我々は2つのシナリオのための典型的なBABフィールド値を記述する - BABの単一のインスタンスは、暗号スイートを含む2つの関連するインスタンスは、一つの「前もって」に使用されるすべての情報を含み、ペイロード以下の別の場所、セキュリティ結果が含まれている（例えば、MAC）。
For the case where a single BAB is used:
単一BABが使用される場合のために：
The block-type code field value MUST be 0x02.
ブロック型コードフィールドの値が0x02のでなければなりません。
The block processing control flags value can be set to whatever values are required by local policy. Ciphersuite designers should carefully consider the effect of setting flags that either discard the block or delete the bundle in the event that this block cannot be processed.
ブロック処理制御フラグの値がどのような値がローカルポリシーによって要求されるように設定することができます。暗号スイート設計者は慎重にブロックを破棄するか、このブロックは処理できない場合には、バンドルを削除するのいずれかのフラグを設定した場合の効果を検討すべきです。
The ciphersuite ID MUST be documented as a hop-by-hop authentication-ciphersuite that requires one instance of the BAB.
暗号スイートIDはBABの1つのインスタンスを必要とするホップバイホップ認証暗号スイートとして文書化されなければなりません。
The correlator field MUST NOT be present.
相関フィールドが存在してはなりません。
The ciphersuite-parameters field MAY be present, if so specified in the ciphersuite specification.
そう暗号スイート仕様で指定されていれば暗号のパラメータのフィールドは存在してもよいです。
An EID-reference to the security-source MAY be present. The security-source can also be specified as part of key-information described in Section 2.6 or another block such as the Previous-Hop Insertion Block [PHIB]. The security-source might also be inferred from some implementation-specific means such as the convergence layer.
セキュリティ・ソースへのEID-参照が存在してもよいです。セキュリティソースはまた、前のホップ挿入ブロック[PHIB]として2.6節または他のブロックで説明鍵情報の一部として指定することができます。セキュリティソースはまた、収束層として、いくつかの実装特有の手段から推測されるかもしれません。
An EID-reference to the security-destination MAY be present and is useful to ensure that the bundle has been forwarded to the correct next-hop node.
セキュリティ先にEID-参照が存在しても、バンドルが正しい次ホップノードに転送されたことを確認するのに有用であるもしれ。
The security-result MUST be present as it is effectively the "output" from the ciphersuite calculation (e.g., the MAC or signature) applied to the (relevant parts of the) bundle (as specified in the ciphersuite definition).
それが効果的に暗号の計算（例えば、MACまたは署名）から「出力」であるとして、セキュリティ結果が存在しなければならない束（の関連部分）（暗号の定義で指定されている）に適用されます。
For the case using two related BAB instances, the first instance is as defined above, except the ciphersuite ID MUST be documented as a hop-by-hop authentication ciphersuite that requires two instances of the BAB. In addition, the correlator MUST be present and the security-result length and security-result fields MUST be absent. The second instance of the BAB MUST have the same correlator value present and MUST contain security-result length and security-result data fields. The other optional fields MUST NOT be present. Typically, this second instance of a BAB will be the last block of the bundle.
二つの関連BABインスタンスを使用した場合について、最初のインスタンスは、暗号スイートIDがBABの2つのインスタンスを必要とするホップバイホップ認証暗号スイートとして文書化されなければならない以外は、上記で定義した通りです。また、相関が存在しなければならないとセキュリティ結果の長さとセキュリティ結果フィールドは存在してはなりません。 BABの2番目のインスタンスは、本同じ相関値を持っていなければならず、セキュリティ結果の長さとセキュリティ結果データフィールドを含まなければなりません。他の任意のフィールドが存在してはなりません。典型的には、BABのこの第二のインスタンスは、バンドルの最後のブロックです。
The details of key transport for BAB are specified by the particular ciphersuite. In the absence of conflicting requirements, the following should be noted by implementors:
BABのためのキーの輸送の詳細は、特定の暗号スイートによって指定されています。相反する要件がない場合には、次のように実装者に注意すべきです。
o the key-information item in Section 2.6 is OPTIONAL, and if not provided, then the key SHOULD be inferred from the source-destination tuple, being the previous key used, a key created from a key-derivation function, or a pre-shared key.
O 2.6節内のキー情報項目は任意であり、設けられていない場合、キーは使用前のキー、キー導出関数から作成されたキー、又はプレであり、送信元と宛先のタプルから推測されるべきです共有鍵。
o if all the nodes are security-aware, the capabilities of the underlying convergence layer might be useful for identifying the security-source.
すべてのノードがセキュリティを意識している場合は、O、根本的な収束層の機能は、セキュリティ・ソースを同定するために有用であるかもしれません。
o depending upon the key mechanism used, bundles can be signed by the sender, or authenticated for one or more recipients, or both.
使用するキー機構に応じO、バンドルは、送信者によって署名することができ、または1つ以上の受信者、またはその両方に対して認証します。
A PIB is an ASB with the following additional restrictions:
PIBは、以下の追加の制限がASBです。
The block-type code value MUST be 0x03.
ブロックタイプのコード値は、0x03のでなければなりません。
The block processing control flags value can be set to whatever values are required by local policy. Ciphersuite designers should carefully consider the effect of setting flags that either discard the block or delete the bundle in the event that this block cannot be processed.
ブロック処理制御フラグの値がどのような値がローカルポリシーによって要求されるように設定することができます。暗号スイート設計者は慎重にブロックを破棄するか、このブロックは処理できない場合には、バンドルを削除するのいずれかのフラグを設定した場合の効果を検討すべきです。
The ciphersuite ID MUST be documented as an end-to-end authentication-ciphersuite or as an end-to-end error-detection-ciphersuite.
暗号スイートのIDは、エンドツーエンド認証暗号スイートとして、または、エンドツーエンドのエラー検出・暗号スイートとして文書化されなければなりません。
The correlator MUST be present if the ciphersuite requires that more than one related instance of a PIB be present in the bundle. The correlator MUST NOT be present if the ciphersuite only requires one instance of the PIB in the bundle.
暗号スイートは、PIBの複数の関連するインスタンスが、バンドル内に存在する必要がある場合、相関器が存在しなければなりません。暗号スイートのみバンドルにPIBの1つのインスタンスを必要とする場合、相関は存在してはなりません。
The ciphersuite-parameters field MAY be present.
暗号スイート・パラメータのフィールドが存在してもよいです。
An EID-reference to the security-source MAY be present. The security-source can also be specified as part of key-information described in Section 2.6.
セキュリティ・ソースへのEID-参照が存在してもよいです。セキュリティソースも、セクション2.6で説明鍵情報の一部として指定することができます。
An EID-reference to the security-destination MAY be present.
セキュリティ先にEID-参照が存在してもよいです。
The security-result is effectively the "output" from the ciphersuite calculation (e.g., the MAC or signature) applied to the (relevant parts of the) bundle. As in the case of the BAB, this field MUST be present if the correlator is absent. If more than one related instance of the PIB is required, then this is handled in the same way as described for the BAB above.
セキュリティ結果を効果的に暗号の計算（例えば、MACまたは署名）から「出力」とは、バンドル（の関連部分）に適用されます。相関が存在しない場合BABの場合と同様に、このフィールドが存在しなければなりません。 PIBの複数の関連するインスタンスが必要とされる場合、これは上記BABについて記載したのと同じ方法で処理されます。
The ciphersuite MAY process less than the entire original bundle payload. This might be because it is defined to process some subset of the bundle, or perhaps because the current payload is a fragment of an original bundle. For whatever reason, if the ciphersuite processes less than the complete, original bundle payload, the ciphersuite-parameters of this block MUST specify which bytes of the bundle payload are protected.
暗号スイートは、全体の原稿束ペイロード未満を処理することができます。バンドルのサブセットを処理するように定義されているためであるかもしれない、またはおそらく現在のペイロードは、原稿束の断片であるからです。暗号スイートが完了し、原稿束ペイロード未満で処理する場合、何らかの理由で、このブロックの暗号のパラメータは、保護されているバンドルペイロードのバイトを指定しなければなりません。
For some ciphersuites, (e.g., those using asymmetric keying to produce signatures or those using symmetric keying with a group key), the security information can be checked at any hop on the way to the security-destination that has access to the required keying information. This possibility is further discussed in Section 3.6.
いくつかの暗号スイートのために、（例えば、グループ鍵を用いて対称キーを使用して署名を生成するために、非対称キーを使用するものまたはそれら）は、セキュリティ情報が必要なキー情報へのアクセスを有するセキュリティ目的地までの途中の任意のホップで確認することができ。この可能性はさらに、セクション3.6で議論されています。
The use of a generally available key is RECOMMENDED if custodial transfer is employed and all nodes SHOULD verify the bundle before accepting custody.
親権転送が採用されている場合、一般的に利用できるキーの使用が推奨され、すべてのノードが親権を受け入れる前にバンドルを確認する必要があります。
Most asymmetric PIB ciphersuites will use the PIB-source to indicate who the signer is and will not require the PIB-dest field because the key needed to verify the PIB authenticator will be a public key associated with the PIB-source.
ほとんどの非対称PIBの暗号スイートは、署名者が誰であるかを示すために、PIB-ソースを使用し、PIB認証を検証するために必要なキーがPIB-ソースに関連する公開鍵となりますので、PIB-DESTフィールドを必要としません。
A typical confidentiality ciphersuite will encrypt the payload using a randomly generated bundle encrypting key (BEK) and will use a key-information item in the PCB security-parameters to carry the BEK encrypted with some long-term key encryption key (KEK) or well-known public key. If neither the destination nor security-destination resolves the key to use for decryption, the key-information item in the ciphersuite-parameters field can also be used to indicate the decryption key with which the BEK can be recovered. If the bundle already contains PIBs and/or PCBs, these SHOULD also be encrypted using this same BEK, as described just below for "super-encryption". The encrypted block is encapsulated into a new PCB that replaces the original block at the same place in the bundle.
典型的な守秘暗号スイートは、キー（BEK）を暗号化し、ランダムに生成されたバンドルを使用してペイロードを暗号化し、BEKを運ぶためにPCBのセキュリティパラメータにキー情報項目を使用するいくつかの長期的なキー暗号化キー（KEK）で暗号化またはウェル公開鍵-known。先にもセキュリティ先でもないが、復号化に使用するキーを解決する場合は、暗号スイート・パラメータフィールド内のキー情報項目もBEKを回復することが可能な復号鍵を示すために使用することができます。バンドルがすでにのPIBおよび/またはPCBを含まれている場合は、「スーパー暗号化」のためだけに以下に説明するように、これらはまた、これと同じBEKを使用して暗号化する必要があります。暗号化されたブロックは、バンドル内の同じ場所で元のブロックを置き換える新しいPCBにカプセル化されます。
It is strongly RECOMMENDED that a data integrity mechanism be used in conjunction with confidentiality, and that encryption-only ciphersuites NOT be used. AES-Galois/Counter Mode (AES-GCM) satisfies this requirement. The "authentication tag" or "integrity check value" is stored into the security-result rather than being appended to the payload as is common in some protocols since, as described below, it is important that there be no change in the size of the payload.
強く、データの整合性機構は、機密性と組み合わせて使用することをお勧めされ、その暗号化のみの暗号スイートは使用できません。 AES-ガロア/カウンタモード（AES-GCM）この要件を満たしています。 「認証タグ」または「整合性チェック値は、」セキュリティ結果に格納されるのではなく、以下に記載されるように、それの大きさに変化がないことが重要であるので、一部のプロトコルでは一般的であるように、ペイロードに付加されますペイロード。
The payload is encrypted "in-place", that is, following encryption, the payload block payload field contains ciphertext, not plaintext. The payload block processing control flags are unmodified.
ペイロードはつまり、暗号化以下、ペイロードブロックペイロードフィールドは暗号文、平文ではないが含まれ、「その場で」暗号化されています。ペイロードブロック処理制御フラグは未修飾です。
The "in-place" encryption of payload bytes is to allow bundle payload fragmentation and reassembly, and custody transfer, to operate without knowledge of whether or not encryption has occurred and, if so, how many times.
ペイロードバイトの「インプレース」暗号化はかどうか、暗号化の知識がなくても動作するように、バンドルペイロードの断片化と再構築、および管理転送を可能にすることです発生していると、そうであれば、何回。
Fragmentation, reassembly, and custody transfer are adversely affected by a change in size of the payload due to ambiguity about what byte range of the original payload is actually in any particular fragment. Ciphersuites SHOULD place any payload expansion, such as authentication tags (integrity check values) and any padding generated by a block-mode cipher, into an integrity check value item in the security-result field (see Section 2.6) of the confidentiality block.
断片化、再アセンブリ、および管理輸送に悪影響元ペイロードのどのバイト範囲に関する曖昧さに起因するペイロードのサイズの変化によって影響を受ける任意の特定のフラグメントに実際にあります。暗号スイートは、セキュリティ結果フィールドのインテグリティ・チェック値項目に、認証タグなどの任意のペイロード展開、（完全性チェック値）とブロック・モード暗号によって生成されたパディングを置くべき機密性ブロック（セクション2.6を参照）。
Payload super-encryption is allowed, that is, encrypting a payload that has already been encrypted, perhaps more than once. Ciphersuites SHOULD define super-encryption such that, as well as re-encrypting the payload, it also protects the parameters of earlier encryption. Failure to do so may represent a vulnerability in some circumstances.
ペイロードの高度暗号化は、すでにおそらく複数回、暗号化されたペイロードを暗号化する、つまり、許可されています。暗号スイートは、このようなことだけでなく、再暗号化ペイロードの高度暗号化を定義する必要があり、それはまた、以前の暗号化のパラメータを保護します。これを怠ると、いくつかの状況では、脆弱性を表すことができます。
Confidentiality is normally applied to the payload, and possibly to additional blocks. It is RECOMMENDED to apply a Payload Confidentiality ciphersuite to non-payload blocks only if these SHOULD be super-encrypted with the payload. If super-encryption of the block is not desired, then protection of the block SHOULD be done using the Extension Security Block mechanism rather than PCB.
機密性は、通常のペイロードに、そしておそらく追加のブロックに適用されます。これらのペイロードで超暗号化されるべきである場合にのみ、非ペイロードブロックにペイロード機密性暗号スイートを適用することをお勧めします。ブロックのスーパー暗号化が望まれていない場合、ブロックの保護は、拡張セキュリティブロック・メカニズムではなく、PCBを使用して行われるべきです。
Multiple related PCB instances are required if both the payload and PIBs and PCBs in the bundle are to be encrypted. These multiple PCB instances require correlators to associate them with each other since the key-information is provided only in the first PCB.
バンドル内のペイロードとのPIBとPCBの両方が暗号化される場合、複数の関連するPCBのインスタンスが必要とされます。キー情報のみが第1印刷回路基板に設けられているので、これら複数のPCBインスタンスは、互いにそれらを関連付けるために相関器を必要とします。
There are situations where more than one PCB instance is required but the instances are not "related" in the sense that requires correlators. One example is where a payload is encrypted for more than one security-destination so as to be robust in the face of routing uncertainties. In this scenario, the payload is encrypted using a BEK. Several PCBs contain the BEK encrypted using different KEKs, one for each destination. These multiple PCB instances are not "related" and SHOULD NOT contain correlators.
そこに複数のPCBインスタンスが必要とされる状況がありますが、インスタンスは相関器を必要とする意味で「関連」ではありません。ルーティング不確実性の面で堅牢であるように、ペイロードが複数のセキュリティ先のために暗号化される一例です。このシナリオでは、ペイロードはBEKを使用して暗号化されます。いくつかのPCBはBEKが異なるのKEK、宛先ごとに1を使用して暗号化が含まれています。これらの複数のPCBのインスタンスは、「関連」ではないとの相関器を含むべきではありません。
The ciphersuite MAY apply different rules to confidentiality for non-payload blocks.
暗号スイートは、非ペイロードブロックの機密性に異なるルールを適用することができます。
A PCB is an ASB with the following additional restrictions:
PCBは、以下の追加の制限がASBです。
The block-type code value MUST be 0x04.
ブロックタイプのコード値は、0x04のでなければなりません。
The block processing control flags value can be set to whatever values are required by local policy, except that a PCB "first block" MUST have the "replicate in every fragment" flag set. This flag SHOULD NOT be set otherwise. Ciphersuite designers should carefully consider the effect of setting flags that either discard the block or delete the bundle in the event that this block cannot be processed.
ブロック処理制御フラグの値がPCB「最初のブロックは、」「すべての断片内で複製」フラグが設定されなければならないことを除いて、ローカルポリシーによって要求されるどのような値に設定することができます。このフラグは、そうでない場合は設定するべきではありません。暗号スイート設計者は慎重にブロックを破棄するか、このブロックは処理できない場合には、バンドルを削除するのいずれかのフラグを設定した場合の効果を検討すべきです。
The ciphersuite ID MUST be documented as a confidentiality ciphersuite.
暗号スイートのIDは、機密性の暗号スイートとして文書化されなければなりません。
The correlator MUST be present if there is more than one related PCB instance. The correlator MUST NOT be present if there are no related PCB instances.
複数の関連するPCBのインスタンスがある場合、相関が存在しなければなりません。何の関連PCBインスタンスが存在しない場合は相関が存在してはなりません。
If a correlator is present, the key-information MUST be placed in the PCB "first block".
相関が存在する場合、鍵情報がPCB「最初のブロック」に置かなければなりません。
Any additional bytes generated as a result of encryption and/or authentication processing of the payload SHOULD be placed in an "integrity check value" field (see Section 2.6) in the security-result of the first PCB.
暗号化および/またはペイロードの認証処理の結果として生成された任意の追加のバイトが最初のPCBのセキュリティ結果に（セクション2.6を参照）、「整合性チェック値」フィールドに置かれるべきです。
The ciphersuite-parameters field MAY be present.
暗号スイート・パラメータのフィールドが存在してもよいです。
An EID-reference to the security-source MAY be present. The security-source can also be specified as part of key-information described in Section 2.6.
セキュリティ・ソースへのEID-参照が存在してもよいです。セキュリティソースも、セクション2.6で説明鍵情報の一部として指定することができます。
An EID-reference to the security-destination MAY be present.
セキュリティ先にEID-参照が存在してもよいです。
The security-result MAY be present and normally contains fields such as an encrypted bundle encryption key, authentication tag, or the encrypted versions of bundle blocks other than the payload block.
セキュリティ結果が存在し、通常、暗号化されたバンドル暗号鍵、認証タグ、またはペイロードブロック以外の束のブロックの暗号化されたバージョンなどのフィールドが含まれていてもよい（MAY）。
The ciphersuite MAY process less than the entire original bundle payload, either because the current payload is a fragment of the original bundle or just because it is defined to process some subset. For whatever reason, if the ciphersuite processes less than the complete, original bundle payload, the "first" PCB MUST specify, as part of the ciphersuite-parameters, which bytes of the bundle payload are protected.
暗号スイートは、現在のペイロードが原稿束の断片であるのいずれかであるためか、いくつかのサブセットを処理するように定義されているという理由だけで、全体の原稿束ペイロード未満で処理することができます。暗号スイートが完了し、原稿束ペイロード未満で処理する場合、何らかの理由で、「第一」PCBは、保護されているバンドルペイロードのバイト暗号のパラメータの一部として、指定しなければなりません。
PCB ciphersuites MUST specify which blocks are to be encrypted. The specification MAY be flexible and be dependent upon block type, security policy, various data values, and other inputs, but it MUST be deterministic. The determination of whether or not a block is to be encrypted MUST NOT be ambiguous.
PCB暗号スイートは、暗号化されるべきブロックを指定しなければなりません。仕様は、柔軟で、ブロックタイプ、セキュリティポリシー、各種のデータ値、及び他の入力に依存するが、それは決定的でなければなりませんかもしれません。ブロックを暗号化するか否かの判定が曖昧であってはいけません。
As was the case for the BAB and PIB, if the ciphersuite requires more than one instance of the PCB, then the "first block" MUST contain any optional fields (e.g., security-destination, etc.) that apply to all instances with this correlator. These MUST be contained in the first instance and MUST NOT be repeated in other correlated blocks. Fields that are specific to a particular instance of the PCB MAY appear in that PCB. For example, security-result fields MAY (and probably will) be included in multiple related PCB instances, with each result being specific to that particular block. Similarly, several PCBs might each contain a ciphersuite-parameters field with an IV specific to that PCB instance.
BABおよびPIBの場合と同様に暗号スイートは、PCBの複数のインスタンスを必要とする場合、は、「最初のブロックは、」これですべてのインスタンスに適用されるオプションのフィールド（例えば、セキュリティ先、等）を含有しなければなりません相関器。これらは、最初のインスタンスに含まれている必要があり、および他の相関ブロックに繰り返してはいけません。 PCBの特定のインスタンスに固有のフィールドは、PCBに表示されることがあります。例えば、セキュリティ結果フィールドは、（おそらくう）各結果は、その特定のブロックに特定された状態で、複数の関連PCBインスタンスに含まれるかもしれ。同様に、いくつかのPCBはそれぞれそのPCBのインスタンスに固有のIVと暗号のパラメータフィールドを含むかもしれません。
Put another way: when confidentiality will generate multiple blocks, it MUST create a "first" PCB with the required ciphersuite ID, parameters, etc., as specified above. Typically, this PCB will appear early in the bundle. This "first" PCB contains the parameters that apply to the payload and also to the other correlated PCBs. The correlated PCBs follow the "first" PCB and MUST NOT repeat the ciphersuite-parameters, security-source, or security-destination fields from the first PCB. These correlated PCBs need not follow immediately after the "first" PCB, and probably will not do so. Each correlated block, encapsulating an encrypted PIB or PCB, is at the same place in the bundle as the original PIB or PCB.
別の言い方をすれば：機密性は、複数のブロックを生成します時には、上記指定されているように、それは、など必要な暗号スイートID、パラメータ、と「最初」PCBを作成する必要があります。一般的に、このPCBは、初期のバンドルで表示されます。この「最初」PCBは、ペイロードにしても、他の相関のPCBに適用されるパラメータが含まれています。相関PCBは、「最初の」PCBに従うと、最初のPCBからの暗号スイート・パラメータ、セキュリティ・ソース、またはセキュリティ先のフィールドを繰り返してはなりません。これらの相関PCBは、「最初の」PCBの直後に続く必要がなく、おそらくそうではないだろう。各相関ブロックは、暗号化されたPIB又はPCBを封入し、元のPIBやPCBなどのバンドル内の同じ場所にあります。
A ciphersuite MUST NOT mix payload data and a non-payload block in a single PCB.
暗号スイートは、ペイロードデータと、単一のPCB内の非ペイロードブロックを混ぜてはなりません。
Even if a to-be-encrypted block has the "discard" flag set, whether or not the PCB's "discard" flag is set is an implementation/policy decision for the encrypting node. (The "discard" flag is more properly called the "Discard if block can't be processed" flag.)
暗号化されたブロックは、PCBの「廃棄」フラグがセットされているか否かのフラグを「捨てる」のセットを、持っている場合でも、暗号化ノードの実装/政策決定です。 （フラグは、より適切にフラグ「ブロックが処理できない場合は破棄」と呼ばれる「廃棄します」）。
Any existing EID-list in the to-be-encapsulated original block remains exactly as-is, and is copied to become the EID-list for the replacing block. The encapsulation process MUST NOT replace or remove the existing EID-list entries. This is critically important for correct updating of entries at the security-destination.
TO-カプセル化され、元ブロック内の既存のEIDリストはそのまま正確に残り、交換ブロックのEIDリストとなるようにコピーされます。カプセル化プロセスは、交換するか、既存のEID-リストのエントリを削除してはなりません。これは、セキュリティ、先のエントリの正確な更新のために非常に重要です。
At the security-destination, either the specific destination or the bundle-destination, the processes described above are reversed. The payload is decrypted "in-place" using the salt, IV, and key values in the first PCB, including verification using the ICV. These values are described in Section 2.6. Each correlated PCB is also processed at the same destination, using the salt and key values from the first PCB and the block-specific IV item. The encapsulated block item in the security-result is decrypted and validated, using also the tag that SHOULD have been appended to the ciphertext of the original block data. Assuming the validation succeeds, the resultant plaintext, which is the entire content of the original block, replaces the PCB at the same place in the bundle. The block type reverts to that of the original block prior to encapsulation, and the other block-specific data fields also return to their original values. Implementors are cautioned that this "replacement" process requires delicate stitchery, as the EID-list contents in the decapsulated block are invalid. As noted above, the EID-list references in the original block were preserved in the "replacing" PCB, and will have been updated as necessary as the bundle has toured the DTN. The references from the PCB MUST replace the references within the EID-list of the newly decapsulated block. Caveat implementor.
セキュリティ先、特定の宛先またはバンドル先のいずれかで、上述したプロセスが逆になっています。ペイロードはICVを使用して検証を含む、最初のPCBに塩、IV、およびキー値を使用して、「その場で」復号化されます。これらの値は、2.6節で説明されています。各相関PCBはまた、塩及び第一PCBからキー値およびブロック固有IV項目を使用して、同じ宛先で処理されます。セキュリティ結果でカプセル化されたブロックの項目は、元のブロックデータの暗号文に付加されているはずのタグを使用して、復号化および検証されています。検証が成功したと仮定すると、元のブロックのコンテンツ全体で生じた平文は、バンドル内の同じ場所でPCBを置き換えます。ブロックタイプは、元のブロックの前にカプセル化することに戻り、他のブロックに固有のデータフィールドは、それらの元の値に戻ります。実装者は、カプセル化解除ブロック中EID-リストの内容が無効であるとして、この「交換」プロセスは、繊細なstitcheryが必要であることを警告しています。上述のように、元のブロックにEIDリストの参照は、「置換」PCBに保存し、バンドルがDTN見学したように、必要に応じて更新されています。 PCBからの参照は、新たにデカプセル化ブロックのEID-リスト内の参照を交換しなければなりません。警告実装。
Extension security blocks provide protection for non-payload-related portions of a bundle. ESBs MUST NOT be used for the primary block or payload, including payload-related security blocks (PIBs and PCBs).
拡張セキュリティブロックは、バンドルの非ペイロードに関連する部分のための保護を提供します。 ESBは、ペイロードに関連するセキュリティ・ブロック（のPIBやPCB）を含む、一次ブロック又はペイロードのために使用してはいけません。
It is sometimes desirable to protect certain parts of a bundle in ways other than those applied to the bundle payload. One such example is bundle metadata that might specify the kind of data in the payload but not the actual payload detail, as described in [DTNMD].
バンドルペイロードに適用されるもの以外の方法でバンドルの特定の部分を保護することが望ましい場合があります。その一例は、[DTNMD]に記載されているように、ペイロード内のデータの種類ではなく、実際のペイロードの詳細を指定することがバンドルメタデータです。
ESBs are typically used to apply confidentiality protection. While it is possible to create an integrity-only ciphersuite, the block protection is not transparent and makes access to the data more difficult. For simplicity, this discussion describes the use of a confidentiality ciphersuite.
ESBは、一般的に機密性保護を適用するために使用されています。それは整合性のみの暗号スイートを作成することは可能ですが、ブロック保護は透明ではなく、データへのアクセスをより困難にします。簡単にするために、この議論は、機密性の暗号スイートの使用を記載しています。
The protection mechanisms in ESBs are similar to other security blocks with two important differences:
ESBでの保護メカニズムは、2つの重要な相違点と、他のセキュリティ・ブロックに似ています：
o different key values are used (using the same key as that for payload would defeat the purpose)
O異なるキー値が使用されている（ペイロードと同じキーを使用する目的にそぐわないです）
o the block is not encrypted or super-encrypted with the payload
Oブロックは、暗号化またはペイロードとスーパーは、暗号化されていません
A typical ESB ciphersuite will encrypt the extension block using a randomly generated ephemeral key and will use the key-information item in the security-parameters field to carry the key encrypted with some long-term key encryption key (KEK) or well-known public key. If neither the destination nor security-destination resolves the key to use for decryption, the key-information item in the ciphersuite-parameters field can be used also to indicate the decryption key with which the BEK can be recovered.
典型的なESBの暗号スイートは、ランダムに生成された短期キーを使用して、拡張ブロックを暗号化し、いくつかの長期鍵暗号鍵（KEK）、または周知のパブリックで暗号化鍵を運ぶためにセキュリティパラメータフィールドにキー情報項目を使用しますキー。先にもセキュリティ先でもないが、復号化に使用するキーを解決する場合は、暗号スイート・パラメータフィールド内のキー情報項目は、BEKを回復することが可能な復号鍵を示すためにも使用することができます。
It is strongly RECOMMENDED that a data integrity mechanism be used in conjunction with confidentiality, and that encryption-only ciphersuites NOT be used. AES-GCM satisfies this requirement.
強く、データの整合性機構は、機密性と組み合わせて使用することをお勧めされ、その暗号化のみの暗号スイートは使用できません。 AES-GCMは、この要件を満たしています。
The ESB is placed in the bundle in the same position as the block being protected. That is, the entire original block is processed (encrypted, etc.) and encapsulated in a "replacing" ESB-type block, and this appears in the bundle at the same sequential position as the original block. The processed data is placed in the security-result field.
ESBは、保護されているブロックと同じ位置に束に配置されます。すなわち、全体の元のブロックが処理（暗号化等）及び「交換」ESB型ブロック内にカプセル化し、これは、元のブロックと同じシーケンシャル位置に束に表示されています。処理されたデータは、セキュリティ、結果フィールドに置かれています。
The process is reversed at the security-destination with the recovered plaintext block replacing the ESB that had encapsulated it. Processing of EID-list entries, if any, is described in Section 2.4, and this MUST be followed in order to correctly recover EIDs.
プロセスは、それがカプセル化されたESBを置換回収平文ブロックとセキュリティ先に反転されます。 EID-リストエントリの処理は、もしあれば、2.4節で説明されており、これは正しくのEIDを回復するために従わなければなりません。
An ESB is an ASB with the following additional restrictions:
ESBは、以下の追加の制限がASBです。
The block type is 0x09.
ブロックタイプが0x09のです。
Ciphersuite flags indicate which fields are present in this block. Ciphersuite designers should carefully consider the effect of setting flags that either discard the block or delete the bundle in the event that this block cannot be processed.
暗号スイートのフラグは、このブロック内に存在するフィールドを示しています。暗号スイート設計者は慎重にブロックを破棄するか、このブロックは処理できない場合には、バンドルを削除するのいずれかのフラグを設定した場合の効果を検討すべきです。
EID-references MUST be stored in the EID-reference list.
EID-参照はEID-参照リストに保存する必要があります。
The security-source MAY be present. The security-source can also be specified as part of key-information described in Section 2.6. If neither is present, then the bundle-source is used as the security-source.
セキュリティ・ソースが存在してもよいです。セキュリティソースも、セクション2.6で説明鍵情報の一部として指定することができます。どちらも存在している場合は、バンドル・ソースは、セキュリティ・ソースとして使用されています。
The security-destination MAY be present. If not present, then the bundle-destination is used as the security-destination.
セキュリティ先が存在してもよいです。存在しない場合、バンドル先セキュリティ先として使用されます。
The security-parameters MAY optionally contain a block-type code field to indicate the type of the encapsulated block. Since this replicates a field in the encrypted portion of the block, it is a slight security risk, and its use is therefore OPTIONAL.
セキュリティパラメータは、必要に応じてカプセル化されたブロックの種類を示すために、ブロック・タイプ・コード・フィールドを含むかもしれません。これはブロックの暗号化された部分でフィールドを複製するので、それはわずかなセキュリティ上のリスクであり、その使用は、したがって、任意です。
Various ciphersuites include several items in the security-parameters and/or security-result fields. Which items MAY appear is defined by the particular ciphersuite description. A ciphersuite MAY support several instances of the same type within a single block.
様々な暗号スイートは、セキュリティパラメータおよび/またはセキュリティ結果フィールドで複数の項目を含みます。どのアイテムが特定の暗号スイートの記述によって定義されて表示されることがあります。暗号スイートは、単一のブロック内の同じタイプの複数のインスタンスをサポートするかもしれません。
Each item is represented as a type-length-value. Type is a single byte indicating which item this is. Length is the count of data bytes to follow, and is an SDNV-encoded integer. Value is the data content of the item.
各項目は、タイプレングス値として表されます。タイプは、これがどの項目を示す単一のバイトです。長さは、データのカウントが続くバイトであり、SDNVエンコード整数です。値は、項目のデータ内容です。
Item types are
アイテムの種類があります
0: reserved
0：予約済み
1: initialization vector (IV)
1：初期化ベクトル（IV）
2: reserved
2：予約済み
3: key-information
3：鍵情報
4: fragment-range (offset and length as a pair of SDNVs)
4：断片レンジ（SDNVsのペアとしてオフセット及び長さ）
5: integrity signature
5：整合性の署名
6: unassigned
6：割り当てられていません
7: salt
7：塩
8: PCB integrity check value (ICV)
8：PCB整合性チェック値（ICV）
9: reserved
9：予約
10: encapsulated block
10：カプセル化されたブロック
11: block type of encapsulated block
11：カプセル化されたブロックのブロックタイプ
12 - 191: reserved
12から191：予約済み
192 - 250: private use
192から250：私的使用
251 - 255: reserved
251から255：予約済み
The following descriptions apply to the usage of these items for all ciphersuites. Additional characteristics are noted in the discussion for specific suites.
以下の説明では、すべての暗号スイートのためにこれらのアイテムの使用に適用されます。追加の特性は、特定のスイートのための議論で指摘されています。
o initialization vector (IV): random value, typically eight to sixteen bytes.
O初期化ベクトル（IV）：ランダムな値、典型的には8〜16バイト。
o key-information: key material encoded or protected by the key management system and used to transport an ephemeral key protected by a long-term key. This item is discussed further in Section 2.7.
O鍵情報：主要材料符号化された、または鍵管理システムによって保護され、長期キーによって保護短期キーを輸送するために使用されます。こちらの商品は2.7節で詳しく説明されています。
o fragment-range: pair of SDNV values (offset then length) specifying the range of payload bytes to which a particular operation applies. This is termed "fragment-range" since that is its typical use, even though sometimes it describes a subset range that is not a fragment. The offset value MUST be the offset within the original bundle, which might not be the offset within the current bundle if the current bundle is already a fragment.
O断片範囲：ペイロードの範囲を指定SDNV値のペアは、（その後、長さオフセット）特定の操作が適用されるバイト。それは、その典型的な使用であるので、これは、時にはそれがフラグメントではないサブセット範囲を記述していても、「フラグメント・レンジ」と呼ばれています。オフセット値は、現在のバンドルが既に断片である場合、現在のバンドル内のオフセットされていない場合があり、元のバンドル内のオフセットされなければなりません。
o integrity signature: result of BAB or PIB digest or signing operation. This item is discussed further in Section 2.7.
O整合性の署名：BABまたはPIBダイジェストや署名操作の結果。こちらの商品は2.7節で詳しく説明されています。
o salt: an IV-like value used by certain confidentiality suites.
O塩：特定の機密スイートによって使用されるIV-ような値。
o PCB integrity check value (ICV): output from certain confidentiality ciphersuite operations to be used at the destination to verify that the protected data has not been modified.
O PCBインテグリティ・チェック値（ICV）：保護されたデータが変更されていないことを確認するために先に使用される特定の機密暗号スイート操作から出力。
o encapsulated block: result of confidentiality operation on certain blocks, contains the ciphertext of the block and MAY also contain an integrity check value appended to the ciphertext; MAY also contain padding if required by the encryption mode; used for non-payload blocks only.
Oカプセル化されたブロック：特定のブロックに機密操作の結果は、ブロックの暗号文が含まれており、また、暗号文に付加整合性チェック値を含むかもしれません。暗号化モードによって必要とされる場合は、パディングを含む可能性があります。唯一の非ペイロードブロックに使用。
o block type of encapsulated block: block-type code for a block that has been encapsulated in ESB.
カプセル化されたブロックのOブロックタイプ：ESB内にカプセル化されたブロックのブロックタイプコード。
This specification endeavors to maintain separation between the security protocol and key management. However, these two interact in the transfer of key-information, etc., from security-source to security-destination. The intent of the separation is to facilitate the use of a variety of key management systems without needing to tailor a ciphersuite to each individually.
セキュリティプロトコルと鍵管理間の分離を維持するために、この仕様の努力。しかし、これらの二つは、セキュリティ・ソースからのセキュリティ先に、などのキー情報の転送、中に相互作用します。分離の目的は、個別に暗号スイートを調整することなく、鍵管理システムの様々な使用を容易にすることです。
The key management process deals with such things as long-term keys, specifiers for long-term keys, certificates for long-term keys, and integrity signatures using long-term keys. The ciphersuite itself SHOULD NOT require a knowledge of these, and separation is improved if it treats these as opaque entities to be handled by the key management process.
長期キー、長期キーを使用して、長期的なキー、長期鍵の証明書、および整合性の署名の指定子のようなものと鍵管理プロセスを扱っています。暗号スイート自体は、これらの知識を必要とすべきではない、それはこれらのような不透明なエンティティが鍵管理プロセスによって処理される扱う場合の分離性が向上します。
The key management process deals specifically with the content of two of the items defined in Section 2.6: key-information (item type 3) and integrity signature (item type 5). The ciphersuite MUST define the details and format for these items. To facilitate interoperability, it is strongly RECOMMENDED that the implementations use the appropriate definitions from the Cryptographic Message Syntax (CMS) [RFC5652] and related RFCs.
鍵情報（アイテムタイプ3）と整合性の署名（項目タイプ5）：具体的には、セクション2.6で定義されたアイテムのうちの2つのコンテンツと鍵管理プロセスを扱います。暗号スイートは、これらの項目の詳細とフォーマットを定義しなければなりません。相互運用性を容易にするために、強く実装が暗号メッセージ構文（CMS）[RFC5652]および関連するRFCから適切な定義を使用することをお勧めします。
Many situations will require several pieces of key-information. Again, ciphersuites MUST define whether they accept these packed into a single key-information item and/or separated into multiple instances of key-information. For interoperability, it is RECOMMENDED that ciphersuites accept these packed into a single key-information item, and that they MAY additionally choose to accept them sent as separate items.
多くの状況では、キーいくつかの情報が必要になります。再度、暗号スイートは、彼らがこれらの単一のキー情報項目に充填および/または鍵情報の複数のインスタンスに分離受け入れるかどうかを定義しなければなりません。相互運用性のためには、暗号スイートが、これらは、単一のキー情報項目に詰め込ま受け入れることを、彼らはさらに彼らは別々のアイテムとして送信受け入れることを選択するかもしれないことを推奨します。
Given the above definitions, nodes are free to combine applications of PIB and PCB in any way they wish -- the correlator value allows for multiple applications of security services to be handled separately. Since PIB and PCB apply to the payload and ESB to non-payload blocks, combinations of ESB with PIB and/or PCB are not considered.
上記の定義を考えると、ノードは、彼らが望む任意の方法でPIBとPCBのアプリケーションを組み合わせて自由である - 相関値を別々に処理するためのセキュリティ・サービスの複数のアプリケーションが可能になります。 PIBとPCBは、非ペイロードブロックにペイロードとESBに適用されるので、PIB及び/又はPCBとESBの組み合わせが考慮されません。
There are some obvious security problems that could arise when applying multiple services. For example, if we encrypted a payload but left a PIB security-result containing a signature in the clear, payload guesses could be confirmed.
複数のサービスを適用するときに発生する可能性があり、いくつかの明らかなセキュリティ上の問題があります。我々はペイロードを暗号化されたが、明確で署名を含むPIBセキュリティ-結果を残した場合、ペイロードの推測を確認することができました。
We cannot, in general, prevent all such problems since we cannot assume that every ciphersuite definition takes account of every other ciphersuite definition. However, we can limit the potential for such problems by requiring that any ciphersuite that applies to one instance of a PIB or PCB MUST be applied to all instances with the same correlator.
我々は、すべての暗号スイート定義は他のすべての暗号スイートの定義を考慮していると仮定することはできませんので、我々は、一般的には、すべてのこのような問題を防ぐことはできません。しかし、我々は、PIBまたはPCBの1つのインスタンスに適用される任意の暗号スイートは、同じ相関を持つすべてのインスタンスに適用されなければならないことを要求することによって、このような問題の可能性を制限することができます。
We now list the PIB and PCB combinations that we envisage as being useful to support:
私たちは、今、私たちがサポートすることが有用であると想定PIBおよびPCBの組み合わせをリスト：
Encrypted tunnels - a single bundle MAY be encrypted many times en route to its destination. Clearly, it has to be decrypted an equal number of times, but we can imagine each encryption as representing the entry into yet another layer of tunnel. This is supported by using multiple instances of PCB, but with the payload encrypted multiple times, "in-place". Depending upon the ciphersuite definition, other blocks can and should be encrypted, as discussed above and in Section 2.4 to ensure that parameters are protected in the case of super-encryption.
暗号化トンネル - 単一のバンドルは、その目的地への途中で何度も暗号化されてもよいです。明らかに、同じ回数を解読しなければならないが、我々は、トンネルのさらに別の層への侵入を表すものとして、それぞれの暗号化を想像することができます。これは、PCBの複数のインスタンスを使用することによってサポートされていますが、ペイロードに「インプレース」、複数回暗号化されています。パラメータは、スーパー暗号化の場合に保護されることを確実にするために、上記と2.4節で説明したように暗号スイート定義に応じて、他のブロックはと、暗号化されなければならないことができます。
Multiple parallel authenticators - a single security-source might wish to protect the integrity of a bundle in multiple ways. This could be required if the bundle's path is unpredictable and if various nodes might be involved as security-destinations. Similarly, if the security-source cannot determine in advance which algorithms to use, then using all might be reasonable. This would result in uses of PIB that, presumably, all protect the payload, and which cannot in general protect one another. Note that this logic can also apply to a BAB, if the unpredictable routing happens in the convergence layer, so we also envisage support for multiple parallel uses of BAB.
複数の並列のオーセンティケータ - 単一のセキュリティ・ソースは複数の方法でバンドルの整合性を保護したいかもしれません。バンドルのパスが予測不能である場合、これは必要になることができ、さまざまなノードには、セキュリティの目的地として関与している可能性がある場合。セキュリティソースを使用するためのアルゴリズムを予め決定することができない場合は同様に、すべてを使用することは合理的であるかもしれません。これは、おそらく、すべてのペイロードを保護することをPIBの用途につながる、とされ、一般的に互いを保護することはできません。予測不可能なルーティングが収束層で発生した場合、この論理はまた、BABに適用できることに留意されたいので、我々はまた、BABの複数の平行な用途のためのサポートを考えます。
Multiple sequential authenticators - if some security-destination requires assurance about the route that bundles have taken, then it might insist that each forwarding node add its own PIB. More likely, however, would be that outbound "bastion" nodes would be configured to sign bundles as a way of allowing the sending "domain" to take accountability for the bundle. In this case, the various PIBs will likely be layered, so that each protects the earlier applications of PIB.
複数の連続オーセンティケータは、 - いくつかのセキュリティ-先がバンドルが取られているルートについての保証を必要とする場合、それは各転送ノードは、自身のPIBを追加することを主張するかもしれません。もっとありそうな、しかし、アウトバウンド「砦」のノードがバンドルの責任を取るために送信する「ドメイン」を可能にする方法としてバンドルに署名するように設定されることになります。各々がPIBの以前のアプリケーションを保護するように、この場合に、種々のPIBは、おそらく、積層されます。
Authenticated and encrypted bundles - a single bundle MAY require both authentication and confidentiality. Some specifications first apply the authenticator and follow this by encrypting the payload and authenticator. As noted previously in the case where the authenticator is a signature, there are security reasons for this ordering. (See the PCB-RSA-AES128-PAYLOAD-PIB-PCB ciphersuite defined in Section 4.3.) Others apply the authenticator after encryption, that is, to the ciphertext. This ordering is generally RECOMMENDED and minimizes attacks that, in some cases, can lead to recovery of the encryption key.
認証および暗号化のバンドル - 単一のバンドルには、認証と機密性の両方を必要とする場合があります。いくつかの仕様は、第1のオーセンティケータを適用し、ペイロードとオーセンティケータを暗号化することによって、これを従ってください。オーセンティケータが署名である場合には先に述べたように、この順序付けのためのセキュリティ上の理由があります。 （セクション4.3で定義されたPCB-RSA-AES128-PAYLOAD-PIB-PCBの暗号スイートを参照してください。）その他は、暗号文に、つまり、暗号化した後、オーセンティケータを適用します。この順序は、一般的に推奨して、いくつかのケースでは、暗号化キーの回復につながる可能性の攻撃を最小限に抑えています。
There are, no doubt, other valid ways to combine PIB and PCB instances, but these are the "core" set supported in this specification. Having said that, as will be seen, the mandatory ciphersuites defined here are quite specific and restrictive in terms of limiting the flexibility offered by the correlator mechanism. This is primarily designed to keep this specification as simple as possible, while at the same time supporting the above scenarios.
そこPIBおよびPCBのインスタンスを結合するために、間違いなく、他の有効な方法がありますが、これらはこの仕様でサポートされている「コア」のセットです。見られるように、ここで定義された必須暗号スイートは、相関メカニズムによって提供される柔軟性を制限するという点で、非常に具体的で制限されている、と述べました。これは主に、同時に上記のシナリオをサポートしながら、可能な限りシンプルなこの仕様を保つように設計されています。
This section describes the security aspects of bundle processing.
このセクションでは、バンドル処理のセキュリティ面について説明します。
All nodes are REQUIRED to have and enforce their own configurable security policies, whether these policies be explicit or default, as defined in Section 6.
第6節で定義されているすべてのノードは、これらのポリシーは、明示的またはデフォルトにするかどうかを、持っていると、自分の設定可能なセキュリティポリシーを適用する必要があります。
All nodes serve as Policy Enforcement Points (PEPs) insofar as they enforce polices that MAY restrict the permissions of bundle nodes to inject traffic into the network. Policies MAY apply to traffic that originates at the current node, traffic that terminates at the current node, and traffic that is to be forwarded by the current node to other nodes. If a particular transmission request, originating either locally or remotely, satisfies the node's policy or policies and is therefore accepted, then an outbound bundle can be created and dispatched. If not, then in its role as a PEP, the node will not create or forward a bundle. Error handling for such cases is currently considered out of scope for this document.
すべてのノードは、それらがネットワークにトラフィックを注入するために、バンドルノードの権限を制限することができるポリシーを強制するものであれば、ポリシー実行ポイント（PEPは）としての役割を果たす。ポリシーは、他のノードに現在のノードによって転送されるべき現在のノードに発信トラフィック、現在のノードで終端するトラフィック、トラフィックに適用することができます。特定の送信要求は、ローカルまたはリモート発信、ノードのポリシーまたはポリシーを満たし、したがって、受け入れられた場合、アウトバウンドバンドルを作成してディスパッチすることができます。そうでない場合には、PEPとしての役割では、ノードは、バンドルを作成したり、転送しません。このような場合のエラー処理は、現在、このドキュメントの範囲外と考えられています。
Policy enforcing code MAY override all other processing steps described here and elsewhere in this document. For example, it is valid to implement a node that always attempts to attach a PIB. Similarly, it is also valid to implement a node that always rejects all requests that imply the use of a PIB.
ポリシー施行のコードは、この文書で、ここで、他の場所に記載の他の全ての処理ステップを無効にすることができます。例えば、常にPIBを添付しようとするノードを実装するために有効です。同様に、常にPIBの使用を意味するものではすべての要求を拒否したノードを実装することも有効です。
Nodes MUST consult their security policy to determine the criteria that a received bundle ought to meet before it will be forwarded. These criteria MUST include a determination of whether or not the received bundle MUST include a valid BAB, PIB, PCB, or ESB. If the bundle does not meet the node's policy criteria, then the bundle MUST be discarded and processed no further; in this case, a bundle status report indicating the failure MAY be generated.
ノードは、その受け取ったバンドルが、それが転送される前に満たすべき基準を決定するために、セキュリティポリシーを参照する必要があります。これらの基準は、受信されたバンドルが有効BAB、PIB、PCB、またはESBを含まなければならないか否かの決意を含まなければなりません。バンドルは、ノードのポリシー基準を満たしていない場合は、バンドルは捨てなければなりませんし、それ以上処理しません。この場合には、失敗を示すバンドルステータスレポートを生成することができます。
The node's policy MAY call for the node to add or subtract some security blocks. For example, it might require that the node attempt to encrypt (parts of) the bundle for some security-destination or that it add a PIB. If the node's policy requires a BAB to be added to the bundle, it MUST be added last so that the calculation of its security-result MAY take into consideration the values of all other blocks in the bundle.
ノードの方針は、いくつかのセキュリティブロックを追加または削除するノードのために呼び出すことができます。例えば、それは、ノードの試みがいくつかのセキュリティ先のためか、それはPIBを追加し、そのバンドル（の部分）を暗号化することが必要な場合があります。ノードのポリシーがバンドルに追加されるBABを必要とする場合、それは最後に追加されなければならない、そのセキュリティ-結果の計算を考慮にバンドル内のすべての他のブロックの値をとることができるように。
The processing order of security actions for a bundle is critically important for the actions to complete successfully. In general, the actions performed at the originating node MUST be executed in the reverse sequence at the destination. There are variations and exceptions, and these are noted below.
アクションが正常に完了するためにバンドルのセキュリティアクションの処理順序は非常に重要です。一般的には、発信元ノードが行う動作は、先に逆の順序で実行されなければなりません。そこバリエーションと例外があり、これらは以下に記載されています。
The sequence is maintained in the ordering of security blocks in the bundle. It is for this reason that blocks MUST NOT be rearranged at forwarding nodes, whether or not they support the security protocols. The only blocks that participate in this ordering are the primary and payload blocks, and the PIB and PCB security blocks themselves. All other extension blocks, including ESBs, are ignored for purposes of determining the processing order.
シーケンスは、バンドル内のセキュリティブロックの順序で維持されています。それは、彼らがセキュリティプロトコルをサポートしているか否か、ブロックが転送ノードに再配置してはならないのはこのためです。この順序に参加ブロックのみ、プライマリおよびペイロードブロックであり、そしてPIBおよびPCBセキュリティブロックそのもの。 ESBを含む他のすべての拡張ブロックが、処理順序を決定する目的のために無視されます。
The security blocks are added to and removed from a bundle in a last-in-first-out (LIFO) manner, with the top of the stack immediately after the primary block. A newly created bundle has just the primary and payload blocks, and the stack is empty. As security actions are requested for the bundle, security blocks are pushed onto the stack immediately after the primary block. The early actions have security blocks close to the payload, later actions have blocks nearer to the primary block. The actions deal with only those blocks in the bundle at the time, so, for example, the first to be added processes only the payload and primary blocks, the next might process the first if it chooses and the payload and primary, and so on. The last block to be added can process all the blocks.
セキュリティブロックは、直ちに一次ブロックした後、スタックの最上部と、に加え、後入れ先出し（LIFO）方式でバンドルから除去されます。新しく作成されたバンドルはちょうどプライマリおよびペイロードブロックがあり、スタックが空です。セキュリティアクションをバンドルするために要求されると、セキュリティ・ブロックは、直ちに主要ブロックの後にスタックにプッシュされています。初期のアクションは、後のアクションが近い主要ブロックにブロックを持って、ペイロードに近いセキュリティブロックを持っています。アクションはこれに一度にバンドル内のブロックのみを扱うので、例えば、添加する第一工程のみペイロードと主要ブロックを、それが選択し、ペイロードとプライマリ場合は、次の最初の処理かもしれない、そして。追加する最後のブロックは、すべてのブロックを処理することができます。
When the bundle is received, this process is reversed and security processing begins at the top of the stack, immediately after the primary block. The security actions are performed, and the block is popped from the stack. Processing continues with the next security block until finally only the payload and primary blocks remain.
バンドルを受信した場合、このプロセスは逆転され、セキュリティ処理は直ちに一次ブロックした後、スタックの最上部から始まります。セキュリティアクションが実行され、ブロックがスタックからポップされます。最終的には唯一のペイロードと主要ブロックが残るまで処理は、次のセキュリティブロックで継続します。
The simplicity of this description is undermined by various real-world requirements. Nonetheless, it serves as a helpful initial framework for understanding the bundle security process.
この説明の簡略化は、様々な現実世界の要件によって損なわれています。それにもかかわらず、バンドルセキュリティプロセスを理解するために役立つ初期のフレームワークとして機能します。
The first issue is a very common one and easy to handle. The bundle may be sent indirectly to its destination, requiring several forwarding hops to finally arrive there. Security processing happens at each node, assuming that the node supports bundle security. For the following discussion, we assume that a bundle is created and that confidentiality, then payload integrity, and finally bundle authentication are applied to it. The block sequence would therefore be primary-BAB-PIB-PCB-payload. Traveling from source to destination requires going through one intermediate node, so the trip consists of two hops.
最初の問題は非常に一般的なものと扱いやすいです。バンドルは、いくつかの転送が最終的にそこに到達するために必要ホップ、その宛先に間接的に送信することができます。セキュリティ処理は、ノードがバンドルセキュリティをサポートしていると仮定して、各ノードで行われます。以下の議論のために、我々は、バンドルが作成されていると仮定し、その機密性、そして、ペイロードの完全性、そして最後にバンドル認証がそれに適用されます。ブロックシーケンスは、したがって、一次BAB-PIB-PCB-ペイロードであろう。送信元から宛先への旅は一つの中間ノードを経由する必要があり、その旅は、2つのホップから構成されています。
When the bundle is received at the intermediate node, the receive processing validates the BAB and pops it from the stack. However, the PIBs and PCBs have the final destination as their security-destination, so these cannot be processed and removed. The intermediate node then begins the send process with the four remaining blocks in the bundle. The outbound processing adds any security blocks required by local policy, and these are pushed on the stack immediately after the primary block, ahead of the PIB. In this example, the intermediate node adds a PIB as a signature that the bundle has passed through the node.
バンドルは、中間ノードで受信されると、受信処理はBABを検証し、スタックからそれをポップ。しかし、のPIBおよびPCBは、セキュリティ先として最終目的地を持っているので、これらが処理され、削除することはできません。中間ノードは、次に、バンドル内の残りの4つのブロックと送信プロセスを開始します。アウトバウンド処理はローカルポリシーによって要求されるセキュリティ・ブロックを追加し、これらは先にPIBの、すぐに主要ブロックの後にスタックにプッシュされています。この例では、中間ノードは、バンドルがノードを通過した署名としてPIBを付加します。
The receive processing at the destination first handles the intermediate node's PIB and pops it, next is the originator's PIB, also popped, and finally the originator's confidentiality block that allows the payload to be decrypted and the bundle handled for delivery.
先の受信処理は、第1の中間ノードのPIBを処理し、それをポップ、次もポップ発信者のPIB、及びペイロードを復号化するとバンドルが配信のために取り扱うことができ、最終的に発信者の機密性ブロックです。
In practice, DTNs are likely to be more complex. The security policy for a node specifies the security requirements for a bundle. The policy will possibly cause one or more security operations to be applied to the bundle at the current node, each with its own security-destination. Application of policy at subsequent nodes might cause additional security operations, each with a security-destination. The list of security-destinations in the security blocks (BAB, PIB and PCB, not ESB) creates a partial-ordering of nodes that MUST be visited en route to the bundle-destination.
実際には、DTNsはより複雑である可能性が高いです。ノードのセキュリティポリシーは、バンドルのセキュリティ要件を指定します。ポリシーは、おそらく1つまたは複数のセキュリティ・オペレーションは、現在のノードでバンドルに独自のセキュリティ先とそれぞれ適用されます。以降のノードでのポリシーの適用は、セキュリティの先で各追加のセキュリティ・オペレーションが発生する可能性があります。セキュリティ・ブロック（BAB、PIBおよびPCB、ないESB）におけるセキュリティの目的地のリストは、バンドル先への途中で訪問しなければならないノードの部分的な順序付けを作成します。
The bundle security scheme does not deal with security paths that overlap partially but not completely. The security policy for a node MUST avoid specifying, for a bundle, a security-destination that causes a conflict with any existing security-destination in that bundle. This is discussed further in Section 3.3.
バンドルセキュリティ方式は、部分的にではなく、完全に重なってセキュリティ・パスを扱っていません。ノードのセキュリティポリシーは、バンドル、そのバンドル内のすべての既存のセキュリティ先との競合が発生し、セキュリティ先のために、指定避けなければなりません。これは、3.3節で詳しく説明されています。
The second issue relates to the reversibility of certain security process actions. In general, the actions fall into two categories: those that do not affect other parts of the bundle and those that are fully reversible. Creating a bundle signature, for example, does not change the bundle content except for the result. The encryption performed as part of the confidentiality processing does change the bundle, but the reverse processing at the destination restores the original content.
第二の問題は、特定のセキュリティプロセスのアクションの可逆性に関するものです。バンドルの他の部分に影響を与えないものと完全に可逆的なもの：一般的に、アクションは、2つのカテゴリに分類されます。バンドル署名の作成、例えば、結果以外のバンドル内容は変更されません。秘匿処理の一部として実行される暗号化は、バンドルを変更したが、先の逆処理は、元のコンテンツを復元します。
The third category is the one where the bundle content has changed slightly and in a non-destructive way, but there is no mechanism to reverse the change. The simplest example is the addition of an EID-reference to a security block. The addition of the reference causes the text to be added to the bundle's dictionary. The text may also be used by other references, so removal of the block and this specific EID-reference does not cause removal of the text from the dictionary. This shortcoming is of no impact to the "sequential" or "wrapping" security schemes described above, but does cause failures with "parallel" authentication mechanisms. Solutions for this problem are implementation specific and typically involve multi-pass processing such that blocks are added at one stage and the security-results calculated at a later stage of the overall process.
第三のカテゴリーは、バンドルコンテンツがわずかと非破壊的な方法で変更されているが、変化を逆にする機構がないものです。最も単純な例では、セキュリティブロックにEID-参照の付加です。参照の追加は、テキストがバンドルの辞書に追加されます。ブロックの除去およびこの特定のEID-参照が辞書からテキストの除去を起こさないように、テキストはまた、他の文献で使用することができます。この欠点は、上述した「連続」または「ラッピング」セキュリティ方式に無影響であるが、「平行」認証メカニズムと障害を引き起こすありません。この問題の解決策は、実装固有のものであり、典型的には、ブロックが一の段階で添加され、セキュリティの結果は、全体的なプロセスの後の段階で計算されるように、マルチパス処理を含みます。
Certain ciphersuites have sequence requirements for their correct operation, most notably the bundle authentication ciphersuites. Processing for bundle authentication is required to happen after all other sending operations, and prior to any receive operations at the next-hop node. Therefore, it follows that BABs MUST always be pushed onto the stack after all others.
特定の暗号スイートは、彼らの正しい操作のためのシーケンス要件、最も顕著なのバンドル認証暗号スイートを持っています。バンドル認証のための処理は、他のすべての送信操作の後に発生することが必要とされ、任意の前には、次ホップノードで操作を受けます。したがって、バブスは常に他のすべての後にスタックにプッシュしなければならないことになります。
Although we describe the security block list as a stack, there are some blocks that are placed after the payload and therefore are not part of the stack. The BundleAuthentication ciphersuite #1 ("BA1") requires a second, correlated block to contain the security-result, and this block is placed after the payload, usually as the last block in the bundle. We can apply the stack rules even to these blocks by specifying that they be added to the end of the bundle at the same time that their "owner" or "parent" block is pushed on the stack. In fact, they form a stack beginning at the payload but growing in the other direction. Also, not all blocks in the main stack have a corresponding entry in the trailing stack. The only blocks that MUST follow the payload are those mandated by ciphersuites as correlated blocks for holding a security-result. No other blocks are required to follow the payload block and it is NOT RECOMMENDED that they do so.
我々はスタックとしてセキュリティブロックリストを記載しているが、ペイロードの後に配置され、したがって、スタックの一部ではない、いくつかのブロックがあります。 BundleAuthenticationの暗号スイート＃1（「BA1」）は、セキュリティの結果を含むように第二、相関ブロックを必要とし、このブロックは、通常、バンドル内の最後のブロックとして、ペイロードの後に配置されています。我々は、彼らが自分の「所有者」または「親」のブロックがスタックにプッシュされると同時に、束の端に付加されることを指定することでも、これらのブロックにスタックルールを適用することができます。実際に、彼らはスタックのペイロードから始まるが、他の方向に成長を形成します。また、メインスタック内のないすべてのブロックが末尾のスタック内の対応するエントリを持っています。ペイロードに従わなければならない唯一のブロックは、セキュリティの結果を保持するための相関ブロックとして暗号スイートによって義務付けられたものです。他のブロックは、ペイロードブロックを追跡する必要はありません、彼らがそうすることをお勧めしません。
ESBs are effectively placeholders for the blocks they encapsulate and, since those do not form part of the processing sequence described above, ESBs themselves do not either. ESBs MAY be correlated, however, so the "no reordering" requirement applies to them as well.
ESBは、効果的にそれらはカプセル化ブロックのプレースホルダであり、それらは、上記の処理手順の一部を形成しないので、それ自体がどちらかないのESB。 ESBにはしかし、相関させることができるので、「いいえ並べ替え」の要件は、同様にそれらに適用されます。
Each security block has a security path, as described in the discussion for Figure 1, and the paths for various blocks are often different.
図1に関して議論で説明したように各セキュリティブロックは、セキュリティパスを有し、様々なブロックのための経路がしばしば異なっています。
BABs are always for a single hop, and these restricted paths never cause conflict.
バブスは、シングルホップのために常にであり、これらの制限されたパスが競合を起こすことはありません。
The paths for PIBs and PCBs are often from bundle-source to bundle-destination, to provide end-to-end protection. A bundle-source-to-bundle-destination path likewise never causes a problem.
PIBやPCBのパスは、エンド・ツー・エンドの保護を提供するために、バンドル先をすることがしばしばバンドルソースからです。バンドル・ソース・ツー・バンドル先のパスも同様に問題になることはありません。
Another common scenario is for gateway-to-gateway protection of traffic between two sub-networks ("tunnel-mode").
別の一般的なシナリオは、2つのサブネットワーク（「トンネルモード」）との間のトラフィックのゲートウェイ間の保護のためのものです。
Looking at Figure 1 and the simplified version shown in Figure 4, we can regard BN2 and BN3 as gateways connecting the two sub-networks labeled "An internet". As long as they provide security for the BN2- BN3 path, all is well. Problems begin, for example, when BN2 adds blocks with BN4 as the security-destination, and the originating node BN1 has created blocks with BN3 as security-destination. We now have two paths, and neither is a subset of the other.
図1および図4に示す簡略化されたバージョンを見て、我々は、「インターネット」と記された2つのサブネットワークを接続するゲートウェイとしてBN2とBN3とみなすことができます。限り、彼らはBN2- BN3パスにセキュリティを提供として、すべてが順調です。 BN2がセキュリティ先としてBN4とブロックを追加するときの問題は、例えば、開始、および元のノードBN1は、セキュリティ先としてBN3でブロックを作成しました。私たちは今、2つのパスがあり、どちらも他のサブセットです。
This scenario should be prevented by node BN2's security policy being aware of the already existing block with BN3 as the security-destination. This policy SHOULD NOT specify a security-destination that is further distant than any existing security-destination.
このシナリオでは、ノードBN2のセキュリティポリシーは、セキュリティ-先としてBN3と既存のブロックを意識することによって防止しなければなりません。このポリシーは、既存のセキュリティ先よりさらに離れているセキュリティ先を指定しないでください。
+---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+
| BN1 v | | ^ BN2 v | | ^ BN3 v | | ^ BN4 |
+---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+
>>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^
<------------- BN1 to BN3 path ------------>
<------------- BN2 to BN4 path ------------>
Figure 4: Overlapping Security Paths
図4：セキュリティパスの重複
Consider the case where the security concern is for data integrity, so the blocks are PIBs. BN1 creates one ("PIa") along with the new bundle, and BN2 pushes its own PIB "PIb" on the stack, with security-destination BN4. When this bundle arrives at BN3, the bundle blocks are
セキュリティ上の懸念は、データの整合性のためであるので、ブロックがPIBのある場合を考えてみましょう。 BN1は、新しいバンドルとともに1（「PIA」）を作成し、BN2は、セキュリティ先BN4と、スタック上に独自のPIB「PIB」をプッシュします。このバンドルは、BN3に到着すると、バンドルブロックがあります
primary - PIb - PIa - payload
主要 - PIB - ぴあ - ペイロード
Block PIb is not destined for this node BN3, so it has to be forwarded. This is the security-destination for block PIa so, after validation, it should be removed from the bundle; however, that will invalidate the PIb signature when the block is checked at the final destination. The PIb signature includes the primary block, PIb itself, PIa and the payload block, so PIa MUST remain in the bundle. This is why security blocks are treated as a stack and add/remove operations are permitted only at the top-of-stack.
ブロックPIBは、このノードBN3宛てされていないので、転送する必要があります。この検証の後、それはバンドルから除去されなければならないので、ブロックPIAのセキュリティ先です。ブロックが最終目的地にチェックされている場合しかし、それは、PIB署名が無効になります。 PIB署名のでPIAバンドルに留まるしなければならない、主要ブロック、PIB自体、PIAとペイロードブロックとを含みます。セキュリティブロックがスタックとして扱われ、追加/削除操作のみトップ・オブ・スタックで許可されている理由はここにあります。
The situation would be worse if the security concern is confidentiality, and PCBs are employed, using the confidentiality ciphersuite #3 ("PC3") described in Section 4.3. In this scenario, BN1 would encrypt the bundle with BN3 as security-destination, BN2 would create an overlapping security path by super-encrypting the payload and encapsulating the PC3 block for security-destination BN4. BN3 forwards all the blocks without change. BN4 decrypts the payload from its super-encryption and decapsulates the PC3 block, only to find that it should have been processed earlier. Assuming that BN4 has no access to BN3's key store, BN4 has no way to decrypt the bundle and recover the original content.
セキュリティ上の懸念は機密であり、PCB類は、4.3節で説明した＃3（「PC3」）のCipherSuite機密性を使用して、採用されている場合、状況は悪化するだろう。このシナリオでは、BN1セキュリティ先としてBN3とバンドルを暗号化するであろう、BN2は、ペイロードをスーパー暗号化およびセキュリティ先BN4用PC3ブロックをカプセル化することによって重複セキュリティパスを作成することになります。 BN3は変更せずにすべてのブロックを転送します。 BN4は、その超暗号化からペイロードを解読し、PC3ブロックのカプセル化を解除し、唯一のそれは以前に処理されている必要があることを発見します。 BN4がBN3のキーストアにアクセスできないと仮定すると、BN4は、オリジナルのコンテンツをバンドルを解読し、回復する方法はありません。
As mentioned above, authors of security policy need to use care to ensure that their policies do not cause overlaps. These guidelines should prove helpful.
前述したように、セキュリティポリシーの作成者は、彼らの政策が重複を起こさないように注意して使用する必要があります。これらのガイドラインは有用証明する必要があります。
The originator of a bundle can always specify the bundle-destination as the security-destination and should be cautious about doing otherwise.
バンドルの発信者は、常にセキュリティ先としてバンドル先を指定することができますし、そうでないことには慎重でなければなりません。
In the "tunnel-mode" scenario where two sub-networks are connected by a tunnel through a network, the gateways can each specify the other as security-destination and should be cautious about doing otherwise.
2つのサブネットワークは、ネットワークを介してトンネルによって接続されている「トンネルモード」のシナリオでは、ゲートウェイは各セキュリティ先として他を指定することができ、そうでなければやって慎重であるべきです。
BAB is never a problem because it is always only a single hop.
それは常に、単一のホップであるため、BABが問題になることはありません。
PIB for a bundle without PCB will usually specify the bundle-destination as security-destination.
PCBのないバンドルのPIBは、通常、セキュリティ先としてバンドル先を指定します。
PIB for a bundle containing a PCB should specify as its security-destination the security-destination of the PCB (outermost PCB if there are more than one).
（2つ以上が存在する場合PCB最外）PCBを含むバンドルのPIBは、そのセキュリティ宛先としてPCBのセキュリティ先を特定すべきです。
In order to verify a signature or MAC on a bundle, the exact same bits, in the exact same order, MUST be input to the calculation upon verification as were input upon initial computation of the original signature or MAC value. Consequently, a node MUST NOT change the encoding of any URI [RFC3986] in the dictionary field, e.g., changing the DNS part of some HTTP URL from lower case to upper case. Because bundles MAY be modified while in transit (either correctly or due to implementation errors), a canonical form of any given bundle (that contains a BAB or PIB) MUST be defined.
元の署名またはMAC値の初期計算時に入力されたとしてバンドルに署名またはMACを検証するために、正確に同じビットが、正確に同じ順序で、検証の際に計算に入力しなければなりません。したがって、ノードは、大文字に小文字からいくつかのHTTP URLのDNS部分を変更すること、例えば、辞書フィールド内の任意のURI [RFC3986]のエンコードを変更しないでください。トランジット（どちらかが正しくまたは実装誤差に起因する）に、任意の所与のバンドル（すなわち、BAB又はPIBを含有する）の正規形を定義する必要がありながらバンドルを変更することができるからです。
This section defines bundle canonicalization algorithms used in Sections 4.1 and 4.2 ciphersuites. Other ciphersuites can use these or define their own canonicalization procedures.
このセクションは、セクション4.1および4.2暗号スイートで使用されるバンドル正規化アルゴリズムを定義します。他の暗号スイートは、これらを使用したり、独自の正規化手順を定義することができます。
The first algorithm that can be used permits no changes at all to the bundle between the security-source and the security-destination. It is mainly intended for use in BAB ciphersuites. This algorithm conceptually catenates all blocks in the order presented, but omits all security-result data fields in blocks of this ciphersuite type. That is, when a BAB ciphersuite specifies this algorithm, we omit all BAB security-results for all BAB ciphersuites. When a PIB ciphersuite specifies this algorithm, we omit all PIB security-results for all PIB ciphersuites. All security-result length fields are included, even though their corresponding security-result data fields are omitted.
許可をセキュリティ・ソースおよびセキュリティ目的地との間のバンドルに全く変更を使用することができない最初のアルゴリズム。これは主にBABの暗号スイートでの使用を意図しています。このアルゴリズムは、概念的に提示ために、すべてのブロックをcatenatesが、この暗号スイートタイプのブロック内のすべてのセキュリティ・結果のデータフィールドを省略します。それはBABの暗号スイートは、このアルゴリズムを指定した場合、我々はすべてのBABの暗号スイートのすべてのBABセキュリティ-結果を省略しています。 PIBの暗号スイートは、このアルゴリズムを指定すると、我々はすべてのPIBの暗号スイートのためのすべてのPIBセキュリティ-結果を省略します。すべてのセキュリティ・結果の長さフィールドは、それに対応するセキュリティ・結果のデータ・フィールドが省略されていても、含まれています。
Notes:
ノート：
o In the above, we specify that security-result data is omitted. This means that no bytes of the security-result data are input. We do not set the security-result length to zero. Rather, we assume that the security-result length will be known to the module that implements the ciphersuite before the security-result is calculated, and require that this value be in the security-result length field even though the security-result data itself will be omitted.
O上記において、我々は、セキュリティ結果データが省略されていることを指定します。これは、セキュリティ結果データのないバイトが入力されていないことを意味します。我々はゼロにセキュリティ結果の長さを設定しないでください。むしろ、我々は、セキュリティ・結果の長さが計算され、セキュリティ、結果の前に暗号スイートを実装してモジュールに知られているであろうことを想定し、この値は、セキュリティ・結果の長さフィールドであることを必要としていても、セキュリティ結果データそのものます省略すること。
o The 'res' bit of the ciphersuite ID, which indicates whether or not the security-result length and security-result data field are present, is part of the canonical form.
Oセキュリティ結果の長さとセキュリティ結果データフィールドが存在するか否かを示す暗号スイートのID、の「のRES」ビットは、標準形の一部です。
o The value of the block data length field, which indicates the length of the block, is also part of the canonical form. Its value indicates the length of the entire bundle when the bundle includes the security-result data field.
ブロックの長さを示しているブロックデータ長フィールドの値O、また、標準形の一部です。バンドルはセキュリティ結果データフィールドを含む場合、その値は、バンドル全体の長さを示します。
o BABs are always added to bundles after PIBs, so when a PIB ciphersuite specifies this strict canonicalization algorithm and the PIB is received with a bundle that also includes one or more BABs, application of strict canonicalization as part of the PIB security-result verification process requires that all BABs in the bundle be ignored entirely.
O BABSはいつものPIB後バンドルに追加されるので、PIBの暗号スイートは、この厳格な正規化アルゴリズムを指定し、PIBはまた、1つ以上のBABSを含むバンドルに受信された場合、PIBセキュリティ結果検証プロセスの一部として厳密正規のアプリケーションバンドル内のすべてのバブスが完全に無視されている必要があります。
This algorithm is intended to protect parts of the bundle that SHOULD NOT be changed in transit. Hence, it omits the mutable parts of the bundle.
このアルゴリズムは、輸送中に変更すべきではありませんバンドルの部分を保護することを意図しています。したがって、束の可変部分を省略しています。
The basic approach is to define a canonical form of the primary block and catenate it with the security (PIBs and PCBs only) and payload blocks in the order that they will be transmitted. This algorithm ignores all other blocks, including ESBs, because it cannot be determined whether or not they will change as the bundle transits the network. In short, this canonicalization protects the payload, payload-related security blocks, and parts of the primary block.
基本的なアプローチは、一次ブロックの正規の形式を定義し、それらが送信されるようにするために、セキュリティ（のPIBやPCBのみ）とペイロードブロックとそれをCATENATEすることです。バンドルがネットワークを通過するよう、彼らが変わるか否かを判断することができないので、このアルゴリズムは、のESBを含む他のすべてのブロックを無視します。要するに、この正規化は、ペイロード、ペイロードに関連するセキュリティ・ブロック、及び一次ブロックの部分を保護します。
Many fields in various blocks are stored as variable-length SDNVs. These are canonicalized in unpacked form, as eight-byte fixed-width fields in network byte order. The size of eight bytes is chosen because implementations MAY handle larger values as invalid, as noted in [DTNBP].
各ブロック内の多くのフィールドは可変長SDNVsとして記憶されます。これらは、ネットワークバイト順の8バイトの固定幅フィールドとして、アンパック形式で正規化されています。実装は無効として大きな値を処理することができるので、[DTNBP]で述べたように8バイトの大きさは、選択されます。
The canonical form of the primary block is shown in Figure 5. Essentially, it de-references the dictionary block, adjusts lengths where necessary, and ignores flags that MAY change in transit.
主要ブロックは、本質的に図5に示されているの正規形、そのデリファレンス辞書ブロックは、必要に応じて長さを調整し、輸送中に変更される可能性フラグを無視します。
+----------------+----------------+----------------+----------------+
| Version | Processing flags (incl. COS and SRR) |
+----------------+----------------+---------------------------------+
| Canonical primary block length |
+----------------+----------------+---------------------------------+
| Destination endpoint ID length |
+----------------+----------------+---------------------------------+
| |
| Destination endpoint ID |
| |
+----------------+----------------+---------------------------------+
| Source endpoint ID length |
+----------------+----------------+----------------+----------------+
| |
| Source endpoint ID |
| |
+----------------+----------------+---------------------------------+
| Report-to endpoint ID length |
+----------------+----------------+----------------+----------------+
| |
| Report-to endpoint ID |
| |
+----------------+----------------+----------------+----------------+
| |
+ Creation Timestamp (2 x SDNV) +
| |
+---------------------------------+---------------------------------+
| Lifetime |
+----------------+----------------+----------------+----------------+
Figure 5: The Canonical Form of the Primary Bundle Block
図5：プライマリバンドルブロックの正規の形式
The fields shown in Figure 5 are as follows:
次のように図5に示されるフィールドは、次のとおりです。
The version value is the single-byte value in the primary block.
バージョン値は、プライマリブロック内の単一バイトの値です。
The processing flags value in the primary block is an SDNV, and includes the class-of-service (COS) and status report request (SRR) fields. For purposes of canonicalization, the SDNV is unpacked into a fixed-width field, and some bits are masked out. The unpacked field is ANDed with mask 0x0000 0000 0007 C1BE to set to zero all reserved bits and the "bundle is a fragment" bit.
主要ブロックの処理フラグの値がSDNVであり、クラス・オブ・サービス（COS）及び状態報告要求（SRR）フィールドを含みます。正規化の目的のために、SDNVは固定幅フィールドに展開され、そしていくつかのビットがマスクされています。解凍されたフィールドはゼロにすべての予約ビットを設定するために、マスク0000 0000 0007 C1BEとAND演算され、ビット「バンドルフラグメントです」。
The canonical primary block length value is a four-byte value containing the length (in bytes) of this structure, in network byte order.
正規一次ブロック長の値は、ネットワークバイト順で、この構造体の長さ（バイト）を含む4バイトの値です。
The destination endpoint ID length and value are the length (as a four-byte value in network byte order) and value of the destination endpoint ID from the primary bundle block. The URI is simply copied from the relevant part(s) of the dictionary block and is not itself canonicalized. Although the dictionary entries contain "null-terminators", the null-terminators are not included in the length or the canonicalization.
宛先エンドポイントIDの長さと値は、一次バンドルブロックから宛先エンドポイントIDの（ネットワークバイト順における4バイトの値など）の長さおよび値です。 URIは、単純に辞書ブロックの関連部分（複数可）からコピーされ、それ自体は正規化されていません。辞書のエントリは、「ヌル・ターミネータ」が含まれているものの、ヌル・ターミネータは、長さや正規化には含まれません。
The source endpoint ID length and value are handled similarly to the destination.
ソースエンドポイントIDの長さと値を先と同様に処理されます。
The report-to endpoint ID length and value are handled similarly to the destination.
レポートするためのIDの長さと値をエンドポイントは先と同様に処理されます。
The creation timestamp (2 x SDNV) and lifetime (SDNV) are simply copied from the primary block, with the SDNV values being represented as eight-byte unpacked values.
作成タイムスタンプ（2×SDNV）および寿命（SDNV）は単にSDNV値は8バイトアンパック値として表現されると、一次ブロックからコピーされます。
Fragment offset and total application data unit length are ignored, as is the case for the "bundle is a fragment" bit mentioned above. If the payload data to be canonicalized is less than the complete, original bundle payload, the offset and length are specified in the security-parameters.
上記「バンドルフラグメントである」ビットの場合のようにフラグメントオフセットおよび全アプリケーションデータユニットの長さは、無視されます。正規化されるべきペイロードデータが完了し、原稿束ペイロードよりも小さい場合、オフセットおよび長さは、セキュリティパラメータで指定されています。
For non-primary blocks being included in the canonicalization, the block processing control flags value used for canonicalization is the unpacked SDNV value with reserved and mutable bits masked to zero. The unpacked value is ANDed with mask 0x0000 0000 0000 0077 to zero reserved bits and the "last block" flag. The "last block" flag is ignored because BABs and other security blocks MAY be added for some parts of the journey but not others, so the setting of this bit might change from hop to hop.
正規化に含まれる非プライマリブロックについて、正規化のために使用されるブロック処理制御フラグの値がゼロにマスク予約及び可変ビットのアンパックSDNV値です。アンパック値をゼロ予約ビットと「最後のブロック」フラグをマスク0000 0000 0000 0077とANDされます。バブスや他のセキュリティ・ブロックは、いくつかの旅の一部ではなく、他人のために添加することができるので、「最後のブロック」フラグは無視されるので、このビットの設定は、ホップするホップから変更される可能性があります。
Endpoint ID references in security blocks are canonicalized using the de-referenced text form in place of the reference pair. The reference count is not included, nor is the length of the endpoint ID text.
セキュリティブロック内のエンドポイントIDの参照は、参照ペアの代わりにデ参照テキスト形式を使用して正規化されます。参照カウントが含まれ、またエンドポイントIDのテキストの長されていません。
The block-length is canonicalized as an eight-byte unpacked value in network byte order. If the payload data to be canonicalized is less than the complete, original bundle payload, this field contains the size of the data being canonicalized (the "effective block") rather that the actual size of the block.
ブロック長は、ネットワークバイト順に8バイトアンパック値として正規化されています。正規化されるべきペイロードデータが完了し、原稿束ペイロード未満である場合、このフィールドは、正規化されたデータのサイズ（「有効ブロック」）はなく、そのブロックの実際のサイズを含んでいます。
Payload blocks are generally canonicalized as-is, with the exception that, in some instances, only a portion of the payload data is to be protected. In such a case, only those bytes are included in the canonical form, and additional ciphersuite-parameters are required to specify which part of the payload is protected, as discussed further below.
ペイロードブロックは、一般に、いくつかの例では、ペイロードデータの一部のみが保護されるべき例外を除いて、そのまま正規化されています。このような場合には、のみバイトは正規形で含まれており、追加の暗号スイート・パラメータは、さらに後述するように、保護されているペイロードのどの部分を指定するために必要とされます。
Security blocks are handled likewise, except that the ciphersuite will likely specify that the "current" security block security-result field not be considered part of the canonical form. This differs from the strict canonicalization case since we might use the mutable canonicalization algorithm to handle sequential signatures such that signatures cover earlier ones.
セキュリティブロックは、暗号スイートは、おそらく「現在」のセキュリティブロックセキュリティ-結果フィールドは、標準的な形式の一部とは見なされないように指定することを除いて、同様に処理されます。私たちは署名が以前のものをカバーするようなシーケンシャル署名を処理するために変更可能な正規化アルゴリズムを使用する場合がありますので、これは厳しい正規化の場合とは異なります。
ESBs MUST NOT be included in the canonicalization.
ESBが正規に含んではいけません。
Notes:
ノート：
o The canonical form of the bundle is not transmitted. It is simply an artifact used as input to digesting.
O束の標準形は送信されません。これは単に消化への入力として使用アーティファクトです。
o We omit the reserved flags because we cannot determine if they will change in transit. The masks specified above will have to be revised if additional flags are defined and they need to be protected.
彼らは輸送中に変更される場合、我々は判断できないので、O我々は、予約のフラグを省略します。上記の指定されたマスクは、追加のフラグが定義されている場合は改訂する必要がありますし、彼らが保護される必要があります。
o Our URI encoding does not preserve the null-termination convention from the dictionary field, nor do we separate the scheme and the scheme-specific part (SSP) as is done there.
O私たちのURIエンコーディングが辞書フィールドからNULL終端規則を保存しない、またそこに行われているように、私たちはスキームとスキーマ固有部分（SSP）を分離します。
o The URI encoding will cause errors if any node rewrites the dictionary content (e.g., changing the DNS part of an HTTP URL from lower case to upper case). This could happen transparently when a bundle is synched to disk using one set of software and then read from disk and forwarded by a second set of software. Because there are no general rules for canonicalizing URIs (or IRIs), this problem may be an unavoidable source of integrity failures.
任意のノードは、辞書コンテンツを書き換える場合はURIエンコードエラーを引き起こすであろうO（例えば、大文字に小文字からのHTTP URLのDNS部分を変更します）。バンドルはソフトウェアの1セットを使用してディスクと同期して、ディスクから読み取られ、ソフトウェアの第二セットによって転送されたとき、これは透過的に発生する可能性があります。 canonicalizingのURI（虹彩）のための一般的な規則が存在しないため、この問題は、完全性障害の不可避源であってもよいです。
o All SDNV fields here are canonicalized as eight-byte unpacked values in network byte order. Length fields are canonicalized as four-byte values in network byte order. Encoding does not need optimization since the values are never sent over the network.
OここではすべてのSDNVフィールドはネットワークバイト順に8バイトアンパック値として正規化されています。長さフィールドは、ネットワークバイト順で4バイトの値として正規化されています。値は、ネットワークを介して送信されることはありませんので、エンコーディングは、最適化を必要としません。
If a bundle is fragmented before the PIB is applied, then the PIB applies to a fragment and not the entire bundle. However, the protected fragment could be subsequently further fragmented, which would leave the verifier unable to know which bytes were protected by the PIB. Even in the absence of fragmentation, the same situation applies if the ciphersuite is defined to allow protection of less than the entire, original bundle payload.
PIBが適用される前に、バンドルが断片化されている場合、PIBは、フラグメント全体ではなく、バンドルに適用されます。ただし、保護された断片は、PIBによって保護されたバイトを知ることができない検証を残すであろう、その後さらに断片化することができました。暗号スイートは、全体、原稿束ペイロード未満の保護を可能にするために定義されている場合でも、フラグメンテーションが存在しない場合には、同じ状況が適用されます。
For this reason, PIB ciphersuites that support applying a PIB to less than the complete, original bundle payload MUST specify, as part of the ciphersuite-parameters, which bytes of the bundle payload are protected. When verification occurs, only the specified range of the payload bytes are input to PIB verification. It is valid for a ciphersuite to be specified so as to only apply to entire bundles and not to fragments. A ciphersuite MAY be specified to apply to only a portion of the payload, regardless of whether the payload is a fragment or the complete, original bundle payload.
この理由のため、完全な、原稿束ペイロード以下にPIBを適用サポートPIBの暗号スイートは、保護されているバンドルペイロードのバイト暗号のパラメータの一部として、指定しなければなりません。検証が発生したときに、ペイロードバイトの唯一の指定された範囲は、PIB検証に入力されます。唯一の全体の束にしていないフラグメントに適用するように暗号スイートを指定することが有効です。暗号スイートにかかわらず、ペイロードがフラグメントまたは完全な、原稿束ペイロードであるかどうかの、ペイロードの一部のみに適用するように指定することができます。
The same fragmentation issue applies equally to PCB ciphersuites. Ciphersuites that support applying confidentiality to fragments MUST specify, as part of the ciphersuite-parameters, which bytes of the bundle payload are protected. When decrypting a fragment, only the specified bytes are processed. It is also valid for a confidentiality ciphersuite to be specified so as to only apply to entire bundles and not to fragments.
同じ断片化の問題は、PCBの暗号スイートにも同様に適用されます。フラグメントに機密性を適用サポート暗号スイートは、バンドルペイロードのバイトが保護されている暗号のパラメータの一部として、指定しなければなりません。断片を復号化する際、必ず指定のバイトが処理されます。唯一の全体の束にしていないフラグメントに適用するように機密性の暗号スイートを指定することも有効です。
This definition of mutable canonicalization assumes that endpoint IDs themselves are immutable and is unsuitable for use in environments where that assumption might be violated.
変更可能な正規のこの定義は、エンドポイントのID自体は不変であると仮定し、その仮定に違反する可能性がある環境での使用には適しません。
The canonicalization applies to a specific bundle and not a specific payload. If a bundle is forwarded in some way, the recipient is not able to verify the original integrity signature since the source EID will be different, and possibly other fields.
正規化は、特定のバンドルではなく、特定のペイロードに適用されます。束が何らかの方法で転送される場合、ソースEIDが異なること、およびおそらく他のフィールドので、受信者は、元の完全性の署名を確認することができません。
The solution for either of these issues is to define and use a PIB ciphersuite having an alternate version of mutable canonicalization any fields from the primary block.
これらの問題のいずれかのための解決策は、可変正規化の代替バージョン主要ブロックから任意のフィールドを有するPIBの暗号スイートを定義して使用することです。
Every bundle MUST contain a primary block that contains the source and destination endpoint IDs, and possibly other EIDs (in the dictionary field), and that cannot be encrypted. If endpoint ID confidentiality is required, then bundle-in-bundle encapsulation can solve this problem in some instances.
すべてのバンドルは、ソースおよび宛先エンドポイントID、および（辞書フィールドで）おそらく他のEIDを含有する一次ブロックを含まなければなりません、そしてそれは、暗号化することができません。エンドポイントIDの機密性が必要な場合は、バンドル・イン・バンドルカプセル化は、いくつかの例では、この問題を解決することができます。
Similarly, confidentiality requirements MAY also apply to other parts of the primary block (e.g., the current-custodian), and that is supported in the same manner.
同様に、機密性の要件は、プライマリブロック（例えば、電流カストディアン）の他の部分に適用されることがあり、それは同様に支持されています。
Nodes implementing this specification SHALL consult their security policy to determine whether or not a received bundle is required by policy to include a BAB. If the bundle has no BAB, and one is not required, then BAB processing on the received bundle is complete, and the bundle is ready to be further processed for PIB/PCB/ESB handling or delivery or forwarding.
この仕様を実装するノードが受信バンドルはBABを含めるようにポリシーによって必要とされているかどうかを判断するために、セキュリティポリシーを協議します。バンドルがないBABがなく、いずれかが必要とされない場合、受信したバンドルにBAB処理が完了し、バンドルはさらにPIB / PCB / ESB処理または送達または転送のために処理する準備ができています。
If the bundle is required to have a BAB but does not, then the bundle MUST be discarded and processed no further. If the bundle is required to have a BAB but all of its BABs identify a node other than the receiving node as the BAB security-destination, then the bundle MUST be discarded and processed no further.
バンドルはBABを持つことが必要ですが、その後、バンドルを捨てなければなりませんし、それ以上処理されていないしていない場合。バンドルはBABが要求されるが、そのBABSの全てがBABセキュリティ先として受信したノード以外のノードを識別し、次いで束を捨てなければならなくて、さらなる処理しない場合。
If the bundle is required to have a BAB, and has one or more BABs that identify the receiving node as the BAB security-destination, or for which there is no security-destination, then the value in the security-result field(s) of the BAB(s) MUST be verified according to the ciphersuite specification. If, for all such BABs in the bundle, either the BAB security source cannot be determined or the security-result value check fails, the bundle has failed to authenticate, and the bundle MUST be discarded and processed no further. If any of the BABs present verify, or if a BAB is not required, the bundle is ready for further processing as determined by extension blocks and/or policy.
バンドルはBABが必要、及びBABセキュリティ先として受信ノードを識別する1つ以上のBABSを有している場合、またはそのためにはセキュリティ先、セキュリティ結果フィールドにその値（複数可）が存在しませんBAB（単数または複数）の暗号スイート仕様に従って検証されなければなりません。 、バンドル内のすべてのそのようバブスのために、BABセキュリティソースを決定することができないか、セキュリティ、結果の値チェックが失敗したいずれかの場合は、バンドルは認証に失敗しました、とバンドルは破棄され、それ以上処理されてはなりません。 BABSのいずれかが存在するかどうかを確認、またはBABが必要とされない場合に拡張ブロックおよび/またはポリシーによって決定されるように、バンドルは、さらなる処理のために準備ができています。
BABs received in a bundle MUST be stripped before the bundle is forwarded. New BABs MAY be added as required by policy. This MAY require correcting the "last block" field of the to-be-forwarded bundle.
バンドルが転送される前に、バンドルで受信バブスは取り除かなければなりません。ポリシーで必要とされる新バブスを添加してもよいです。これは、TO--転送するバンドルの「最後のブロック」のフィールドを修正する必要になる場合があります。
Further processing of the bundle MUST take place in the order indicated by the various blocks from the primary block to the payload block, except as defined by an applicable specification.
バンドルのさらなる処理は、適用可能な仕様で定義される場合を除き、ペイロードブロックに一次ブロックから各ブロックで示される順序で行わなければなりません。
If the bundle has a PCB and the receiving node is the PCB-destination for the bundle (either because the node is listed as the bundle's PCB-destination or because the node is listed as the bundle-destination and there is no PCB-dest), the node MUST decrypt the relevant parts of the bundle in accordance with the ciphersuite specification. The PCB SHALL be deleted. If the relevant parts of the bundle cannot be decrypted (i.e., the decryption key cannot be deduced or decryption fails), then the bundle MUST be discarded and processed no further; in this case, a bundle deletion status report (see the Bundle Protocol Specification [DTNBP]) indicating the decryption failure MAY be generated. If the PCB security-result included the ciphertext of a block other than the payload block, the recovered plaintext block MUST be placed in the bundle at the location from which the PCB was deleted.
バンドルは、PCBを有し、受信ノードは、バンドルのPCB-宛先（ノードがバンドルのPCB先として記載されているため、またはノードがバンドル先として記載されているため、ノーPCB-DESTがないのいずれか）である場合、ノードは、暗号スイート仕様に従ってバンドルの関連部分を解読しなければなりません。 PCBは削除されるものとします。バンドルの関連する部分（すなわち、復号鍵を導き出すことができない、または復号化に失敗した）復号化できない場合、バンドルは捨てなければならなくて、さらなる処理しません。この場合、バンドル削除ステータスレポートは、復号失敗を示す生成されてもよい（バンドルプロトコル仕様[DTNBP]を参照します）。 PCBセキュリティ結果は、ペイロード・ブロック以外のブロックの暗号文が含まれている場合、回収された平文ブロックは、PCBが削除された場所に束に配置する必要があります。
If the bundle has one or more PIBs for which the receiving node is the bundle's PIB-destination (either because the node is listed in the bundle's PIB-destination or because the node is listed as the bundle-destination and there is no PIB-dest), the node MUST verify the value in the PIB security-result field(s) in accordance with the ciphersuite specification. If all the checks fail, the bundle has failed to authenticate and the bundle SHALL be processed according to the security policy. A bundle status report indicating the failure MAY be generated. Otherwise, if the PIB verifies, the bundle is ready to be processed for either delivery or forwarding. Before forwarding the bundle, the node SHOULD remove the PIB from the bundle, subject to the requirements of Section 3.2, unless it is likely that some downstream node will also be able to verify the PIB.
バンドルは、受信ノードがバンドルのPIB先された一の以上のPIB（ノードは、バンドルのPIB先に記載されているいずれかのため場合、またはノードがバンドル先として記載されているため、ノーPIB-DESTは存在しません）、ノードは、暗号スイート仕様に従ってPIBセキュリティ結果フィールド（複数可）の値を確認しなければなりません。すべてのチェックが失敗した場合、バンドルは認証に失敗しましたとのバンドルは、セキュリティポリシーに従って処理されるものとします。失敗を示すバンドルステータスレポートを生成することができます。 PIBが確認した場合にそれ以外の場合は、バンドルは配信や転送のいずれかのために処理する準備ができています。いくつかの下流ノードにもPIBを確認することができるようになります可能性がある場合を除きバンドルを転送する前に、ノードは、セクション3.2の要件に従う、バンドルからPIBを削除する必要があります。
If the bundle has a PIB and the receiving node is not the bundle's PIB-dest, the receiving node MAY attempt to verify the value in the security-result field. If it is able to check and the check fails, the node SHALL discard the bundle and it MAY send a bundle status report indicating the failure.
バンドルがPIBを持っており、受信ノードは、バンドルのPIB-DESTされていない場合、受信ノードは、セキュリティ、結果フィールドの値を検証しようとすることができます。それは確認することができるし、チェックが失敗した場合、ノードは、バンドルを廃棄すると、それは失敗を示すバンドルステータスレポートを送信することができます。
If the bundle has an ESB and the receiving node is the ESB-destination for the bundle (either because the node is listed as the bundle's ESB-destination or because the node is listed as the bundle-destination and there is no ESB-destination), the node MUST decrypt and/or decapsulate the encapsulated block in accordance with the ciphersuite specification. The decapsulated block replaces the ESB in the bundle block sequence, and the ESB is thereby deleted. If the content cannot be decrypted (i.e., the decryption key cannot be deduced or decryption fails), then the bundle MAY be discarded and processed no further unless the security policy specifies otherwise. In this case, a bundle deletion status report (see the Bundle Protocol Specification [DTNBP]) indicating the decryption failure MAY be generated.
バンドルは、ESBを有し、受信ノードは、バンドルのESB-宛先（ノードがバンドルのESB-先として記載されているため、またはノードがバンドル先として記載されているため、ノーESB-先が存在しないのいずれか）である場合、ノードは、復号化及び/又は暗号スイート仕様に従ってカプセル化されたブロックをデカプセル化しなければなりません。デカプセル化ブロックは、バンドルブロックシーケンスでESBを置き換え、およびESBは、それによって削除されます。コンテンツは（すなわち、復号鍵を推測することはできませんまたは復号化に失敗した）復号化できない場合は、セキュリティポリシーが別途定める場合を除き、その後、バンドルには、さらに廃棄されていないと処理されてもよいです。この場合、バンドル削除ステータスレポートは、復号失敗を示す生成されてもよい（バンドルプロトコル仕様[DTNBP]を参照します）。
An application MAY request (in an implementation-specific manner) that a node be registered as a member of an endpoint and that received bundles destined for that endpoint be delivered to that application.
ノードは、エンドポイントのメンバーとそのエンドポイントに宛てられている受信バンドルとして登録すること（実装固有の方法で）アプリケーションMAY要求がそのアプリケーションに配信されます。
An option for use in such cases is known as "at-most-once-delivery". If this option is chosen, the application indicates that it wants the node to check for duplicate bundles, discard duplicates, and deliver at most one copy of each received bundle to the application. If this option is not chosen, the application indicates that it wants the node to deliver all received bundle copies to the application. If this option is chosen, the node SHALL deliver at most one copy of each received bundle to the application. If the option is not chosen, the node SHOULD, subject to policy, deliver all bundles.
このような場合に使用するためのオプションは、「最大1回配信」として知られています。このオプションを選択すると、アプリケーションは、ノードが、重複したバンドルをチェックし、重複を破棄し、アプリケーションに受信された各バンドルの最大1つのコピーを提供したいと考えていることを示しています。このオプションが選択されていない場合、アプリケーションは、アプリケーションに受信したすべてのバンドルのコピーを提供するためにノードを望んでいることを示しています。このオプションを選択すると、ノードがアプリケーションに受信された各バンドルの最大1つのコピーを交付しなければなりません。オプションが選択されていない場合、ノードは、ポリシーの対象、すべてのバンドルを提供する必要があります。
To enforce this, the node MUST look at the source/timestamp pair value of each complete (reassembled, if necessary) bundle received and determine if this pair, which uniquely identifies a bundle, has been previously received. If it has, then the bundle is a duplicate. If it has not, then the bundle is not a duplicate. The source/ timestamp pair SHALL be added to the list of pair values already received by that node.
これを強制するために、ノードは、それぞれ（必要に応じて、再組み立て）は、完全な束のソース/タイムスタンプペアの値で受信見て一意にバンドルを識別するこのペアは、以前に受信されたかどうかを決定しなければなりません。それがある場合、バンドルが重複しています。それがない場合、バンドルは重複ではありません。ソース/タイムスタンプの対が既にそのノードによって受信された一対の値のリストに追加されるものとします。
Each node implementation MAY decide how long to maintain a table of pair value state.
各ノードの実装では、ペア値状態のテーブルを維持するためにどのくらい決めることができます。
If it is necessary for a node to fragment a bundle and security services have been applied to that bundle, the fragmentation rules described in [DTNBP] MUST be followed. As defined there and repeated here for completeness, only the payload MAY be fragmented; security blocks, like all extension blocks, can never be fragmented. In addition, the following security-specific processing is REQUIRED:
ノードバンドルを断片化し、セキュリティサービスは、そのバンドルに適用されていることが必要である場合、[DTNBP]に記載の断片化規則に従わなければなりません。そこに定義されて万全を期すためにここで繰り返すと、ペイロードだけが断片化してもよい（MAY）。セキュリティブロックは、すべての拡張ブロックのように、断片化することはできません。また、次のセキュリティ固有の処理が必要となります。
The security policy requirements for a bundle MUST be applied individually to all the bundles resulting from a fragmentation event.
バンドルのセキュリティポリシー要件は、断片化のイベントから生じたすべてのバンドルに個別に適用されなければなりません。
If the original bundle contained a PIB, then each of the PIB instances MUST be included in some fragment.
原稿束は、PIBを含有していた場合、各PIBインスタンスのは、いくつかの断片に含まれなければなりません。
If the original bundle contained one or more PCBs, then any PCB instances containing a key-information item MUST have the "replicate in every fragment" flag set, and thereby be replicated in every fragment. This is to ensure that the canonical block-sequence can be recovered during reassembly.
原稿束は、1つの以上のPCBが含まれている場合、キー情報項目を含む任意のPCBのインスタンスは、「各断片に複製」フラグを設定する必要があり、それによってすべての断片に複製されます。これは、標準的なブロックシーケンスが再構築中に回収できるようにすることです。
If the original bundle contained one or more correlated PCBs not containing a key-information item, then each of these MUST be included in some fragment, but SHOULD NOT be sent more than once. They MUST be placed in a fragment in accordance with the fragmentation rules described in [DTNBP].
原稿束は、キー情報項目を含まない一つまたはそれ以上の相関のPCBが含まれている場合、これらのそれぞれは、いくつかの断片に含まれなければならないが、複数回送信されるべきではありません。彼らは[DTNBP]に記載の断片化規則に従って断片に置かなければなりません。
Note: various fragments MAY have additional security blocks added at this or later stages, and it is possible that correlators will collide. In order to facilitate uniqueness, ciphersuites SHOULD include the fragment-offset of the fragment as a high-order component of the correlator.
注意：様々なフラグメントは、この以降の段階で追加された追加のセキュリティ・ブロックを持っているかもしれません、相関が衝突する可能性があります。一意性を容易にするために、暗号スイートは、相関器の高次成分として断片オフセット断片を含むべきです。
When a partial bundle has been received, the receiving node SHALL consult its security policy to determine if it MAY fragment the bundle, converting the received portion into a bundle fragment for further forwarding. Whether or not reactive fragmentation is permitted SHALL depend on the security policy and the ciphersuite used to calculate the BAB authentication information, if required. (Some BAB ciphersuites, i.e., the mandatory BAB-HMAC (Hashed Message Authentication Code) ciphersuite defined in Section 4.1, do not accommodate reactive fragmentation because the security-result in the BAB requires that the entire bundle be signed. It is conceivable, however, that a BAB ciphersuite could be defined such that multiple security-results are calculated, each on a different segment of a bundle, and that these security-results could be interspersed between bundle payload segments such that reactive fragmentation could be accommodated.)
部分的なバンドルを受信した場合、受信ノードは、それがさらに転送のバンドルフラグメントに受信変換部、バンドルを断片化可能性がある場合を決定するために、そのセキュリティポリシーを協議しなければなりません。反応性の断片化が許可されているかどうかは、セキュリティポリシーおよび必要に応じて、BAB認証情報を計算するために使用される暗号スイートに依存しないものとします。セクション4.1で定義されている（一部BAB暗号群、すなわち、必須BAB-HMAC（ハッシュメッセージ認証コード）暗号スイートBABにおけるセキュリティ結果がバンドル全体が署名する必要があるため、反応性の断片化に対応していない。しかし、考えられます、BABの暗号スイートは、バンドルの異なるセグメントにそれぞれ、複数のセキュリティ結果が算出されるように定義され、これらのセキュリティの結果は、反応フラグメンテーションを収容することができるようにバンドルペイロードセグメント間に散在することができることをすることができること。）
If the bundle is reactively fragmented by the intermediate receiver and the BAB-ciphersuite is of an appropriate type (e.g., with multiple security-results embedded in the payload), the bundle MUST be fragmented immediately after the last security-result value in the partial payload that is received. Any data received after the last security-result value MUST be dropped.
バンドルは反応性中間体受信機によって断片化およびBAB-暗号スイートは、（ペイロードに埋め込まれた複数のセキュリティ・結果と例えば、）適切なタイプのものである場合、バンドルは部分的に最後のセキュリティ結果値の直後に断片化されなければなりません受信されたペイロード。最後に、セキュリティ・結果値の後に受け取ったデータはすべて削除する必要があります。
If a partial bundle is received at the intermediate receiver and is reactively fragmented and forwarded, only the part of the bundle that was not received MUST be retransmitted, though more of the bundle MAY be retransmitted. Before retransmitting a portion of the bundle, it SHALL be changed into a fragment and, if the original bundle included a BAB, the fragmented bundle MUST also, and its BAB SHALL be recalculated.
部分束が中間受信機で受信され、反応的に断片化され、転送された場合、バンドルの複数が再送してもよいが、受信されなかった束の一部のみが、再送信されなければなりません。束の一部を再送信する前に、それがフラグメントに変更されるものとし、原稿束はBABが含まれている場合、断片化されたバンドルもなければならず、そのBABが再計算されるものとします。
This specification does not define any ciphersuite that can handle this reactive fragmentation case.
この仕様は、この反応フラグメンテーションケースを扱うことができる任意の暗号を定義していません。
An interesting possibility is a ciphersuite definition such that the transmission of a follow-up fragment would be accompanied by the signature for the payload up to the restart point.
興味深い可能性は、フォローアップの断片の送信が再開点までのペイロードの署名を伴うことになること暗号スイート定義なものです。
An evaluation of resilience to cryptographic attack necessarily depends upon the algorithms chosen for bulk data protection and for key transport. The mandatory ciphersuites described in the following section use AES, RSA, and SHA algorithms in ways that are believed to be reasonably secure against ciphertext-only, chosen-ciphertext, known-plaintext, and chosen-plaintext attacks.
暗号の攻撃に弾力性の評価は必ずしもバルクデータ保護のために、キーの輸送のために選ばれたアルゴリズムに依存します。以下のセクションで使用AES、RSA、およびSHA暗号文のみ、選択暗号文に対して合理的に安全であると考えられている方法で、アルゴリズムは、既知平文、及び選択平文攻撃に記載必須の暗号スイート。
The design has carefully preserved the resilience of the algorithms against attack. For example, if a message is encrypted, then any message integrity signature is also encrypted so that guesses cannot be confirmed.
デザインは、攻撃に対するアルゴリズムの回復力を慎重に保存されています。メッセージが暗号化されている場合は推測が確認できないように、例えば、その後、任意のメッセージの整合性の署名も暗号化されています。
This section defines the mandatory ciphersuites for this specification. There is currently one mandatory ciphersuite for use with each of the security block types BAB, PIB, PCB, and ESB. The BAB ciphersuite is based on shared secrets using HMAC. The PIB ciphersuite is based on digital signatures using RSA with SHA-256. The PCB and ESB ciphersuites are based on using RSA for key transport and AES for bulk encryption.
このセクションでは、この仕様のために必須暗号スイートを定義します。セキュリティブロックタイプBAB、PIB、PCB、およびESBのそれぞれで使用するための1つの必須暗号スイートは現在あり。 BABの暗号スイートがHMACを使用して、共有秘密に基づいています。 PIBの暗号スイートは、SHA-256でRSAを使用してデジタル署名に基づいています。 PCBおよびESB暗号スイートは、バルク暗号化のための鍵の輸送およびAESのためにRSAを使用することに基づいています。
In all uses of CMS eContent in this specification, the relevant eContentType to be used is id-data as specified in [RFC5652].
本明細書におけるCMS e-コンテンツのすべての使用において、使用される関連のeContentTypeは[RFC5652]で指定されるように、IDデータです。
The ciphersuites use the mechanisms defined in Cryptographic Message Syntax (CMS) [RFC5652] for packaging the keys, signatures, etc., for transport in the appropriate security block. The data in the CMS object is not the bundle data, as would be the typical usage for CMS. Rather, the "message data" packaged by CMS is the ephemeral key, message digest, etc., used in the core code of the ciphersuite.
暗号スイートは、適切なセキュリティブロック内輸送のために、等、鍵、署名を包装するための暗号メッセージ構文（CMS）で定義されたメカニズム[RFC5652]を使用します。 CMSの一般的な使用法であるようCMSオブジェクト内のデータは、バンドルデータはありません。むしろ、CMSによってパッケージ化「メッセージデータは、」暗号スイートのコアコードで使用される短期キー、メッセージダイジェスト、等、です。
In all cases where we use CMS, implementations SHOULD NOT include additional attributes whether signed or unsigned, authenticated or unauthenticated.
私たちはCMSを使用するすべてのケースでは、実装は符号付きまたは符号なし、認証済みまたは認証されていないかどうか追加の属性を含めるべきではありません。
The BAB-HMAC ciphersuite has ciphersuite ID value 0x001.
BAB-HMACの暗号スイートは、暗号スイートID値0x001を持っています。
BAB-HMAC uses the strict canonicalization algorithm in Section 3.4.1.
BAB-HMACは、セクション3.4.1における厳格な正規化アルゴリズムを使用しています。
Strict canonicalization supports digesting of a fragment-bundle. It does not permit the digesting of only a subset of the payload, but only the complete contents of the payload of the current bundle, which might be a fragment. The fragment-range item for security-parameters is not used to indicate a fragment, as this information is digested within the primary block.
厳格な標準化は、フラグメント・バンドルの消化をサポートしています。これは、フラグメントであるかもしれない、ペイロードのサブセットのみの消化を可能にするが、現在のバンドルのペイロードの唯一の完全な内容はありません。この情報は、一次ブロック内で消化されるように、セキュリティパラメータの断片レンジ項目は、断片を示すために使用されていません。
The variant of HMAC to be used is HMAC-SHA1 as defined in [RFC2104].
[RFC2104]で定義されるように使用されるHMACの変異体は、HMAC-SHA1です。
This ciphersuite requires the use of two related instances of the BAB. It involves placing the first BAB instance (as defined in Section 2.2) just after the primary block. The second (correlated) instance of the BAB MUST be placed after all other blocks (except possibly other BAB blocks) in the bundle.
この暗号スイートは、BABの二つの関連のインスタンスを使用する必要があります。 （セクション2.2で定義されるように）それだけで、一次ブロックした後、最初のBABインスタンスを配置することを含みます。 BABの第二（相関関係）のインスタンスがバンドル内の（おそらく他のBABブロックを除く）全ての他のブロックの後に配置されなければなりません。
This means that, normally, the BAB will be the second and last blocks of the bundle. If a forwarder wishes to apply more than one correlated BAB pair, then this can be done. There is no requirement that each application "wrap" the others, but the forwarder MUST insert all the "up front" BABs, and their "at back" "partners" (without any security-result), before canonicalizing.
これは通常、BABは、バンドルの第二及び最後のブロックになります、ということを意味します。フォワーダが複数の相関BABペアを適用したい場合、これは行うことができます。各アプリケーションが他の人を「ラップ」が、フォワーダがcanonicalizing前に、すべての「フロントアップ」バブスを挿入し、（任意のセキュリティ結果なし）その「裏で」「パートナー」しなければならない必要はありません。
Inserting more than one correlated BAB pair would be useful if the bundle could be routed to more than one potential "next hop" or if both an old and a new key were valid at sending time, with no certainty about the situation that will obtain at reception time.
バンドルは、複数の潜在的な「次のホップ」または古いものと新しいキーの両方がで取得する状況についての確信を持って、時間を送ることに有効であった場合にルーティングすることができれば、複数の相関BABのペアを挿入すると有用であろう受付時間。
The security-result is the output of the HMAC-SHA1 calculation with the input being the result of running the entire bundle through the strict canonicalization algorithm. Both required BAB instances MUST be included in the bundle before canonicalization.
セキュリティ結果は、入力が厳密な正規化アルゴリズムを介して全体の束を実行した結果であるとHMAC-SHA1の計算の出力です。どちらも必要なBABインスタンスは、正規化前のバンドルに含まれなければなりません。
Security-parameters are OPTIONAL with this scheme, but if used, then the only field that can be present is key-information (see Section 2.6).
セキュリティ・パラメータは、この方式ではオプションですが、使用している場合、その後、存在することができる唯一のフィールドは、キー情報は、（2.6節を参照）です。
In the absence of key-information, the receiver is expected to be able to find the correct key based on the sending identity. The sending identity MAY be known from the security-source field or the content of a previous-hop block in the bundle. It MAY also be determined using implementation-specific means such as the convergence layer.
鍵情報がない場合、受信機は、送信IDに基づいて正しい鍵を見つけることができると期待されます。送信アイデンティティは、セキュリティ・ソース・フィールドまたはバンドル内の前のホップブロックの内容から知ることができます。また、そのような収束層として実装固有の手段を用いて決定することができます。
The PIB-RSA-SHA256 ciphersuite has ciphersuite ID value 0x02.
PUB-RSA-SHA256暗号スイートは、暗号スイートのID値が0x02を持っています。
PIB-RSA-SHA256 uses the mutable canonicalization algorithm in Section 3.4.2, with the security-result data field for only the "current" block being excluded from the canonical form. The resulting canonical form of the bundle is the input to the signing process. This ciphersuite requires the use of a single instance of the PIB.
PIB-RSA-SHA256が正規の形式から除外されているだけで、「現在」のブロックのためのセキュリティ・結果データのフィールドで、セクション3.4.2における変更可能な正規化アルゴリズムを使用しています。束の得られた標準形は、署名プロセスに入力されます。この暗号スイートは、PIBの単一のインスタンスを使用する必要があります。
Because the signature field in SignedData SignatureValue is a security-result field, the entire key-information item MUST be placed in the block's security-result field, rather than security-parameters.
SignedData SignatureValueで署名フィールドは、セキュリティ結果フィールドであるため、全体のキー情報項目ではなく、セキュリティパラメータよりも、ブロックのセキュリティ結果フィールドに置かれなければなりません。
If the bundle being signed has been fragmented before signing, then we have to specify which bytes were signed in case the signed bundle is subsequently fragmented for a second time. If the bundle is a fragment, then the ciphersuite-parameters MUST include a fragment-range field, as described in Section 2.6, specifying the offset and length of the signed fragment. If the entire bundle is signed, then these numbers MUST be omitted.
署名されているバンドルが署名する前に断片化されている場合、我々は、署名されたバンドルが二度目の後に断片化されている場合に調印されたバイト数を指定する必要があります。バンドルがフラグメントである場合、セクション2.6で説明したように、その後、暗号のパラメータは、署名されたフラグメントのオフセットおよび長さを指定し、断片レンジフィールドを含まなければなりません。バンドル全体が署名されている場合、これらの数字は省略しなければなりません。
Implementations MUST support the use of the "SignedData" type as defined in [RFC5652], Section 5.1, with SignerInfo type SignerIdentifier containing the issuer and serial number of a suitable certificate. The data to be signed is the output of the SHA256 mutable canonicalization process.
[RFC5652]で定義されるような実装は、発行者と適切な証明書のシリアル番号を含むのSignerInfo型SignerIdentifierと、セクション5.1「のSignedData」タイプの使用をサポートしなければなりません。署名されるべきデータは、SHA256可変正規化プロセスの出力です。
RSA is used with SHA256 as specified for the id-sha256 signature scheme in [RFC4055], Section 5. The output of the signing process is the SignatureValue field for the PIB.
[RFC4055]でのID-SHA256署名方式に指定されたRSAはSHA256で使用され、第5署名プロセスの出力は、PIBのためSignatureValueフィールドです。
"Commensurate strength" cryptography is generally held to be a good idea. A combination of RSA with SHA-256 is reckoned to require a 3076-bit RSA key according to this logic. Few implementations will choose this length by default (and probably some just will not support such long keys). Since this is an experimental protocol, we expect that 1024- or 2048-bit RSA keys will be used in many cases, and that this will be fine since we also expect that the hash function "issues" will be resolved before any standard would be derived from this protocol.
「見合っ力」暗号が一般的に良いアイデアであることを保持されています。 SHA-256とのRSAの組み合わせは、この論理によれば3076ビットのRSAキーを要求するように数えています。いくつかの実装では、デフォルトでは、この長さを選択します（そしておそらくいくつかは、まさにこのような長いキーをサポートしていません）。これは実験的なプロトコルであるので、我々は1024または2048ビットのRSA鍵は、多くの場合、使用されることを、私たちはまた、任意の標準のようになります前に、ハッシュ関数「問題」は解決されることを期待しているので、これは罰金になることを期待しますこのプロトコルから派生。
The PCB-RSA-AES128-PAYLOAD-PIB-PCB ciphersuite has ciphersuite ID value 0x003.
PCB-RSA-AES128-PAYLOAD-PIB-PCBの暗号スイートは、暗号スイートID値0x003を有します。
This scheme encrypts PIBs, PCBs, and the payload. The key size for this ciphersuite is 128 bits.
このスキームはのPIB、PCB類、およびペイロードを暗号化します。この暗号スイートのための鍵サイズは128ビットです。
Encryption is done using the AES algorithm in Galois/Counter Mode (GCM) as described in [RFC5084]. Note: parts of the following description are borrowed from [RFC4106].
[RFC5084]に記載されるように暗号化はガロア/カウンタ・モード（GCM）でAESアルゴリズムを使用して行われます。注：以下の説明の部分は、[RFC4106]から借用されています。
The choice of GCM avoids expansion of the payload, which causes problems with fragmentation/reassembly and custody transfer. GCM also includes authentication, essential in preventing attacks that can alter the decrypted plaintext or even recover the encryption key.
GCMの選択は、断片化/再構築および管理転送で問題が発生したペイロードの拡大を回避することができます。 GCMはまた、復号された平文を変更したり、暗号化キーを回復することができ、攻撃を防ぐのに不可欠な認証を、含まれています。
GCM is a block cipher mode of operation providing both confidentiality and data integrity. The GCM encryption operation has four inputs: a secret key, an initialization vector (IV), a plaintext, and an input for additional authenticated data (AAD), which is not used here. It has two outputs, a ciphertext whose length is identical to the plaintext, and an authentication tag, also known as the integrity check value (ICV).
GCMは、機密性とデータの整合性の両方を提供するオペレーションのブロック暗号モードです。秘密鍵、初期化ベクトル（IV）、平文、ここで使用されていない追加の認証されたデータ（AAD）、入力：GCM暗号化操作は、4つの入力を有しています。これは、2つの出力、長さが平文と同一であり、また、整合性チェック値（ICV）として知られている認証タグ、暗号文を有します。
For consistency with the description in [RFC5084], we refer to the GCM IV as a nonce. The same key and nonce combination MUST NOT be used more than once. The nonce has the following layout:
[RFC5084]の記述に一貫性を保つために、我々はナンスとしてGCM IVを参照してください。同じ鍵とナンスの組み合わせを複数回使用してはいけません。ナンスは、次のようなレイアウトになっています。
+----------------+----------------+----------------+----------------+
| salt |
+----------------+----------------+----------------+----------------+
| |
| initialization vector |
| |
+----------------+----------------+----------------+----------------+
Figure 6: Nonce Format for PCB-RSA-AES128-PAYLOAD-PIB-PCB
図6：PCB-RSA-AES128-PAYLOAD-PIB-PCBのためのノンスフォーマット
The salt field is a four-octet value, usually chosen at random. It MUST be the same for all PCBs that have the same correlator value. The salt need not be kept secret.
塩田は、通常はランダムに選ばれた4オクテット値、です。これは、同じ相関値を持つすべてのPCBに対して同じでなければなりません。塩は秘密にする必要はありません。
The initialization vector (IV) is an eight-octet value, usually chosen at random. It MUST be different for all PCBs that have the same correlator value. The value need not be kept secret.
初期化ベクトル（IV）は、通常、ランダムに選択された8オクテット値です。これは、同じ相関値を持つすべてのPCBに対して異なっている必要があります。値は秘密にする必要はありません。
The key (bundle encryption key, BEK) is a 16-octet (128 bits) value, usually chosen at random. The value MUST be kept secret, as described below.
キー（バンドル暗号鍵、BEK）は、通常、ランダムに選択された16オクテット（128ビット）の値です。後述のように値が、秘密にしなければなりません。
The integrity check value is a 16-octet value used to verify that the protected data has not been altered. The value need not be kept secret.
整合性チェック値は、保護されたデータが変更されていないことを確認するために使用される16オクテットの値です。値は秘密にする必要はありません。
This ciphersuite requires the use of a single PCB instance to deal with payload confidentiality. If the bundle already contains PIBs or PCBs, then the ciphersuite will create additional correlated blocks to protect these PIBs and PCBs. These "additional" blocks replace the original blocks on a one-to-one basis, so the number of blocks remains unchanged. All of these related blocks MUST have the same correlator value. The term "first PCB" in this section refers to the single PCB if there is only one or, if there are several, then to the one containing the key-information. This MUST be the first of the set.
この暗号スイートは、ペイロードの機密性に対処するために、単一のPCBのインスタンスを使用する必要があります。バンドルがすでにのPIBかのPCBが含まれている場合、暗号スイートは、これらのPIBとPCBを保護するために、追加の相関ブロックを作成します。これらの「追加」ブロックが1対1で、元のブロックを交換するので、ブロックの数は変わりません。これらの関連ブロックのすべては、同じ相関値を持たなければなりません。 1つまたはが存在する場合、キー情報を含むものであり、いくつかがある場合の用語このセクションにおける「第1のPCB」は、単一のPCBを指します。これは、セットの最初でなければなりません。
First PCB - the first PCB MAY contain a correlator value, and MAY specify security-source and/or security-destination in the EID-list. If not specified, the bundle-source and bundle-destination, respectively, are used for these values, as with other ciphersuites. The block MUST contain security-parameters and security-result fields. Each field MAY contain several items formatted as described in Section 2.6.
まずPCB - 最初のPCBは、相関値を含んでいてもよく、EID-listにセキュリティのソースおよび/またはセキュリティ先を指定するかもしれません。 、束源およびバンドルの宛先を指定しない場合、それぞれ、他の暗号スイートと同様に、これらの値のために使用されます。ブロックは、セキュリティパラメータとセキュリティ結果フィールドを含まなければなりません。各フィールドには、2.6節で説明したようにフォーマットされたいくつかの項目を含むかもしれません。
Security-parameters
セキュリティパラメータ
key-information
鍵情報
salt
塩
IV (this instance applies only to payload)
IV（この例では、ペイロードのみに適用されます）
fragment offset and length, if bundle is a fragment
バンドルがフラグメントである場合はフラグメントは、オフセットおよび長さ
Security-result
セキュリティ結果
ICV
ICV
Subsequent PCBs MUST contain a correlator value to link them to the first PCB. Security-source and security-destination are implied from the first PCB; however, see the discussion in Section 2.4 concerning EID-list entries. They MUST contain security-parameters and security-result fields as follows:
以降のPCBは最初のPCBにリンクする相関値を含まなければなりません。セキュリティ・ソースとセキュリティ先は、最初のPCBから暗示されています。ただし、EIDリストエントリに関するセクション2.4での議論を参照してください。次のように彼らは、セキュリティ・パラメータとセキュリティ結果フィールドを含まなければなりません：
Security-parameters
セキュリティパラメータ
IV for this specific block
この特定のブロックのためにIV
Security-result
セキュリティ結果
encapsulated block
カプセル化されたブロック
The security-parameters and security-result fields in the subsequent PCBs MUST NOT contain any items other than these two. Items such as key and salt are supplied in the first PCB and MUST NOT be repeated.
その後のPCB類のセキュリティ・パラメータとセキュリティ結果フィールドは、これら2以外のすべての項目を含めることはできません。そのようなキーや塩などの項目は、最初のPCBに供給され、繰り返されてはなりません。
Implementations MUST support use of "enveloped-data" type as defined in [RFC5652], Section 6, with RecipientInfo type KeyTransRecipientInfo containing the issuer and serial number of a suitable certificate. They MAY support additional RecipientInfo types. The "encryptedContent" field in EncryptedContentInfo contains the encrypted BEK that protects the payload and certain security blocks of the bundle.
[RFC5652]で定義されるような実装は、のRecipientInfoタイプKeyTransRecipientInfoは、発行者と適切な証明書のシリアル番号を含むとともに、第6の「エンベロープデータ」タイプの使用をサポートしなければなりません。彼らは、追加のRecipientInfoタイプをサポートするかもしれません。 EncryptedContentInfoで「暗号化コンテンツ」フィールドは、ペイロードと、バンドルの特定のセキュリティ・ブロックを保護し、暗号化されBEKが含まれています。
The Integrity Check Value from the AES-GCM encryption of the payload is placed in the security-result field of the first PCB.
ペイロードのAES-GCM暗号化の整合性チェック値は、最初のPCBのセキュリティ-結果フィールドに配置されます。
If the bundle being encrypted is a fragment-bundle, we have to specify which bytes are encrypted in case the bundle is subsequently fragmented again. If the bundle is a fragment, the ciphersuite-parameters MUST include a fragment-range field, as described in Section 2.6, specifying the offset and length of the encrypted fragment. Note that this is not the same pair of fields that appear in the primary block as "offset and length". The "length" in this case is the length of the fragment, not the original length. If the bundle is not a fragment, then this field MUST be omitted.
暗号化されたバンドルがフラグメント・バンドルであれば、私たちはバンドルは、その後再び断片化された場合には暗号化されたバイト数を指定する必要があります。バンドルがフラグメントである場合、セクション2.6で説明したように、暗号のパラメータは、暗号化されたフラグメントのオフセットおよび長さを指定し、断片レンジフィールドを含まなければなりません。これは、「オフセットと長さ」などの主要ブロックに表示されるフィールドの同じペアではないことに留意されたいです。この場合の「長さ」は、断片の長さではなく、元の長さです。バンドルがフラグメントされていない場合、このフィールドは省略しなければなりません。
The confidentiality processing for payload and other blocks is different, mainly because the payload might be fragmented later at some other node.
ペイロード及び他のブロックの秘匿処理は、ペイロードが他のノードで後フラグメント化されるかもしれない主な理由は、異なっています。
For the payload, only the bytes of the bundle payload field are affected, being replaced by ciphertext. The salt, IV, and key values specified in the first PCB are used to encrypt the payload, and the resultant authentication tag (ICV) is placed in an ICV item in the security-result field of that first PCB. The other bytes of the payload block, such as type, flags, and length, are not modified.
ペイロードのために、バンドルペイロードフィールドのバイトのみが、暗号文によって置換され、影響を受けています。最初のPCBで指定された塩、IV、及びキー値は、ペイロードを暗号化するために使用され、得られた認証タグ（ICV）は、その第一PCBのセキュリティ結果フィールドにICVアイテムに配置されます。このようなタイプ、フラグ、および長さのペイロードブロックの他のバイトは、変更されません。
For each PIB or PCB to be protected, the entire original block is encapsulated in a "replacing" PCB. This replacing PCB is placed in the outgoing bundle in the same position as the original block, PIB or PCB. As mentioned above, this is one-to-one replacement, and there is no consolidation of blocks or mixing of data in any way.
各PIB又はPCBを保護するため、全体のオリジナルブロックは、「置換」PCBに封入されています。この置換PCBは、元のブロック、PIBまたはPCBと同じ位置に発信バンドル内に配置されます。上述したように、これは、1対1の交換であり、いかなる方法でもブロックまたはデータの混合のない統合はありません。
The encryption process uses AES-GCM with the salt and key values from the first PCB, and an IV unique to this PCB. The process creates ciphertext for the entire original block and an authentication tag for validation at the security-destination. For this encapsulation process, unlike the processing of the bundle payload, the authentication tag is appended to the ciphertext for the block, and the combination is stored into the encapsulated block item in the security-result.
暗号化プロセスは、塩と最初のPCBからのキー値、およびこのPCBのユニークなIVとAES-GCMを使用しています。プロセス全体元のブロックとセキュリティ先の検証のために認証タグ用の暗号文を生成します。このカプセル化プロセスのために、バンドルペイロードの処理とは異なり、認証タグはブロックの暗号文に付加され、組み合わせは、セキュリティ結果でカプセル化されたブロック項目に格納されます。
The replacing block, of course, also has the same correlator value as the first PCB with which it is associated. It also contains the block-specific IV in security-parameters, and the combination of original-block-ciphertext and authentication tag, stored as an encapsulated block item in the security-result.
交換ブロックは、もちろん、それが関連付けられている第1印刷回路基板と同じ相関値を有します。それはまた、セキュリティ結果にカプセル化されたブロックの項目として格納されたセキュリティ・パラメータのブロック特異IV、及びオリジナルブロック暗号文および認証タグの組み合わせを含んでいます。
If the payload was fragmented after encryption, then all those fragments MUST be present and reassembled before decryption. This process might be repeated several times at different destinations if multiple fragmentation actions have occurred.
ペイロードは、暗号化した後、フラグメント化した場合、それらすべての断片が存在し、復号化の前に再構成されなければなりません。複数の断片化のアクションが発生した場合は、このプロセスは、異なる宛先で数回繰り返される可能性があります。
The size of the GCM counter field limits the payload size to 2^39 - 256 bytes, about half a terabyte. A future revision of this specification will address the issue of handling payloads in excess of this size.
256バイト、約半分テラバイト - GCMカウンタフィールドの大きさは2 ^ 39にペイロードサイズを制限します。この仕様の今後の改正は、このサイズを超えるペイロードを処理する問題に対処します。
The ESB-RSA-AES128-EXT ciphersuite has ciphersuite ID value 0x004.
ESB-RSA-AES128-EXT暗号スイートは、暗号スイートID値0x004を持っています。
This scheme encrypts non-payload-related blocks. It MUST NOT be used to encrypt PIBs, PCBs, or primary or payload blocks. The key size for this ciphersuite is 128 bits.
この方式は、非ペイロード関連のブロックを暗号化します。パブ、PCB類、またはプライマリまたはペイロードのブロックを暗号化するために使用してはいけません。この暗号スイートのキーサイズは128ビットです。
Encryption is done using the AES algorithm in Galois/Counter Mode (GCM) as described in [RFC5084]. Note: parts of the following description are borrowed from [RFC4106].
[RFC5084]に記載されるように暗号化はガロア/カウンタ・モード（GCM）でAESアルゴリズムを使用して行われます。注：以下の説明の部分は、[RFC4106]から借用されています。
GCM is a block cipher mode of operation providing both confidentiality and data origin authentication. The GCM authenticated encryption operation has four inputs: a secret key, an initialization vector (IV), a plaintext, and an input for additional authenticated data (AAD), which is not used here. It has two outputs, a ciphertext whose length is identical to the plaintext, and an authentication tag, also known as the Integrity Check Value (ICV).
GCMは、機密性とデータ発信元認証の両方を提供するオペレーションのブロック暗号モードです。秘密鍵、初期化ベクトル（IV）、平文、ここで使用されていない追加の認証されたデータの入力（AAD）、：GCM認証済み暗号化操作は、4つの入力を有しています。これは、2つの出力、長さが平文と同一であり、また、整合性として知られている認証タグ、値（ICV）を確認し、暗号文を有します。
For consistency with the description in [RFC5084], we refer to the GCM IV as a nonce. The same key and nonce combination MUST NOT be used more than once. The nonce has the following layout:
[RFC5084]の記述に一貫性を保つために、我々はナンスとしてGCM IVを参照してください。同じ鍵とナンスの組み合わせを複数回使用してはいけません。ナンスは、次のようなレイアウトになっています。
+----------------+----------------+---------------------------------+
| salt |
+----------------+----------------+---------------------------------+
| |
| initialization vector |
| |
+----------------+----------------+---------------------------------+
Figure 7: Nonce Format for ESB-RSA-AES128-EXT
図7：ESB-RSA-AES128-EXTのためのノンスフォーマット
The salt field is a four-octet value, usually chosen at random. It MUST be the same for all ESBs that have the same correlator value. The salt need not be kept secret.
塩田は、通常はランダムに選ばれた4オクテット値、です。これは、同じ相関値を持つすべてのESBで同じでなければなりません。塩は秘密にする必要はありません。
The initialization vector (IV) is an eight-octet value, usually chosen at random. It MUST be different for all ESBs that have the same correlator value. The value need not be kept secret.
初期化ベクトル（IV）は、通常、ランダムに選択された8オクテット値です。これは、同じ相関値を持つすべてのESBについて異なっている必要があります。値は秘密にする必要はありません。
The data encryption key is a 16-octet (128 bits) value, usually chosen at random. The value MUST be kept secret, as described below.
データ暗号化キーは、通常、ランダムに選択された16オクテット（128ビット）の値です。後述のように値が、秘密にしなければなりません。
The integrity check value is a 16-octet value used to verify that the protected data has not been altered. The value need not be kept secret.
整合性チェック値は、保護されたデータが変更されていないことを確認するために使用される16オクテットの値です。値は秘密にする必要はありません。
This ciphersuite replaces each BP extension block to be protected with a "replacing" ESB, and each can be individually specified.
この暗号スイートは、「置換」ESBで保護される各BP拡張ブロックを置き換え、それぞれが個別に指定することができます。
If a number of related BP extension blocks are to be protected, they can be grouped as a correlated set and protected using a single key. These blocks replace the original blocks on a one-to-one basis, so the number of blocks remains unchanged. All these related blocks MUST have the same correlator value. The term "first ESB" in this section refers to the single ESB if there is only one or, if there are several, then to the one containing the key or key-identifier. This MUST be the first of the set. If the blocks are individually specified, then there is no correlated set and each block is its own "first ESB".
関連BP拡張ブロックの数が保護される場合、それらは相関セットとしてグループ化され、単一のキーを使用して保護することができます。これらのブロックは、1対1で、元のブロックを交換するので、ブロックの数は変わりません。これらのすべての関連するブロックは、同じ相関値を持たなければなりません。 1つまたはが存在する場合、キーまたはキー識別子を含むものであり、いくつかがある場合、この項における用語「第一ESB」は、単一のESBを指します。これは、セットの最初でなければなりません。ブロックは個別に指定されている場合、そこには相関セットされず、各ブロックはそれ自身の「最初のESB」です。
First ESB - the first ESB MAY contain a correlator value, and MAY specify security-source and/or security-destination in the EID-list. If not specified, the bundle-source and bundle-destination, respectively, are used for these values, as with other ciphersuites. The block MUST contain security-parameters and security-result fields. Each field MAY contain several items formatted as described in Section 2.6.
まずESB - 最初のESBは、相関値を含んでいてもよく、EID-listにセキュリティのソースおよび/またはセキュリティ先を指定するかもしれません。 、束源およびバンドルの宛先を指定しない場合、それぞれ、他の暗号スイートと同様に、これらの値のために使用されます。ブロックは、セキュリティパラメータとセキュリティ結果フィールドを含まなければなりません。各フィールドには、2.6節で説明したようにフォーマットされたいくつかの項目を含むかもしれません。
Security-parameters
セキュリティパラメータ
key-information
鍵情報
salt
塩
IV for this specific block
この特定のブロックのためにIV
block type of encapsulated block (OPTIONAL)
カプセル化されたブロックのブロックタイプ（オプション）
Security-result
セキュリティ結果
encapsulated block
カプセル化されたブロック
Subsequent ESBs MUST contain a correlator value to link them to the first ESB. Security-source and security-destination are implied from the first ESB; however, see the discussion in Section 2.4 concerning EID-list entries. Subsequent ESBs MUST contain security-parameters and security-result fields as follows:
後発のESBは、まずESBにリンクする相関値を含まなければなりません。セキュリティ・ソースとセキュリティ先は、最初のESBから暗示されています。ただし、EIDリストエントリに関するセクション2.4での議論を参照してください。次のように後続のESBには、セキュリティパラメータとセキュリティ結果フィールドを含まなければなりません：
Security-parameters
セキュリティパラメータ
IV for this specific block
この特定のブロックのためにIV
block type of encapsulated block (OPTIONAL)
カプセル化されたブロックのブロックタイプ（オプション）
Security-result
セキュリティ結果
encapsulated block
カプセル化されたブロック
The security-parameters and security-result fields in the subsequent ESBs MUST NOT contain any items other than those listed. Items such as key-information and salt are supplied in the first ESB and MUST NOT be repeated.
セキュリティパラメータとその後のESBにおけるセキュリティ-結果フィールドが記載されている以外のすべての項目を含めることはできません。そのようなキー情報と塩などの項目は、最初のESBに供給され、繰り返されてはなりません。
Implementations MUST support the use of "enveloped-data" type as defined in [RFC5652], Section 6, with RecipientInfo type KeyTransRecipientInfo containing the issuer and serial number of a suitable certificate. They MAY support additional RecipientInfo types. The "encryptedContent" field in EncryptedContentInfo contains the encrypted BEK used to encrypt the content of the block being protected.
[RFC5652]で定義されるような実装は、のRecipientInfoタイプKeyTransRecipientInfoは、発行者と適切な証明書のシリアル番号を含むとともに、第6の「エンベロープデータ」タイプの使用をサポートしなければなりません。彼らは、追加のRecipientInfoタイプをサポートするかもしれません。 EncryptedContentInfoで「暗号化コンテンツ」フィールドには、暗号化されたBEKは保護されているブロックの内容を暗号化するために使用が含まれています。
For each block to be protected, the entire original block is encapsulated in a "replacing" ESB. This replacing ESB is placed in the outgoing bundle in the same position as the original block. As mentioned above, this is one-to-one replacement, and there is no consolidation of blocks or mixing of data in any way.
各ブロックが保護されるため、全体のオリジナルブロックは、「置換」ESB内にカプセル化されています。この交換ESBは、元のブロックと同じ位置に発信バンドル内に配置されます。上述したように、これは、1対1の交換であり、いかなる方法でもブロックまたはデータの混合のない統合はありません。
The encryption process uses AES-GCM with the salt and key values from the first ESB and an IV unique to this ESB. The process creates ciphertext for the entire original block, and an authentication tag for validation at the security-destination. The authentication tag is appended to the ciphertext for the block and the combination is stored into the encapsulated block item in security-result.
暗号化プロセスは、塩と最初のESBから、キー値と、このESBに固有のIVとAES-GCMを使用しています。プロセス全体オリジナルブロックの暗号文、およびセキュリティ先の検証のために認証タグを生成します。認証タグはブロックの暗号文に付加され、組み合わせは、セキュリティ結果でカプセル化されたブロック項目に格納されます。
The replacing block, of course, also has the same correlator value as the first ESB with which it is associated. It also contains the block-specific IV in security-parameters, and the combination of original-block-ciphertext and authentication tag, stored as an encapsulated block item in security-result.
交換ブロックは、もちろん、それが関連付けられている第一のESBと同じ相関値を有します。それはまた、セキュリティ結果にカプセル化されたブロックの項目として格納されたセキュリティ・パラメータのブロック特異IV、及びオリジナルブロック暗号文および認証タグの組み合わせを含んでいます。
Key management in delay-tolerant networks is recognized as a difficult topic and is one that this specification does not attempt to solve. However, solely in order to support implementation and testing, implementations SHOULD support:
遅延トレラントネットワーク内の鍵の管理は難しいトピックとして認識し、この仕様が解決しようとしないものです。しかし、単に実装とテストをサポートするために、実装がサポートする必要があります。
o The use of well-known RSA public keys for all ciphersuites.
すべての暗号スイートのためのよく知られたRSA公開鍵の使用O。
o Long-term pre-shared-symmetric keys for the BAB-HMAC ciphersuite.
BAB-HMACの暗号スイートのためのO長期事前共有対称鍵。
Since endpoint IDs are URIs and URIs can be placed in X.509 [RFC5280] public key certificates (in the subjectAltName extension), implementations SHOULD support this way of distributing public keys. RFC 5280 does not insist that implementations include revocation checking. In the context of a DTN, it is reasonably likely that some nodes would not be able to use revocation checking services (either Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP)) and deployments SHOULD take this into account when planning any public key infrastructure to support this specification.
[RFC5280]（subjectAltName拡張で）公開鍵証明書エンドポイントIDはURIのであり、URIはX.509に配置することができるので、実装は、公開鍵を配布するこの方法をサポートしなければなりません。 RFC 5280は、実装が失効チェックが含まれていることを主張していません。 DTNのコンテキストでは、いくつかのノードが失効チェックサービス（証明書失効リスト（CRL）またはオンライン証明書状態プロトコル（OCSP）のいずれか）を使用することはできないだろうと計画する際の展開はこれを考慮に入れるべきであることを合理的に可能性がありますこの仕様をサポートする任意の公開鍵インフラストラクチャ。
Every node serves as a Policy Enforcement Point insofar as it enforces some policy that controls the forwarding and delivery of bundles via one or more convergence layer protocol implementation. Consequently, every node SHALL have and operate according to its own configurable security policy, whether the policy be explicit or default. The policy SHALL specify:
それは、1つ以上の収束層プロトコルの実装を介してバンドルの転送および配信を制御するいくつかのポリシーを適用としてすべてのノードがあればポリシー施行ポイントとして機能します。その結果、すべてのノードは、ポリシーが明示的またはデフォルトにするか、独自の設定可能なセキュリティポリシーに応じており、動作しなければなりません。ポリシーは、指定しなければなりません。
Under what conditions received bundles SHALL be forwarded.
どのような条件がバンドルが転送されるものとする（SHALL）受け取りました。
Under what conditions received bundles SHALL be required to include valid BABs.
条件を受信するものの下のバンドルには、有効なBABSを含めるように要求されなければなりません。
Under what conditions the authentication information provided in a bundle's BAB SHALL be deemed adequate to authenticate the bundle.
どのような条件の下では、バンドルのBABで提供された認証情報は、バンドルを認証するために十分なものとみなします。
Under what conditions received bundles SHALL be required to have valid PIBs and/or PCBs.
条件を受信するものの下にバンドルが有効なのPIBおよび/またはPCBを持つことが要求されるものとします。
Under what conditions the authentication information provided in a bundle's PIB SHALL be deemed adequate to authenticate the bundle.
どのような条件の下では、バンドルのPIBで提供された認証情報は、バンドルを認証するために十分なものとみなします。
Under what conditions a BAB SHALL be added to a received bundle before that bundle is forwarded.
そのバンドルが転送される前に、どのような条件の下ではBABは、受け取ったバンドルに追加するものとします。
Under what conditions a PIB SHALL be added to a received bundle before that bundle is forwarded.
そのバンドルが転送される前に、どのような条件の下でPIBは、受け取ったバンドルに追加するものとします。
Under what conditions a PCB SHALL be added to a received bundle before that bundle is forwarded.
そのバンドルが転送される前に、どのような条件の下でPCBが受信バンドルに追加するものとします。
Under what conditions an ESB SHALL be applied to one or more blocks in a received bundle before that bundle is forwarded.
そのバンドルが転送される前に、どのような条件の下ではESBを受け、バンドル内の1つまたは複数のブロックに適用しなければなりません。
The actions that SHALL be taken in the event that a received bundle does not meet the receiving node's security policy criteria.
受け取ったバンドルが受信ノードのセキュリティポリシーの基準を満たしていない場合に講じなければならない行為。
This specification does not address how security policies get distributed to nodes. It only REQUIRES that nodes have and enforce security policies.
この仕様は、セキュリティポリシーがノードに分散取得する方法は対応していません。これは、ノードだけが持っているとセキュリティポリシーを適用する必要があります。
If no security policy is specified at a given node, or if a security policy is only partially specified, that node's default policy regarding unspecified criteria SHALL consist of the following:
何のセキュリティポリシーは、特定のノードに指定されていない、またはセキュリティポリシーが部分的にしか指定されている場合は、未指定の基準については、そのノードのデフォルトポリシーは、以下で構成されなければならない場合：
Bundles that are not well-formed do not meet the security policy criteria.
整形されていないバンドルには、セキュリティポリシーの基準を満たしていません。
The mandatory ciphersuites MUST be used.
必須暗号群を使用しなければなりません。
All bundles received MUST have a BAB that MUST be verified to contain a valid security-result. If the bundle does not have a BAB, then the bundle MUST be discarded and processed no further; a bundle status report indicating the authentication failure MAY be generated.
受け取ったすべてのバンドルは、有効なセキュリティ結果を含めることが検証されなければならないBABを持たなければなりません。バンドルがBABを持っていない場合は、バンドルは捨てなければなりませんし、それ以上処理しません。認証が失敗したことを示すバンドルステータスレポートを生成することができます。
No received bundles SHALL be required to have a PIB; if a received bundle does have a PIB, however, the PIB can be ignored unless the receiving node is the PIB-destination, in which case the PIB MUST be verified.
何受信バンドルは、PIBを持つことが必要とはなりません。受信されたバンドルがPIBを持っている場合、受信ノードは、PIBが検証されなければならない場合にはPIB-宛先でない限り、しかし、PIBを無視することができます。
No received bundles SHALL be required to have a PCB; if a received bundle does have a PCB, however, the PCB can be ignored unless the receiving node is the PCB-destination, in which case the PCB MUST be processed. If processing a PCB yields a PIB, that PIB SHALL be processed by the node according to the node's security policy.
何受信バンドルは、PCBを持っている必要はありませんしなければなりません。受信されたバンドルがPCBを持っている場合、受信ノードは、PCBが処理されなければならない場合にはPCB-宛先でない限り、しかし、PCBは無視することができます。 PCBを処理するPIBは、ノードのセキュリティポリシーに従ってノードによって処理されるものと、PIBを得た場合。
A PIB SHALL NOT be added to a bundle before sourcing or forwarding it.
PIBは、調達や、それを転送する前に、バンドルに添加していません。
A PCB SHALL NOT be added to a bundle before sourcing or forwarding it.
PCBは、調達や、それを転送する前に、バンドルに添加していません。
A BAB MUST always be added to a bundle before that bundle is forwarded.
そのバンドルが転送される前に、BABは常にバンドルに追加する必要があります。
If a destination node receives a bundle that has a PIB-destination but the value in that PIB-destination is not the EID of the destination node, the bundle SHALL be delivered at that destination node.
宛先ノードがPIB先を有するが、そのPIB先の値が宛先ノードのEIDないバンドルを受信した場合、バンドルされた宛先ノードに提出されなければなりません。
If a destination node receives a bundle that has an ESB-destination but the value in that ESB-destination is not the EID of the destination node, the bundle SHALL be delivered at that destination node.
宛先ノードがESB-先を有するが、そのESB先の値が宛先ノードのEIDないバンドルを受信した場合、バンドルされた宛先ノードに提出されなければなりません。
If a received bundle does not satisfy the node's security policy for any reason, then the bundle MUST be discarded and processed no further; in this case, a bundle deletion status report (see the Bundle Protocol Specification [DTNBP]) indicating the failure MAY be generated.
受け取ったバンドルが何らかの理由でノードのセキュリティポリシーを満たさない場合は、バンドルは捨てなければなりませんし、それ以上処理しません。この場合には、失敗を示すバンドル削除ステータスレポートは、（バンドルプロトコル仕様[DTNBP]を参照）を生成することができます。
The Bundle Security Protocol builds upon much work of others, in particular, "Cryptographic Message Syntax (CMS)" [RFC5652] and "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280]. The security considerations in these two documents apply here as well.
バンドルセキュリティプロトコルは、他の多くの仕事、特に、「暗号メッセージ構文（CMS）」[RFC5652]と「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール」[RFC5280]の上に構築します。これら二つの文書のセキュリティに関する考慮事項はここにも適用されます。
Several documents specifically consider the use of Galois/Counter Mode (GCM) and of AES and are important to consider when building ciphersuites. These are "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)" [RFC4106] and "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)" [RFC5084]. Although the BSP is not identical, many of the security issues considered in these documents also apply here.
いくつかの文書は、特にガロア/カウンタモード（GCM）とのAESの使用を考慮し、暗号スイートを構築する際に考慮することが重要です。これらは、[RFC4106] "のIPsecカプセル化セキュリティペイロード（ESP）におけるガロア/カウンタモード（GCM）の使用" および[RFC5084]を "暗号メッセージ構文（CMS）でAES-CCMとAES-GCM認証済み暗号化を使用" です。 BSPは同じではありませんが、これらの文書で考慮セキュリティ問題の多くはここにも適用されます。
Certain applications of DTN need to both sign and encrypt a message, and there are security issues to consider with this.
DTNの特定のアプリケーションでは、両方の署名する必要があり、メッセージを暗号化し、これを考慮すべきセキュリティ上の問題があります。
If the intent is to provide an assurance that a message did, in fact, come from a specific source and has not been changed, then it should be signed first and then encrypted. A signature on an encrypted message does not establish any relationship between the signer and the original plaintext message.
意図は、メッセージが、実際には、特定のソースから来たのと変更されていないという保証を提供することであるならば、それは最初に署名してから暗号化する必要があります。暗号化されたメッセージの署名は、署名者と元の平文メッセージとの間の関係を確立しません。
On the other hand, if the intent is to reduce the threat of denial-of-service attacks, then signing the encrypted message is appropriate. A message that fails the signature check will not be processed through the computationally intensive decryption pass. A more extensive discussion of these points is in S/MIME 3.2 Message Specification [RFC5751], especially in Section 3.6.
一方、もし意図は、暗号化されたメッセージが適切である署名、サービス拒否攻撃の脅威を軽減することです。署名チェックに失敗したメッセージは、計算集約的な復号パスを介して処理されません。これらの点のより広範な議論は、特にセクション3.6で、S / MIMEメッセージ3.2仕様[RFC5751]です。
Additional details relating to these combinations can be found in Section 2.8 where it is RECOMMENDED that the encrypt-then-sign combination is usually appropriate for usage in a DTN.
これらの組み合わせに関連する追加の詳細は、暗号化-当時の符号の組み合わせがDTNでの使用のために、通常は適切であることが推奨され、セクション2.8に記載されています。
In a DTN, encrypt-then-sign potentially allows intermediate nodes to verify a signature (over the ciphertext) and thereby apply policy to manage possibly scarce storage or other resources at intermediate nodes in the path the bundle takes from source to destination EID.
バンドル宛先EIDにソースから取るDTNにおいて、暗号化、次いで-SIGNは、潜在的に（暗号文上）中間ノードは、署名を検証することができ、それにより経路内の中間ノードでおそらく乏しい貯蔵または他のリソースを管理するためのポリシーを適用します。
An encrypt-then-sign scheme does not further expose identity in most cases since the BP mandates that the source EID (which is commonly expected to be the security-source) is already exposed in the primary block of the bundle. Should exposure of either the source EID or the signerInfo be considered an interesting vulnerability, then some form of bundle-in-bundle encapsulation would be required as a mitigation.
暗号-THEN-符号化方式は、（一般にセキュリティ源として期待されている）ソースEIDが既に束の主ブロックに露出しているBPの義務ので、ほとんどの場合、身元を公開しません。ソースEIDかのSignerInfoのいずれかの暴露は、その後、バンドル・イン・バンドルカプセル化のいくつかのフォームが緩和として必要とされるであろう、面白い脆弱性を考慮すべきです。
If a BAB ciphersuite uses digital signatures but doesn't include the security-destination (which for a BAB is the next host), then this allows the bundle to be sent to some node other than the intended adjacent node. Because the BAB will still authenticate, the receiving node might erroneously accept and forward the bundle. When asymmetric BAB ciphersuites are used, the security-destination field SHOULD therefore be included in the BAB.
BABの暗号スイートは、デジタル署名を使用するが、（BABための次のホストである）セキュリティ先が含まれていない場合、これはバンドルが意図隣接ノード以外のノードに送信されることを可能にします。 BABがまだ認証されますので、受信ノードは、誤って受け入れ、バンドルを転送することがあります。非対称BABの暗号スイートが使用される場合、セキュリティ宛先フィールドは、したがって、BABに含まれるべきです。
If a bundle's PIB-destination is not the same as its destination, then some node other than the destination (the node identified as the PIB-destination) is expected to validate the PIB security-result while the bundle is en route. However, if for some reason the PIB is not validated, there is no way for the destination to become aware of this. Typically, a PIB-destination will remove the PIB from the bundle after verifying the PIB and before forwarding it. However, if there is a possibility that the PIB will also be verified at a downstream node, the PIB-destination will leave the PIB in the bundle. Therefore, if a destination receives a bundle with a PIB that has a PIB-destination (which isn't the destination), this might, but does not necessarily, indicate a possible problem.
バンドルのPIB-宛先が宛先と同じでない場合は、宛先（PIB-宛先として識別されるノード）以外のノードは、束が途中である間PIBセキュリティ結果を検証することが期待されます。何らかの理由でPIBが検証されていない場合は、先がこのことを認識になる方法はありません。典型的には、PIB-先PIBを確認した後、それを転送する前にバンドルからPIBを除去します。 PIBはまた、下流ノードで検証される可能性がある場合は、PIB先は、バンドル内のPIBを残します。したがって、宛先は、（宛先ではない）PIB-先を有するPIBとバンドル、このかもしれないを受信した場合、必ずしも、可能な問題を示していません。
If a bundle is fragmented after being forwarded by its PIB-source but before being received by its PIB-destination, the payload in the bundle MUST be reassembled before validating the PIB security-result in order for the security-result to validate correctly. Therefore, if the PIB-destination is not capable of performing payload reassembly, its utility as a PIB-destination will be limited to validating only those bundles that have not been fragmented since being forwarded from the PIB-source. Similarly, if a bundle is fragmented after being forwarded by its PIB-source but before being received by its PIB-destination, all fragments MUST be received at that PIB-destination in order for the bundle payload to be able to be reassembled. If not all fragments are received at the PIB-destination node, the bundle will not be able to be authenticated, and will therefore never be forwarded by this PIB-destination node.
バンドルは、そのPIB元によって転送された後、そのPIB-宛先によって受信される前に断片化されている場合は、バンドル内のペイロードが正しく検証するセキュリティ結果ためにPIBセキュリティ結果を検証する前に再組み立てしなければなりません。 PIB-宛先がペイロード再構成を行うことが可能でない場合したがって、PIB-先としての有用性は、PIB-ソースから転送されるので、断片化されていないだけのバンドルを有効に制限されます。バンドルは、そのPIB元によって転送された後、そのPIB-宛先によって受信される前に断片化された場合も同様に、すべての断片は、バンドルペイロードが再アセンブルすることができるようにするために、そのPIB先に受信されなければなりません。いないすべてのフラグメントがPIB-宛先ノードで受信された場合、バンドルは認証されなくなりますので、このPIB-宛先ノードによって転送されることはありません。
Specification of a security-destination other than the bundle-destination creates a routing requirement that the bundle somehow be directed to the security-destination node on its way to the final destination. This requirement is presently private to the ciphersuite, since routing nodes are not required to implement security processing.
バンドル先以外のセキュリティ先の仕様は、バンドル何とか最終目的地への途中でセキュリティ宛先ノードに向けることがルーティング要求を作成します。ルーティングノードは、セキュリティ処理を実現するために必要とされていないので、この要件は、暗号スイートに現在プライベートです。
If a security target were to generate reports in the event that some security validation step fails, then that might leak information about the internal structure or policies of the DTN containing the security target. This is sometimes considered bad security practice, so it SHOULD only be done with care.
セキュリティターゲットは、いくつかのセキュリティ検証のステップが失敗した場合にレポートを生成した場合、その内部構造やセキュリティターゲットを含むDTNのポリシーに関する情報を漏らす可能性があります。これは時々悪いセキュリティの実践と考えられているので、それが唯一の注意を払って行われるべきです。
As indicated above, this document describes both BSP and ciphersuites. A conformant implementation MUST implement both BSP support and the four ciphersuites described in Section 4. It MAY also support other ciphersuites.
上記に示したように、このドキュメントは、BSPと暗号スイートの両方を記載しています。準拠の実装は、それはまた別の暗号スイートをサポートするかもしれBSPのサポートと、第4節で説明した4つの暗号スイートの両方を実装しなければなりません。
Implementations that support BSP but not all four mandatory ciphersuites MUST claim only "restricted compliance" with this specification, even if they provide other ciphersuites.
BSPをサポートする実装ではなく、すべての4つの必須暗号スイートは、彼らが他の暗号スイートを提供していても、この仕様を持つ唯一の「制限されたコンプライアンスを」と主張しなければなりません。
All implementations are strongly RECOMMENDED to provide at least a BAB ciphersuite. A relay node, for example, might not deal with end-to-end confidentiality and data integrity, but it SHOULD exclude unauthorized traffic and perform hop-by-hop bundle verification.
すべての実装が強く、少なくともBABの暗号スイートを提供することをお勧めします。中継ノードは、例えば、エンド・ツー・エンドの機密性とデータの整合性に対処しないかもしれませんが、それは不正なトラフィックを除外し、ホップバイホップバンドルの検証を実行する必要があります。
This protocol has fields that have been registered by IANA.
このプロトコルは、IANAによって登録されているフィールドがあります。
This specification allocates four codepoints from the existing "Bundle Block Types" registry defined in [RFC6255].
この仕様は、[RFC6255]で定義された既存の「バンドルブロックタイプ」レジストリから4つのコードポイントを割り当てます。
Additional Entries for the Bundle Block-Type Codes Registry:
+-------+--------------------------------------+----------------+
| Value | Description | Reference |
+-------+--------------------------------------+----------------+
| 2 | Bundle Authentication Block | This document |
| 3 | Payload Integrity Block | This document |
| 4 | Payload Confidentiality Block | This document |
| 9 | Extension Security Block | This document |
+-------+--------------------------------------+----------------+
This protocol has a ciphersuite number field and certain ciphersuites are defined. An IANA registry has been set up as follows.
このプロトコルは、暗号スイート番号フィールドを有しており、特定の暗号スイートが定義されています。次のようにIANAレジストリが設定されています。
The registration policy for this registry is: Specification Required
このレジストリの登録ポリシーは次のとおりです。仕様が必要
The Value range is: Variable Length
値の範囲は次のとおりです。可変長
Ciphersuite Numbers Registry:
+-------+--------------------------------------+----------------+
| Value | Description | Reference |
+-------+--------------------------------------+----------------+
| 0 | unassigned | This document |
| 1 | BAB-HMAC | This document |
| 2 | PIB-RSA-SHA256 | This document |
| 3 | PCB-RSA-AES128-PAYLOAD-PIB-PCB | This document |
| 4 | ESB-RSA-AES128-EXT | This document |
| >4 | Reserved | This document |
+-------+--------------------------------------+----------------+
This protocol has a ciphersuite flags field and certain flags are defined. An IANA registry has been set up as follows.
このプロトコルは、暗号スイートのフラグフィールドを持っており、特定のフラグが定義されています。次のようにIANAレジストリが設定されています。
The registration policy for this registry is: Specification Required
このレジストリの登録ポリシーは次のとおりです。仕様が必要
The Value range is: Variable Length
値の範囲は次のとおりです。可変長
Ciphersuite Flags Registry:
+-----------------+----------------------------+----------------+
| Bit Position | Description | Reference |
| (right to left) | | |
+-----------------+----------------------------+----------------+
| 0 | Block contains result | This document |
| 1 | Block contains correlator | This document |
| 2 | Block contains parameters | This document |
| 3 | Destination EIDref present | This document |
| 4 | Source EIDref present | This document |
| >4 | Reserved | This document |
+-----------------+----------------------------+----------------+
This protocol has fields for ciphersuite-parameters and results. The field is a type-length-value triple and a registry is required for the "type" sub-field. The values for "type" apply to both the ciphersuite-parameters and the ciphersuite results fields. Certain values are defined. An IANA registry has been set up as follows.
このプロトコルは、暗号スイート・パラメータと結果のためのフィールドがあります。フィールドは、トリプルタイプレングス値であり、レジストリは、「タイプ」サブフィールドのために必要とされます。 「タイプ」の値は、暗号のパラメータ及び暗号スイートの結果フィールドの両方に適用されます。特定の値が定義されています。次のようにIANAレジストリが設定されています。
The registration policy for this registry is: Specification Required
このレジストリの登録ポリシーは次のとおりです。仕様が必要
The Value range is: 8-bit unsigned integer
値の範囲は、8ビット符号なし整数
Ciphersuite-Parameters and Results Type Registry:
+---------+------------------------------------+----------------+
| Value | Description | Reference |
+---------+------------------------------------+----------------+
| 0 | reserved | This document |
| 1 | initialization vector (IV) | This document |
| 2 | reserved | This document |
| 3 | key-information | This document |
| 4 | fragment-range (pair of SDNVs) | This document |
| 5 | integrity signature | This document |
| 6 | unassigned | This document |
| 7 | salt | This document |
| 8 | PCB integrity check value (ICV) | This document |
| 9 | reserved | This document |
| 10 | encapsulated block | This document |
| 11 | block type of encapsulated block | This document |
| 12-191 | reserved | This document |
| 192-250 | private use | This document |
| 251-255 | reserved | This document |
+-------+--------------------------------------+----------------+
[DTNBP] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007.
[DTNBP]スコット、K.およびS.バーリー、 "バンドルプロトコル仕様"、RFC 5050、2007年11月。
[DTNMD] Symington, S., "Delay-Tolerant Networking Metadata Extension Block", RFC 6258, May 2011.
[DTNMD]シミントン、S.、 "遅延耐性ネットワークメタデータの拡張ブロック"、RFC 6258、2011年5月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005.
[RFC4055] Schaad、J.、Kaliski、B.、およびR. Housley氏、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィールで使用するRSA暗号のための追加のアルゴリズムと識別子"、RFC 4055 、2005年6月。
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
[RFC4106] Viega、J.とD.マグリュー、 "IPsecのカプセル化セキュリティペイロード（ESP）におけるガロア/カウンタモード（GCM）の使用"、RFC 4106、2005年6月。
[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, May 2008.
[RFC5280]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652] Housley氏、R.、 "暗号メッセージ構文（CMS）"、STD 70、RFC 5652、2009年9月。
[RFC6255] Blanchet, M., "Delay-Tolerant Networking (DTN) Bundle Protocol IANA Registries", RFC 6255, May 2011.
[RFC6255]ブランシェ、M.、 "遅延耐性ネットワーク（DTN）バンドルプロトコルIANAレジストリ"、RFC 6255、2011年5月。
[DTNarch] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, April 2007.
【DTNarch]サーフ、V.、バーレイ、S.、フック、A.、Torgerson、L.、ダースト、R.、スコット、K.、秋、K.、およびH.ワイス、 "遅延耐性ネットワークアーキテクチャ" 、RFC 4838、2007年4月。
[PHIB] Symington, S., "Delay-Tolerant Networking Previous-Hop Insertion Block", RFC 6259, May 2011.
[PHIB]シミントン、S.、 "遅延耐性ネットワーク前のホップ挿入ブロック"、RFC 6259、2011年5月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)", RFC 5084, November 2007.
[RFC5084] Housley氏、R.、 "暗号メッセージ構文（CMS）でAES-CCMとAES-GCM認証済み暗号化の使用"、RFC 5084、2007年11月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751] Ramsdell、B.、およびS.ターナー、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.2メッセージ仕様"、RFC 5751、2010年1月。
Authors' Addresses
著者のアドレス
Susan Flynn Symington The MITRE Corporation 7515 Colshire Drive McLean, VA 22102 US
スーザン・フリンシミントンザ・MITRE社7515 Colshireドライブマクリーン、バージニア州22102米国
Phone: +1 (703) 983-7209 EMail: susan@mitre.org URI: http://mitre.org/
電話：+1（703）983-7209 Eメール：susan@mitre.org URI：http://mitre.org/
Stephen Farrell Trinity College Dublin Distributed Systems Group Department of Computer Science Trinity College Dublin 2 Ireland
コンピュータサイエンスのステファン・ファレルトリニティ・カレッジ・ダブリン分散システム・グループ部門トリニティ・カレッジ・ダブリンアイルランド
Phone: +353-1-896-2354 EMail: stephen.farrell@cs.tcd.ie
電話：+ 353-1-896-2354 Eメール：stephen.farrell@cs.tcd.ie
Howard Weiss SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046 US
ハワード・ワイスSPARTA、Inc.の7110サミュエル・モールスドライブコロンビア、MD 21046米国
Phone: +1-443-430-8089 EMail: howard.weiss@sparta.com
電話：+ 1-443-430-8089 Eメール：howard.weiss@sparta.com
Peter Lovell SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046 US
ピーター・ラヴェルSPARTA、Inc.の7110サミュエル・モールスドライブコロンビア、MD 21046米国
Phone: +1-443-430-8052 EMail: dtnbsp@gmail.com
電話：+ 1-443-430-8052 Eメール：dtnbsp@gmail.com