RFC 8600

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
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).
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.
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.

1. Introduction
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.
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.
2. Terminology
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.
Broker: A specific type of controller containing control-plane
functions; as used here, the term refers to an XMPP publish-
subscribe service.
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.

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.
Node: The XMPP term for a Topic.
Platform: Any entity that connects to the XMPP-Grid in order to
publish or consume security-relevant information.
Provider: An entity that contains functions to provide information
to other components; as used here, the term refers to an XMPP
publish-subscribe Publisher.
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.
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.

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).
4. Workflow
Implementations of XMPP-Grid adhere to the following workflow:
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 workflow is summarized in the figure below.

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.
The following sections provide protocol examples for the service
discovery and publish-subscribe parts of the workflow.
5. Service Discovery
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:
<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 "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>
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).
6. Publish-Subscribe
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.
First, a Provider would create a Topic as follows:
<iq type='set'
from='datasource@provider.example/F12C2EFC9BB0'
to='broker.security-grid.example'
id='A67507DF-2F22-4937-8D30-88D2F7DBA279'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<create node='MILEHost'/>
</pubsub>
</iq>
Note: The foregoing example is the minimum protocol needed to create
a Topic with the default node configuration on the XMPP publish-
subscribe service specified in the 'to' address of the creation

request stanza. Depending on security requirements, the Provider
might need to request a non-default configuration for the node; see
[XEP-0060] for detailed examples. To also help with the Topic
configuration, the Provider may also optionally include configuration
parameters such as:
<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.
Unless an error occurs (see [XEP-0060] for various error flows), the
Broker responds with success:
<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>

(The payload in the foregoing example is from [RFC7970]; payloads for
additional use cases can be found in [RFC8274].)
The Broker would then deliver that incident report to all Consumers
who are subscribed to the Topic:
<message
from='broker.security-grid.example'
to='xmpp-grid-client@mile-host.example/2EBE702A97D6'
id='37B3921D-4F7F-450F-A589-56119A88BC2E'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='MILEHost'>
<item id='iah37s61s964gquqy47aksbx9453ks77'>
<IODEF-Document version="2.00" xml:lang="en"
xmlns="urn:ietf:params:xml:ns:iodef-2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"http://www.iana.org/assignments/xml-registry/
schema/iodef-2.0.xsd">
<Incident purpose="reporting" restriction="private">
<IncidentID name="csirt.example.com">492382</IncidentID>
<GenerationTime>2015-07-18T09:00:00-05:00</GenerationTime>
<Contact type="organization" role="creator">
<Email>
<EmailTo>contact@csirt.example.com</EmailTo>
</Email>
</Contact>
</Incident>
</IODEF-Document>
</item>
</items>
</event>
</message>
Note that [XEP-0060] uses the XMPP "<message />" stanza for delivery
of content. To ensure that messages are delivered to the Consumer
even if the Consumer is not online at the same time that the
Publisher generates the message, an XMPP-Grid Controller MUST support
"offline messaging" delivery semantics as specified in [RFC6121], the
best practices of which are further explained in [XEP-0160].
7. IANA Considerations
This document has no actions for IANA.