idnits 2.17.1
draft-ietf-mile-xmpp-grid-11.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There is 1 instance of too long lines in the document, the longest one
being 7 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (March 27, 2019) is 1856 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0004'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0030'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0059'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0060'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0203'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0384'
-- Obsolete informational reference (is this intentional?): RFC 6962
(Obsoleted by RFC 9162)
Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 MILE N. Cam-Winget, Ed.
3 Internet-Draft S. Appala
4 Intended status: Standards Track S. Pope
5 Expires: September 28, 2019 Cisco Systems
6 P. Saint-Andre
7 Mozilla
8 March 27, 2019
10 Using XMPP for Security Information Exchange
11 draft-ietf-mile-xmpp-grid-11
13 Abstract
15 This document describes how to use the Extensible Messaging and
16 Presence Protocol (XMPP) to collect and distribute security incident
17 reports and other security-relevant information between network-
18 connected devices, primarily for the purpose of communication among
19 Computer Security Incident Response Teams and associated entities.
20 To illustrate the principles involved, this document describes such a
21 usage for the Incident Object Description Exchange Format (IODEF).
23 Status of This Memo
25 This Internet-Draft is submitted in full conformance with the
26 provisions of BCP 78 and BCP 79.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF). Note that other groups may also distribute
30 working documents as Internet-Drafts. The list of current Internet-
31 Drafts is at https://datatracker.ietf.org/drafts/current/.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as "work in progress."
38 This Internet-Draft will expire on September 28, 2019.
40 Copyright Notice
42 Copyright (c) 2019 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (https://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
55 Table of Contents
57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
59 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
60 4. Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . 5
61 5. Service Discovery . . . . . . . . . . . . . . . . . . . . . . 7
62 6. Publish-Subscribe . . . . . . . . . . . . . . . . . . . . . . 9
63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
65 8.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 13
66 8.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 15
67 8.3. Countermeasures . . . . . . . . . . . . . . . . . . . . . 19
68 8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 22
69 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23
70 10. Operations and Management Considerations . . . . . . . . . . 23
71 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
72 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
73 12.1. Normative References . . . . . . . . . . . . . . . . . . 24
74 12.2. Informative References . . . . . . . . . . . . . . . . . 26
75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
77 1. Introduction
79 This document defines an architecture, i.e., "XMPP-Grid", as a method
80 for using the Extensible Messaging and Presence Protocol (XMPP)
81 [RFC6120] to collect and distribute security incident reports and
82 other security-relevant information among network platforms,
83 endpoints, and any other network-connected device, primarily for the
84 purpose of communication among Computer Security Incident Response
85 Teams and associated entities. In effect, this document specifies an
86 Applicability Statement ([RFC2026], Section 3.2) that defines how to
87 use XMPP for the exchange of security notifications on a controlled-
88 access network among authorized entities.
90 Among other things, XMPP provides a publish-subscribe service
91 [XEP-0060] that acts as a broker, enabling control-plane functions by
92 which entities can discover available information to be published or
93 consumed. Although such information can take the form of any
94 structured data (XML, JSON, etc.), this document illustrates the
95 principles of XMPP-Grid with examples that use the Incident Object
96 Description Exchange Format (IODEF) [RFC7970]. That is, while other
97 security information formats can be shared using XMPP, this document
98 uses IODEF as one such example format that can be published and
99 consumed using XMPP.
101 2. Terminology
103 This document uses XMPP terminology defined in [RFC6120] and
104 [XEP-0060]. Because the intended audience for this document is those
105 who implement and deploy security reporting systems, mappings are
106 provided for the benefit of XMPP developers and operators.
108 Broker: A specific type of controller containing control plane
109 functions; as used here, the term refers to an XMPP publish-
110 subscribe service.
112 Broker Flow: A method by which security incident reports and other
113 security-relevant information is published and consumed in a
114 mediated fashion through a Broker. In this flow, the Broker
115 handles authorization of Consumers and Providers to Topics,
116 receives messages from Providers, and delivers published messages
117 to Consumers.
119 Consumer: An entity that contains functions to receive information
120 from other components; as used here, the term refers to an XMPP
121 publish-subscribe Subscriber.
123 Controller: A "component containing control plane functions that
124 manage and facilitate information sharing or execute on security
125 functions"; as used here, the term refers to an XMPP server, which
126 provides core message delivery [RFC6120] used by publish-subscribe
127 entities.
129 Node: The XMPP term for a Topic.
131 Platform: Any entity that connects to the XMPP-Grid in order to
132 publish or consume security-relevant information.
134 Provider: An entity that contains functions to provide information
135 to other components; as used here, the term refers to an XMPP
136 publish-subscribe Publisher.
138 Topic: A contextual information channel created on a Broker at which
139 messages generated by a Provider are propagated in real time to
140 one or more Consumers. Each Topic is limited to a specific type
141 and format of security data (e.g. IODEF namespace) and provides
142 an XMPP interface by which the data can be obtained.
144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
146 "OPTIONAL" in this document are to be interpreted as described in BCP
147 14 [RFC2119] [RFC8174] when, and only when, they appear in all
148 capitals, as shown here.
150 3. Architecture
152 The following figure illustrates the architecture of XMPP-Grid.
154 +--------------------------------------+
155 | +--------------------------------------+
156 | | +--------------------------------------+
157 | | | |
158 +-| | Platforms |
159 +-| |
160 +--------------------------------------+
161 / \ / \ / \
162 / C \ / \ / \
163 - o - - d - - -
164 ||n||A | a |B | |C
165 ||t|| | t | | |
166 - r - - a - | |
167 \ o / \ / | |
168 \ l / \ / | |
169 /|---------------------|\ | |
170 /|----/ \--------| d |--|\
171 / / Controller \ ctrl | a | \
172 \ \ & Broker / plane | t | /
173 \|----\ /--------| a |--|/
174 \|---------------------|/ | |
175 / \ / \ | |
176 / C \ / \ | |
177 - o - - d - | |
178 ||n||A | a |B | |C
179 ||t|| | t | | |
180 - r - - a - - -
181 \ o / \ / \ /
182 \ l / \ / \ /
183 +------------------------------------+
184 | |-+
185 | Platforms | |
186 | | |-+
187 +------------------------------------+ | |
188 +------------------------------------+ |
189 +------------------------------------+
191 Figure 1: XMPP-Grid Architecture
193 Platforms connect to the Controller (XMPP server) to authenticate and
194 then establish appropriate authorizations to be a Provider or
195 Consumer of topics of interest at the Broker. The control plane
196 messaging is established through XMPP and shown as "A" (control plane
197 interface) in Figure 1. Authorized Platforms can then share data
198 either through the Broker (shown as "B" in Figure 1) or in some cases
199 directly (shown as "C" in Figure 1). This document focuses primarily
200 on the Broker Flow for information sharing ("direct flow"
201 interactions can be used for specialized purposes such as bulk data
202 transfer, but methods for doing so are outside the scope of this
203 document).
205 4. Workflow
207 Implementations of XMPP-Grid workflow adhere to the following
208 workflow:
210 a. A Platform with a source of security data requests connection to
211 the XMPP-Grid via a Controller.
213 b. The Controller authenticates the Platform.
215 c. The Platform establishes authorized privileges (e.g. privilege to
216 publish and/or subscribe to one or more Topics) with a Broker.
218 d. The Platform can publish security incident reports and other
219 security-relevant information to a Topic, subscribe to a Topic,
220 query a Topic, or any combination of these operations.
222 e. A Provider unicasts its Topic updates to the Grid in real time
223 through a Broker. The Broker handles replication and
224 distribution of the Topic to Consumers. A Provider can publish
225 the same or different data to multiple Topics.
227 f. Any Platform on the Grid can subscribe to any Topics published to
228 the Grid (as permitted by authorization policy), and (as
229 Consumers) will then receive a continual, real-time stream of
230 updates from the Topics to which it is subscribed.
232 The general workflow is summarized in the figure below:
234 +--------------+ +------------+ +---------------+
235 | IODEF Client | | Controller | | IODEF Service |
236 | (Consumer) | | & Broker | | (Provider) |
237 +--------------+ +------------+ +---------------+
238 | | |
239 | Establish XMPP | |
240 | Client Session | |
241 | (RFC 6120) | |
242 |--------------------->| |
243 | | Establish XMPP |
244 | | Client Session |
245 | | (RFC 6120) |
246 | |<------------------------|
247 | | Request Topic Creation |
248 | | (XEP-0060) |
249 | |<------------------------|
250 | | Topic Creation Success |
251 | | (XEP-0060) |
252 | |------------------------>|
253 | Request Topic List | |
254 | (XEP-0030) | |
255 |--------------------->| |
256 | Return Topic List | |
257 | (XEP-0030) | |
258 |<---------------------| |
259 | | |
260 | Query Each Topic | |
261 | (XEP-0030) | |
262 |--------------------->| |
263 | Return Topic Data | |
264 | Including Topic Type | |
265 | (XEP-0030) | |
266 |<---------------------| |
267 | | |
268 | Subscribe to IODEF | |
269 | Topic (XEP-0060) | |
270 |--------------------->| |
271 | Subscription Success | |
272 | (XEP-0060) | |
273 |<---------------------| |
274 | | Publish IODEF Incident |
275 | | (XEP-0060) |
276 | Receive IODEF |<------------------------|
277 | Incident (XEP-0060) | |
278 |<---------------------| |
279 | | |
281 Figure 2: IODEF Example Workflow
283 XMPP-Grid implementations MUST adhere to the mandatory-to-implement
284 and mandatory-to-negotiate features as defined in [RFC6120].
285 Similarly, implementations MUST implement [XEP-0060] to facilitate
286 the asynchronous sharing for information. Implementations SHOULD
287 implement Service Discovery as defined in [XEP-0030] to facilitate
288 the means to dynamically discover the available information and
289 namespaces (Topics) to be published or consumed. Implementations
290 should take caution if their deployments allow for a large number of
291 topics. The Result Set Management as defined in [XEP-0059], SHOULD
292 be used to allow the requesting entity to explicitly request Service
293 Discovery result sets to be returned in pages or limited size, if the
294 discovery results are larger in size. Note that the control plane
295 may optionally also implement [XEP-0203] to facilitate delayed
296 delivery of messages to the connected consumer as described in
297 [XEP-0060]. Since information may be timely and sensitive,
298 capability providers should communicate to the controller whether its
299 messages can be cached for delayed delivery during configuration;
300 such function is out of scope for this document.
302 The following sections provide protocol examples for the service
303 discovery and publish-subscribe parts of the workflow.
305 5. Service Discovery
307 Using the XMPP service discovery extension [XEP-0030], a Controller
308 enables Platforms to discover what information can be consumed
309 through the Broker, and at which Topics. Platforms could use
310 [XEP-0059] to restrict the size of the result sets the Controller
311 returns in Service Discovery response. As an example, the Controller
312 at 'security-grid.example' might provide a Broker at
313 'broker.security-grid.example' hosting a number of Topics. A
314 Platform at 'xmpp-grid-client@mile-host.example' would query the
315 Broker about its available Topics by sending an XMPP "disco#items"
316 request to the Broker:
318
322
323
325 The Broker responds with the Topics it hosts:
327
331
332
335
338
339
341 In order to determine the exact nature of each Topic (i.e., in order
342 to find topics that publish incidents in the IODEF format), a
343 Platform would send an XMPP "disco#info" request to each Topic:
345
351
353 The Broker responds with the "disco#info" description, which MUST
354 include an XMPP Data Form [XEP-0004] including a 'pubsub#type' field
355 that specifies the supported namespace (in this example, the IODEF
356 namespace defined in [RFC7970]):
358
362
364
365
366
367
368 http://jabber.org/protocol/pubsub#meta-data
369
370
371 urn:ietf:params:xml:ns:iodef-2.0
372
373
374
375
377 The Platform discovers the topics by obtaining the Broker's response
378 and obtaining the namespaces returned in the "pubsub#type" field (in
379 the foregoing example, IODEF 2.0).
381 6. Publish-Subscribe
383 Using the XMPP publish-subscribe extension [XEP-0060], a Consumer
384 subscribes to a Topic and a Provider publishes information to that
385 Topic, which the Broker then distributes to all subscribed Consumers.
387 First, a Provider would create a Topic as follows:
389
393
394
395
396
398 Note: The foregoing example is the minimal protocol needed to create
399 a Topic with the default node configuration on the XMPP publish-
400 subscribe service specified in the 'to' address of the creation
401 request stanza. Depending on security requirements, the Provider
402 might need to request a non-default configuration for the node; see
403 [XEP-0060] for detailed examples. To also help with the Topic
404 configuration, the Provider may also optionally include
405 configurations parameters such as:
407
408
409
410 http://jabber.org/protocol/pubsub#node_config
411
412 authorize
413 1
414 never
415
416
418 The above configuration indicates the Topic is configured to enable
419 the XMPP-Controller to manage the subscriptions, be in persistent
420 mode and disables the Broker from cacheing the last item published.
421 Please refer to [XEP-0060] a more detailed description of these
422 configuration and other available configuration options.
424 Unless an error occurs (see [XEP-0060] for various error flows), the
425 Broker responds with success:
427
432 Second, a Consumer would subscribe as follows:
434
438
439
441
442
444 Unless an error occurs (see [XEP-0060] for various error flows), the
445 Broker responds with success:
447
451
452
456
457
459 Third, a Provider would publish an incident to the broker using the
460 MILEHost topic as follows:
462
466
467
468 -
469
475
476 492382
477 2015-07-18T09:00:00-05:00
478
479
480 contact@csirt.example.com
481
482
483
484
485
486
487
488
490 (The payload in the foregoing example is from [RFC7970]; payloads for
491 additional use cases can be found in [RFC8274].)
493 The Broker would then deliver that incident report to all Consumers
494 who are subscribed to the Topic:
496
500
501
502 -
503
509
510 492382
511 2015-07-18T09:00:00-05:00
512
513
514 contact@csirt.example.com
515
516
517
518
519
520
521
522
524 Note that [XEP-0060] uses the XMPP "" stanza for delivery
525 of content. To ensure that messages are delivered to the Consumer
526 even if the Consumer is not online at the same time that the
527 Publisher generates the message, an XMPP-Grid Controller MUST support
528 "offline messaging" delivery semantics as specified in [RFC6121],
529 best practices for which are further explained in [XEP-0160].
531 7. IANA Considerations
533 This document has no actions for IANA.
535 8. Security Considerations
537 An XMPP-Grid Controller serves as an controlling broker for XMPP-Grid
538 Platforms such as Enforcement Points, Policy Servers, CMDBs, and
539 Sensors, using a publish-subscribe-search model of information
540 exchange and lookup. By increasing the ability of XMPP-Grid
541 Platforms to learn about and respond to security incident reports and
542 other security-relevant information, XMPP-Grid can improve the
543 timeliness and utility of the security system. However, this
544 integrated security system can also be exploited by attackers if they
545 can compromise it. Therefore, strong security protections for XMPP-
546 Grid are essential.
548 As XMPP is the core of this document, the security considerations of
549 [RFC6120] applies. In addition, as XMPP-Grid defines a specific
550 instance, this section provides a security analysis of the XMPP-Grid
551 data transfer protocol and the architectural elements that employ it,
552 specifically with respect to their use of this protocol. Three
553 subsections define the trust model (which elements are trusted to do
554 what), the threat model (attacks that can be mounted on the system),
555 and the countermeasures (ways to address or mitigate the threats
556 previously identified).
558 8.1. Trust Model
560 The first step in analyzing the security of the XMPP-Grid transport
561 protocol is to describe the trust model, listing what each
562 architectural element is trusted to do. The items listed here are
563 assumptions, but provisions are made in the Threat Model and
564 Countermeasures sections for elements that fail to perform as they
565 were trusted to do.
567 8.1.1. Network
569 The network used to carry XMPP-Grid messages (i.e., the underlying
570 network transport layer over which XMPP runs) is trusted to:
572 o Perform best effort delivery of network traffic
574 The network used to carry XMPP-Grid messages is not expected
575 (trusted) to:
577 o Provide confidentiality or integrity protection for messages sent
578 over it
580 o Provide timely or reliable service
582 8.1.2. XMPP-Grid Platforms
584 Authorized XMPP-Grid Platforms are trusted to:
586 o Preserve the confidentiality of sensitive data retrieved via the
587 XMPP-Grid Controller
589 8.1.3. XMPP-Grid Controller
591 The XMPP-Grid Controller (including its associated Broker) is trusted
592 to:
594 o Broker requests for data and enforce authorization of access to
595 this data throughout its lifecycle
597 o Perform service requests in a timely and accurate manner
599 o Create and maintain accurate operational attributes
601 o Only reveal data to and accept service requests from authorized
602 parties
604 o Preserve the integrity (and confidentiality against unauthorized
605 parties) of the data flowing through it.
607 The XMPP-Grid Controller is not expected (trusted) to:
609 o Verify the truth (correctness) of data
611 8.1.4. Certification Authority
613 To allow XMPP-Grid Platforms to mutually authenticate with XMPP-Grid
614 Controllers, it is expected that a Certification Authority (CA) is
615 employed to issue certificates. Such a CA (or each CA, if there are
616 several) is trusted to:
618 o Ensure that only proper certificates are issued and that all
619 certificates are issued in accordance with the CA's policies
621 o Revoke certificates previously issued when necessary
623 o Regularly and securely distribute certificate revocation
624 information
626 o Promptly detect and report any violations of this trust so that
627 they can be handled
629 The CA is not expected (trusted) to:
631 o Issue certificates that go beyond the XMPP-Grid needs or other
632 constraints imposed by a relying party.
634 8.2. Threat Model
636 To secure the XMPP-Grid data transfer protocol and the architectural
637 elements that implement it, this section identifies the attacks that
638 can be mounted against the protocol and elements.
640 8.2.1. Network Attacks
642 A variety of attacks can be mounted using the network. For the
643 purposes of this subsection the phrase "network traffic" can be taken
644 to mean messages and/or parts of messages. Any of these attacks can
645 be mounted by network elements, by parties who control network
646 elements, and (in many cases) by parties who control network-attached
647 devices.
649 o Network traffic can be passively monitored to glean information
650 from any unencrypted traffic
652 o Even if all traffic is encrypted, valuable information can be
653 gained by traffic analysis (volume, timing, source and destination
654 addresses, etc.)
656 o Network traffic can be modified in transit
658 o Previously transmitted network traffic can be replayed
660 o New network traffic can be added
662 o Network traffic can be blocked, perhaps selectively
664 o A "Man In The Middle" (MITM) attack can be mounted where an
665 attacker interposes itself between two communicating parties and
666 poses as the other end to either party or impersonates the other
667 end to either or both parties
669 o Undesired network traffic can be sent in an effort to overload an
670 architectural component, thus mounting a denial of service attack
672 8.2.2. XMPP-Grid Platforms
674 An unauthorized XMPP-Grid Platform (one which is not recognized by
675 the XMPP-Grid Controller or is recognized but not authorized to
676 perform any actions) cannot mount any attacks other than those listed
677 in the Network Attacks section above.
679 An authorized XMPP-Grid Platform, on the other hand, can mount many
680 attacks. These attacks might occur because the XMPP-Grid Platform is
681 controlled by a malicious, careless, or incompetent party (whether
682 because its owner is malicious, careless, or incompetent or because
683 the XMPP-Grid Platform has been compromised and is now controlled by
684 a party other than its owner). They might also occur because the
685 XMPP-Grid Platform is running malicious software; because the XMPP-
686 Grid Platform is running buggy software (which can fail in a state
687 that floods the network with traffic); or because the XMPP-Grid
688 Platform has been configured improperly. From a security standpoint,
689 it generally makes no difference why an attack is initiated. The
690 same countermeasures can be employed in any case.
692 Here is a list of attacks that can be mounted by an authorized XMPP-
693 Grid Platform:
695 o Cause many false alarms or otherwise overload the XMPP-Grid
696 Controller or other elements in the network security system
697 (including human administrators) leading to a denial of service or
698 disabling parts of the network security system
700 o Omit important actions (such as posting incriminating data),
701 resulting in incorrect access
703 o Use confidential information obtained from the XMPP-Grid
704 Controller to enable further attacks (such as using endpoint
705 health check results to exploit vulnerable endpoints)
707 o Advertise data crafted to exploit vulnerabilities in the XMPP-Grid
708 Controller or in other XMPP-Grid Platforms, with a goal of
709 compromising those systems
711 o Issue a search request or set up a subscription that matches an
712 enormous result, leading to resource exhaustion on the XMPP-Grid
713 Controller, the publishing XMPP-Grid Platform, and/or the network
715 o Establish a communication channel using another XMPP-Grid
716 Platform's session-id
718 o Advertise false data that leads to incorrect (e.g., potentially
719 attacker-controlled or -induced) behavior of XMPP-Grid Platforms,
720 by virtue of applying correct procdeures to the falsified input.
722 Dependencies of or vulnerabilities of authorized XMPP-Grid Platforms
723 can be exploited to effect these attacks. Another way to effect
724 these attacks is to gain the ability to impersonate an XMPP-Grid
725 Platform (through theft of the XMPP-Grid Platform's identity
726 credentials or through other means). Even a clock skew between the
727 XMPP-Grid Platform and XMPP-Grid Controller can cause problems if the
728 XMPP-Grid Platform assumes that old XMPP-Grid Platform data should be
729 ignored.
731 8.2.3. XMPP-Grid Controllers
733 An unauthorized XMPP-Grid Controller (one which is not trusted by
734 XMPP-Grid Platforms) cannot mount any attacks other than those listed
735 in the Network Attacks section above.
737 An authorized XMPP-Grid Controller can mount many attacks. Similar
738 to the XMPP-Grid Platform case described above, these attacks might
739 occur because the XMPP-Grid Controller is controlled by a malicious,
740 careless, or incompetent party (either an XMPP-Grid Controller
741 administrator or an attacker who has seized control of the XMPP-Grid
742 Controller). They might also occur because the XMPP-Grid Controller
743 is running malicious software, because the XMPP-Grid Controller is
744 running buggy software (which can fail in a state that corrupts data
745 or floods the network with traffic), or because the XMPP-Grid
746 Controller has been configured improperly.
748 All of the attacks listed for XMPP-Grid Platform above can be mounted
749 by the XMPP-Grid Controller. Detection of these attacks will be more
750 difficult since the XMPP-Grid Controller can create false operational
751 attributes and/or logs that imply some other party created any bad
752 data.
754 Additional XMPP-Grid Controller attacks can include:
756 o Expose different data to different XMPP-Grid Platforms to mislead
757 investigators or cause inconsistent behavior
759 o Mount an even more effective denial of service attack than a
760 single XMPP-Grid Platform could; some mechanisms include inducing
761 the many platforms to perform the same operation in an
762 amplification-style attack, completely refusing to pass any
763 traffic at all, or sending floods of traffic to (certain)
764 platforms or other targets.
766 o Obtain and cache XMPP-Grid Platform credentials so they can be
767 used to impersonate XMPP-Grid Platforms even after a breach of the
768 XMPP-Grid Controller is repaired. Some SASL mechanisms (including
769 the mandatory-to-implement SCRAM and EXTERNAL with TLS mutual
770 certificate-based authentication) do not admit this class of
771 attack, but others (such as PLAIN) are susceptible.
773 o Obtain and cache XMPP-Grid Controller administrator credentials so
774 they can be used to regain control of the XMPP-Grid Controller
775 after the breach of the XMPP-Grid Controller is repaired.
777 o Eavesdrop, inject or modify the data being transferred between
778 provider and consumer
780 Dependencies of or vulnerabilities of the XMPP-Grid Controller can be
781 exploited to obtain control of the XMPP-Grid Controller and effect
782 these attacks.
784 8.2.4. Certification Authority
786 A Certification Authority trusted to issue certificates for the XMPP-
787 Grid Controller and/or XMPP-Grid Platforms can mount several attacks:
789 o Issue certificates for unauthorized parties, enabling them to
790 impersonate authorized parties such as the XMPP-Grid Controller or
791 an XMPP-Grid Platform. This can lead to all the threats that can
792 be mounted by the certificate's subject.
794 o Issue certificates without following all of the CA's policies.
795 Because this can result in issuing certificates that can be used
796 to impersonate authorized parties, this can lead to all the
797 threats that can be mounted by the certificate's subject.
799 o Fail to revoke previously issued certificates that need to be
800 revoked. This can lead to undetected impersonation of the
801 certificate's subject or failure to revoke authorization of the
802 subject, and therefore can lead to all of the threats that can be
803 mounted by that subject.
805 o Fail to regularly and securely distribute certificate revocation
806 information. This can cause a relying party to accept a revoked
807 certificate, leading to undetected impersonation of the
808 certificate's subject or failure to revoke authorization of the
809 subject, and therefore can lead to all of the threats that can be
810 mounted by that subject. It can also cause a relying party to
811 refuse to proceed with a transaction because timely revocation
812 information is not available, even though the transaction should
813 be permitted to proceed.
815 o Allow the CA's private key to be revealed to an unauthorized
816 party. This can lead to all the threats above. Even worse, the
817 actions taken with the private key will not be known to the CA.
819 o Fail to promptly detect and report errors and violations of trust
820 so that relying parties can be promptly notified. This can cause
821 the threats listed earlier in this section to persist longer than
822 necessary, leading to many knock-on effects.
824 8.3. Countermeasures
826 Below are countermeasures for specific attack scenarios to the XMPP-
827 Grid infrastructure.
829 8.3.1. Securing the XMPP-Grid Data Transfer Protocol
831 To address network attacks, the XMPP-Grid data transfer protocol
832 described in this document requires that the XMPP-Grid messages MUST
833 be carried over TLS (minimally TLS 1.2 and preferrably TLS 1.3
834 [RFC8446]) as described in [RFC6120] and updated by [RFC7590]. The
835 XMPP-Grid Controller and XMPP-Grid Platforms SHOULD mutually
836 authenticate. The XMPP-Grid Platform MUST verify the XMPP-Grid
837 Controller's certificate and determine whether the XMPP-Grid
838 Controller is trusted by this XMPP-Grid Platform before completing
839 the TLS handshake. To ensure interoperability, implementations MUST
840 implement at least one of either the SASL EXTERNAL mechanism
841 [RFC4422] or the SASL SCRAM mechanism. When using the SASL SCRAM
842 mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over
843 the SCRAM-SHA-256 variant; and SHA-256 variants [RFC7677] SHOULD be
844 preferred over SHA-1 variants [RFC5802]). XMPP-Grid Platforms and
845 XMPP-Grid Controllers using certificate-based authentication SHOULD
846 each verify the revocation status of the other party's certificate.
847 The selection of which XMPP-Grid Platform authentication technique to
848 use in any particular deployment is left to the administrator.
850 These protocol security measures provide protection against all the
851 network attacks listed in the above document section except denial of
852 service attacks. If protection against these denial of service
853 attacks is desired, ingress filtering, rate limiting per source IP
854 address, and other denial of service mitigation measures can be
855 employed. In addition, an XMPP-Grid Controller MAY automatically
856 disable a misbehaving XMPP-Grid Platform.
858 8.3.2. Securing XMPP-Grid Platforms
860 XMPP-Grid Platforms can be deployed in locations that are susceptible
861 to physical attacks. Physical security measures can be taken to
862 avoid compromise of XMPP-Grid Platforms, but these are not always
863 practical or completely effective. An alternative measure is to
864 configure the XMPP-Grid Controller to provide read-only access for
865 such systems. The XMPP-Grid Controller SHOULD also include a full
866 authorization model so that individual XMPP-Grid Platforms can be
867 configured to have only the privileges that they need. The XMPP-Grid
868 Controller MAY provide functional templates so that the administrator
869 can configure a specific XMPP-Grid Platform as a DHCP [RFC2131]
870 server and authorize only the operations and metadata types needed by
871 a DHCP server to be permitted for that XMPP-Grid Platform. These
872 techniques can reduce the negative impacts of a compromised XMPP-Grid
873 Platform without diminishing the utility of the overall system.
875 To handle attacks within the bounds of this authorization model, the
876 XMPP-Grid Controller MAY also include rate limits and alerts for
877 unusual XMPP-Grid Platform behavior. XMPP-Grid Controllers SHOULD
878 make it easy to revoke an XMPP-Grid Platform's authorization when
879 necessary. The XMPP-Grid Controller SHOULD include auditable logs of
880 XMPP-Grid Platform activities.
882 To avoid compromise of XMPP-Grid Platform, XMPP-Grid Platform SHOULD
883 be hardened against attack and minimized to reduce their attack
884 surface. They should be well managed to minimize vulnerabilities in
885 the underlying platform and in systems upon which the XMPP-Grid
886 Platform depends. Personnel with administrative access should be
887 carefully screened and monitored to detect problems as soon as
888 possible.
890 8.3.3. Securing XMPP-Grid Controllers
892 Because of the serious consequences of XMPP-Grid Controller
893 compromise, XMPP-Grid Controllers need to be especially well hardened
894 against attack and minimized to reduce their attack surface. They
895 need to be well managed to minimize vulnerabilities in the underlying
896 platform and in systems upon which the XMPP-Grid Controller depends.
897 Network security measures such as firewalls or intrusion detection
898 systems can be used to monitor and limit traffic to and from the
899 XMPP-Grid Controller. Personnel with administrative access ought to
900 be carefully screened and monitored to detect problems as soon as
901 possible. Administrators SHOULD NOT use password-based
902 authentication but SHOULD instead use non-reusable credentials and
903 multi-factor authentication (where available). Physical security
904 measures ought to be employed to prevent physical attacks on XMPP-
905 Grid Controllers.
907 To ease detection of XMPP-Grid Controller compromise should it occur,
908 XMPP-Grid Controller behavior should be monitored to detect unusual
909 behavior (such as a reboot, a large increase in traffic, or different
910 views of an information repository for similar XMPP-Grid Platforms).
911 It is a matter of local policy whether XMPP-Grid Platforms log and/or
912 notify administrators when peculiar XMPP-Grid Controller behavior is
913 detected, and whether read-only audit logs of security-relevant
914 information (especially administrative actions) are maintained;
915 however, such behavior is encouraged to aid in forensic analysis.
916 Furthermore, if compromise of an XMPP-Grid Controller is detected, a
917 careful analysis should be performed and any reusable credentials
918 that can have been compromised should be reissued.
920 To address the potential for the XMPP-Grid controller to eavesdrop,
921 modify or inject data, it would be desirable to deploy end-to-end
922 encryption between the provider and the consumer(s). Unfortunately,
923 because there is no standardized method for encryption of one-to-many
924 messages within XMPP, techniques for enforcing end-to-end encryption
925 are out of scope for this specification.
927 8.3.4. Broker Access Models for Topics
929 The XMPP publish-subscribe specification [XEP-0060] defines five
930 access models for subscribing to Topics at a Broker: open, presence,
931 roster, authorize, and whitelist. The first model allows
932 uncontrolled access and the next two models are appropriate only in
933 instant-messaging applications. Therefore, a Broker SHOULD support
934 only the authorize model (under which the Topic owner needs to
935 approve all subscription requests and only subscribers can retrieve
936 data items) and the whitelist model (under which only preconfigured
937 Platforms can subscribe or retrieve data items). In order to ease
938 the deployment burden, subscription approvals and whitelist
939 management can be automated (e.g, the Topic "owner" can be a policy
940 server). The choice between "authorize" and "whitelist" as the
941 default access model is a matter for local service policy.
943 8.3.5. Limit on Search Result Size
945 While XMPP-Grid is designed for high scalability to 100,000s of
946 Platforms, an XMPP-Grid Controller MAY establish a limit to the
947 amount of data it is willing to return in search or subscription
948 results. Platforms could use [XEP-0059] to restrict the size of the
949 result sets the Controller returns in search or subscription results
950 or topics' service discovery. This mitigates the threat of an XMPP-
951 Grid Platform causing resource exhaustion by issuing a search or
952 subscription that leads to an enormous result.
954 8.3.6. Securing the Certification Authority
956 As noted above, compromise of a Certification Authority (CA) trusted
957 to issue certificates for the XMPP-Grid Controller and/or XMPP-Grid
958 Platforms is a major security breach. Many guidelines for proper CA
959 security have been developed: the CA/Browser Forum's Baseline
960 Requirements, the AICPA/CICA Trust Service Principles, the IETF's
961 Certificate Transparency [RFC6962] etc. The CA operator and relying
962 parties should agree on an appropriately rigorous security practices
963 to be used.
965 Even with the most rigorous security practices, a CA can be
966 compromised. If this compromise is detected quickly, relying parties
967 can remove the CA from their list of trusted CAs, and other CAs can
968 revoke any certificates issued to the CA. However, CA compromise may
969 go undetected for some time, and there's always the possibility that
970 a CA is being operated improperly or in a manner that is not in the
971 interests of the relying parties. For this reason, relying parties
972 may wish to "pin" a small number of particularly critical
973 certificates (such as the certificate for the XMPP-Grid Controller).
974 Once a certificate has been pinned, the relying party will not accept
975 another certificate in its place unless the Administrator explicitly
976 commands it to do so. This does not mean that the relying party will
977 not check the revocation status of pinned certificates. However, the
978 Administrator can still be consulted if a pinned certificate is
979 revoked, since the CA and revocation process are not completely
980 trusted. By "pinning" one or a small set of certificates, the
981 relying party has the effective XMPP-Grid Controller(s) authorized to
982 connect to.
984 8.3.7. End-to-End Encryption of Messages
986 Because it is expected that there will be a relatively large number
987 of Consumers for every Topic, for purposes of content discovery and
988 scaling this document specifies a "one-to-many" communications
989 pattern using the XMPP Publish-Subscribe extension. Unfortunately,
990 there is no standardized technology for end-to-end encryption of one-
991 to-many messages in XMPP. This implies that messages can be subject
992 to eavesdropping, data injection, and data modification attacks
993 within a Broker or Controller. If it is necessary to mitigate
994 against such attacks, implementers would need to select a messaging
995 pattern other than [XEP-0060], most likely the basic "instant
996 messaging" pattern specified in [RFC6121] with a suitable XMPP
997 extension for end-to-end encryption (such as [RFC3923] or a more
998 modern method such as [XEP-0384]). The description of such an
999 approach is out of scope for this document.
1001 8.4. Summary
1003 XMPP-Grid's considerable value as a broker for security-sensitive
1004 data exchange distribution also makes the protocol and the network
1005 security elements that implement it a target for attack. Therefore,
1006 strong security has been included as a basic design principle within
1007 the XMPP-Grid design process.
1009 The XMPP-Grid data transfer protocol provides strong protection
1010 against a variety of different attacks. In the event that an XMPP-
1011 Grid Platform or XMPP-Grid Controller is compromised, the effects of
1012 this compromise have been reduced and limited with the recommended
1013 role-based authorization model and other provisions, and best
1014 practices for managing and protecting XMPP-Grid systems have been
1015 described. Taken together, these measures should provide protection
1016 commensurate with the threat to XMPP-Grid systems, thus ensuring that
1017 they fulfill their promise as a network security clearing-house.
1019 9. Privacy Considerations
1021 XMPP-Grid Platforms can publish information about endpoint health,
1022 network access, events (which can include information about what
1023 services an endpoint is accessing), roles and capabilities, and the
1024 identity of the end user operating the endpoint. Any of this
1025 published information can be queried by other XMPP-Grid Platforms and
1026 could potentially be used to correlate network activity to a
1027 particular end user.
1029 Dynamic and static information brokered by an XMPP-Grid Controller,
1030 ostensibly for purposes of correlation by XMPP-Grid Platforms for
1031 intrusion detection, could be misused by a broader set of XMPP-Grid
1032 Platforms which hitherto have been performing specific roles with
1033 strict well-defined separation of duties.
1035 Care needs to be taken by deployers of XMPP-Grid to ensure that the
1036 information published by XMPP-Grid Platforms does not violate
1037 agreements with end users or local and regional laws and regulations.
1038 This can be accomplished either by configuring XMPP-Grid Platforms to
1039 not publish certain information or by restricting access to sensitive
1040 data to trusted XMPP-Grid Platforms. That is, the easiest means to
1041 ensure privacy or protect sensitive data, is to omit or not share it
1042 at all.
1044 Similarly, care must be taken by deployers and XMPP-Grid Controller
1045 implementations as they implement the appropriate auditing tools. In
1046 particular, any information, such as logs must be sensitive to the
1047 type of information stored to ensure that the information does not
1048 violate privacy and agreements with end users or local and regional
1049 laws and regulations.
1051 Another consideration for deployers is to enable end-to-end
1052 encryption to ensure the data is protected from the data layer to
1053 data layer and thus protect it from the transport layer. The means
1054 to achieve end-to-end encrpytion is beyond the scope of this
1055 document.
1057 10. Operations and Management Considerations
1059 In order to facilitate the management of Providers and the onboarding
1060 of Consumers, it is helpful to generate the following ahead of time:
1062 o Agreement between the operators of Provider services and the
1063 implementers of Consumer software regarding identifiers for common
1064 Topics (e.g., these could be registered with the XMPP Software
1065 Foundation's registry of well-known nodes for service discovery
1066 and publish-subscribe located at ).
1069 o Security certificates (including appropriate certificate chains)
1070 for Controllers, including identification of any Providers
1071 associated with the Controllers (which might be located at
1072 subdomains).
1074 o Consistent and secure access control policies for publishing and
1075 subscribing to Topics.
1077 These matters are out of scope for this document but ought to be
1078 addressed by the XMPP-Grid community.
1080 11. Acknowledgements
1082 The authors would like to acknowledge the contributions, authoring
1083 and/or editing of the following people: Joseph Salowey, Lisa
1084 Lorenzin, Clifford Kahn, Henk Birkholz, Jessica Fitzgerald-McKay,
1085 Steve Hanna, and Steve Venema. In addition, we want to thank Takeshi
1086 Takahashi, Panos Kampanakis, Adam Montville, Chris Inacio, and Dave
1087 Cridland for reviewing and providing valuable comments.
1089 12. References
1091 12.1. Normative References
1093 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
1094 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
1095 .
1097 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1098 Requirement Levels", BCP 14, RFC 2119,
1099 DOI 10.17487/RFC2119, March 1997,
1100 .
1102 [RFC3923] Saint-Andre, P., "End-to-End Signing and Object Encryption
1103 for the Extensible Messaging and Presence Protocol
1104 (XMPP)", RFC 3923, DOI 10.17487/RFC3923, October 2004,
1105 .
1107 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
1108 Authentication and Security Layer (SASL)", RFC 4422,
1109 DOI 10.17487/RFC4422, June 2006,
1110 .
1112 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
1113 "Salted Challenge Response Authentication Mechanism
1114 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802,
1115 DOI 10.17487/RFC5802, July 2010,
1116 .
1118 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
1119 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
1120 March 2011, .
1122 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence
1123 Protocol (XMPP): Instant Messaging and Presence",
1124 RFC 6121, DOI 10.17487/RFC6121, March 2011,
1125 .
1127 [RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer
1128 Security (TLS) in the Extensible Messaging and Presence
1129 Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June
1130 2015, .
1132 [RFC7677] Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple
1133 Authentication and Security Layer (SASL) Mechanisms",
1134 RFC 7677, DOI 10.17487/RFC7677, November 2015,
1135 .
1137 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1138 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1139 May 2017, .
1141 [XEP-0004]
1142 Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and
1143 P. Saint-Andre, "Data Forms", XSF XEP 0004, August 2007.
1145 [XEP-0030]
1146 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint-
1147 Andre, "Service Discovery", XSF XEP 0030, July 2010.
1149 [XEP-0059]
1150 Paterson, I., Saint-Andre, P., Mercier, V., and J.
1151 Seguineau, "Result Set Management", XSF XEP 0059,
1152 September 2006.
1154 [XEP-0060]
1155 Millard, P., Saint-Andre, P., and R. Meijer, "Publish-
1156 Subscribe", XSF XEP 0060, December 2017.
1158 [XEP-0203]
1159 Saint-Andre, P., "Delayed Delivery", XSF XEP 0203,
1160 December 2009.
1162 [XEP-0384]
1163 Straub, A., "Publish-Subscribe", XSF XEP 0384, July 2018.
1165 12.2. Informative References
1167 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
1168 RFC 2131, DOI 10.17487/RFC2131, March 1997,
1169 .
1171 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
1172 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
1173 .
1175 [RFC7970] Danyliw, R., "The Incident Object Description Exchange
1176 Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
1177 November 2016, .
1179 [RFC8274] Kampanakis, P. and M. Suzuki, "Incident Object Description
1180 Exchange Format Usage Guidance", RFC 8274,
1181 DOI 10.17487/RFC8274, November 2017,
1182 .
1184 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
1185 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
1186 .
1188 [XEP-0160]
1189 Saint-Andre, P., "Publish-Subscribe", XSF XEP 0160,
1190 October 2016.
1192 Authors' Addresses
1194 Nancy Cam-Winget (editor)
1195 Cisco Systems
1196 3550 Cisco Way
1197 San Jose, CA 95134
1198 USA
1200 Email: ncamwing@cisco.com
1201 Syam Appala
1202 Cisco Systems
1203 3550 Cisco Way
1204 San Jose, CA 95134
1205 USA
1207 Email: syam1@cisco.com
1209 Scott Pope
1210 Cisco Systems
1211 5400 Meadows Road
1212 Suite 300
1213 Lake Oswego, OR 97035
1214 USA
1216 Email: scottp@cisco.com
1218 Peter Saint-Andre
1219 Mozilla
1221 Email: stpeter@mozilla.com