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
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
使用可扩展消息和状态协议（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).
本文档描述了如何使用可扩展消息和状态协议（XMPP）在网络连接设备之间收集和分发安全事件报告和其他安全相关信息，主要用于计算机安全事件响应团队和相关实体之间的通信。为了说明所涉及的原则，本文档描述了事件对象描述交换格式（IODEF）的这种用法。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了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.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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.
本文档定义了一种体系结构，即“XMPP网格”，作为一种使用可扩展消息和状态协议（XMPP）[RFC6120]在网络平台、端点和任何其他网络连接设备之间收集和分发安全事件报告和其他安全相关信息的方法，主要用于计算机安全事件响应团队和相关实体之间的通信。实际上，本文件规定了适用性声明（[RFC2026]，第3.2节），该声明定义了如何使用XMPP在授权实体之间的受控访问网络上交换安全通知。
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等）的形式，但本文档通过使用事件对象描述交换格式（IODEF）[RFC7970]的示例说明了XMPP网格的原理。也就是说，虽然其他安全信息格式可以使用XMPP共享，但本文档使用IODEF作为一种示例格式，可以使用XMPP发布和使用。
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.
控制器：包含控制平面功能的组件，用于管理和促进信息共享或执行安全功能；这里使用的术语是指XMPP服务器，它提供发布-订阅实体使用的核心消息传递[RFC6120]。
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网格以发布或使用安全相关信息的任何实体。
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.
主题：在代理上创建的上下文信息通道，提供者生成的消息在该通道上实时传播给一个或多个使用者。每个主题仅限于特定类型和格式的安全数据（例如，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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The following figure illustrates the architecture of XMPP-Grid.
下图说明了XMPP网格的体系结构。
+--------------------------------------+
| +--------------------------------------+
| | +--------------------------------------+
| | | |
+-| | 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 | |
| | |-+
+------------------------------------+ | |
+------------------------------------+ |
+------------------------------------+
+--------------------------------------+
| +--------------------------------------+
| | +--------------------------------------+
| | | |
+-| | 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网格体系结构
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
平台连接到控制器（XMPP服务器）进行身份验证，然后建立适当的授权，成为代理中感兴趣主题的提供者或使用者。控制平面消息通过XMPP建立，如图1中的“A”（控制平面接口）所示。然后，授权平台可以共享
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).
数据可以通过代理（图1中显示为“B”），也可以在某些情况下直接（图1中显示为“C”）。本文档主要关注用于信息共享的代理流（“直接流”交互可用于特殊目的，如批量数据传输，但其方法不在本文档范围内）。
Implementations of XMPP-Grid adhere to the following workflow:
XMPP网格的实现遵循以下工作流：
a. A Platform with a source of security data requests connection to the XMPP-Grid via a Controller.
a. 具有安全数据源的平台通过控制器请求连接到XMPP网格。
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. 平台通过代理建立授权权限（例如，发布和/或订阅一个或多个主题的权限）。
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) | |
|<---------------------| |
| | |
+--------------+ +------------+ +---------------+
| 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网格实现必须遵守[RFC6120]中定义的强制实现和强制协商功能。类似地，实现必须实现发布-订阅扩展[XEP-0060]，以促进信息的异步共享。实现应实现[XEP-0030]中定义的服务发现，以便于动态发现要发布或使用的可用信息和名称空间（主题）。如果它们的部署允许大量主题，则应注意实现。[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]限制控制器在服务发现响应中返回的结果集的大小。例如，“security grid.example”处的控制器可能在“Broker.security grid.example”处提供一个代理，该代理承载许多主题。“xmpp网格”上的平台-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>
<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='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>
<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>
<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]):
代理用“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>
<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>
<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
注意：前面的示例是创建主题所需的最低协议，该主题在创建的“to”地址中指定了XMPP发布订阅服务上的默认节点配置
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:
请求节。根据安全要求，提供者可能需要请求节点的非默认配置；有关详细示例，请参见[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>
<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'/>
<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>
<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:
除非发生错误（有关各种错误流，请参见[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>
<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:
第三，提供者将使用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>
<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>
<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网格控制器必须支持[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网格控制器使用信息交换和查找的发布-订阅搜索模型，充当XMPP网格平台（如实施点、策略服务器、配置管理数据库（CMDB）和传感器）的控制代理。通过增加XMPP网格平台了解和响应安全事件报告和其他安全相关信息的能力，XMPP网格可以提高安全系统的及时性和实用性。但是，如果攻击者能够破坏该集成安全系统，则攻击者也可以利用该系统进行攻击。因此，为XMPP网格提供强大的安全保护至关重要。
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网格定义了一个特定实例，因此本节提供了XMPP网格数据传输协议和使用该协议的体系结构元素的安全性分析，特别是关于它们对该协议的使用。三个小节定义了信任模型（哪些元素被信任去做什么）、威胁模型（可以安装在系统上的攻击）和对策（解决或缓解先前识别的威胁的方法）。
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网格传输协议的安全性的第一步是描述信任模型，并列出每个体系结构元素的信任作用。此处列出的项目是假设，但“威胁模型”（第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网格消息的网络（即XMPP运行的底层网络传输层）受信任：
o Perform best-effort delivery of network traffic
o 尽最大努力交付网络流量
The network used to carry XMPP-Grid messages is not expected (trusted) to:
用于承载XMPP网格消息的网络不应（受信任）用于：
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网格平台受信任：
o Preserve the confidentiality of sensitive data retrieved via the XMPP-Grid Controller
o 保护通过XMPP网格控制器检索的敏感数据的机密性
The XMPP-Grid Controller (including its associated Broker) is trusted to:
XMPP网格控制器（包括其关联的代理）受信任：
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网格控制器不应（受信任）执行以下操作：
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网格平台与XMPP网格控制器相互认证，预计将使用证书颁发机构（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网格需求或依赖方施加的其他约束的证书。
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网格数据传输协议及其实现的体系结构元素的安全，本节确定了可针对该协议和元素的攻击。
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）攻击可以在攻击者介入通信双方并向其中一方或双方假冒另一端的情况下进行
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网格平台（未经XMPP网格控制器识别或已识别但未授权执行任何操作的平台）不能发起除“网络攻击”（第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网格平台可以发起许多攻击。发生这些攻击的原因可能是XMPP网格平台由恶意、粗心或不称职的一方控制（无论是因为其所有者是恶意、粗心或不称职的，还是因为XMPP网格平台已受损，现在由其所有者以外的一方控制）。也可能是因为XMPP网格平台正在运行恶意软件、XMPP网格平台正在运行有缺陷的软件（在流量充斥网络的状态下可能会失败）或者XMPP网格平台配置不正确。从安全角度来看，发起攻击的原因通常没有区别。在任何情况下都可以采用相同的对策。
Here is a list of attacks that can be mounted by an authorized XMPP-Grid Platform:
以下是授权XMPP网格平台可以装载的攻击列表：
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网格控制器或网络安全系统中的其他元件（包括人工管理员）过载，导致拒绝服务或部分网络安全系统被禁用。
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网格控制器获得的机密信息来启用进一步的攻击（例如使用端点健康检查结果来利用易受攻击的端点）。
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网格控制器或其他XMPP网格平台中的漏洞，从而危害这些系统。
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网格控制器、发布XMPP网格平台和/或网络上的资源耗尽。
o Establish a communication channel using another XMPP-Grid Platform's session-id.
o 使用另一个XMPP网格平台的会话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网格平台不正确（例如，潜在的攻击者控制或诱导）行为的虚假数据。
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
可以利用授权XMPP网格平台的依赖性或漏洞来实施这些攻击。实施这些攻击的另一种方法是获得模拟XMPP网格平台的能力（通过盗窃XMPP网格平台的身份凭证或
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网格平台假定应忽略旧的XMPP网格平台数据，则即使是XMPP网格平台和XMPP网格控制器之间的时钟偏移也会导致问题。
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网格控制器（XMPP网格平台不信任的控制器）不能装载“网络攻击”（第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网格控制器可以装载许多攻击。与上述XMPP网格平台案例类似，发生这些攻击的原因可能是XMPP网格控制器由恶意、粗心或不称职的一方（XMPP网格控制器管理员或已夺取XMPP网格控制器控制权的攻击者）控制。也可能是因为XMPP网格控制器运行的是恶意软件，XMPP网格控制器运行的是有缺陷的软件（可能在损坏数据或使网络流量泛滥的状态下发生故障），或者XMPP网格控制器配置不正确。
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网格平台列出的所有攻击都可以由XMPP网格控制器装载。检测这些攻击将更加困难，因为XMPP网格控制器可以创建虚假的操作属性和/或日志，这意味着其他方创建了任何不良数据。
Additional XMPP-Grid Controller attacks can include:
其他XMPP网格控制器攻击可能包括：
o Exposing different data to different XMPP-Grid Platforms to mislead investigators or cause inconsistent behavior.
o 将不同的数据暴露于不同的XMPP网格平台以误导调查人员或导致不一致的行为。
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网格平台更有效的拒绝服务攻击；一些机制包括诱导多个平台在放大式攻击中执行相同的操作，完全拒绝通过任何流量，或向（某些）平台或其他目标发送大量流量。
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网格平台凭据，以便即使在修复了XMPP网格控制器的漏洞之后，也可以使用这些凭据来模拟XMPP网格平台。一些简单身份验证和安全层（SASL）机制（包括强制实施紧急停堆和外部TLS基于相互证书的身份验证）不允许此类攻击，但其他机制（如平原）则容易受到攻击。
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网格控制器管理员凭据，以便在修复XMPP网格控制器的漏洞后，可以使用这些凭据重新获得对XMPP网格控制器的控制。
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网格控制器的依赖项或漏洞来获得对XMPP网格控制器的控制并实施这些攻击。
A Certification Authority trusted to issue certificates for the XMPP-Grid Controller and/or XMPP-Grid Platforms can mount several attacks:
受信任为XMPP网格控制器和/或XMPP网格平台颁发证书的证书颁发机构可能会发起多种攻击：
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网格控制器或XMPP网格平台。这可能会导致证书的主体装载的所有威胁。
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网格基础设施的特定攻击场景的对策。
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网格数据传输协议要求XMPP网格消息必须通过TLS（最低TLS 1.2，最好是TLS 1.3[RFC8446]），如[RFC6120]所述，并由[RFC7590]更新。XMPP网格控制器和XMPP网格平台应该相互验证。在完成TLS握手之前，XMPP网格平台必须验证XMPP网格控制器的证书，并确定该XMPP网格平台是否信任XMPP网格控制器。为确保互操作性，实施必须至少实现SASL外部机制[RFC4422]或SASL紧急停堆机制。使用SASL紧急停堆机制时，应优先选择SCRAM-SHA-256-PLUS型，而不是SCRAM-SHA-256型，且SHA-256型[RFC7677]应优先于SHA-1型[RFC5802]）。使用基于证书的身份验证的XMPP网格平台和XMPP网格控制器应各自验证另一方证书的吊销状态。要在任何特定部署中使用的XMPP网格平台身份验证技术的选择权留给管理员。
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网格控制器可以自动禁用行为异常的XMPP网格平台。
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
XMPP网格平台可以部署在易受物理攻击的位置。可以采取物理安全措施来避免XMPP网格平台受损，但这些措施并不总是切实可行或完全有效。另一种方法是配置XMPP网格控制器，为此类系统提供只读访问。XMPP网格控制器还应该包括一个完整的授权模型，以便可以对各个XMPP网格平台进行授权
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网格控制器可以提供功能模板，以便管理员可以将特定的XMPP网格平台配置为DHCP[RFC2131]服务器，并仅授权DHCP服务器所需的操作和元数据类型，以允许该XMPP网格平台使用。这些技术可以减少受损XMPP网格平台的负面影响，而不会降低整个系统的效用。
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网格控制器还可能包括速率限制和异常XMPP网格平台行为警报。XMPP网格控制器应使必要时撤销XMPP网格平台的授权变得容易。XMPP网格控制器应该包括XMPP网格平台活动的可审核日志。
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网格平台受损，应该对其进行加固以抵御攻击，并将其最小化以减少攻击面。应该对它们进行良好的管理，以尽量减少底层平台和XMPP网格平台所依赖的系统中的漏洞。应仔细筛选和监控具有管理权限的人员，以尽快发现问题。
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网格控制器危害的严重后果，XMPP网格控制器需要针对攻击进行特别良好的加固，并最小化以减少其攻击面。需要对它们进行良好的管理，以尽量减少底层平台和XMPP网格控制器所依赖的系统中的漏洞。网络安全措施（如防火墙或入侵检测系统）可用于监控和限制进出XMPP网格控制器的流量。应仔细筛选和监控具有管理权限的人员，以尽快发现问题。管理员不应使用基于密码的身份验证，而应使用不可重用的凭据和多因素身份验证（如果可用）。应该采取物理安全措施来防止对XMPP网格控制器的物理攻击。
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网格控制器泄露时易于检测，应监控XMPP网格控制器行为以检测异常行为（例如重新启动、流量大幅增加或类似XMPP网格平台的信息存储库的不同视图）。当检测到特殊的XMPP网格控制器行为时，XMPP网格平台是否记录和/或通知管理员，以及是否维护安全相关信息（特别是管理操作）的只读审核日志，这是本地策略的问题；然而，鼓励这种行为来帮助法医分析。
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网格控制器受损，则应进行仔细分析，并重新发布可能受损的任何可重用凭据。
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网格控制器窃听、修改或注入数据的可能性，需要在提供者和使用者之间部署端到端加密。不幸的是，由于XMPP中没有标准化的一对多消息加密方法，因此用于实施端到端加密的技术超出了本规范的范围。
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发布-订阅规范[XEP-0060]定义了在代理上订阅主题的五种访问模型：开放、存在、花名册、授权和白名单。第一个模型允许不受控制的访问，接下来的两个模型仅适用于即时消息应用程序。因此，代理应该只支持授权模型（在该模型下，主题所有者需要批准所有订阅请求，只有订阅者可以检索数据项）和白名单模型（在该模型下，只有预配置的平台可以订阅或检索数据项）。为了减轻部署负担，可以自动化订阅批准和白名单管理（例如，“所有者”主题可以是策略服务器）。“授权”和“白名单”作为默认访问模型的选择取决于本地服务策略。
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网格是为数十万平台的高可扩展性而设计的，但XMPP网格控制器可能会对其愿意在搜索或订阅结果中返回的数据量设定限制。平台可以使用[XEP-0059]限制控制器在搜索或订阅结果或主题服务发现中返回的结果集的大小。这减轻了XMPP网格平台通过发布搜索或订阅导致巨大结果而导致资源耗尽的威胁。
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
如上所述，受信任为XMPP网格控制器和/或XMPP网格平台颁发证书的证书颁发机构（CA）的泄露是一个重大的安全漏洞。已经制定了许多适当的CA安全准则：CA/浏览器论坛的基线要求、美国注册会计师协会（AICPA）/加拿大特许会计师协会（CICA）信托
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.
服务原则、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网格控制器的证书）。一旦锁定了一个证书，依赖方将不会接受另一个证书，除非管理员明确命令它这样做。这并不意味着依赖方不会检查固定证书的吊销状态。但是，如果已吊销固定证书，仍然可以咨询管理员，因为CA和吊销过程不完全可信。通过“固定”一个或一小组证书，依赖方已确定授权连接的有效XMPP网格控制器。
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发布-订阅扩展指定了“一对多”通信模式。不幸的是，在XMPP中没有标准化的端到端加密一对多消息的技术。这意味着消息可能在代理或控制器中受到窃听、数据注入和数据修改攻击。如果有必要抵御此类攻击，则实施者需要选择[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网格作为安全敏感数据交换分发代理的巨大价值也使得协议和实现它的网络安全元素成为攻击目标。因此，在XMPP网格设计过程中，强安全性已被作为一项基本设计原则。
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网格数据传输协议针对各种不同的攻击提供了强大的保护。如果XMPP网格平台或XMPP网格控制器受到损害，则通过推荐的基于角色的授权模型和其他规定，这种损害的影响会减少并受到限制，并且已经描述了管理和保护XMPP网格系统的最佳实践。综上所述，这些措施应提供与XMPP网格系统所面临的威胁相称的保护，从而确保它们履行其作为网络安全交换所的承诺。
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网格平台可以发布有关端点健康状况、网络访问、事件（可以包括端点正在访问哪些服务的信息）、角色和功能以及操作端点的最终用户的身份的信息。任何发布的信息都可以被其他XMPP网格平台查询，并可能被用于将网络活动与特定的最终用户关联起来。
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网格控制器代理的动态和静态信息，表面上是为了XMPP网格平台关联入侵检测的目的，可能被更广泛的XMPP网格平台滥用，这些平台迄今为止一直以严格、明确的职责分离执行特定的角色。
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网格部署人员需要谨慎，以确保XMPP网格平台发布的信息不会违反与最终用户的协议或当地和地区法律法规。这可以通过将XMPP网格平台配置为不发布某些信息或将敏感数据的访问限制到受信任的XMPP网格平台来实现。也就是说，确保隐私或保护敏感数据的最简单方法是忽略或根本不共享这些数据。
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网格控制器实现在实现适当的审计工具时必须小心。特别是，任何信息（如日志）必须对存储的信息类型敏感，以确保信息不会违反隐私和与最终用户的协议或当地和地区法律法规。
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.
部署人员的另一个考虑事项是启用端到端加密，以确保数据在数据层之间传输时受到保护，从而免受传输层的保护。实现端到端加密的方法超出了本文档的范围。
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 提供商服务的运营商和消费者软件的实施者之间就公共主题的标识符达成的协议（例如，可在XMPP软件基金会的服务发现和发布订阅知名节点注册中心注册，地址为<https://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网格社区来解决。
[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.，“互联网标准过程——第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]Melnikov，A.，Ed.和K.Zeilenga，Ed.，“简单身份验证和安全层（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]Newman，C.，Menon Sen，A.，Melnikov，A.，和N.Williams，“盐渍挑战响应认证机制（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.，“可扩展消息和状态协议（XMPP）：核心”，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.，“可扩展消息和状态协议（XMPP）：即时消息和状态”，RFC 6121DOI 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，“在可扩展消息传递和存在协议（XMPP）中使用传输层安全性（TLS）”，RFC 7590，DOI 10.17487/RFC75902015年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，“数据表格”，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，“服务发现”，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，“结果集管理”，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，“发布-订阅”，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]圣安德烈，P.，“延迟交付”，XSF XEP 02032009年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.，“动态主机配置协议”，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]Laurie，B.，Langley，A.和E.Kasper，“证书透明度”，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.，“事件对象描述交换格式版本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，“事件对象描述交换格式使用指南”，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.“传输层安全（TLS）协议版本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]圣安德烈，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.
作者要感谢以下人士的贡献、创作和/或编辑：约瑟夫·萨洛维、丽莎·洛伦津、克利福德·卡恩、亨克·比克霍尔茨、杰西卡·菲茨杰拉德·麦凯、史蒂夫·汉纳和史蒂夫·维尼玛。此外，我们要感谢Takeshi Takahashi、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
南希·卡姆·维格特（编辑）美国加利福尼亚州圣何塞市思科路3550号思科系统公司95134
Email: ncamwing@cisco.com
Email: ncamwing@cisco.com
Syam Appala Cisco Systems 3550 Cisco Way San Jose, CA 95134 United States of America
美国加利福尼亚州圣何塞市思科路3550号Syam Appala思科系统公司95134
Email: syam1@cisco.com
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套房300美国奥斯威戈湖，或97035
Email: scottp@cisco.com
Email: scottp@cisco.com
Peter Saint-Andre Mozilla
彼得·圣安德烈·莫齐拉
Email: stpeter@mozilla.com
Email: stpeter@mozilla.com