RFC 8600
Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange
RFC 8600: Using XMPP for Security Information Exchange 🎀
- Number and status: RFC 8600, on the Standards Track, published June 2019 📅 (ISSN 2070-1721)
- Authors: N. Cam-Winget (Ed.), S. Appala, and S. Pope from Cisco Systems, plus P. Saint-Andre from Mozilla 🧑💻
- Obsoletes / updates: The title block doesn't list anything this RFC obsoletes or updates 🙅♀️
Abstract
okay so this doc is all about using XMPP (the Extensible Messaging and Presence Protocol) to collect and pass around security incident reports and other security-relevant info between network-connected devices ✨. The main goal is helping Computer Security Incident Response Teams (CSIRTs) and their associated crew talk to each other. To show how the principles work, it uses the Incident Object Description Exchange Format (IODEF) as its example 💖.
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, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 📚.
For the current status, any errata, and how to send feedback, head to 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. 💜
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, since they spell out 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 they are provided without warranty as described in the 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 . . . . . . . . . . . . . . . . . . . . . . . 281. Introduction 🌈
okay bestie, so this doc defines an architecture called "XMPP-Grid" 🧚. It's a way of using XMPP [RFC6120] to collect and share security incident reports and other security-relevant info among network platforms, endpoints, and any other network-connected device. Again, the main point is letting CSIRTs and associated entities talk to each other 💅. Technically, this doc is an Applicability Statement ([RFC2026], Section 3.2), which just means it explains how to use XMPP to swap security notifications on a controlled-access network between authorized entities 🔐.
XMPP comes with a publish-subscribe service [XEP-0060] that acts as a broker 🫶. This lets entities do control-plane stuff, like finding out what information is available to publish or consume. The info can be any structured data (XML, JSON, and so on) 💜. This doc uses examples built on the Incident Object Description Exchange Format (IODEF) [RFC7970] to show the XMPP-Grid principles in action. Other security formats can totally ride along on XMPP too, but IODEF is just the one used as the example 🍓.
2. Terminology ✨
This doc uses the XMPP terms defined in [RFC6120] and [XEP-0060]. Since the people reading it are the ones building and running security reporting systems, the doc includes mappings for XMPP developers and operators 🎀.
- Broker: A specific type of controller with control-plane functions. In this doc, it's an XMPP publish-subscribe service 🧠.
- Broker Flow: A way of publishing and consuming security incident reports and other security-relevant info in a mediated fashion through a Broker 💖. The Broker handles authorization of Consumers and Providers to Topics, takes in messages from Providers, and delivers published messages to Consumers 📬.
- Consumer: An entity with functions for receiving info from other components. Here, it's an XMPP publish-subscribe Subscriber 👂.
- Controller: A component with control-plane functions that manage and facilitate info sharing or run security functions. Here, it's an XMPP server, which provides the core message delivery [RFC6120] that publish-subscribe entities use 🛰️.
- Node: The XMPP word for a Topic 🔁.
- Platform: Any entity that connects to the XMPP-Grid to publish or consume security-relevant info 🖥️.
- Provider: An entity with functions for providing info to other components. Here, it's an XMPP publish-subscribe Publisher 🎁.
- Topic: A contextual info channel created on a Broker. Messages a Provider generates get propagated in real time to one or more Consumers on it 📡. Each Topic is limited to one specific type and format of security data (IODEF namespace, for example), and it offers an XMPP interface so the data can be fetched 🦋.
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 💅.
3. Architecture 🏛️
Here's the XMPP-Grid architecture, drawn out for you 👀:
+--------------------------------------+
| +--------------------------------------+
| | +--------------------------------------+
| | | |
+-| | 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 ✨
Platforms connect to the Controller (the XMPP server) to authenticate, and then they get the right authorizations to be a Provider or Consumer of the topics they care about at the Broker 🔑. The control-plane messaging runs over XMPP and is labelled "A" (control-plane interface) in Figure 1 🎀. Once authorized, Platforms can share data through the Broker (labelled "B" in Figure 1) or, in some cases, directly (labelled "C" in Figure 1) 🦋. This doc focuses mainly on the Broker Flow for info sharing. Direct flow interactions can be used for specialized purposes, like bulk data transfer, but the methods for doing that are outside this doc's scope 🧚♀️.
4. Workflow ✨
okay so here's how the whole thing flows, bestie 🎀 every implementation follows these steps:
- a. A Platform with a source of security data requests connection to the XMPP-Grid via a Controller. 🔌
- b. The Controller authenticates the Platform. 🔐
- c. The Platform establishes authorized privileges (e.g., privilege to publish and/or subscribe to one or more Topics) with a Broker. 🗝️
- 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. 📣
- 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. 🚀
- 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. 🌊
the general vibe is summarized in this little picture, iykyk 🦋
+--------------+ +------------+ +---------------+
| 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 Workflowthis part is non-negotiable, no cap 💅 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.
okay the next bit is giving discovery vibes ✨ 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. 🫶
The following sections provide protocol examples for the service discovery and publish-subscribe parts of the workflow. 🧚
5. Service Discovery 🌸
so using the XMPP service discovery extension [XEP-0030], a Controller lets Platforms 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:
<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>now the plot twist 😭 to figure out the exact nature of each Topic (aka find the ones that publish incidents in the IODEF format), a Platform sends an XMPP disco#info request to each Topic:
<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 answers 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='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>and that's how the Platform finds the Topics! 🌈 it gets the Broker's response, then grabs the namespaces returned in the "pubsub#type" field (in the example above, IODEF 2.0) 💖
6. Publish-Subscribe ✨
okay so this is the part where the magic happens 🪄 Using the XMPP publish-subscribe extension [XEP-0060], a Consumer subscribes to a Topic, and a Provider publishes info to that Topic, and then the Broker passes it along to every subscribed Consumer. literally so good 😭
First up, a Provider creates a Topic like this:
<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>💅 heads up: that example is the bare minimum for making a Topic with the default node configuration on the XMPP publish-subscribe service named in the 'to' address of the creation request stanza. Depending on security requirements, the Provider might need a non-default configuration for the node, so check out [XEP-0060] for detailed examples 🎀
To help with the Topic configuration, the Provider may also (optionally) include configuration parameters, like this:
<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>So what does that config actually do? 🤔 The Topic is set up so the Broker will a) explicitly approve subscription requests, b) persistently store every message posted to the Topic, and c) not deliver the most recently published item when an entity first subscribes. Iconic behaviour, no cap 🧚 For a deeper dive into this config and the other options, go check out [XEP-0060] 🌸
Unless an error happens (see [XEP-0060] for the different error flows), the Broker replies with a success:
<iq type='result'
from='broker.security-grid.example'
to='datasource@provider.example/F12C2EFC9BB0'
id='A67507DF-2F22-4937-8D30-88D2F7DBA279'/>Second, a Consumer subscribes like so:
<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 happens (see [XEP-0060] for the error flows), the Broker makes an authorization decision. If access is granted, it sends back a success:
<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 publishes an incident to the Broker using the MILEHost Topic, like this:
<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 that example comes from [RFC7970]. Want more payloads for other use cases? Peek at [RFC8274] 👀)
Then the Broker delivers that incident report to every Consumer 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>Quick note: [XEP-0060] uses the XMPP "<message />" stanza to deliver content 💌 Now, to make sure messages still reach the Consumer even when it isn't online at the same moment the Publisher generates the message, an XMPP-Grid Controller MUST support "offline messaging" delivery semantics as specified in [RFC6121]. The best practices for that are explained further in [XEP-0160] 🫶
7. IANA Considerations 🌷
This document has no actions for IANA. Zero. Nada. Chill 😌
8. Security Considerations 🔐
Okay, this section is serious, bestie 😭🚨 An XMPP-Grid Controller acts as the controlling broker for XMPP-Grid Platforms like enforcement points, policy servers, Configuration Management Databases (CMDBs), and sensors. It uses a publish-subscribe-search model for sharing info and looking things up. By helping XMPP-Grid Platforms learn about and respond to security incident reports and other security-relevant info, XMPP-Grid can improve the timeliness and usefulness of the security system ✨ BUT this integrated system can also be exploited by attackers if they manage to compromise it. So strong security protections for XMPP-Grid are absolutely essential. Non-negotiable 💀
Since XMPP is the core of this document, the security considerations of [RFC6120] apply. On top of that, because XMPP-Grid defines a specific instance, this section provides a security analysis of the XMPP-Grid data transfer protocol and the architectural elements that use it, specifically with respect to how they use this protocol. Three subsections cover 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 identified earlier) 🧠
8.1. Trust Model 🤝
First step: 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 do what they were trusted to do 👀
8.1.1. Network 🛜
The network carrying XMPP-Grid messages (aka the underlying network transport layer that XMPP runs over) is trusted to:
- Perform best-effort delivery of network traffic
The network carrying XMPP-Grid messages is not expected (trusted) to:
- Provide confidentiality or integrity protection for messages sent over it
- Provide timely or reliable service
8.1.2. XMPP-Grid Platforms 🧩
Authorized XMPP-Grid Platforms are trusted to:
- Preserve the confidentiality of sensitive data retrieved via the XMPP-Grid Controller
8.1.3. XMPP-Grid Controller 👑
The XMPP-Grid Controller (including its associated Broker) is trusted to:
- Broker requests for data and enforce authorization of access to this data throughout its lifecycle
- Perform service requests in a timely and accurate manner
- Create and maintain accurate operational attributes
- Only reveal data to and accept service requests from authorized parties
- Preserve the integrity (and confidentiality against unauthorized parties) of the data flowing through it.
The XMPP-Grid Controller is not expected (trusted) to:
- Verify the truth (correctness) of data
8.1.4. Certification Authority 📜
For XMPP-Grid Platforms to mutually authenticate with XMPP-Grid Controllers, it's expected that a Certification Authority (CA) is employed to issue certificates. That CA (or each CA, if there are several) is trusted to:
- Ensure that only proper certificates are issued and that all certificates are issued in accordance with the CA's policies
- Revoke certificates previously issued when necessary
- Regularly and securely distribute certificate revocation information
- Promptly detect and report any violations of this trust so that they can be handled
The CA is not expected (trusted) to:
- Issue certificates that go beyond the XMPP-Grid needs or other constraints imposed by a relying party.
8.2. Threat Model 😈
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 those elements. Villain arc incoming 🦹
8.2.1. Network Attacks 🌐
A bunch of attacks can be mounted using the network. For this subsection, the phrase "network traffic" can be read as messages and/or parts of messages. Any of these attacks can be launched by network elements, by parties who control network elements, and (in many cases) by parties who control network-attached devices 🙈
- Network traffic can be passively monitored to glean information from any unencrypted traffic
- Even if all traffic is encrypted, valuable information can be gained by traffic analysis (volume, timing, source and destination addresses, etc.)
- Network traffic can be modified in transit
- Previously transmitted network traffic can be replayed
- New network traffic can be added
- Network traffic can be blocked, perhaps selectively
- 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
- Undesired network traffic can be sent in an effort to overload an architectural component, thus mounting a denial-of-service attack
8.2.2. XMPP-Grid Platforms
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).
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.
Here is a list of attacks that can be mounted by an authorized XMPP- Grid Platform:
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 Omit important actions (such as posting incriminating data), resulting in incorrect access.
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 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 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 Establish a communication channel using another XMPP-Grid Platform's session-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.
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.
8.2.3. XMPP-Grid Controllers
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).
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.
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.
Additional XMPP-Grid Controller attacks can include:
o Exposing different data to different XMPP-Grid Platforms to mislead investigators or cause inconsistent behavior.
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 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 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 Eavesdropping, injecting, or modifying the data being transferred between Provider and Consumer.
Dependencies or vulnerabilities of the XMPP-Grid Controller can be exploited to obtain control of the XMPP-Grid Controller and effect these attacks.
8.2.4. Certification Authority
A Certification Authority trusted to issue certificates for the XMPP- Grid Controller and/or XMPP-Grid Platforms can mount several attacks:
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 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 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 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 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 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.
8.3. Countermeasures
Below are countermeasures for specific attack scenarios to the XMPP- Grid infrastructure.
8.3.1. Securing the XMPP-Grid Data Transfer Protocol
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.
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.3.2. Securing XMPP-Grid Platforms
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.
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.
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.
8.3.3. Securing XMPP-Grid Controllers 🔐
okay so XMPP-Grid Controllers are the most important piece, bestie, so they need to be SUPER hardened 💪. Since losing a Controller has seriously bad consequences, they need to be as small as possible so there's less attack surface to poke at ✨. They also need careful management so the underlying platform and the systems the Controller depends on don't have holes 🕳️. Network security stuff like firewalls or intrusion detection systems can watch and limit the traffic going to and from the Controller 🚧. The people with admin access ought to be carefully screened and monitored so problems get caught ASAP 👀. Admins SHOULD NOT use password-based authentication. They SHOULD use non-reusable credentials and multi-factor authentication (where it's available) instead 🔑. Physical security should also be used to stop physical attacks on XMPP-Grid Controllers 🏰.
To make it easier to notice if a Controller gets compromised, you should watch how it behaves for anything unusual 🦋. Examples are a reboot, a big spike in traffic, or different views of an information repository for similar XMPP-Grid Platforms 👁️. Whether XMPP-Grid Platforms log and/or notify administrators when weird Controller behavior shows up is up to local policy 📋. The same goes for whether read-only audit logs of security-relevant information (especially administrative actions) get kept. Still, this behavior is encouraged because it helps with forensic analysis 🕵️♀️.
Also, if a Controller compromise is detected, a careful analysis should be done, and any reusable credentials that could have been compromised should be reissued 🔄.
Now, the Controller could eavesdrop on, modify, or inject data, which is a little scary 😭. Ideally you'd have end-to-end encryption between the Provider and the Consumer(s) 🔐. Unfortunately, XMPP doesn't have a standardized way to encrypt one-to-many messages yet, so techniques for enforcing end-to-end encryption are out of scope for this spec 🙃.
8.3.4. Broker Access Models for Topics 🚪
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 open model allows uncontrolled access, and the presence and roster models are only appropriate in instant-messaging applications 💬. So a Broker SHOULD support only the authorize model (where the Topic owner has to approve every subscription request, and only subscribers can retrieve data items) and the whitelist model (where only preconfigured Platforms can subscribe or retrieve data items) 💅. To make things less of a hassle, subscription approvals and whitelist management can be automated. For example, the Topic "owner" can be a policy server 🤖. Whether "authorize" or "whitelist" is the default access model is up to local service policy 🎀.
8.3.5. Limit on Search Result Size 📏
XMPP-Grid is built to scale up to hundreds of thousands of Platforms, which is iconic 🌍. Still, an XMPP-Grid Controller MAY set a limit on how much data it's willing to return in search or subscription results 🧢. Platforms could use [XEP-0059] to restrict the size of the result sets the Controller sends back for searches, subscriptions, or topics' service discovery 🍓. This helps stop an XMPP-Grid Platform from causing resource exhaustion by running a search or subscription that returns a massive result 💀.
8.3.6. Securing the Certification Authority 🏛️
Like we said earlier, if a Certification Authority (CA) trusted to issue certificates for the XMPP-Grid Controller and/or XMPP-Grid Platforms gets compromised, that's a major security breach 🚨. People have developed lots of guidelines for proper CA security, like 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], and more 📚. The CA operator and the relying parties should agree on appropriately rigorous security practices to use 🤝.
Even with the strictest security practices, a CA can still get compromised 😩. If it gets caught fast, relying parties can remove the CA from their list of trusted CAs, and other CAs can revoke any certificates they issued to that CA 🧹. But CA compromise can go unnoticed for a while, and there's always a chance a CA is being run improperly or in a way that doesn't serve the relying parties' interests 👀. That's why relying parties may want to "pin" a small number of especially critical certificates, like the certificate for the XMPP-Grid Controller 📌. Once a certificate is pinned, the relying party won't accept another certificate in its place unless the Administrator explicitly commands it to 🙅♀️. Pinning doesn't mean the relying party stops checking the revocation status of pinned certificates ✅. The Administrator can still be consulted if a pinned certificate gets revoked, since the CA and revocation process aren't completely trusted 🫶. By pinning one certificate or a small set of them, the relying party has identified the effective XMPP-Grid Controller(s) authorized for connection 👑.
8.3.7. End-to-End Encryption of Messages 💌
A lot of Consumers are expected for every Topic, so for content discovery and scaling, this document specifies a "one-to-many" communications pattern using the XMPP Publish-Subscribe extension 📣. The problem is there's no standardized tech for end-to-end encryption of one-to-many messages in XMPP 😤. That means messages can be eavesdropped on, injected with data, or modified within a Broker or Controller 🫣. If you need to mitigate those attacks, implementers would need to pick a messaging pattern other than [XEP-0060], most likely the basic "instant messaging" pattern from [RFC6121] with a suitable XMPP extension for end-to-end encryption 🧩. How to do that is out of scope for this document 🙈.
8.4. Summary 🌟
XMPP-Grid is super valuable as a broker for security-sensitive data exchange, which also makes the protocol and the network security elements that implement it a target for attackers 🎯. So strong security was included as a basic design principle right from the start of the XMPP-Grid design process 💖.
The XMPP-Grid data transfer protocol gives strong protection against a bunch of different attacks 🛡️. If an XMPP-Grid Platform or XMPP-Grid Controller gets compromised, the damage is reduced and limited by the recommended role-based authorization model and other provisions, and the best practices for managing and protecting XMPP-Grid systems have been described 📝. Put together, these measures should give protection that matches the threat to XMPP-Grid systems, so they can do their job as a network security clearinghouse 🏆✨.
9. Privacy Considerations 🙈
XMPP-Grid Platforms can publish info about endpoint health, network access, events (which can include which services an endpoint is accessing), roles and capabilities, and the identity of the end user operating the endpoint 📡. Any of that published info can be queried by other XMPP-Grid Platforms, and it could be used to link network activity back to a particular end user 😬.
Dynamic and static information brokered by an XMPP-Grid Controller is meant for correlation by XMPP-Grid Platforms for intrusion detection 🕵️. But a broader set of XMPP-Grid Platforms that used to have specific roles with a strict, well-defined separation of duties could misuse it 🚫.
Deployers of XMPP-Grid need to make sure the info published by XMPP-Grid Platforms doesn't break agreements with end users or local and regional laws and regulations ⚖️. They can do this by configuring Platforms not to publish certain info, or by limiting access to sensitive data to trusted XMPP-Grid Platforms 🔒. Honestly, the easiest way to protect privacy or sensitive data is to just leave it out or not share it at all 🫠.
Similarly, deployers and XMPP-Grid Controller implementations have to be careful when they set up auditing tools 🧐. Any information, like logs, must be sensitive to the type of information stored, so it doesn't violate privacy or agreements with end users or local and regional laws and regulations 📜.
Another thing for deployers to consider is enabling end-to-end encryption, so data stays protected while in transit between data layers and is shielded from the transport layer 🔐. How to achieve end-to-end encryption is beyond the scope of this document 🌈.
10. Operations and Management Considerations 🛠️
To make it easier to manage Providers and onboard Consumers, it helps to set up the following ahead of time 🗓️:
- Agreement between the operators of Provider services and the implementers of Consumer software about identifiers for common Topics (for example, these could be registered in the XMPP Software Foundation's registry of well-known nodes for service discovery and publish-subscribe, located at
https://xmpp.org/registrar/nodes.html) 📒. - Security certificates (including appropriate certificate chains) for Controllers, including identification of any Providers associated with the Controllers (which might be located at subdomains) 🎀.
- Consistent and secure access control policies for publishing and subscribing to Topics 🔑.
These matters are out of scope for this document, but the XMPP-Grid community ought to address them 🫶.
11. References 📚
The reference entries weren't included in the text I was given, so this part only has the heading for now. They'll need to be added with the next part so every citation ([XEP-0060], [XEP-0059], [RFC6121], [RFC6962], and the rest) gets its full entry 💜.
11. References ✨
11.1. Normative References 💖
Okay bestie, these are the references the spec basically cannot function without, so read them like they're your homework list 📚 💅
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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-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-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-0060] Millard, P., Saint-Andre, P., and R. Meijer, "Publish- Subscribe", XSF XEP 0060, January 2019, <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>.
11.2. Informative References 🦋
These ones are more like the "good to know" section. Not required, but very much iconic for context 🧚
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <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>.
[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>.
[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>.
[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>.
[XEP-0160] Saint-Andre, P., "Best Practices for Handling Offline Messages", XSF XEP 0160, October 2016, <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. Such a squad 🫶
Authors' Addresses 💜
Nancy Cam-Winget (editor) Cisco Systems 3550 Cisco Way San Jose, CA 95134 United States of America
Email: ncamwing@cisco.com
Syam Appala Cisco Systems 3550 Cisco Way San Jose, CA 95134 United States of America
Email: syam1@cisco.com
Scott Pope Cisco Systems 5400 Meadows Road Suite 300 Lake Oswego, OR 97035 United States of America
Email: scottp@cisco.com
Peter Saint-Andre Mozilla
Email: stpeter@mozilla.com
📦 where this page comes from
- ietf: rfc8600 2019-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms