[要約] RFC 8600は、XMPPを使用してセキュリティ情報の交換を行うためのガイドラインです。このRFCの目的は、セキュリティ情報の効率的な共有と相互運用性の向上を促進することです。
Internet Engineering Task Force (IETF) N. Cam-Winget, Ed.
Request for Comments: 8600 S. Appala
Category: Standards Track S. Pope
ISSN: 2070-1721 Cisco Systems
P. Saint-Andre
Mozilla
June 2019
Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange
セキュリティ情報交換のためのExtensible Messaging and Presence Protocol（XMPP）の使用
Abstract
概要
This document describes how to use the Extensible Messaging and Presence Protocol (XMPP) to collect and distribute security incident reports and other security-relevant information between network-connected devices, primarily for the purpose of communication among Computer Security Incident Response Teams and associated entities. To illustrate the principles involved, this document describes such a usage for the Incident Object Description Exchange Format (IODEF).
このドキュメントでは、Extensible Messaging and Presence Protocol（XMPP）を使用して、セキュリティインシデントレポートやその他のセキュリティ関連情報を収集し、ネットワークに接続されたデバイス間で配布する方法について説明します。関連する原則を説明するために、このドキュメントでは、インシデントオブジェクト記述交換フォーマット（IODEF）の使用法について説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8600.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8600で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Service Discovery . . . . . . . . . . . . . . . . . . . . . . 8
6. Publish-Subscribe . . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 14
8.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 16
8.3. Countermeasures . . . . . . . . . . . . . . . . . . . . . 20
8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 23
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24
10. Operations and Management Considerations . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . 27
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
This document defines an architecture, i.e., "XMPP-Grid", as a method for using the Extensible Messaging and Presence Protocol (XMPP) [RFC6120] to collect and distribute security incident reports and other security-relevant information among network platforms, endpoints, and any other network-connected device, primarily for the purpose of communication among Computer Security Incident Response Teams and associated entities. In effect, this document specifies an Applicability Statement ([RFC2026], Section 3.2) that defines how to use XMPP for the exchange of security notifications on a controlled-access network among authorized entities.
このドキュメントでは、Extensible Messaging and Presence Protocol（XMPP）[RFC6120]を使用してネットワークプラットフォーム、エンドポイント間でセキュリティインシデントレポートやその他のセキュリティ関連情報を収集および配布する方法として、アーキテクチャ、つまり「XMPP-Grid」を定義しています。その他のネットワーク接続デバイス。主に、コンピューターセキュリティインシデントレスポンスチームと関連エンティティ間の通信を目的としています。事実上、このドキュメントは、承認されたエンティティ間でアクセスが制御されたネットワーク上のセキュリティ通知を交換するためにXMPPを使用する方法を定義する適用性ステートメント（[RFC2026]、セクション3.2）を指定します。
Among other things, XMPP provides a publish-subscribe service [XEP-0060] that acts as a broker, enabling control-plane functions by which entities can discover available information to be published or consumed. Although such information can take the form of any structured data (XML, JSON, etc.), this document illustrates the principles of XMPP-Grid with examples that use the Incident Object Description Exchange Format (IODEF) [RFC7970]. That is, while other security information formats can be shared using XMPP, this document uses IODEF as one such example format that can be published and consumed using XMPP.
とりわけ、XMPPは、ブローカーとして機能するパブリッシュサブスクライブサービス[XEP-0060]を提供し、エンティティが公開または消費される利用可能な情報を発見できるコントロールプレーン機能を可能にします。このような情報は任意の構造化データ（XML、JSONなど）の形式を取ることができますが、このドキュメントでは、XMPP-Gridの原則と、インシデントオブジェクト記述交換フォーマット（IODEF）[RFC7970]を使用する例を示します。つまり、XMPPを使用して他のセキュリティ情報形式を共有できますが、このドキュメントでは、XMPPを使用して公開および利用できる形式の例としてIODEFを使用しています。
This document uses XMPP terminology defined in [RFC6120] and [XEP-0060]. Because the intended audience for this document is those who implement and deploy security reporting systems, mappings are provided for the benefit of XMPP developers and operators.
このドキュメントでは、[RFC6120]と[XEP-0060]で定義されているXMPP用語を使用しています。このドキュメントの対象読者は、セキュリティレポートシステムを実装および展開する人であるため、XMPP開発者およびオペレーターのためにマッピングが提供されています。
Broker: A specific type of controller containing control-plane functions; as used here, the term refers to an XMPP publish-subscribe service.
ブローカー：コントロールプレーン機能を含む特定のタイプのコントローラー。ここで使用されているように、この用語はXMPPパブリッシュ/サブスクライブサービスを指します。
Broker Flow: A method by which security incident reports and other security-relevant information are published and consumed in a mediated fashion through a Broker. In this flow, the Broker handles authorization of Consumers and Providers to Topics, receives messages from Providers, and delivers published messages to Consumers.
ブローカーフロー：ブローカーを介して、セキュリティインシデントレポートおよびその他のセキュリティ関連情報が仲介された方法で発行および利用される方法。このフローでは、ブローカーはコンシューマーとプロバイダーのトピックへの承認を処理し、プロバイダーからメッセージを受信し、公開されたメッセージをコンシューマーに配信します。
Consumer: An entity that contains functions to receive information from other components; as used here, the term refers to an XMPP publish-subscribe Subscriber.
消費者：他のコンポーネントから情報を受け取る機能を含むエンティティ。ここで使用される用語は、XMPPパブリッシュ/サブスクライブサブスクライバーを指します。
Controller: A component containing control-plane functions that manage and facilitate information sharing or execute on security functions; as used here, the term refers to an XMPP server, which provides core message delivery [RFC6120] used by publish-subscribe entities.
コントローラー：情報の共有を管理および促進する、またはセキュリティ機能で実行するコントロールプレーン機能を含むコンポーネント。ここで使用されているように、この用語はパブリッシュサブスクライブエンティティによって使用されるコアメッセージ配信[RFC6120]を提供するXMPPサーバーを指します。
Node: The XMPP term for a Topic.
ノード：トピックのXMPP用語。
Platform: Any entity that connects to the XMPP-Grid in order to publish or consume security-relevant information.
プラットフォーム：セキュリティ関連情報を公開または利用するためにXMPP-Gridに接続するエンティティ。
Provider: An entity that contains functions to provide information to other components; as used here, the term refers to an XMPP publish-subscribe Publisher.
プロバイダー：他のコンポーネントに情報を提供する機能を含むエンティティ。ここで使用される用語は、XMPPパブリッシュ/サブスクライブパブリッシャーを指します。
Topic: A contextual information channel created on a Broker on which messages generated by a Provider are propagated in real time to one or more Consumers. Each Topic is limited to a specific type and format of security data (e.g., IODEF namespace) and provides an XMPP interface by which the data can be obtained.
トピック：ブローカーで作成されたコンテキスト情報チャネルで、プロバイダーによって生成されたメッセージが1つ以上のコンシューマーにリアルタイムで伝播されます。各トピックは、特定のタイプと形式のセキュリティデータ（IODEF名前空間など）に制限され、データを取得できるXMPPインターフェイスを提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The following figure illustrates the architecture of XMPP-Grid.
次の図は、XMPP-Gridのアーキテクチャを示しています。
+--------------------------------------+
| +--------------------------------------+
| | +--------------------------------------+
| | | |
+-| | Platforms |
+-| |
+--------------------------------------+
/ \ / \ / \
/ C \ / \ / \
- o - - d - - -
||n||A | a |B | |C
||t|| | t | | |
- r - - a - | |
\ o / \ / | |
\ l / \ / | |
/|---------------------|\ | |
/|----/ \--------| d |--|\
/ / Controller \ ctrl | a | \
\ \ & Broker / plane | t | /
\|----\ /--------| a |--|/
\|---------------------|/ | |
/ \ / \ | |
/ C \ / \ | |
- o - - d - | |
||n||A | a |B | |C
||t|| | t | | |
- r - - a - - -
\ o / \ / \ /
\ l / \ / \ /
+------------------------------------+
| |-+
| Platforms | |
| | |-+
+------------------------------------+ | |
+------------------------------------+ |
+------------------------------------+
Figure 1: XMPP-Grid Architecture
図1：XMPP-Gridアーキテクチャ
Platforms connect to the Controller (XMPP server) to authenticate and then establish appropriate authorizations to be a Provider or Consumer of topics of interest at the Broker. The control-plane messaging is established through XMPP and is shown as "A" (control-plane interface) in Figure 1. Authorized Platforms can then share data either through the Broker (shown as "B" in Figure 1) or, in some cases, directly (shown as "C" in Figure 1). This document focuses primarily on the Broker Flow for information sharing ("direct flow" interactions can be used for specialized purposes, such as bulk data transfer, but methods for doing so are outside the scope of this document).
プラットフォームはコントローラー（XMPPサーバー）に接続して認証し、ブローカーで関心のあるトピックのプロバイダーまたはコンシューマーになるための適切な承認を確立します。コントロールプレーンメッセージングはXMPPを介して確立され、図1では「A」（コントロールプレーンインターフェース）として示されています。承認プラットフォームは、ブローカー（図1で「B」として示される）または一部のプラットフォームでデータを共有できます。ケース、直接（図1で「C」として表示）。このドキュメントは、情報共有のためのブローカーフローに主に焦点を合わせています（「ダイレクトフロー」の相互作用は、バルクデータ転送などの特殊な目的に使用できますが、その方法はこのドキュメントの範囲外です）。
Implementations of XMPP-Grid adhere to the following workflow:
XMPP-Gridの実装は、次のワークフローに従います。
a. A Platform with a source of security data requests connection to the XMPP-Grid via a Controller.
a. セキュリティデータのソースを持つプラットフォームは、コントローラーを介してXMPP-Gridへの接続を要求します。
b. The Controller authenticates the Platform.
b. コントローラはプラットフォームを認証します。
c. The Platform establishes authorized privileges (e.g., privilege to publish and/or subscribe to one or more Topics) with a Broker.
c. プラットフォームは、ブローカーに承認された特権（1つまたは複数のトピックをパブリッシュおよび/またはサブスクライブする特権など）を確立します。
d. The Platform can publish security incident reports and other security-relevant information to a Topic, subscribe to a Topic, query a Topic, or perform any combination of these operations.
d. プラットフォームは、セキュリティインシデントレポートやその他のセキュリティ関連情報をトピックに公開したり、トピックをサブスクライブしたり、トピックにクエリを実行したり、これらの操作の任意の組み合わせを実行したりできます。
e. A Provider unicasts its Topic updates to the Grid in real time through a Broker. The Broker handles replication and distribution of the Topic to Consumers. A Provider can publish the same or different data to multiple Topics.
e. プロバイダーは、ブローカーを通じてリアルタイムでトピックの更新をグリッドにユニキャストします。ブローカーは、トピックの複製とコンシューマーへの配布を処理します。プロバイダーは、同じデータまたは異なるデータを複数のトピックに公開できます。
f. Any Platform on the Grid can subscribe to any Topic published to the Grid (as permitted by the authorization policy) and (as Consumers) will then receive a continual, real-time stream of updates from the Topics to which it is subscribed.
f. グリッド上の任意のプラットフォームは、グリッドに発行された任意のトピックにサブスクライブでき（承認ポリシーで許可されているとおり）、その後（コンシューマーとして）、サブスクライブしているトピックから継続的なリアルタイムの更新ストリームを受け取ります。
The general workflow is summarized in the figure below.
一般的なワークフローを次の図にまとめます。
+--------------+ +------------+ +---------------+
| IODEF Client | | Controller | | IODEF Service |
| (Consumer) | | & Broker | | (Provider) |
+--------------+ +------------+ +---------------+
| | |
| Establish XMPP | |
| Client Session | |
| (RFC 6120) | |
|--------------------->| |
| | Establish XMPP |
| | Client Session |
| | (RFC 6120) |
| |<------------------------|
| | Request Topic Creation |
| | (XEP-0060) |
| |<------------------------|
| | Topic Creation Success |
| | (XEP-0060) |
| |------------------------>|
| Request Topic List | |
| (XEP-0030) | |
|--------------------->| |
| Return Topic List | |
| (XEP-0030) | |
|<---------------------| |
| | |
| Query Each Topic | |
| (XEP-0030) | |
|--------------------->| |
| Return Topic Data | |
| Including Topic Type | |
| (XEP-0030) | |
|<---------------------| |
| | |
| Subscribe to IODEF | |
| Topic (XEP-0060) | |
|--------------------->| |
| Subscription Success | |
| (XEP-0060) | |
|<---------------------| |
| | Publish IODEF Incident |
| | (XEP-0060) |
| Receive IODEF |<------------------------|
| Incident (XEP-0060) | |
|<---------------------| |
| | |
Figure 2: IODEF Example Workflow
図2：IODEFのワークフロー例
XMPP-Grid implementations MUST adhere to the mandatory-to-implement and mandatory-to-negotiate features as defined in [RFC6120]. Similarly, implementations MUST implement the publish-subscribe extension [XEP-0060] to facilitate the asynchronous sharing of information. Implementations SHOULD implement Service Discovery as defined in [XEP-0030] to facilitate the means to dynamically discover the available information and namespaces (Topics) to be published or consumed. Care should be taken with implementations if their deployments allow for a large number of Topics. The result set management as defined in [XEP-0059] SHOULD be used to allow the requesting entity to explicitly request Service Discovery result sets to be returned in pages or a limited size, if the discovery results are larger in size. Note that the control plane may optionally also implement [XEP-0203] to facilitate delayed delivery of messages to the connected consumer as described in [XEP-0060]. Since information may be timely and sensitive, capability providers should communicate to the Controller whether its messages can be cached for delayed delivery during configuration; such a function is out of scope for this document.
XMPP-Grid実装は、[RFC6120]で定義されているように、実装が必須の機能とネゴシエートが必須の機能に準拠する必要があります。同様に、情報の非同期共有を容易にするために、実装はパブリッシュ/サブスクライブ拡張[XEP-0060]を実装する必要があります。実装は、[XEP-0030]で定義されているようにService Discoveryを実装して、公開または消費される利用可能な情報と名前空間（トピック）を動的に発見する手段を促進する必要があります。デプロイメントで多数のトピックが許可されている場合、実装には注意が必要です。 [XEP-0059]で定義されている結果セット管理は、発見エンティティのサイズが大きい場合、要求エンティティがサービス発見結果セットをページまたは制限されたサイズで返すように明示的に要求できるようにするために使用する必要があります。 [XEP-0060]で説明されているように、コントロールプレーンはオプションで[XEP-0203]を実装して、接続されたコンシューマーへのメッセージの遅延配信を容易にすることもできます。情報はタイムリーで機密性が高い場合があるため、機能プロバイダーは、構成中にメッセージの遅延配信のためにメッセージをキャッシュできるかどうかをコントローラーに通知する必要があります。このような関数は、このドキュメントの範囲外です。
The following sections provide protocol examples for the service discovery and publish-subscribe parts of the workflow.
次のセクションでは、ワークフローのサービスディスカバリとパブリッシュサブスクライブの部分のプロトコル例を示します。
Using the XMPP service discovery extension [XEP-0030], a Controller enables Platforms to discover what information can be consumed through the Broker and at which Topics. Platforms could use [XEP-0059] to restrict the size of the result sets the Controller returns in a Service Discovery response. As an example, the Controller at 'security-grid.example' might provide a Broker at 'broker.security-grid.example', which hosts a number of Topics. A Platform at 'xmpp-grid-client@mile-host.example' would query the Broker about its available Topics by sending an XMPP "disco#items" request to the Broker:
XMPPサービス検出拡張機能[XEP-0030]を使用すると、コントローラーは、ブローカーを通じてどの情報をどのトピックで消費できるかをプラットフォームが検出できるようにします。プラットフォームは[XEP-0059]を使用して、Service Discovery応答でコントローラーが返す結果セットのサイズを制限できます。例として、「security-grid.example」のコントローラーは、「broker.security-grid.example」にブローカーを提供し、多数のトピックをホストします。 「xmpp-grid-client@mile-host.example」のプラットフォームは、ブローカーにXMPP "disco＃items"リクエストを送信することにより、利用可能なトピックについてブローカーにクエリを実行します。
<iq type='get' from='xmpp-grid-client@mile-host.example/2EBE702A97D6' to='broker.security-grid.example' id='B3C17F7B-B9EF-4ABA-B08D-805DA9F34626'> <query xmlns='http://jabber.org/protocol/disco#items'/> </iq> The Broker responds with the Topics it hosts:
<iq type = 'get' from='xmpp-grid-client@mile-host.example/2EBE702A97D6 'to =' broker.security-grid.example 'id =' B3C17F7B-B9EF-4ABA-B08D-805DA9F34626 '> < query xmlns = 'http：//jabber.org/protocol/disco#items'/> </ iq>ブローカーは、ホストするトピックで応答します。
<iq type='result'
from='broker.security-grid.example'
to='xmpp-grid-client@mile-host.example/2EBE702A97D6'
id='B3C17F7B-B9EF-4ABA-B08D-805DA9F34626'>
<query xmlns='http://jabber.org/protocol/disco#items'>
<item node='NEA1'
name='Endpoint Posture Information'
jid='broker.security-grid.example'/>
<item node='MILEHost'
name='MILE Host Data'
jid='broker.security-grid.example'/>
</query>
</iq>
In order to determine the exact nature of each Topic (i.e., in order to find Topics that publish incidents in the IODEF format), a Platform would send an XMPP "disco#info" request to each Topic:
各トピックの正確な性質を判断するために（つまり、IODEF形式でインシデントを公開するトピックを見つけるために）、プラットフォームはXMPP "disco＃info"リクエストを各トピックに送信します。
<iq type='get' from='xmpp-grid-client@mile-host.example/2EBE702A97D6' to='broker.security-grid.example' id='D367D4ED-2795-489C-A83E-EAAFA07A0356'> <query xmlns='http://jabber.org/protocol/disco#info' node='MILEHost'/> </iq> The Broker responds with the "disco#info" description, which MUST include an XMPP data form [XEP-0004] with a 'pubsub#type' field that specifies the supported namespace (in this example, the IODEF namespace defined in [RFC7970]):
<iq type = 'get' from='xmpp-grid-client@mile-host.example/2EBE702A97D6 'to =' broker.security-grid.example 'id =' D367D4ED-2795-489C-A83E-EAAFA07A0356 '> < query xmlns = 'http：//jabber.org/protocol/disco#info' node = 'MILEHost' /> </ iq>ブローカーは「disco＃info」の説明で応答します。これにはXMPPデータフォームを含める必要があります[XEP -0004サポートされている名前空間を指定する「pubsub＃type」フィールド（この例では、[RFC7970]で定義されているIODEF名前空間）：
<iq type='result'
from='broker.security-grid.example'
to='xmpp-grid-client@mile-host.example/2EBE702A97D6'
id='D367D4ED-2795-489C-A83E-EAAFA07A0356'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='MILEHost'>
<identity category='pubsub' type='leaf'/>
<feature var='http://jabber.org/protocol/pubsub'/>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#meta-data</value>
</field>
<field var='pubsub#type' label='Payload type' type='text-single'>
<value>urn:ietf:params:xml:ns:iodef-2.0</value>
</field>
</x>
</query>
</iq>
The Platform discovers the Topics by obtaining the Broker's response and obtaining the namespaces returned in the "pubsub#type" field (in the foregoing example, IODEF 2.0).
プラットフォームは、ブローカーの応答を取得し、「pubsub＃type」フィールド（上記の例ではIODEF 2.0）に返された名前空間を取得することにより、トピックを検出します。
Using the XMPP publish-subscribe extension [XEP-0060], a Consumer subscribes to a Topic, and a Provider publishes information to that Topic, which the Broker then distributes to all subscribed Consumers.
XMPPパブリッシュサブスクライブ拡張[XEP-0060]を使用して、コンシューマーはトピックにサブスクライブし、プロバイダーはそのトピックに情報をパブリッシュし、ブローカーはサブスクライブしたすべてのコンシューマーに情報を配信します。
First, a Provider would create a Topic as follows:
まず、プロバイダーは次のようにトピックを作成します。
<iq type='set'
from='datasource@provider.example/F12C2EFC9BB0'
to='broker.security-grid.example'
id='A67507DF-2F22-4937-8D30-88D2F7DBA279'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<create node='MILEHost'/>
</pubsub>
</iq>
Note: The foregoing example is the minimum protocol needed to create a Topic with the default node configuration on the XMPP publish-subscribe service specified in the 'to' address of the creation request stanza. Depending on security requirements, the Provider might need to request a non-default configuration for the node; see [XEP-0060] for detailed examples. To also help with the Topic configuration, the Provider may also optionally include configuration parameters such as:
注：上記の例は、作成要求スタンザの「宛先」アドレスで指定されたXMPPパブリッシュ/サブスクライブサービスでデフォルトのノード構成でトピックを作成するために必要な最小プロトコルです。セキュリティー要件によっては、プロバイダーがノードのデフォルト以外の構成を要求する必要がある場合があります。詳細な例については、[XEP-0060]を参照してください。トピックの設定にも役立つように、プロバイダーはオプションで次のような設定パラメーターを含めることもできます。
<configure>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#node_config</value>
</field>
<field var='pubsub#access_model'><value>authorize</value></field>
<field var='pubsub#persist_items'><value>1</value></field>
<field var='pubsub#send_last_published_item'>
<value>never</value>
</field>
</x>
</configure>
The above configuration indicates the Topic is configured so that the Broker will a) explicitly approve subscription requests, b) persistently store all messages posted to the Topic, and c) not deliver the most recently published when an entity initially subscribes to the Topic. Please refer to [XEP-0060] for a more detailed description of this configuration and other available configuration options.
上記の構成は、ブローカーがa）サブスクリプション要求を明示的に承認し、b）トピックに投稿されたすべてのメッセージを永続的に保存し、c）エンティティが最初にトピックをサブスクライブしたときに最新のパブリッシュを配信しないようにトピックが構成されていることを示しています。この構成およびその他の使用可能な構成オプションの詳細については、[XEP-0060]を参照してください。
Unless an error occurs (see [XEP-0060] for various error flows), the Broker responds with success:
エラーが発生しない限り（さまざまなエラーフローについては[XEP-0060]を参照）、ブローカーは正常に応答します。
<iq type='result'
from='broker.security-grid.example'
to='datasource@provider.example/F12C2EFC9BB0'
id='A67507DF-2F22-4937-8D30-88D2F7DBA279'/>
Second, a Consumer would subscribe as follows:
次に、コンシューマは次のようにサブスクライブします。
<iq type='set' from='xmpp-grid-client@mile-host.example/2EBE702A97D6' to='broker.security-grid.example' id='9C6EEE9E-F09A-4418-8D68-3BA6AF852522'> <pubsub xmlns='http://jabber.org/protocol/pubsub'> <subscribe node='MILEHost' jid='xmpp-grid-client@mile-host.example'/> </pubsub> </iq> Unless an error occurs (see [XEP-0060] for various error flows), the Broker makes an appropriate authorization decision. If access is granted, it responds with success:
<iq type = 'set' from='xmpp-grid-client@mile-host.example/2EBE702A97D6 'to =' broker.security-grid.example 'id =' 9C6EEE9E-F09A-4418-8D68-3BA6AF852522 '> < pubsub xmlns = 'http：//jabber.org/protocol/pubsub'> <subscribe node = 'MILEHost' jid='xmpp-grid-client@mile-host.example '/> </ pubsub> </ iq>以外はエラーが発生した場合（さまざまなエラーフローについては[XEP-0060]を参照）、ブローカーが適切な承認決定を行います。アクセスが許可されると、成功して応答します。
<iq type='result'
from='broker.security-grid.example'
to='xmpp-grid-client@mile-host.example/2EBE702A97D6'
id='9C6EEE9E-F09A-4418-8D68-3BA6AF852522'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<subscription
node='MILEHost'
jid='xmpp-grid-client@mile-host.example'
subscription='subscribed'/>
</pubsub>
</iq>
Third, a Provider would publish an incident to the Broker using the MILEHost Topic as follows:
3番目に、プロバイダーは次のようにMILEHostトピックを使用してブローカーにインシデントを公開します。
<iq type='set'
from='datasource@provider.example/F12C2EFC9BB0'
to='broker.security-grid.example'
id='2A17D283-0DAE-4A6C-85A9-C10B1B40928C'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='MILEHost'>
<item id='8bh1g27skbga47fh9wk7'>
<IODEF-Document version="2.00" xml:lang="en"
xmlns="urn:ietf:params:xml:ns:iodef-2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"http://www.iana.org/assignments/xml-registry/
schema/iodef-2.0.xsd">
<Incident purpose="reporting" restriction="private">
<IncidentID name="csirt.example.com">492382</IncidentID>
<GenerationTime>2015-07-18T09:00:00-05:00</GenerationTime>
<Contact type="organization" role="creator">
<Email>
<EmailTo>contact@csirt.example.com</EmailTo>
</Email>
</Contact>
</Incident>
</IODEF-Document>
</item>
</publish>
</pubsub>
</iq>
(The payload in the foregoing example is from [RFC7970]; payloads for additional use cases can be found in [RFC8274].)
（前述の例のペイロードは[RFC7970]からのものです。追加の使用例のペイロードは[RFC8274]にあります。）
The Broker would then deliver that incident report to all Consumers who are subscribed to the Topic:
次に、ブローカーはそのインシデントレポートを、トピックにサブスクライブしているすべてのコンシューマーに配信します。
<message
from='broker.security-grid.example'
to='xmpp-grid-client@mile-host.example/2EBE702A97D6'
id='37B3921D-4F7F-450F-A589-56119A88BC2E'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='MILEHost'>
<item id='iah37s61s964gquqy47aksbx9453ks77'>
<IODEF-Document version="2.00" xml:lang="en"
xmlns="urn:ietf:params:xml:ns:iodef-2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"http://www.iana.org/assignments/xml-registry/
schema/iodef-2.0.xsd">
<Incident purpose="reporting" restriction="private">
<IncidentID name="csirt.example.com">492382</IncidentID>
<GenerationTime>2015-07-18T09:00:00-05:00</GenerationTime>
<Contact type="organization" role="creator">
<Email>
<EmailTo>contact@csirt.example.com</EmailTo>
</Email>
</Contact>
</Incident>
</IODEF-Document>
</item>
</items>
</event>
</message>
Note that [XEP-0060] uses the XMPP "<message />" stanza for delivery of content. To ensure that messages are delivered to the Consumer even if the Consumer is not online at the same time that the Publisher generates the message, an XMPP-Grid Controller MUST support "offline messaging" delivery semantics as specified in [RFC6121], the best practices of which are further explained in [XEP-0160].
[XEP-0060]はコンテンツの配信にXMPP "<message />"スタンザを使用することに注意してください。パブリッシャーがメッセージを生成すると同時にコンシューマーがオンラインでなくても、メッセージがコンシューマーに確実に配信されるように、XMPP-Grid Controllerは[RFC6121]で指定されている「オフラインメッセージング」配信セマンティクスをサポートする必要があります。これはベストプラクティスです。 [XEP-0160]でさらに説明されています。
This document has no actions for IANA.
このドキュメントには、IANAに対するアクションはありません。
An XMPP-Grid Controller serves as a controlling broker for XMPP-Grid Platforms such as enforcement points, policy servers, Configuration Management Databases (CMDBs), and sensors, using a publish-subscribe-search model of information exchange and lookup. By increasing the ability of XMPP-Grid Platforms to learn about and respond to security incident reports and other security-relevant information, XMPP-Grid can improve the timeliness and utility of the security system. However, this integrated security system can also be exploited by attackers if they can compromise it. Therefore, strong security protections for XMPP-Grid are essential.
XMPP-Grid Controllerは、情報交換とルックアップのパブリッシュ/サブスクライブ検索モデルを使用して、施行ポイント、ポリシーサーバー、構成管理データベース（CMDB）、センサーなどのXMPP-Gridプラットフォームの制御ブローカーとして機能します。 XMPP-Gridプラットフォームがセキュリティインシデントレポートやその他のセキュリティ関連情報を学習して対応する能力を高めることにより、XMPP-Gridはセキュリティシステムの適時性と有用性を向上させることができます。ただし、この統合セキュリティシステムは、攻撃者がセキュリティシステムを危険にさらす可能性がある場合、攻撃者によって悪用される可能性もあります。したがって、XMPP-Gridの強力なセキュリティ保護が不可欠です。
As XMPP is the core of this document, the security considerations of [RFC6120] apply. In addition, as XMPP-Grid defines a specific instance, this section provides a security analysis of the XMPP-Grid data transfer protocol and the architectural elements that employ it, specifically with respect to their use of this protocol. Three subsections define the trust model (which elements are trusted to do what), the threat model (attacks that can be mounted on the system), and the countermeasures (ways to address or mitigate the threats previously identified).
XMPPはこのドキュメントの中核であるため、[RFC6120]のセキュリティに関する考慮事項が適用されます。さらに、XMPP-Gridは特定のインスタンスを定義するため、このセクションでは、XMPP-Gridデータ転送プロトコルとそれを使用するアーキテクチャ要素のセキュリティ分析を、特にこのプロトコルの使用に関して提供します。 3つのサブセクションでは、信頼モデル（どの要素が何を実行するかを信頼する）、脅威モデル（システムにマウントできる攻撃）、および対策（以前に特定した脅威に対処または軽減する方法）を定義します。
The first step in analyzing the security of the XMPP-Grid transport protocol is to describe the trust model and list what each architectural element is trusted to do. The items listed here are assumptions, but provisions are made in "Threat Model" (Section 8.2) and "Countermeasures" (Section 8.3) for elements that fail to perform as they were trusted to do.
XMPP-Gridトランスポートプロトコルのセキュリティを分析する最初のステップは、信頼モデルを記述し、各アーキテクチャ要素が信頼できることをリストすることです。ここに記載されている項目は仮定ですが、「脅威モデル」（セクション8.2）および「対策」（セクション8.3）で、信頼されているために実行に失敗した要素がプロビジョニングされています。
The network used to carry XMPP-Grid messages (i.e., the underlying network transport layer over which XMPP runs) is trusted to:
XMPP-Gridメッセージを伝送するために使用されるネットワーク（つまり、XMPPが実行される基礎となるネットワークトランスポート層）は、次のものに対して信頼されています。
o Perform best-effort delivery of network traffic
o ネットワークトラフィックのベストエフォート配信を実行する
The network used to carry XMPP-Grid messages is not expected (trusted) to:
XMPP-Gridメッセージの伝送に使用されるネットワークは、次のことを期待されていません（信頼されていません）。
o Provide confidentiality or integrity protection for messages sent over it
o 送信されるメッセージの機密性または完全性を保護する
o Provide timely or reliable service
o タイムリーまたは信頼できるサービスを提供する
Authorized XMPP-Grid Platforms are trusted to:
承認されたXMPP-Gridプラットフォームは、以下に信頼されています。
o Preserve the confidentiality of sensitive data retrieved via the XMPP-Grid Controller
o XMPP-Grid Controllerを介して取得した機密データの機密性を保持します
The XMPP-Grid Controller (including its associated Broker) is trusted to:
XMPP-Grid Controller（関連するブローカーを含む）は、次のことを信頼されています。
o Broker requests for data and enforce authorization of access to this data throughout its lifecycle
o ブローカーがデータを要求し、そのライフサイクルを通じてこのデータへのアクセスの承認を実施する
o Perform service requests in a timely and accurate manner
o タイムリーかつ正確な方法でサービスリクエストを実行する
o Create and maintain accurate operational attributes
o 正確な運用属性を作成して維持する
o Only reveal data to and accept service requests from authorized parties
o 許可された関係者のみにデータを開示し、サービスリクエストを受け入れる
o Preserve the integrity (and confidentiality against unauthorized parties) of the data flowing through it.
o データを通過するデータの整合性（および無許可の当事者に対する機密性）を保持します。
The XMPP-Grid Controller is not expected (trusted) to:
XMPP-Grid Controllerは以下のことを期待されていません（信頼されています）。
o Verify the truth (correctness) of data
o データの真実性（正確性）を検証する
To allow XMPP-Grid Platforms to mutually authenticate with XMPP-Grid Controllers, it is expected that a Certification Authority (CA) is employed to issue certificates. Such a CA (or each CA, if there are several) is trusted to:
XMPP-GridプラットフォームがXMPP-Gridコントローラーと相互認証できるようにするには、証明機関（CA）を使用して証明書を発行する必要があります。そのようなCA（または、複数のCAがある場合は各CA）は、次のことを信頼されます。
o Ensure that only proper certificates are issued and that all certificates are issued in accordance with the CA's policies
o 適切な証明書のみが発行され、すべての証明書がCAのポリシーに従って発行されていることを確認します
o Revoke certificates previously issued when necessary
o 以前に発行された証明書を必要に応じて取り消す
o Regularly and securely distribute certificate revocation information
o 証明書失効情報を定期的かつ安全に配布します
o Promptly detect and report any violations of this trust so that they can be handled
o この信頼の違反を迅速に検出して報告し、それらを処理できるようにする
The CA is not expected (trusted) to:
CAは以下のことを期待されていません（信頼されています）。
o Issue certificates that go beyond the XMPP-Grid needs or other constraints imposed by a relying party.
o XMPP-Gridのニーズまたは証明書利用者によって課されたその他の制約を超える証明書を発行します。
To secure the XMPP-Grid data transfer protocol and the architectural elements that implement it, this section identifies the attacks that can be mounted against the protocol and elements.
XMPP-Gridデータ転送プロトコルとそれを実装するアーキテクチャ要素を保護するために、このセクションでは、プロトコルと要素に対して実装できる攻撃を特定します。
A variety of attacks can be mounted using the network. For the purposes of this subsection, the phrase "network traffic" can be taken to mean messages and/or parts of messages. Any of these attacks can be mounted by network elements, by parties who control network elements, and (in many cases) by parties who control network-attached devices.
ネットワークを使用して、さまざまな攻撃を仕掛けることができます。このサブセクションでは、「ネットワークトラフィック」という語句は、メッセージまたはメッセージの一部、あるいはその両方を意味すると解釈できます。これらの攻撃はいずれも、ネットワーク要素、ネットワーク要素を制御する関係者、および（多くの場合）ネットワーク接続デバイスを制御する関係者が仕掛けることができます。
o Network traffic can be passively monitored to glean information from any unencrypted traffic
o ネットワークトラフィックを受動的に監視して、暗号化されていないトラフィックから情報を収集できます。
o Even if all traffic is encrypted, valuable information can be gained by traffic analysis (volume, timing, source and destination addresses, etc.)
o すべてのトラフィックが暗号化されている場合でも、トラフィック分析によって貴重な情報（ボリューム、タイミング、送信元および宛先アドレスなど）を取得できます。
o Network traffic can be modified in transit
o ネットワークトラフィックは転送中に変更できます
o Previously transmitted network traffic can be replayed
o 以前に送信されたネットワークトラフィックを再生できます
o New network traffic can be added
o 新しいネットワークトラフィックを追加できます
o Network traffic can be blocked, perhaps selectively
o ネットワークトラフィックは、おそらく選択的にブロックできます
o A man-in-the-middle (MITM) attack can be mounted where an attacker interposes itself between two communicating parties and impersonates the other end to either or both parties
o 中間者（MITM）攻撃は、攻撃者が2つの通信している当事者の間に自分自身を介在させ、もう一方の端を一方または両方の当事者に偽装する場合に実装できます。
o Undesired network traffic can be sent in an effort to overload an architectural component, thus mounting a denial-of-service attack
o 不要なネットワークトラフィックを送信して、アーキテクチャコンポーネントに過負荷をかけ、サービス拒否攻撃を仕掛けることができます。
An unauthorized XMPP-Grid Platform (one that is not recognized by the XMPP-Grid Controller or is recognized but not authorized to perform any actions) cannot mount any attacks other than those listed in "Network Attacks" (Section 8.2.1).
不正なXMPP-Gridプラットフォーム（XMPP-Grid Controllerによって認識されない、または認識されてもアクションを実行する権限がないもの）は、「ネットワーク攻撃」（セクション8.2.1）に記載されている以外の攻撃をマウントできません。
An authorized XMPP-Grid Platform, on the other hand, can mount many attacks. These attacks might occur because the XMPP-Grid Platform is controlled by a malicious, careless, or incompetent party (whether because its owner is malicious, careless, or incompetent or because the XMPP-Grid Platform has been compromised and is now controlled by a party other than its owner). They might also occur because the XMPP-Grid Platform is running malicious software, the XMPP-Grid Platform is running buggy software (which can fail in a state that floods the network with traffic), or the XMPP-Grid Platform has been configured improperly. From a security standpoint, it generally makes no difference why an attack is initiated. The same countermeasures can be employed in any case.
一方、承認されたXMPP-Gridプラットフォームは、多くの攻撃を仕掛けることができます。これらの攻撃は、XMPP-Gridプラットフォームが悪意のある、不注意な、または無能な当事者によって制御されているために発生する可能性があります（所有者が悪意のある、不注意、または無能なため、またはXMPP-Gridプラットフォームが侵害され、現在は当事者によって制御されているため）その所有者以外）。また、XMPP-Gridプラットフォームが悪意のあるソフトウェアを実行している、XMPP-Gridプラットフォームがバグのあるソフトウェアを実行している（ネットワークがトラフィックで溢れる状態で失敗する可能性がある）、またはXMPP-Gridプラットフォームが正しく構成されていないために発生することもあります。セキュリティの観点からは、通常、攻撃が開始される理由に違いはありません。いずれの場合も同じ対策を採用できます。
Here is a list of attacks that can be mounted by an authorized XMPP-Grid Platform:
以下は、承認されたXMPP-Gridプラットフォームがマウントできる攻撃のリストです。
o Cause many false alarms or otherwise overload the XMPP-Grid Controller or other elements in the network security system (including human administrators), leading to a denial of service or parts of the network security system being disabled.
o 多くの誤警報を引き起こすか、そうでなければXMPP-Grid Controllerまたはネットワークセキュリティシステム（人間の管理者を含む）の他の要素に過負荷をかけ、サービス拒否またはネットワークセキュリティシステムの一部を無効にします。
o Omit important actions (such as posting incriminating data), resulting in incorrect access.
o 重要なアクション（有害なデータの投稿など）を省略して、誤ったアクセスを発生させる。
o Use confidential information obtained from the XMPP-Grid Controller to enable further attacks (such as using endpoint health check results to exploit vulnerable endpoints).
o XMPP-Grid Controllerから取得した機密情報を使用して、さらなる攻撃を可能にします（エンドポイントのヘルスチェック結果を使用して脆弱なエンドポイントを悪用するなど）。
o Advertise data crafted to exploit vulnerabilities in the XMPP-Grid Controller or in other XMPP-Grid Platforms with the goal of compromising those systems.
o XMPP-Grid Controllerまたは他のXMPP-Grid Platformの脆弱性を悪用して作成されたデータをアドバタイズし、これらのシステムを侵害することを目標にします。
o Issue a search request or set up a subscription that matches an enormous result, leading to resource exhaustion on the XMPP-Grid Controller, the publishing XMPP-Grid Platform, and/or the network.
o 検索要求を発行するか、膨大な結果と一致するサブスクリプションを設定すると、XMPP-Grid Controller、公開XMPP-Grid Platform、ネットワーク、またはその両方でリソースが枯渇します。
o Establish a communication channel using another XMPP-Grid Platform's session-id.
o 別のXMPP-GridプラットフォームのセッションIDを使用して通信チャネルを確立します。
o Advertise false data that leads to incorrect (e.g., potentially attacker-controlled or -induced) behavior of XMPP-Grid Platforms by virtue of applying correct procedures to the falsified input.
o 改ざんされた入力に正しい手順を適用することにより、XMPP-Gridプラットフォームの不正な（たとえば、攻撃者が制御または誘導する可能性がある）動作につながる誤ったデータを宣伝します。
Dependencies or vulnerabilities of authorized XMPP-Grid Platforms can be exploited to effect these attacks. Another way to effect these attacks is to gain the ability to impersonate an XMPP-Grid Platform (through theft of the XMPP-Grid Platform's identity credentials or through other means). Even a clock skew between the XMPP-Grid Platform and XMPP-Grid Controller can cause problems if the XMPP-Grid Platform assumes that old XMPP-Grid Platform data should be ignored.
承認されたXMPP-Gridプラットフォームの依存関係または脆弱性は、これらの攻撃に影響を与えるために悪用される可能性があります。これらの攻撃に影響を与える別の方法は、XMPP-Gridプラットフォームを偽装する能力を獲得することです（XMPP-GridプラットフォームのID資格情報の盗難またはその他の手段を通じて）。 XMPP-GridプラットフォームとXMPP-Gridコントローラー間のクロックスキューでも、XMPP-Gridプラットフォームが古いXMPP-Gridプラットフォームデータを無視する必要があると想定している場合、問題が発生する可能性があります。
An unauthorized XMPP-Grid Controller (one that is not trusted by XMPP-Grid Platforms) cannot mount any attacks other than those listed in "Network Attacks" (Section 8.2.1).
不正なXMPP-Grid Controller（XMPP-Grid Platformによって信頼されていないコントローラー）は、「ネットワーク攻撃」（セクション8.2.1）にリストされている以外の攻撃をマウントできません。
An authorized XMPP-Grid Controller can mount many attacks. Similar to the XMPP-Grid Platform case described above, these attacks might occur because the XMPP-Grid Controller is controlled by a malicious, careless, or incompetent party (either an XMPP-Grid Controller administrator or an attacker who has seized control of the XMPP-Grid Controller). They might also occur because the XMPP-Grid Controller is running malicious software, the XMPP-Grid Controller is running buggy software (which can fail in a state that corrupts data or floods the network with traffic), or the XMPP-Grid Controller has been configured improperly.
承認されたXMPP-Grid Controllerは、多くの攻撃を仕掛けることができます。上記のXMPP-Grid Platformのケースと同様に、XMPP-Grid Controllerは悪意のある、不注意な、または無能な当事者（XMPP-Grid Controller管理者またはXMPPの制御を奪った攻撃者のいずれか）によって制御されるため、これらの攻撃が発生する可能性があります-グリッドコントローラー）。また、XMPP-Grid Controllerが悪意のあるソフトウェアを実行している、XMPP-Grid Controllerがバグのあるソフトウェアを実行している（データが破損したり、ネットワークがトラフィックで溢れる状態になる可能性がある）、またはXMPP-Grid Controllerが正しく構成されていません。
All of the attacks listed for XMPP-Grid Platform above can be mounted by the XMPP-Grid Controller. Detection of these attacks will be more difficult since the XMPP-Grid Controller can create false operational attributes and/or logs that imply some other party created any bad data.
上記のXMPP-Grid Platformにリストされているすべての攻撃は、XMPP-Grid Controllerによってマウントできます。 XMPP-Grid Controllerは、他の誰かが不正なデータを作成したことを意味する誤った操作属性やログを作成できるため、これらの攻撃の検出はより困難になります。
Additional XMPP-Grid Controller attacks can include:
追加のXMPP-Grid Controller攻撃には、次のものがあります。
o Exposing different data to different XMPP-Grid Platforms to mislead investigators or cause inconsistent behavior.
o さまざまなデータをさまざまなXMPP-Gridプラットフォームに公開して、調査員を誤解させたり、一貫性のない動作を引き起こしたりする。
o Mounting an even more effective denial-of-service attack than a single XMPP-Grid Platform could; some mechanisms include inducing many platforms to perform the same operation in an amplification-style attack, completely refusing to pass any traffic at all, or sending floods of traffic to (certain) platforms or other targets.
o 単一のXMPP-Gridプラットフォームよりもさらに効果的なサービス拒否攻撃を仕掛けること。いくつかのメカニズムには、増幅スタイルの攻撃で同じ操作を実行するように多くのプラットフォームを誘導する、トラフィックをまったく渡すことを完全に拒否する、または（特定の）プラットフォームまたは他のターゲットにトラフィックのフラッドを送信することが含まれます。
o Obtaining and caching XMPP-Grid Platform credentials so they can be used to impersonate XMPP-Grid Platforms even after a breach of the XMPP-Grid Controller is repaired. Some Simple Authentication and Security Layer (SASL) mechanisms (including the mandatory-to-implement SCRAM and EXTERNAL with TLS mutual certificate-based authentication) do not admit this class of attack, but others (such as PLAIN) are susceptible.
o XMPP-Grid Platformの資格情報を取得してキャッシュし、XMPP-Grid Controllerの違反が修復された後でも、XMPP-Grid Platformの偽装に使用できるようにします。一部の単純認証およびセキュリティ層（SASL）メカニズム（TLS相互認証ベースの認証を伴う必須の実装SCRAMおよびEXTERNALを含む）は、このクラスの攻撃を許可しませんが、他の（PLAINなど）は影響を受けやすいです。
o Obtaining and caching XMPP-Grid Controller administrator credentials so they can be used to regain control of the XMPP-Grid Controller after the breach of the XMPP-Grid Controller is repaired.
o XMPP-Grid Controllerの違反が修復された後、XMPP-Grid Controllerの管理者資格情報を取得してキャッシュし、XMPP-Grid Controllerの制御を回復するために使用できるようにします。
o Eavesdropping, injecting, or modifying the data being transferred between Provider and Consumer.
o プロバイダーとコンシューマーの間で転送されるデータを盗聴、挿入、または変更する。
Dependencies or vulnerabilities of the XMPP-Grid Controller can be exploited to obtain control of the XMPP-Grid Controller and effect these attacks.
XMPP-Grid Controllerの依存関係または脆弱性を悪用して、XMPP-Grid Controllerの制御を取得し、これらの攻撃に影響を与えることができます。
A Certification Authority trusted to issue certificates for the XMPP-Grid Controller and/or XMPP-Grid Platforms can mount several attacks:
XMPP-Grid ControllerやXMPP-Grid Platformの証明書を発行すると信頼されている認証局は、いくつかの攻撃を仕掛けることができます。
o Issue certificates for unauthorized parties, enabling them to impersonate authorized parties such as the XMPP-Grid Controller or an XMPP-Grid Platform. This can lead to all the threats that can be mounted by the certificate's subject.
o 許可されていない当事者に対して証明書を発行し、XMPP-Grid ControllerやXMPP-Grid Platformなどの許可された当事者になりすますことができるようにします。これは、証明書のサブジェクトによってマウントされるすべての脅威につながる可能性があります。
o Issue certificates without following all of the CA's policies. Because this can result in issuing certificates that can be used to impersonate authorized parties, this can lead to all the threats that can be mounted by the certificate's subject.
o CAのすべてのポリシーに従わずに証明書を発行します。これにより、認証された当事者を偽装するために使用できる証明書が発行される可能性があるため、証明書のサブジェクトによってマウントされるすべての脅威につながる可能性があります。
o Fail to revoke previously issued certificates that need to be revoked. This can lead to undetected impersonation of the certificate's subject or failure to revoke authorization of the subject and therefore can lead to all of the threats that can be mounted by that subject.
o 失効する必要がある以前に発行された証明書を失効させない。これにより、証明書のサブジェクトの偽装が検出されなかったり、サブジェクトの承認が取り消されなかったりする可能性があるため、そのサブジェクトによってマウントされる可能性のあるすべての脅威につながる可能性があります。
o Fail to regularly and securely distribute certificate revocation information. This can cause a relying party to accept a revoked certificate, leading to undetected impersonation of the certificate's subject or failure to revoke authorization of the subject and therefore can lead to all of the threats that can be mounted by that subject. It can also cause a relying party to refuse to proceed with a transaction because timely revocation information is not available, even though the transaction should be permitted to proceed.
o 証明書失効情報を定期的かつ安全に配布できません。これにより、証明書利用者が失効した証明書を受け入れるようになり、証明書のサブジェクトの偽装が検出されなかったり、サブジェクトの承認を取り消すことができなくなり、そのサブジェクトによってマウントされる可能性のあるすべての脅威につながる可能性があります。また、トランザクションの続行を許可する必要がある場合でも、適時の失効情報を利用できないため、証明書利用者はトランザクションの続行を拒否する可能性があります。
o Allow the CA's private key to be revealed to an unauthorized party. This can lead to all the threats above. Even worse, the actions taken with the private key will not be known to the CA.
o CAの秘密鍵が無許可の第三者に公開されることを許可します。これは、上記のすべての脅威につながる可能性があります。さらに悪いことに、秘密鍵で行われたアクションはCAに知らされません。
o Fail to promptly detect and report errors and violations of trust so that relying parties can be promptly notified. This can cause the threats listed earlier in this section to persist longer than necessary, leading to many knock-on effects.
o 信頼者にエラーや信頼違反を迅速に検出して報告し、依存者に迅速に通知できるようにすること。これにより、このセクションで前述した脅威が必要以上に長く持続し、多くのノックオン効果が発生する可能性があります。
Below are countermeasures for specific attack scenarios to the XMPP-Grid infrastructure.
以下は、XMPP-Gridインフラストラクチャに対する特定の攻撃シナリオの対策です。
To address network attacks, the XMPP-Grid data transfer protocol described in this document requires that the XMPP-Grid messages MUST be carried over TLS (minimally TLS 1.2 and preferably TLS 1.3 [RFC8446]) as described in [RFC6120] and updated by [RFC7590]. The XMPP-Grid Controller and XMPP-Grid Platforms SHOULD mutually authenticate. The XMPP-Grid Platform MUST verify the XMPP-Grid Controller's certificate and determine whether the XMPP-Grid Controller is trusted by this XMPP-Grid Platform before completing the TLS handshake. To ensure interoperability, implementations MUST implement at least either the SASL EXTERNAL mechanism [RFC4422] or the SASL SCRAM mechanism. When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]). XMPP-Grid Platforms and XMPP-Grid Controllers using certificate-based authentication SHOULD each verify the revocation status of the other party's certificate. The selection of the XMPP-Grid Platform authentication technique to use in any particular deployment is left to the administrator.
ネットワーク攻撃に対処するには、このドキュメントで説明されているXMPP-Gridデータ転送プロトコルは、[RFC6120]で説明され、[ RFC7590]。 XMPP-Grid ControllerとXMPP-Grid Platformsは相互に認証する必要があります。 XMPP-Gridプラットフォームは、TLSハンドシェイクを完了する前に、XMPP-Grid Controllerの証明書を検証し、XMPP-Grid ControllerがこのXMPP-Grid Platformによって信頼されているかどうかを判断する必要があります。相互運用性を確保するために、実装は少なくともSASL EXTERNALメカニズム[RFC4422]またはSASL SCRAMメカニズムのいずれかを実装する必要があります。 SASL SCRAMメカニズムを使用する場合、SCRAM-SHA-256-PLUSバリアントはSCRAM-SHA-256バリアントよりも優先されるべきであり、SHA-256バリアント[RFC7677]はSHA-1バリアントよりも優先されるべきです[RFC5802]）。証明書ベースの認証を使用するXMPP-GridプラットフォームおよびXMPP-Gridコントローラーは、それぞれ相手の証明書の失効ステータスを検証する必要があります（SHOULD）。特定のデプロイメントで使用するXMPP-Gridプラットフォーム認証手法の選択は、管理者に任されています。
These protocol security measures provide protection against all the network attacks listed in Section 8.2 except denial-of-service attacks. If protection against these denial-of-service attacks is desired, ingress filtering, rate limiting per source IP address, and other denial-of-service mitigation measures can be employed. In addition, an XMPP-Grid Controller MAY automatically disable a misbehaving XMPP-Grid Platform.
これらのプロトコルセキュリティ対策は、サービス拒否攻撃を除き、セクション8.2にリストされているすべてのネットワーク攻撃に対する保護を提供します。これらのサービス拒否攻撃に対する保護が必要な場合は、入力フィルタリング、送信元IPアドレスごとのレート制限、およびその他のサービス拒否緩和策を採用できます。さらに、XMPP-Grid Controllerは、正しく動作しないXMPP-Grid Platformを自動的に無効にする場合があります。
XMPP-Grid Platforms can be deployed in locations that are susceptible to physical attacks. Physical security measures can be taken to avoid compromise of XMPP-Grid Platforms, but these are not always practical or completely effective. An alternative measure is to configure the XMPP-Grid Controller to provide read-only access for such systems. The XMPP-Grid Controller SHOULD also include a full authorization model so that individual XMPP-Grid Platforms can be configured to have only the privileges that they need. The XMPP-Grid Controller MAY provide functional templates so that the administrator can configure a specific XMPP-Grid Platform as a DHCP [RFC2131] server and authorize only the operations and metadata types needed by a DHCP server to be permitted for that XMPP-Grid Platform. These techniques can reduce the negative impacts of a compromised XMPP-Grid Platform without diminishing the utility of the overall system.
XMPP-Gridプラットフォームは、物理的な攻撃を受けやすい場所に配置できます。 XMPP-Gridプラットフォームの侵害を回避するために物理的なセキュリティ対策を講じることができますが、これらは常に実用的または完全に効果的であるとは限りません。代替手段は、XMPP-Grid Controllerを構成して、そのようなシステムに読み取り専用アクセスを提供することです。 XMPP-Grid Controllerには、完全な承認モデルも含まれている必要があるため（SHOULD）、個々のXMPP-Gridプラットフォームは、必要な特権のみを持つように構成できます。 XMPP-Grid Controllerは、管理者が特定のXMPP-Grid PlatformをDHCP [RFC2131]サーバーとして構成し、DHCPサーバーが必要とする操作とメタデータタイプのみをそのXMPP-Grid Platformに許可できるように機能テンプレートを提供する場合があります（MAY） 。これらの手法は、システム全体のユーティリティを損なうことなく、侵害されたXMPP-Gridプラットフォームの悪影響を減らすことができます。
To handle attacks within the bounds of this authorization model, the XMPP-Grid Controller MAY also include rate limits and alerts for unusual XMPP-Grid Platform behavior. XMPP-Grid Controllers SHOULD make it easy to revoke an XMPP-Grid Platform's authorization when necessary. The XMPP-Grid Controller SHOULD include auditable logs of XMPP-Grid Platform activities.
この認証モデルの範囲内で攻撃を処理するために、XMPP-Grid Controllerは、異常なXMPP-Grid Platform動作のレート制限とアラートも含めることができます（MAY）。 XMPP-Grid Controllerは、必要なときにXMPP-Grid Platformの承認を簡単に取り消す必要があります（SHOULD）。 XMPP-Grid Controllerには、XMPP-Grid Platformアクティビティの監査可能なログを含める必要があります（SHOULD）。
To avoid compromise of XMPP-Grid Platforms, they SHOULD be hardened against attack and minimized to reduce their attack surface. They should be well managed to minimize vulnerabilities in the underlying platform and in systems upon which the XMPP-Grid Platform depends. Personnel with administrative access should be carefully screened and monitored to detect problems as soon as possible.
XMPP-Gridプラットフォームの妥協を避けるために、それらは攻撃に対して強化されるべきであり、攻撃の表面を減らすために最小化されるべきです。基盤となるプラットフォームとXMPP-Gridプラットフォームが依存するシステムの脆弱性を最小限に抑えるために、適切に管理する必要があります。管理アクセス権を持つ担当者は、問題をできるだけ早く検出するために、注意深くスクリーニングおよび監視する必要があります。
Because of the serious consequences of XMPP-Grid Controller compromise, XMPP-Grid Controllers need to be especially well hardened against attack and minimized to reduce their attack surface. They need to be well managed to minimize vulnerabilities in the underlying platform and in systems upon which the XMPP-Grid Controller depends. Network security measures such as firewalls or intrusion detection systems can be used to monitor and limit traffic to and from the XMPP-Grid Controller. Personnel with administrative access ought to be carefully screened and monitored to detect problems as soon as possible. Administrators SHOULD NOT use password-based authentication but SHOULD instead use non-reusable credentials and multi-factor authentication (where available). Physical security measures ought to be employed to prevent physical attacks on XMPP-Grid Controllers.
XMPP-Grid Controllerの妥協の深刻な結果のため、XMPP-Grid Controllerは攻撃に対して特に十分に強化され、攻撃対象を減らすために最小化される必要があります。基盤となるプラットフォームやXMPP-Grid Controllerが依存するシステムの脆弱性を最小限に抑えるには、適切に管理する必要があります。ファイアウォールや侵入検知システムなどのネットワークセキュリティ対策を使用して、XMPP-Grid Controllerとの間のトラフィックを監視および制限できます。管理アクセス権を持つ担当者は、問題をできるだけ早く検出するために、注意深くスクリーニングおよび監視する必要があります。管理者はパスワードベースの認証を使用すべきではありませんが、代わりに再利用不可能な資格情報と多要素認証（利用可能な場合）を使用すべきです（SHOULD）。 XMPP-Grid Controllerへの物理的な攻撃を防ぐために、物理的なセキュリティ対策を採用する必要があります。
To ease detection of XMPP-Grid Controller compromise should it occur, XMPP-Grid Controller behavior should be monitored to detect unusual behavior (such as a reboot, a large increase in traffic, or different views of an information repository for similar XMPP-Grid Platforms). It is a matter of local policy whether XMPP-Grid Platforms log and/or notify administrators when peculiar XMPP-Grid Controller behavior is detected and whether read-only audit logs of security-relevant information (especially administrative actions) are maintained; however, such behavior is encouraged to aid in forensic analysis.
XMPP-Grid Controllerの侵害が発生した場合の検出を容易にするために、XMPP-Grid Controllerの動作を監視して、異常な動作（再起動、トラフィックの大幅な増加、または同様のXMPP-Gridプラットフォームの情報リポジトリのさまざまなビューなど）を検出する必要があります）。固有のXMPP-Grid Controllerの動作が検出されたときにXMPP-Grid Platformsがログに記録したり、管理者に通知したりするかどうか、およびセキュリティ関連情報（特に管理アクション）の読み取り専用の監査ログを維持するかどうかは、ローカルポリシーの問題です。ただし、このような動作は、フォレンジック分析を支援するために推奨されています。
Furthermore, if compromise of an XMPP-Grid Controller is detected, a careful analysis should be performed, and any reusable credentials that could have been compromised should be reissued.
さらに、XMPP-Grid Controllerの侵害が検出された場合、慎重な分析を実行し、侵害された可能性のある再利用可能な資格情報を再発行する必要があります。
To address the potential for the XMPP-Grid Controller to eavesdrop, modify or inject data, it would be desirable to deploy end-to-end encryption between the Provider and the Consumer(s). Unfortunately, because there is no standardized method for encryption of one-to-many messages within XMPP, techniques for enforcing end-to-end encryption are out of scope for this specification.
XMPP-Grid Controllerがデータを盗聴、変更、または挿入する可能性に対処するには、プロバイダーとコンシューマーの間でエンドツーエンドの暗号化を展開することが望ましいでしょう。残念ながら、XMPP内で1対多のメッセージを暗号化するための標準化された方法はないため、エンドツーエンドの暗号化を強制する手法はこの仕様の範囲外です。
The XMPP publish-subscribe specification [XEP-0060] defines five access models for subscribing to Topics at a Broker: open, presence, roster, authorize, and whitelist. The first model allows uncontrolled access, and the next two models are appropriate only in instant-messaging applications. Therefore, a Broker SHOULD support only the authorize model (under which the Topic owner needs to approve all subscription requests and only subscribers can retrieve data items) and the whitelist model (under which only preconfigured Platforms can subscribe or retrieve data items). In order to ease the deployment burden, subscription approvals and whitelist management can be automated (e.g., the Topic "owner" can be a policy server). The choice between "authorize" and "whitelist" as the default access model is a matter for local service policy.
XMPP publish-subscribe仕様[XEP-0060]は、ブローカーでトピックにサブスクライブするための5つのアクセスモデルを定義しています。オープン、プレゼンス、名簿、許可、ホワイトリストです。最初のモデルは制御されていないアクセスを許可し、次の2つのモデルはインスタントメッセージングアプリケーションでのみ適切です。したがって、ブローカーは、承認モデル（トピック所有者がすべてのサブスクリプション要求を承認する必要があり、サブスクライバーのみがデータアイテムを取得できる）とホワイトリストモデル（事前構成されたプラットフォームのみがデータアイテムをサブスクライブまたは取得できる）のみをサポートする必要があります（SHOULD）。導入の負担を軽減するために、サブスクリプションの承認とホワイトリストの管理を自動化できます（たとえば、トピックの「所有者」をポリシーサーバーにすることができます）。デフォルトのアクセスモデルとして「許可」と「ホワイトリスト」のどちらを選択するかは、ローカルサービスポリシーの問題です。
While XMPP-Grid is designed for high scalability to hundreds of thousands of Platforms, an XMPP-Grid Controller MAY establish a limit to the amount of data it is willing to return in search or subscription results. Platforms could use [XEP-0059] to restrict the size of the result sets the Controller returns in search or subscription results or topics' service discovery. This mitigates the threat of an XMPP-Grid Platform causing resource exhaustion by issuing a search or subscription that leads to an enormous result.
XMPP-Gridは、数十万のプラットフォームへの高いスケーラビリティを実現するように設計されていますが、XMPP-Grid Controllerは、検索またはサブスクリプションの結果で返すことができるデータの量に制限を設定する場合があります。プラットフォームは[XEP-0059]を使用して、コントローラーが検索またはサブスクリプションの結果またはトピックのサービスディスカバリで返す結果セットのサイズを制限できます。これは、膨大な結果につながる検索またはサブスクリプションを発行することにより、リソースの枯渇を引き起こすXMPP-Gridプラットフォームの脅威を軽減します。
As noted above, compromise of a Certification Authority (CA) trusted to issue certificates for the XMPP-Grid Controller and/or XMPP-Grid Platforms is a major security breach. Many guidelines for proper CA security have been developed: the CA/Browser Forum's Baseline Requirements, the American Institute of Certified Public Accountants (AICPA) / Canadian Institute of Chartered Accountants (CICA) Trust Service Principles, the IETF's Certificate Transparency [RFC6962], etc. The CA operator and relying parties should agree on appropriately rigorous security practices to be used.
上記のように、XMPP-Grid Controllerおよび/またはXMPP-Grid Platformの証明書を発行すると信頼されている証明機関（CA）の侵害は、主要なセキュリティ違反です。適切なCAセキュリティに関する多くのガイドラインが作成されています。CA/ブラウザフォーラムのベースライン要件、アメリカ公認会計士協会（AICPA）/カナダ公認会計士協会（CICA）の信託サービス原則、IETFの証明書の透明性[RFC6962]など。CAのオペレーターと依存者は、使用する適切な厳格なセキュリティ慣行に同意する必要があります。
Even with the most rigorous security practices, a CA can be compromised. If this compromise is detected quickly, relying parties can remove the CA from their list of trusted CAs, and other CAs can revoke any certificates issued to the CA. However, CA compromise may go undetected for some time, and there's always the possibility that a CA is being operated improperly or in a manner that is not in the interests of the relying parties. For this reason, relying parties may wish to "pin" a small number of particularly critical certificates (such as the certificate for the XMPP-Grid Controller). Once a certificate has been pinned, the relying party will not accept another certificate in its place unless the Administrator explicitly commands it to do so. This does not mean that the relying party will not check the revocation status of pinned certificates. However, the Administrator can still be consulted if a pinned certificate is revoked, since the CA and revocation process are not completely trusted. By "pinning" one or a small set of certificates, the relying party has identified the effective XMPP-Grid Controller(s) authorized for connection.
最も厳格なセキュリティプラクティスがあっても、CAは危険にさらされる可能性があります。この侵害が迅速に検出された場合、証明書利用者は信頼できるCAのリストからCAを削除でき、他のCAはCAに対して発行された証明書を取り消すことができます。ただし、CAの侵害はしばらくの間検出されない可能性があり、CAが不適切に、または証明書利用者の利益とならない方法で操作されている可能性が常にあります。このため、証明書利用者は、少数の特に重要な証明書（XMPP-Grid Controllerの証明書など）を「固定」することを望む場合があります。証明書が固定されると、管理者が明示的に指示しない限り、証明書利用者は代わりに別の証明書を受け入れません。これは、依存パーティがピン留めされた証明書の失効ステータスをチェックしないことを意味しません。ただし、CAと失効プロセスは完全に信頼されていないため、固定された証明書が失効した場合でも、管理者に相談することができます。証明書の1つまたは少数のセットを「固定」することにより、依存パーティは、接続が許可された有効なXMPP-Grid Controllerを識別しました。
Because it is expected that there will be a relatively large number of Consumers for every Topic, for the purposes of content discovery and scaling, this document specifies a "one-to-many" communications pattern using the XMPP Publish-Subscribe extension. Unfortunately, there is no standardized technology for end-to-end encryption of one-to-many messages in XMPP. This implies that messages can be subject to eavesdropping, data injection, and data modification attacks within a Broker or Controller. If it is necessary to mitigate against such attacks, implementers would need to select a messaging pattern other than [XEP-0060], most likely the basic "instant messaging" pattern specified in [RFC6121] with a suitable XMPP extension for end-to-end encryption. The description of such an approach is out of scope for this document.
コンテンツの検出とスケーリングの目的で、すべてのトピックに比較的多数のコンシューマーが存在することが予想されるため、このドキュメントでは、XMPP Publish-Subscribe拡張を使用して「1対多」の通信パターンを指定します。残念ながら、XMPPで1対多のメッセージをエンドツーエンドで暗号化するための標準化されたテクノロジーはありません。これは、メッセージがブローカーまたはコントローラー内で盗聴、データインジェクション、およびデータ変更攻撃を受ける可能性があることを意味します。このような攻撃を軽減する必要がある場合、実装者は[XEP-0060]以外のメッセージングパターンを選択する必要があります。おそらく、[RFC6121]で指定されている基本的な「インスタントメッセージング」パターンで、エンドツーエンドの適切なXMPP拡張を使用します。暗号化を終了します。このようなアプローチの説明は、このドキュメントの範囲外です。
XMPP-Grid's considerable value as a broker for security-sensitive data exchange distribution also makes the protocol and the network security elements that implement it a target for attack. Therefore, strong security has been included as a basic design principle within the XMPP-Grid design process.
XMPP-Gridは、セキュリティの影響を受けやすいデータ交換配布のブローカーとしてかなりの価値があるため、それを実装するプロトコルとネットワークセキュリティ要素も攻撃の対象になります。したがって、XMPP-Grid設計プロセスの基本的な設計原則として、強力なセキュリティが含まれています。
The XMPP-Grid data transfer protocol provides strong protection against a variety of different attacks. In the event that an XMPP-Grid Platform or XMPP-Grid Controller is compromised, the effects of this compromise are reduced and limited with the recommended role-based authorization model and other provisions, and best practices for managing and protecting XMPP-Grid systems have been described. Taken together, these measures should provide protection commensurate with the threat to XMPP-Grid systems, thus ensuring that they fulfill their promise as a network security clearinghouse.
XMPP-Gridデータ転送プロトコルは、さまざまな異なる攻撃に対する強力な保護を提供します。 XMPP-GridプラットフォームまたはXMPP-Gridコントローラーが侵害された場合、この侵害の影響は、推奨されるロールベースの承認モデルおよびその他の規定により軽減および制限され、XMPP-Gridシステムの管理および保護のベストプラクティスは、記載されています。まとめると、これらの対策はXMPP-Gridシステムへの脅威に見合った保護を提供し、ネットワークセキュリティクリアリングハウスとしての約束を確実に果たすはずです。
XMPP-Grid Platforms can publish information about endpoint health, network access, events (which can include information about which services an endpoint is accessing), roles and capabilities, and the identity of the end user operating the endpoint. Any of this published information can be queried by other XMPP-Grid Platforms and could potentially be used to correlate network activity to a particular end user.
XMPP-Gridプラットフォームは、エンドポイントの状態、ネットワークアクセス、イベント（エンドポイントがアクセスしているサービスに関する情報を含むことができる）、役割と機能、およびエンドポイントを操作するエンドユーザーのIDに関する情報を公開できます。この公開された情報はすべて、他のXMPP-Gridプラットフォームによって照会でき、ネットワークアクティビティを特定のエンドユーザーに関連付けるために使用される可能性があります。
Dynamic and static information brokered by an XMPP-Grid Controller, ostensibly for the purposes of correlation by XMPP-Grid Platforms for intrusion detection, could be misused by a broader set of XMPP-Grid Platforms that hitherto have been performing specific roles with a strict, well-defined separation of duties.
XMPP-Gridコントローラーによるブローカリングされた動的および静的な情報は、表面上は侵入検知用のXMPP-Gridプラットフォームによる相関を目的としており、これまで厳密に特定の役割を果たしてきたXMPP-Gridプラットフォームの幅広いセットによって悪用される可能性があります。明確な職務分掌。
Care needs to be taken by deployers of XMPP-Grid to ensure that the information published by XMPP-Grid Platforms does not violate agreements with end users or local and regional laws and regulations. This can be accomplished either by configuring XMPP-Grid Platforms to not publish certain information or by restricting access to sensitive data to trusted XMPP-Grid Platforms. That is, the easiest means to ensure privacy or protect sensitive data is to omit or not share it at all.
XMPP-Grid Platformによって公開された情報がエンドユーザーまたは地域や地域の法律や規制との合意に違反しないように、XMPP-Gridの展開者が注意を払う必要があります。これは、特定の情報を公開しないようにXMPP-Gridプラットフォームを構成するか、信頼できるXMPP-Gridプラットフォームへの機密データへのアクセスを制限することによって実現できます。つまり、プライバシーを確保したり、機密データを保護したりする最も簡単な方法は、データを省略するか、まったく共有しないことです。
Similarly, care must be taken by deployers and XMPP-Grid Controller implementations as they implement the appropriate auditing tools. In particular, any information, such as logs, must be sensitive to the type of information stored to ensure that the information does not violate privacy and agreements with end users or local and regional laws and regulations.
同様に、デプロイヤとXMPP-Grid Controllerの実装は、適切な監査ツールを実装するため、注意が必要です。特に、ログなどの情報は、保存されている情報の種類に敏感で、プライバシーやエンドユーザーとの合意、または地域や地域の法律や規制に違反しないようにする必要があります。
Another consideration for deployers is to enable end-to-end encryption to ensure the data is protected while in transit between data layers and thus protected from the transport layer. The means to achieve end-to-end encryption is beyond the scope of this document.
デプロイヤーにとってのもう1つの考慮事項は、エンドツーエンドの暗号化を有効にして、データレイヤー間で転送中のデータを確実に保護し、トランスポートレイヤーから保護することです。エンドツーエンドの暗号化を実現する手段は、このドキュメントの範囲外です。
In order to facilitate the management of Providers and the onboarding of Consumers, it is helpful to generate the following ahead of time:
プロバイダーの管理とコンシューマーのオンボーディングを容易にするために、事前に以下を生成しておくと役立ちます。
o Agreement between the operators of Provider services and the implementers of Consumer software regarding identifiers for common Topics (e.g., these could be registered with the XMPP Software Foundation's registry of well-known nodes for service discovery and publish-subscribe, located at <https://xmpp.org/registrar/ nodes.html>).
o 一般的なトピックの識別子に関するプロバイダーサービスのオペレーターとコンシューマーソフトウェアの実装者の間の合意（たとえば、これらは、<https：/にある、サービス検出およびパブリッシュサブスクライブ用の既知のノードのXMPPソフトウェア財団のレジストリに登録できます。 /xmpp.org/registrar/nodes.html>）。
o Security certificates (including appropriate certificate chains) for Controllers, including identification of any Providers associated with the Controllers (which might be located at subdomains).
o コントローラーに関連付けられているプロバイダー（サブドメインにある可能性がある）の識別を含む、コントローラーのセキュリティ証明書（適切な証明書チェーンを含む）。
o Consistent and secure access control policies for publishing and subscribing to Topics.
o トピックを公開および購読するための一貫した安全なアクセス制御ポリシー。
These matters are out of scope for this document but ought to be addressed by the XMPP-Grid community.
これらの問題はこのドキュメントの範囲外ですが、XMPP-Gridコミュニティで対処する必要があります。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, <https://www.rfc-editor.org/info/rfc2026>.
[RFC2026] Bradner、S。、「The Internet Standards Process-Revision 3」、BCP 9、RFC 2026、DOI 10.17487 / RFC2026、1996年10月、<https://www.rfc-editor.org/info/rfc2026> 。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006, <https://www.rfc-editor.org/info/rfc4422>.
[RFC4422]メルニコフ、A。、エド。 K. Zeilenga編、「Simple Authentication and Security Layer（SASL）」、RFC 4422、DOI 10.17487 / RFC4422、2006年6月、<https://www.rfc-editor.org/info/rfc4422>。
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, DOI 10.17487/RFC5802, July 2010, <https://www.rfc-editor.org/info/rfc5802>.
[RFC5802]ニューマン、C。、メノンセン、A。、メルニコフ、A。、およびN.ウィリアムズ、「ソルトチャレンジレスポンス認証メカニズム（SCRAM）SASLおよびGSS-APIメカニズム」、RFC 5802、DOI 10.17487 / RFC5802、 2010年7月、<https://www.rfc-editor.org/info/rfc5802>。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[RFC6120] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Core」、RFC 6120、DOI 10.17487 / RFC6120、2011年3月、<https://www.rfc-editor.org/info/rfc6120 >。
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, DOI 10.17487/RFC6121, March 2011, <https://www.rfc-editor.org/info/rfc6121>.
[RFC6121] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Instant Messaging and Presence」、RFC 6121、DOI 10.17487 / RFC6121、2011年3月、<https://www.rfc-editor.org/ info / rfc6121>。
[RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June 2015, <https://www.rfc-editor.org/info/rfc7590>.
[RFC7590] Saint-Andre、P。およびT. Alkemade、「Extensible Messaging and Presence Protocol（XMPP）でのトランスポート層セキュリティ（TLS）の使用」、RFC 7590、DOI 10.17487 / RFC7590、2015年6月、<https：/ /www.rfc-editor.org/info/rfc7590>。
[RFC7677] Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms", RFC 7677, DOI 10.17487/RFC7677, November 2015, <https://www.rfc-editor.org/info/rfc7677>.
[RFC7677] Hansen、T。、「SCRAM-SHA-256およびSCRAM-SHA-256-PLUS単純認証およびセキュリティ層（SASL）メカニズム」、RFC 7677、DOI 10.17487 / RFC7677、2015年11月、<https：// www .rfc-editor.org / info / rfc7677>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[XEP-0004] Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and P. Saint-Andre, "Data Forms", XSF XEP 0004, August 2007, <https://xmpp.org/extensions/xep-0004.html>.
[XEP-0004] Eatmon、R.、Hildebrand、J.、Miller、J.、Muldowney、T。、およびP. Saint-Andre、「Data Forms」、XSF XEP 0004、2007年8月、<https：// xmpp .org / extensions / xep-0004.html>。
[XEP-0030] Hildebrand, J., Millard, P., Eatmon, R., and P. Saint-Andre, "Service Discovery", XSF XEP 0030, October 2017, <https://xmpp.org/extensions/xep-0030.html>.
[XEP-0030] Hildebrand、J.、Millard、P.、Eatmon、R。、およびP. Saint-Andre、「Service Discovery」、XSF XEP 0030、2017年10月、<https://xmpp.org/extensions/ xep-0030.html>。
[XEP-0059] Paterson, I., Saint-Andre, P., Mercier, V., and J. Seguineau, "Result Set Management", XSF XEP 0059, September 2006, <https://xmpp.org/extensions/xep-0059.html>.
[XEP-0059] Paterson、I.、Saint-Andre、P.、Mercier、V。、およびJ. Seguineau、「Result Set Management」、XSF XEP 0059、2006年9月、<https://xmpp.org/extensions /xep-0059.html>。
[XEP-0060] Millard, P., Saint-Andre, P., and R. Meijer, "Publish-Subscribe", XSF XEP 0060, January 2019, <https://xmpp.org/extensions/xep-0060.html>.
[XEP-0060] Millard、P.、Saint-Andre、P。、およびR. Meijer、「Publish-Subscribe」、XSF XEP 0060、2019年1月、<https://xmpp.org/extensions/xep-0060。 html>。
[XEP-0203] Saint-Andre, P., "Delayed Delivery", XSF XEP 0203, September 2009, <https://xmpp.org/extensions/xep-0203.html>.
[XEP-0203] Saint-Andre、P。、「遅延配信」、XSF XEP 0203、2009年9月、<https://xmpp.org/extensions/xep-0203.html>。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、DOI 10.17487 / RFC2131、1997年3月、<https://www.rfc-editor.org/info/rfc2131>。
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, <https://www.rfc-editor.org/info/rfc6962>.
[RFC6962]ローリーB.、ラングレーA.、およびE.キャスパー、「証明書の透明性」、RFC 6962、DOI 10.17487 / RFC6962、2013年6月、<https://www.rfc-editor.org/info/rfc6962 >。
[RFC7970] Danyliw, R., "The Incident Object Description Exchange Format Version 2", RFC 7970, DOI 10.17487/RFC7970, November 2016, <https://www.rfc-editor.org/info/rfc7970>.
[RFC7970] Danyliw、R。、「The Incident Object Description Exchange Format Version 2」、RFC 7970、DOI 10.17487 / RFC7970、2016年11月、<https://www.rfc-editor.org/info/rfc7970>。
[RFC8274] Kampanakis, P. and M. Suzuki, "Incident Object Description Exchange Format Usage Guidance", RFC 8274, DOI 10.17487/RFC8274, November 2017, <https://www.rfc-editor.org/info/rfc8274>.
[RFC8274] Kampanakis、P。およびM. Suzuki、「Incident Object Description Exchange Format Usage Guidance」、RFC 8274、DOI 10.17487 / RFC8274、2017年11月、<https://www.rfc-editor.org/info/rfc8274> 。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] Rescorla、E。、「The Transport Layer Security（TLS）Protocol Version 1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。
[XEP-0160] Saint-Andre, P., "Best Practices for Handling Offline Messages", XSF XEP 0160, October 2016, <https://xmpp.org/extensions/xep-0160.html>.
[XEP-0160] Saint-Andre、P。、「オフラインメッセージを処理するためのベストプラクティス」、XSF XEP 0160、2016年10月、<https://xmpp.org/extensions/xep-0160.html>。
Acknowledgements
謝辞
The authors would like to acknowledge the contributions, authoring and/or editing of the following people: Joseph Salowey, Lisa Lorenzin, Clifford Kahn, Henk Birkholz, Jessica Fitzgerald-McKay, Steve Hanna, and Steve Venema. In addition, we want to thank Takeshi Takahashi, Panos Kampanakis, Adam Montville, Chris Inacio, and Dave Cridland for reviewing and providing valuable comments.
著者は、Joseph Salowey、Lisa Lorenzin、Clifford Kahn、Henk Birkholz、Jessica Fitzgerald-McKay、Steve Hanna、Steve Venemaの貢献、執筆、編集を認めたいと思います。また、貴重なコメントの確認と提供をしてくださった高橋武、Panos Kampanakis、Adam Montville、Chris Inacio、Dave Cridlandに感謝します。
Authors' Addresses
著者のアドレス
Nancy Cam-Winget (editor) Cisco Systems 3550 Cisco Way San Jose, CA 95134 United States of America
Nancy Cam-Winget（編集者）Cisco Systems 3550 Cisco Way San Jose、CA 95134アメリカ合衆国
Email: ncamwing@cisco.com
Syam Appala Cisco Systems 3550 Cisco Way San Jose, CA 95134 United States of America
Syam Appala Cisco Systems 3550 Cisco Way San Jose、CA 95134アメリカ合衆国
Email: syam1@cisco.com
Scott Pope Cisco Systems 5400 Meadows Road Suite 300 Lake Oswego, OR 97035 United States of America
Scott Pope Cisco Systems 5400 Meadows Road Suite 300 Lake Oswego、OR 97035アメリカ合衆国
Email: scottp@cisco.com
Peter Saint-Andre Mozilla
ピーターセントアンドレモジラ
Email: stpeter@mozilla.com