idnits 2.17.1
draft-ietf-mile-xmpp-grid-09.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 :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (December 29, 2018) is 1936 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-0060'
-- Obsolete informational reference (is this intentional?): RFC 6962
(Obsoleted by RFC 9162)
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 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: July 2, 2019 Cisco Systems
6 P. Saint-Andre
7 Mozilla
8 December 29, 2018
10 Using XMPP for Security Information Exchange
11 draft-ietf-mile-xmpp-grid-09
13 Abstract
15 This document describes how to use the Extensible Messaging and
16 Presence Protocol (XMPP) to collect and distribute security-relevant
17 information between network-connected devices. To illustrate the
18 principles involved, this document describes such a usage for the
19 Incident Object Description Exchange Format (IODEF).
21 Status of This Memo
23 This Internet-Draft is submitted in full conformance with the
24 provisions of BCP 78 and BCP 79.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF). Note that other groups may also distribute
28 working documents as Internet-Drafts. The list of current Internet-
29 Drafts is at https://datatracker.ietf.org/drafts/current/.
31 Internet-Drafts are draft documents valid for a maximum of six months
32 and may be updated, replaced, or obsoleted by other documents at any
33 time. It is inappropriate to use Internet-Drafts as reference
34 material or to cite them other than as "work in progress."
36 This Internet-Draft will expire on July 2, 2019.
38 Copyright Notice
40 Copyright (c) 2018 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents
45 (https://trustee.ietf.org/license-info) in effect on the date of
46 publication of this document. Please review these documents
47 carefully, as they describe your rights and restrictions with respect
48 to this document. Code Components extracted from this document must
49 include Simplified BSD License text as described in Section 4.e of
50 the Trust Legal Provisions and are provided without warranty as
51 described in the Simplified BSD License.
53 Table of Contents
55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
57 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
58 4. Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . 5
59 5. Service Discovery . . . . . . . . . . . . . . . . . . . . . . 7
60 6. Publish-Subscribe . . . . . . . . . . . . . . . . . . . . . . 8
61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
63 8.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 12
64 8.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 13
65 8.3. Countermeasures . . . . . . . . . . . . . . . . . . . . . 17
66 8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 20
67 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
68 10. Operations and Management Considerations . . . . . . . . . . 21
69 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
70 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
71 12.1. Normative References . . . . . . . . . . . . . . . . . . 22
72 12.2. Informative References . . . . . . . . . . . . . . . . . 23
73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
75 1. Introduction
77 This document describes "XMPP-Grid": a method for using the
78 Extensible Messaging and Presence Protocol (XMPP) [RFC6120] to
79 collect and distribute security-relevant information among network
80 platforms, endpoints, and any other network-connected device. Among
81 other things, XMPP provides a publish-subscribe service [XEP-0060]
82 that acts as a broker, enabling control-plane functions by which
83 entities can discover available information to be published or
84 consumed. Although such information can take the form of any
85 structured data (XML, JSON, etc.), this document illustrates the
86 principles of XMPP-Grid with examples that use the Incident Object
87 Description Exchange Format (IODEF) [RFC7970]. That is, while other
88 security information formats can be shared using XMPP, this document
89 uses IODEF as one such example format that can be published and
90 consumed using XMPP.
92 2. Terminology
94 This document uses XMPP terminology defined in [RFC6120] and
95 [XEP-0060]. Because the intended audience for this document is those
96 who implement and deploy security reporting systems, mappings are
97 provided for the benefit of XMPP developers and operators.
99 Broker: A specific type of controller containing control plane
100 functions; as used here, the term refers to an XMPP publish-
101 subscribe service.
103 Broker Flow: A method by which security-related information is
104 published and consumed in a mediated fashion through a Broker. In
105 this flow, the Broker handles authorization of Consumers and
106 Providers to Topics, receives messages from Providers, and
107 delivers published messages to Consumers.
109 Consumer: An entity that contains functions to receive information
110 from other components; as used here, the term refers to an XMPP
111 publish-subscribe Subscriber.
113 Controller: A "component containing control plane functions that
114 manage and facilitate information sharing or execute on security
115 functions"; as used here, the term refers to an XMPP server, which
116 provides core message delivery [RFC6120] used by publish-subscribe
117 entities.
119 Node: The XMPP term for a Topic.
121 Platform: Any entity that connects to the XMPP-Grid in order to
122 publish or consume security-related data.
124 Provider: An entity that contains functions to provide information
125 to other components; as used here, the term refers to an XMPP
126 publish-subscribe Publisher.
128 Topic: A contextual information channel created on a Broker at which
129 messages generated by a Provider are propagated in real time to
130 one or more Consumers. Each Topic is limited to a specific type
131 and format of security data (e.g. IODEF namespace) and provides
132 an XMPP interface by which the data can be obtained.
134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
136 "OPTIONAL" in this document are to be interpreted as described in BCP
137 14 [RFC2119] [RFC8174] when, and only when, they appear in all
138 capitals, as shown here.
140 3. Architecture
142 The following figure illustrates the architecture of XMPP-Grid.
144 +--------------------------------------+
145 | +--------------------------------------+
146 | | +--------------------------------------+
147 | | | |
148 +-| | Platforms |
149 +-| |
150 +--------------------------------------+
151 / \ / \ / \
152 / C \ / \ / \
153 - o - - d - - -
154 ||n||A | a |B | |C
155 ||t|| | t | | |
156 - r - - a - | |
157 \ o / \ / | |
158 \ l / \ / | |
159 /|---------------------|\ | |
160 /|----/ \--------| d |--|\
161 / / Controller \ ctrl | a | \
162 \ \ & Broker / plane | t | /
163 \|----\ /--------| a |--|/
164 \|---------------------|/ | |
165 / \ / \ | |
166 / C \ / \ | |
167 - o - - d - | |
168 ||n||A | a |B | |C
169 ||t|| | t | | |
170 - r - - a - - -
171 \ o / \ / \ /
172 \ l / \ / \ /
173 +------------------------------------+
174 | |-+
175 | Platforms | |
176 | | |-+
177 +------------------------------------+ | |
178 +------------------------------------+ |
179 +------------------------------------+
181 Figure 1: XMPP-Grid Architecture
183 Platforms connect to the Controller (XMPP server) to authenticate and
184 then establish appropriate authorizations to be a Provider or
185 Consumer of interested Topics at the Broker. The control plane
186 messaging is established through XMPP and shown as "A" (control plane
187 interface) in Figure 1. Authorized nodes can then share data either
188 through the Broker (shown as "B" in Figure 1) or in some cases
189 directly (shown as "C" in Figure 1). This document focuses primarily
190 on the Broker Flow for information sharing ("direct flow"
191 interactions can be used for specialized purposes such as bulk data
192 transfer, but methods for doing so are outside the scope of this
193 document).
195 4. Workflow
197 A typical XMPP-Grid workflow is as follows:
199 a. A Platform with a source of security data requests connection to
200 the XMPP-Grid via a Controller.
202 b. The Controller authenticates the Platform.
204 c. The Platform establishes authorized privileges (e.g. privilege to
205 publish and/or subscribe to one or more Topics) with a Broker.
207 d. The Platform can publish security-related data to a Topic,
208 subscribe to a Topic, query a Topic, or any combination of these
209 operations.
211 e. A Provider unicasts its Topic updates to the Grid in real time
212 through a Broker. The Broker handles replication and
213 distribution of the Topic to Consumers. A Provider can publish
214 the same or different data to multiple Topics.
216 f. Any Platform on the Grid can subscribe to any Topics published to
217 the Grid (as permitted by authorization policy), and (as
218 Consumers) will then receive a continual, real-time stream of
219 updates from the Topics to which it is subscribed.
221 The general workflow is summarized in the figure below:
223 +--------------+ +------------+ +---------------+
224 | IODEF Client | | Controller | | IODEF Service |
225 | (Consumer) | | & Broker | | (Provider) |
226 +--------------+ +------------+ +---------------+
227 | | |
228 | Establish XMPP | |
229 | Client Session | |
230 | (RFC 6120) | |
231 |--------------------->| |
232 | | Establish XMPP |
233 | | Client Session |
234 | | (RFC 6120) |
235 | |<------------------------|
236 | | Request Topic Creation |
237 | | (XEP-0060) |
238 | |<------------------------|
239 | | Topic Creation Success |
240 | | (XEP-0060) |
241 | |------------------------>|
242 | Request Topic List | |
243 | (XEP-0030) | |
244 |--------------------->| |
245 | Return Topic List | |
246 | (XEP-0030) | |
247 |<---------------------| |
248 | | |
249 | Query Each Topic | |
250 | (XEP-0030) | |
251 |--------------------->| |
252 | Return Topic Data | |
253 | Including Topic Type | |
254 | (XEP-0030) | |
255 |<---------------------| |
256 | | |
257 | Subscribe to IODEF | |
258 | Topic (XEP-0060) | |
259 |--------------------->| |
260 | Subscription Success | |
261 | (XEP-0060) | |
262 |<---------------------| |
263 | | Publish IODEF Incident |
264 | | (XEP-0060) |
265 | Receive IODEF |<------------------------|
266 | Incident (XEP-0060) | |
267 |<---------------------| |
268 | | |
270 Figure 2: IODEF Example Workflow
272 XMPP-Grid implementations MUST adhere to the mandatory-to-implement
273 and mandatory-to-negotiate features as defined in [RFC6120].
274 Similarly, implementations MUST implement [XEP-0060] to facilitate
275 the asynchronous sharing for information. The Service Discovery per
276 [XEP-0030] SHOULD be implemented to facilitate the means to
277 dynamically discover the available information and namespaces
278 (Topics) to be published or consumed.
280 The following sections provide protocol examples for the service
281 discovery and publish-subscribe parts of the workflow.
283 5. Service Discovery
285 Using the XMPP service discovery extension [XEP-0030], a Controller
286 enables Platforms to discover what information can be consumed
287 through the Broker, and at which Topics. As an example, the
288 Controller at 'security-grid.example' might provide a Broker at
289 'broker.security-grid.example' hosting a number of Topics. A
290 Platform at 'xmpp-grid-client@mile-host.example' would query the
291 Broker about its available Topics by sending an XMPP "disco#items"
292 request to the Broker:
294
298
299
301 The Broker responds with the Topics it hosts:
303
307
308
311
314
315
317 In order to determine the exact nature of each Topic (i.e., in order
318 to find topics that publish incidents in the IODEF format), a
319 Platform would send an XMPP "disco#info" request to each Topic:
321
327
329 The Broker responds with the "disco#info" description, which SHOULD
330 include an XMPP Data Form [XEP-0004] including a 'pubsub#type' field
331 that specifies the supported namespace (in this example, the IODEF
332 namespace defined in [RFC7970]):
334
338
340
341
342
343
344 http://jabber.org/protocol/pubsub#meta-data
345
346
347 urn:ietf:params:xml:ns:iodef-2.0
348
349
350
351
353 6. Publish-Subscribe
355 Using the XMPP publish-subscribe extension [XEP-0030], a Consumer
356 subscribes to a Topic and a Provider publishes information to that
357 Topic, which the Broker then distributes to all subscribed Consumers.
359 First, a Provider would create a Topic as follows:
361
365
366
367
368
369 Note: The foregoing example is the minimal protocol needed to create
370 a Topic with the default node configuration on the XMPP publish-
371 subscribe service specified in the 'to' address of the creation
372 request stanza. Depending on security requirements, the Provider
373 might need to request a non-default configuration for the node; see
374 [XEP-0060] for detailed examples.
376 Unless an error occurs (see [XEP-0060] for various error flows), the
377 Broker responds with success:
379
384 Second, a Consumer would subscribe as follows:
386
390
391
393
394
396 Unless an error occurs (see [XEP-0060] for various error flows), the
397 Broker responds with success:
399
403
404
408
409
411 Third, a Provider would publish an incident as follows:
413
417
418
419 -
420
426
427 492382
428 2015-07-18T09:00:00-05:00
429
430
431 contact@csirt.example.com
432
433
434
435
436
437
438
439
441 (The payload in the foregoing example is from [RFC7970]; payloads for
442 additional use cases can be found in [RFC8274].)
444 The Broker would then deliver that incident report to all Consumers
445 who are subscribe to the Topic:
447
451
452
453 -
454
460
461 492382
462 2015-07-18T09:00:00-05:00
463
464
465 contact@csirt.example.com
466
467
468
469
470
471
472
473
475 7. IANA Considerations
477 This document has no actions for IANA.
479 8. Security Considerations
481 An XMPP-Grid Controller serves as an controlling broker for XMPP-Grid
482 Platforms such as Enforcement Points, Policy Servers, CMDBs, and
483 Sensors, using a publish-subscribe-search model of information
484 exchange and lookup. By increasing the ability of XMPP-Grid
485 Platforms to learn about and respond to security-relevant events and
486 data, XMPP-Grid can improve the timeliness and utility of the
487 security system. However, this integrated security system can also
488 be exploited by attackers if they can compromise it. Therefore,
489 strong security protections for XMPP-Grid are essential.
491 This section provides a security analysis of the XMPP-Grid data
492 transfer protocol and the architectural elements that employ it,
493 specifically with respect to their use of this protocol. Three
494 subsections define the trust model (which elements are trusted to do
495 what), the threat model (attacks that can be mounted on the system),
496 and the countermeasures (ways to address or mitigate the threats
497 previously identified).
499 8.1. Trust Model
501 The first step in analyzing the security of the XMPP-Grid transport
502 protocol is to describe the trust model, listing what each
503 architectural element is trusted to do. The items listed here are
504 assumptions, but provisions are made in the Threat Model and
505 Countermeasures sections for elements that fail to perform as they
506 were trusted to do.
508 8.1.1. Network
510 The network used to carry XMPP-Grid messages (i.e., the underlying
511 network transport layer over which XMPP runs) is trusted to:
513 o Perform best effort delivery of network traffic
515 The network used to carry XMPP-Grid messages is not expected
516 (trusted) to:
518 o Provide confidentiality or integrity protection for messages sent
519 over it
521 o Provide timely or reliable service
523 8.1.2. XMPP-Grid Platforms
525 Authorized XMPP-Grid Platforms are trusted to:
527 o Preserve the confidentiality of sensitive data retrieved via the
528 XMPP-Grid Controller
530 8.1.3. XMPP-Grid Controller
532 The XMPP-Grid Controller (including its associated Broker) is trusted
533 to:
535 o Broker requests for data and enforce authorization of access to
536 this data throughout its lifecycle
538 o Perform service requests in a timely and accurate manner
540 o Create and maintain accurate operational attributes
541 o Only reveal data to and accept service requests from authorized
542 parties
544 The XMPP-Grid Controller is not expected (trusted) to:
546 o Verify the truth (correctness) of data
548 8.1.4. Certification Authority
550 The Certification Authority (CA) that issues certificates for the
551 XMPP-Grid Controller and/or XMPP-Grid Platforms (or each CA, if there
552 are several) is trusted to:
554 o Ensure that only proper certificates are issued and that all
555 certificates are issued in accordance with the CA's policies
557 o Revoke certificates previously issued when necessary
559 o Regularly and securely distribute certificate revocation
560 information
562 o Promptly detect and report any violations of this trust so that
563 they can be handled
565 The CA is not expected (trusted) to:
567 o Issue certificates that go beyond the XMPP-Grid needs or other
568 constraints imposed by a relying party.
570 8.2. Threat Model
572 To secure the XMPP-Grid data transfer protocol and the architectural
573 elements that implement it, this section identifies the attacks that
574 can be mounted against the protocol and elements.
576 8.2.1. Network Attacks
578 A variety of attacks can be mounted using the network. For the
579 purposes of this subsection the phrase "network traffic" can be taken
580 to mean messages and/or parts of messages. Any of these attacks can
581 be mounted by network elements, by parties who control network
582 elements, and (in many cases) by parties who control network-attached
583 devices.
585 o Network traffic can be passively monitored to glean information
586 from any unencrypted traffic
588 o Even if all traffic is encrypted, valuable information can be
589 gained by traffic analysis (volume, timing, source and destination
590 addresses, etc.)
592 o Network traffic can be modified in transit
594 o Previously transmitted network traffic can be replayed
596 o New network traffic can be added
598 o Network traffic can be blocked, perhaps selectively
600 o A "Man In The Middle" (MITM) attack can be mounted where an
601 attacker interposes itself between two communicating parties and
602 poses as the other end to either party or impersonates the other
603 end to either or both parties
605 o Undesired network traffic can be sent in an effort to overload an
606 architectural component, thus mounting a denial of service attack
608 8.2.2. XMPP-Grid Platforms
610 An unauthorized XMPP-Grid Platform (one which is not recognized by
611 the XMPP-Grid Controller or is recognized but not authorized to
612 perform any actions) cannot mount any attacks other than those listed
613 in the Network Attacks section above.
615 An authorized XMPP-Grid Platform, on the other hand, can mount many
616 attacks. These attacks might occur because the XMPP-Grid Platform is
617 controlled by a malicious, careless, or incompetent party (whether
618 because its owner is malicious, careless, or incompetent or because
619 the XMPP-Grid Platform has been compromised and is now controlled by
620 a party other than its owner). They might also occur because the
621 XMPP-Grid Platform is running malicious software; because the XMPP-
622 Grid Platform is running buggy software (which can fail in a state
623 that floods the network with traffic); or because the XMPP-Grid
624 Platform has been configured improperly. From a security standpoint,
625 it generally makes no difference why an attack is initiated. The
626 same countermeasures can be employed in any case.
628 Here is a list of attacks that can be mounted by an authorized XMPP-
629 Grid Platform:
631 o Cause many false alarms or otherwise overload the XMPP-Grid
632 Controller or other elements in the network security system
633 (including human administrators) leading to a denial of service or
634 disabling parts of the network security system
636 o Omit important actions (such as posting incriminating data),
637 resulting in incorrect access
639 o Use confidential information obtained from the XMPP-Grid
640 Controller to enable further attacks (such as using endpoint
641 health check results to exploit vulnerable endpoints)
643 o Advertise data crafted to exploit vulnerabilities in the XMPP-Grid
644 Controller or in other XMPP-Grid Platforms, with a goal of
645 compromising those systems
647 o Issue a search request or set up a subscription that matches an
648 enormous result, leading to resource exhaustion on the XMPP-Grid
649 Controller, the publishing XMPP-Grid Platform, and/or the network
651 o Establish a communication channel using another XMPP-Grid
652 Platform's session-id
654 Dependencies of or vulnerabilities of authorized XMPP-Grid Platforms
655 can be exploited to effect these attacks. Another way to effect
656 these attacks is to gain the ability to impersonate an XMPP-Grid
657 Platform (through theft of the XMPP-Grid Platform's identity
658 credentials or through other means). Even a clock skew between the
659 XMPP-Grid Platform and XMPP-Grid Controller can cause problems if the
660 XMPP-Grid Platform assumes that old XMPP-Grid Platform data deserves
661 to be ignored.
663 8.2.3. XMPP-Grid Controllers
665 An unauthorized XMPP-Grid Controller (one which is not trusted by
666 XMPP-Grid Platforms) cannot mount any attacks other than those listed
667 in the Network Attacks section above.
669 An authorized XMPP-Grid Controller can mount many attacks. Similar
670 to the XMPP-Grid Platform case described above, these attacks might
671 occur because the XMPP-Grid Controller is controlled by a malicious,
672 careless, or incompetent party (either an XMPP-Grid Controller
673 administrator or an attacker who has seized control of the XMPP-Grid
674 Controller). They might also occur because the XMPP-Grid Controller
675 is running malicious software, because the XMPP-Grid Controller is
676 running buggy software (which can fail in a state that corrupts data
677 or floods the network with traffic), or because the XMPP-Grid
678 Controller has been configured improperly.
680 All of the attacks listed for XMPP-Grid Platform above can be mounted
681 by the XMPP-Grid Controller. Detection of these attacks will be more
682 difficult since the XMPP-Grid Controller can create false operational
683 attributes and/or logs that imply some other party created any bad
684 data.
686 Additional XMPP-Grid Controller attacks can include:
688 o Expose different data to different XMPP-Grid Platforms to mislead
689 investigators or cause inconsistent behavior
691 o Mount an even more effective denial of service attack than a
692 single XMPP-Grid Platform could
694 o Obtain and cache XMPP-Grid Platform credentials so they can be
695 used to impersonate XMPP-Grid Platforms even after a breach of the
696 XMPP-Grid Controller is repaired
698 o Obtain and cache XMPP-Grid Controller administrator credentials so
699 they can be used to regain control of the XMPP-Grid Controller
700 after the breach of the XMPP-Grid Controller is repaired
702 Dependencies of or vulnerabilities of the XMPP-Grid Controller can be
703 exploited to obtain control of the XMPP-Grid Controller and effect
704 these attacks.
706 8.2.4. Certification Authority
708 A Certification Authority trusted to issue certificates for the XMPP-
709 Grid Controller and/or XMPP-Grid Platforms can mount several attacks:
711 o Issue certificates for unauthorized parties, enabling them to
712 impersonate authorized parties such as the XMPP-Grid Controller or
713 an XMPP-Grid Platform. This can lead to all the threats that can
714 be mounted by the certificate's subject.
716 o Issue certificates without following all of the CA's policies.
717 Because this can result in issuing certificates that can be used
718 to impersonate authorized parties, this can lead to all the
719 threats that can be mounted by the certificate's subject.
721 o Fail to revoke previously issued certificates that need to be
722 revoked. This can lead to undetected impersonation of the
723 certificate's subject or failure to revoke authorization of the
724 subject, and therefore can lead to all of the threats that can be
725 mounted by that subject.
727 o Fail to regularly and securely distribute certificate revocation
728 information. This can cause a relying party to accept a revoked
729 certificate, leading to undetected impersonation of the
730 certificate's subject or failure to revoke authorization of the
731 subject, and therefore can lead to all of the threats that can be
732 mounted by that subject. It can also cause a relying party to
733 refuse to proceed with a transaction because timely revocation
734 information is not available, even though the transaction should
735 be permitted to proceed.
737 o Allow the CA's private key to be revealed to an unauthorized
738 party. This can lead to all the threats above. Even worse, the
739 actions taken with the private key will not be known to the CA.
741 o Fail to promptly detect and report errors and violations of trust
742 so that relying parties can be promptly notified. This can cause
743 the threats listed earlier in this section to persist longer than
744 necessary, leading to many knock-on effects.
746 8.3. Countermeasures
748 Below are countermeasures for specific attack scenarios to the XMPP-
749 Grid infrastructure.
751 8.3.1. Securing the XMPP-Grid Data Transfer Protocol
753 To address network attacks, the XMPP-Grid data transfer protocol
754 described in this document requires that the XMPP-Grid messages MUST
755 be carried over TLS (minimally TLS 1.2 [RFC8446]) as described in
756 [RFC6120] and updated by [RFC7590]. The XMPP-Grid Platform MUST
757 verify the XMPP-Grid Controller's certificate and determine whether
758 the XMPP-Grid Controller is trusted by this XMPP-Grid Platform before
759 completing the TLS handshake. The XMPP-Grid Controller MUST
760 authenticate the XMPP-Grid Platform either using the SASL EXTERNAL
761 mechanism [RFC4422] or using the SASL SCRAM mechanism (with the
762 SCRAM-SHA-256-PLUS variant being preferred over the SCRAM-SHA-256
763 variant and SHA-256 variants [RFC7677] being preferred over SHA-1
764 varients [RFC5802]). XMPP-Grid Platforms and XMPP-Grid Controllers
765 using mutual certificate-based authentication SHOULD each verify the
766 revocation status of the other party's certificate. All XMPP-Grid
767 Controllers and XMPP-Grid Platforms MUST implement both SASL EXTERNAL
768 and SASL SCRAM. The selection of which XMPP-Grid Platform
769 authentication technique to use in any particular deployment is left
770 to the administrator.
772 These protocol security measures provide protection against all the
773 network attacks listed in the above document section except denial of
774 service attacks. If protection against these denial of service
775 attacks is desired, ingress filtering, rate limiting per source IP
776 address, and other denial of service mitigation measures can be
777 employed. In addition, an XMPP-Grid Controller MAY automatically
778 disable a misbehaving XMPP-Grid Platform.
780 8.3.2. Securing XMPP-Grid Platforms
782 XMPP-Grid Platforms can be deployed in locations that are susceptible
783 to physical attacks. Physical security measures can be taken to
784 avoid compromise of XMPP-Grid Platforms, but these are not always
785 practical or completely effective. An alternative measure is to
786 configure the XMPP-Grid Controller to provide read-only access for
787 such systems. The XMPP-Grid Controller SHOULD also include a full
788 authorization model so that individual XMPP-Grid Platforms can be
789 configured to have only the privileges that they need. The XMPP-Grid
790 Controller MAY provide functional templates so that the administrator
791 can configure a specific XMPP-Grid Platform as a DHCP [RFC2131]
792 server and authorize only the operations and metadata types needed by
793 a DHCP server to be permitted for that XMPP-Grid Platform. These
794 techniques can reduce the negative impacts of a compromised XMPP-Grid
795 Platform without diminishing the utility of the overall system.
797 To handle attacks within the bounds of this authorization model, the
798 XMPP-Grid Controller MAY also include rate limits and alerts for
799 unusual XMPP-Grid Platform behavior. XMPP-Grid Controllers SHOULD
800 make it easy to revoke an XMPP-Grid Platform's authorization when
801 necessary. Another way to detect attacks from XMPP-Grid Platforms is
802 to create fake entries in the available data (honeytokens) which
803 normal XMPP-Grid Platforms will not attempt to access. The XMPP-Grid
804 Controller SHOULD include auditable logs of XMPP-Grid Platform
805 activities.
807 To avoid compromise of XMPP-Grid Platform, XMPP-Grid Platform SHOULD
808 be hardened against attack and minimized to reduce their attack
809 surface. They should be well managed to minimize vulnerabilities in
810 the underlying platform and in systems upon which the XMPP-Grid
811 Platform depends. Personnel with administrative access should be
812 carefully screened and monitored to detect problems as soon as
813 possible.
815 8.3.3. Securing XMPP-Grid Controllers
817 Because of the serious consequences of XMPP-Grid Controller
818 compromise, XMPP-Grid Controllers need to be especially well hardened
819 against attack and minimized to reduce their attack surface. They
820 need to be well managed to minimize vulnerabilities in the underlying
821 platform and in systems upon which the XMPP-Grid Controller depends.
822 Network security measures such as firewalls or intrusion detection
823 systems can be used to monitor and limit traffic to and from the
824 XMPP-Grid Controller. Personnel with administrative access ought to
825 be carefully screened and monitored to detect problems as soon as
826 possible. Administrators SHOULD NOT use password-based
827 authentication but should instead use non-reusable credentials and
828 multi-factor authentication (where available). Physical security
829 measures ought to be employed to prevent physical attacks on XMPP-
830 Grid Controllers.
832 To ease detection of XMPP-Grid Controller compromise should it occur,
833 XMPP-Grid Controller behavior should be monitored to detect unusual
834 behavior (such as a reboot, a large increase in traffic, or different
835 views of an information repository for similar XMPP-Grid Platforms).
836 XMPP-Grid Platforms should log and/or notify administrators when
837 peculiar XMPP-Grid Controller behavior is detected. To aid forensic
838 investigation, permanent read-only audit logs of security-relevant
839 information (especially administrative actions) should be maintained.
840 If XMPP-Grid Controller compromise is detected, a careful analysis
841 should be performed of the impact of this compromise. Any reusable
842 credentials that can have been compromised should be reissued.
844 8.3.4. Broker Access Models for Topics
846 The XMPP publish-subscribe specification [XEP-0060] defines five
847 access models for subscribing to Topics at a Broker: open, presence,
848 roster, authorize, and whitelist. The first model allows
849 uncontrolled access and the next two models are appropriate only in
850 instant-messaging applications. Therefore, a Broker SHOULD support
851 only the authorize model (under which the Topic owner needs to
852 approve all subscription requests and only subscribers can retrieve
853 data items) and the whitelist model (under which only preconfigured
854 Platforms can subscribe or retrieve data items). In order to ease
855 the deployment burden, subscription approvals and whitelist
856 management can be automated (e.g, the Topic "owner" can be a policy
857 server). The choice between "authorize" and "whitelist" as the
858 default access model is a matter for local service policy.
860 8.3.5. Limit on Search Result Size
862 While XMPP-Grid is designed for high scalability to 100,000s of
863 Platforms, an XMPP-Grid Controller MAY establish a limit to the
864 amount of data it is willing to return in search or subscription
865 results. This mitigates the threat of an XMPP-Grid Platform causing
866 resource exhaustion by issuing a search or subscription that leads to
867 an enormous result.
869 8.3.6. Securing the Certification Authority
871 As noted above, compromise of a Certification Authority (CA) trusted
872 to issue certificates for the XMPP-Grid Controller and/or XMPP-Grid
873 Platforms is a major security breach. Many guidelines for proper CA
874 security have been developed: the CA/Browser Forum's Baseline
875 Requirements, the AICPA/CICA Trust Service Principles, the IETF's
876 Certificate Transparency [RFC6962] etc. The CA operator and relying
877 parties should agree on an appropriately rigorous security practices
878 to be used.
880 Even with the most rigorous security practices, a CA can be
881 compromised. If this compromise is detected quickly, relying parties
882 can remove the CA from their list of trusted CAs, and other CAs can
883 revoke any certificates issued to the CA. However, CA compromise may
884 go undetected for some time, and there's always the possibility that
885 a CA is being operated improperly or in a manner that is not in the
886 interests of the relying parties. For this reason, relying parties
887 may wish to "pin" a small number of particularly critical
888 certificates (such as the certificate for the XMPP-Grid Controller).
889 Once a certificate has been pinned, the relying party will not accept
890 another certificate in its place unless the Administrator explicitly
891 commands it to do so. This does not mean that the relying party will
892 not check the revocation status of pinned certificates. However, the
893 Administrator can still be consulted if a pinned certificate is
894 revoked, since the CA and revocation process are not completely
895 trusted.
897 8.4. Summary
899 XMPP-Grid's considerable value as a broker for security-sensitive
900 data exchange distribution also makes the protocol and the network
901 security elements that implement it a target for attack. Therefore,
902 strong security has been included as a basic design principle within
903 the XMPP-Grid design process.
905 The XMPP-Grid data transfer protocol provides strong protection
906 against a variety of different attacks. In the event that an XMPP-
907 Grid Platform or XMPP-Grid Controller is compromised, the effects of
908 this compromise have been reduced and limited with the recommended
909 role-based authorization model and other provisions, and best
910 practices for managing and protecting XMPP-Grid systems have been
911 described. Taken together, these measures should provide protection
912 commensurate with the threat to XMPP-Grid systems, thus ensuring that
913 they fulfill their promise as a network security clearing-house.
915 9. Privacy Considerations
917 XMPP-Grid Platforms can publish information about endpoint health,
918 network access, events (which can include information about what
919 services an endpoint is accessing), roles and capabilities, and the
920 identity of the end user operating the endpoint. Any of this
921 published information can be queried by other XMPP-Grid Platforms and
922 could potentially be used to correlate network activity to a
923 particular end user.
925 Dynamic and static information brokered by an XMPP-Grid Controller,
926 ostensibly for purposes of correlation by XMPP-Grid Platforms for
927 intrusion detection, could be misused by a broader set of XMPP-Grid
928 Platforms which hitherto have been performing specific roles with
929 strict well-defined separation of duties.
931 Care needs to be taken by deployers of XMPP-Grid to ensure that the
932 information published by XMPP-Grid Platforms does not violate
933 agreements with end users or local and regional laws and regulations.
934 This can be accomplished either by configuring XMPP-Grid Platforms to
935 not publish certain information or by restricting access to sensitive
936 data to trusted XMPP-Grid Platforms. That is, the easiest means to
937 ensure privacy or protect sensitive data, is to omit or not share it
938 at all.
940 Another consideration for deployers is to enable end-to-end
941 encryption to ensure the data is protected from the data layer to
942 data layer and thus protect it from the transport layer.
944 10. Operations and Management Considerations
946 In order to facilitate the management of Providers and the onboarding
947 of Consumers, it is helpful to generate the following ahead of time:
949 o Agreement between the operators of Provider services and the
950 implementers of Consumer software regarding identifiers for common
951 Topics (e.g., these could be registered with the XMPP Software
952 Foundation's registry of well-known nodes for service discovery
953 and publish-subscribe located at ).
956 o Security certificates (including appropriate certificate chains)
957 for Controllers, including identification of any Providers
958 associated with the Controllers (which might be located at
959 subdomains).
961 o Consistent and secure access control policies for publishing and
962 subscribing to Topics.
964 These matters are out of scope for this document but ought to be
965 addressed by the XMPP-Grid community.
967 11. Acknowledgements
969 The authors would like to acknowledge the contributions, authoring
970 and/or editing of the following people: Joseph Salowey, Lisa
971 Lorenzin, Clifford Kahn, Henk Birkholz, Jessica Fitzgerald-McKay,
972 Steve Hanna, and Steve Venema. In addition, we want to thank Takeshi
973 Takahashi, Panos Kampanakis, Adam Montville, Chris Inacio, and Dave
974 Cridland for reviewing and providing valuable comments.
976 12. References
978 12.1. Normative References
980 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
981 Requirement Levels", BCP 14, RFC 2119,
982 DOI 10.17487/RFC2119, March 1997,
983 .
985 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
986 Authentication and Security Layer (SASL)", RFC 4422,
987 DOI 10.17487/RFC4422, June 2006,
988 .
990 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
991 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
992 March 2011, .
994 [RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer
995 Security (TLS) in the Extensible Messaging and Presence
996 Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June
997 2015, .
999 [RFC7677] Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple
1000 Authentication and Security Layer (SASL) Mechanisms",
1001 RFC 7677, DOI 10.17487/RFC7677, November 2015,
1002 .
1004 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1005 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1006 May 2017, .
1008 [XEP-0004]
1009 Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and
1010 P. Saint-Andre, "Data Forms", XSF XEP 0004, August 2007.
1012 [XEP-0030]
1013 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint-
1014 Andre, "Service Discovery", XSF XEP 0030, July 2010.
1016 [XEP-0060]
1017 Millard, P., Saint-Andre, P., and R. Meijer, "Publish-
1018 Subscribe", XSF XEP 0060, December 2017.
1020 12.2. Informative References
1022 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
1023 RFC 2131, DOI 10.17487/RFC2131, March 1997,
1024 .
1026 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
1027 "Salted Challenge Response Authentication Mechanism
1028 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802,
1029 DOI 10.17487/RFC5802, July 2010,
1030 .
1032 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
1033 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
1034 .
1036 [RFC7970] Danyliw, R., "The Incident Object Description Exchange
1037 Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
1038 November 2016, .
1040 [RFC8274] Kampanakis, P. and M. Suzuki, "Incident Object Description
1041 Exchange Format Usage Guidance", RFC 8274,
1042 DOI 10.17487/RFC8274, November 2017,
1043 .
1045 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
1046 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
1047 .
1049 Authors' Addresses
1051 Nancy Cam-Winget (editor)
1052 Cisco Systems
1053 3550 Cisco Way
1054 San Jose, CA 95134
1055 USA
1057 Email: ncamwing@cisco.com
1059 Syam Appala
1060 Cisco Systems
1061 3550 Cisco Way
1062 San Jose, CA 95134
1063 USA
1065 Email: syam1@cisco.com
1066 Scott Pope
1067 Cisco Systems
1068 5400 Meadows Road
1069 Suite 300
1070 Lake Oswego, OR 97035
1071 USA
1073 Email: scottp@cisco.com
1075 Peter Saint-Andre
1076 Mozilla
1078 Email: stpeter@mozilla.com