Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange
Extracted elements (31)
End-to-end encryption between Provider and Consumer is acknowledged as desirable but is out of scope because there is no standardized method for encryption of one-to-many XMPP messages. Implementers needing E2E must use the basic instant-messaging pattern (RFC 6121) instead of XEP-0060.
The open, presence, and roster XEP-0060 access models are excluded from XMPP-Grid because open allows uncontrolled access and presence/roster are appropriate only for instant-messaging applications, not security incident exchange among authorized entities.
XMPP publish-subscribe (XEP-0060) was chosen for its one-to-many communications pattern to support high scalability to hundreds of thousands of Platforms; the Broker handles replication so Providers unicast a single update that fans out to all Consumers.
While XMPP-Grid uses XEP-0060 for publish-subscribe (one-to-many), implementations needing end-to-end encryption must fall back to the basic XMPP instant-messaging pattern (RFC 6121) with a suitable E2E extension, since XEP-0060 has no standardized E2E encryption support.
A Broker SHOULD support only the 'authorize' access model (Topic owner approves subscription requests) and the 'whitelist' access model (only preconfigured Platforms can subscribe). The open, presence, and roster models are inappropriate for XMPP-Grid.
Administrators of XMPP-Grid Controllers SHOULD NOT use password-based authentication, but SHOULD instead use non-reusable credentials and multi-factor authentication where available.
An XMPP-Grid Controller MUST support 'offline messaging' delivery semantics as specified in RFC 6121 (using the XMPP <message/> stanza) to ensure messages are delivered to Consumers that are not online at publication time.
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 dynamic discovery of available information and namespaces (Topics). XEP-0059 result set management SHOULD be used when discovery results are large.
The disco#info response from a Broker MUST include an XMPP data form (XEP-0004) with a 'pubsub#type' field that specifies the supported namespace (e.g., the IODEF namespace) so Platforms can identify which Topics match their data format.
The XMPP-Grid Controller SHOULD include a full authorization model so individual Platforms can be configured with only the privileges they need, and SHOULD make it easy to revoke a Platform's authorization when necessary.
The XMPP-Grid Controller SHOULD include auditable logs of Platform activities to aid in forensic analysis and detection of misbehavior.
The XMPP-Grid Platform MUST verify the XMPP-Grid Controller's certificate and determine whether the Controller is trusted before completing the TLS handshake. Mutual authentication between Platform and Controller SHOULD be used.
To ensure interoperability, implementations MUST implement at least either the SASL EXTERNAL mechanism (RFC 4422) or the SASL SCRAM mechanism.
When using SASL SCRAM, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over SCRAM-SHA-256, and SHA-256 variants (RFC 7677) SHOULD be preferred over SHA-1 variants (RFC 5802).
XMPP-Grid implementations MUST adhere to the mandatory-to-implement and mandatory-to-negotiate features as defined in RFC 6120 (XMPP Core).
XMPP-Grid messages MUST be carried over TLS, minimally TLS 1.2 and preferably TLS 1.3 (RFC 8446), as described in RFC 6120 and updated by RFC 7590.
XMPP-Grid Platforms and Controllers using certificate-based authentication SHOULD each verify the revocation status of the other party's certificate.
Audit logs maintained by XMPP-Grid Controllers must be handled carefully to avoid storing information that violates privacy agreements or laws. Restricting access to sensitive Topics, or omitting sensitive data entirely, is the simplest means of protection.
XMPP-Grid Platforms can publish endpoint health, network access events, roles, capabilities, and end-user identity; this information could be correlated to identify specific users' network activity. Deployers MUST ensure published data does not violate user agreements or local regulations.
A Topic is a contextual information channel on a Broker, limited to a specific type and format of security data (e.g., IODEF namespace). Providers publish to Topics; Consumers subscribe and receive real-time updates. Topics map to XMPP publish-subscribe Nodes (XEP-0060).
Service discovery uses XEP-0030 'disco#items' to enumerate available Topics, and 'disco#info' per Topic to retrieve the pubsub#type field (payload namespace). This allows Platforms to dynamically identify Topics that carry specific data formats such as IODEF.
The Broker is an XMPP publish-subscribe service acting as a control-plane broker: it handles authorization of Consumers and Providers to Topics, receives messages from Providers, and delivers published messages to Consumers.
Topic creation uses the XEP-0060 pubsub <create> stanza with optional <configure> parameters including pubsub#access_model (e.g., 'authorize'), pubsub#persist_items, and pubsub#send_last_published_item to control subscription and storage behavior.
A compromised XMPP-Grid Controller poses severe risks beyond what a Platform can do, including exposing different data to different Platforms (inconsistent views), obtaining and caching Platform credentials for future impersonation, and eavesdropping or modifying data in transit between Providers and Consumers.
An authorized but compromised XMPP-Grid Platform can mount attacks including flooding the Controller with false alarms, advertising crafted payloads to exploit other Platforms, issuing subscriptions that cause resource exhaustion, and advertising false data that induces incorrect behavior.
An XMPP-Grid Controller MAY establish limits on search or subscription result sizes, and Platforms SHOULD use XEP-0059 to bound result sets, to mitigate resource-exhaustion denial-of-service attacks from overly broad queries.
Certificate pinning is recommended for particularly critical certificates (such as the XMPP-Grid Controller's certificate) so that a compromised CA cannot silently substitute another certificate; pinned certificates should still be checked for revocation.
Some SASL mechanisms (such as PLAIN) allow a compromised Controller to cache Platform credentials for future impersonation after a breach is repaired; SCRAM and EXTERNAL with TLS mutual certificate-based authentication do not admit this class of attack and are therefore preferred.
The trust model delineates that the network provides only best-effort delivery without confidentiality or integrity; the Controller is trusted to broker and enforce authorization but is not trusted to verify the truth/correctness of data; and Platforms are trusted to preserve confidentiality of retrieved data.
XMPP-Grid workflow: (a) Platform requests connection to Controller; (b) Controller authenticates Platform; (c) Platform establishes authorized privileges (publish/subscribe) with Broker; (d) Platform publishes, subscribes, or queries Topics; (e) Provider unicasts updates through Broker, which replicates to Consumers.