idnits 2.17.1
draft-ietf-mile-xmpp-grid-05.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 (February 8, 2018) is 2269 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)
== Outdated reference: A later version (-16) exists of
draft-ietf-sacm-terminology-14
** Downref: Normative reference to an Informational draft:
draft-ietf-sacm-terminology (ref. 'I-D.ietf-sacm-terminology')
-- 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 5246
(Obsoleted by RFC 8446)
Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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: August 12, 2018 Cisco Systems
6 P. Saint-Andre
7 Mozilla
8 February 8, 2018
10 Using XMPP for Security Information Exchange
11 draft-ietf-mile-xmpp-grid-05
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 http://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 August 12, 2018.
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 (http://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 . . . . . . . . . . . . . . . . . . . 21
68 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
70 11.1. Normative References . . . . . . . . . . . . . . . . . . 21
71 11.2. Informative References . . . . . . . . . . . . . . . . . 22
72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
74 1. Introduction
76 This document describes "XMPP-Grid": a method for using the
77 Extensible Messaging and Presence Protocol (XMPP) [RFC6120] to
78 collect and distribute security-relevant information among network
79 platforms, endpoints, and any other network-connected device. Among
80 other things, XMPP provides a publish-subscribe service [XEP-0060]
81 that acts as a broker, enabling control-plane functions by which
82 entities can discover available information to be published or
83 consumed. Although such information can take the form of any
84 structured data (XML, JSON, etc.), this document illustrates the
85 principles of XMPP-Grid with examples that use the Incident Object
86 Description Exchange Format (IODEF) [RFC7970].
88 2. Terminology
90 This document uses XMPP terminology defined in [RFC6120] and
91 [XEP-0060] as well as Security Automation and Continuous Monitoring
92 (SACM) terminology defined in [I-D.ietf-sacm-terminology]. Because
93 the intended audience for this document is those who implement and
94 deploy security reporting systems, in general the SACM terms are used
95 (however, mappings are provided for the benefit of XMPP developers
96 and operators).
98 Broker: In SACM, a specific type of controller containing control
99 plane functions; as used here, the term refers to an XMPP publish-
100 subscribe service.
102 Broker Flow: In SACM, a method by which security-related information
103 is published and consumed in a mediated fashion through a Broker.
104 In this flow, the Broker handles authorization of Consumers and
105 Providers to Topics, receives messages from Providers, and
106 delivers published messages to Consumers.
108 Consumer: In SACM, an entity that contains functions to receive
109 information from other components; as used here, the term refers
110 to an XMPP publish-subscribe Subscriber.
112 Controller: In SACM, a "component containing control plane functions
113 that manage and facilitate information sharing or execute on
114 security functions"; as used here, the term refers to an XMPP
115 server, which provides core message delivery [RFC6120] used by
116 publish-subscribe entities.
118 Node: The XMPP term for a Topic.
120 Platform: Any entity that connects to the XMPP-Grid in order to
121 publish or consume security-related data.
123 Provider: In SACM, an entity that contains functions to provide
124 information to other components; as used here, the term refers to
125 an XMPP publish-subscribe Publisher.
127 Publisher: The XMPP term for a Provider.
129 Publish-Subscribe Service: The XMPP term for the kind Broker
130 discussed here.
132 Subscriber: The XMPP term for a Consumer.
134 Topic: A contextual information channel created on a Broker at which
135 messages generated by a Provider are propagated in real time to
136 one or more Consumers. Each Topic is limited to a specific type
137 and format of security data (e.g., IODEF) and provides an XMPP
138 interface by which the data can be obtained.
140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
142 document are to be interpreted as described in [RFC2119].
144 3. Architecture
146 The following figure illustrates the architecture of XMPP-Grid.
148 +--------------------------------------+
149 | +--------------------------------------+
150 | | +--------------------------------------+
151 | | | |
152 +-| | Platforms |
153 +-| |
154 +--------------------------------------+
155 / \ / \ / \
156 / C \ / \ / \
157 - o - - d - - -
158 ||n||A | a |B | |C
159 ||t|| | t | | |
160 - r - - a - | |
161 \ o / \ / | |
162 \ l / \ / | |
163 /|---------------------|\ | |
164 /|----/ \--------| d |--|\
165 / / Controller \ ctrl | a | \
166 \ \ & Broker / plane | t | /
167 \|----\ /--------| a |--|/
168 \|---------------------|/ | |
169 / \ / \ | |
170 / C \ / \ | |
171 - o - - d - | |
172 ||n||A | a |B | |C
173 ||t|| | t | | |
174 - r - - a - - -
175 \ o / \ / \ /
176 \ l / \ / \ /
177 +------------------------------------+
178 | |-+
179 | Platforms | |
180 | | |-+
181 +------------------------------------+ | |
182 +------------------------------------+ |
183 +------------------------------------+
185 Figure 1: XMPP-Grid Architecture
187 Platforms connect to the Controller (XMPP server) to authenticate and
188 then establish appropriate authorizations and relationships (e.g.,
189 Provider or Consumer) at the Broker. The control plane messaging is
190 established through XMPP and shown as "A" (control plane interface)
191 in Figure 1. Authorized nodes can then share data either thru the
192 Broker (shown as "B" in Figure 1) or in some cases directly (shown as
193 "C" in Figure 1). This document focuses primarily on the Broker Flow
194 for information sharing ("direct flow" interactions can be used for
195 specialized purposes such as bulk data transfer, but methods for
196 doing so are outside the scope of this document).
198 4. Workflow
200 A typical XMPP-Grid workflow is as follows:
202 a. A Platform with a source of security data requests connection to
203 the XMPP-Grid via a Controller (XMPP server).
205 b. The Controller authenticates the Platform.
207 c. The Platform establishes authorized privileges (e.g. privilege to
208 publish and/or subscribe to security data Topics) with a Broker.
210 d. The Platform can publish security-related data to a Topic,
211 subscribe to a Topic, query a Topic, or any combination of these
212 operations.
214 e. A Provider unicasts its Topic updates to the Grid in real time
215 through a Broker. The Broker handles replication and
216 distribution of the Topic to Consumers. A Provider can publish
217 the same or different data to multiple Topics.
219 f. Any Platform on the Grid can subscribe to any Topics published to
220 the Grid (as permitted by authorization policy), and as Consumers
221 will then receive a continual, real-time stream of updates from
222 the Topics to which it is subscribed.
224 The general workflow is summarized in the figure below:
226 +--------------+ +------------+ +---------------+
227 | IODEF Client | | Controller | | IODEF Service |
228 | (Consumer) | | & Broker | | (Provider) |
229 +--------------+ +------------+ +---------------+
230 | | |
231 | Establish XMPP | |
232 | Client Session | |
233 | (RFC 6120) | |
234 |--------------------->| |
235 | | Establish XMPP |
236 | | Client Session |
237 | | (RFC 6120) |
238 | |<------------------------|
239 | | Request Topic Creation |
240 | | (XEP-0060) |
241 | |<------------------------|
242 | | Topic Creation Success |
243 | | (XEP-0060) |
244 | |------------------------>|
245 | Request Topic List | |
246 | (XEP-0030) | |
247 |--------------------->| |
248 | Return Topic List | |
249 | (XEP-0030) | |
250 |<---------------------| |
251 | | |
252 | Query Each Topic | |
253 | (XEP-0030) | |
254 |--------------------->| |
255 | Return Topic Data | |
256 | Including Topic Type | |
257 | (XEP-0030) | |
258 |<---------------------| |
259 | | |
260 | Subscribe to IODEF | |
261 | Topic (XEP-0060) | |
262 |--------------------->| |
263 | Subscription Success | |
264 | (XEP-0060) | |
265 |<---------------------| |
266 | | Publish IODEF Incident |
267 | | (XEP-0060) |
268 | Receive IODEF |<------------------------|
269 | Incident (XEP-0060) | |
270 |<---------------------| |
271 | | |
273 Figure 2: IODEF Example Workflow
275 The following sections provide protocol examples for the service
276 discovery and publish-subscribe parts of the workflow.
278 5. Service Discovery
280 Using the XMPP service discovery extension [XEP-0030], a Controller
281 enables Platforms to discover what information can be consumed
282 through the Broker, and at which Topics. As an example, the
283 Controller at 'security-grid.example' might provide a Broker at
284 'broker.security-grid.example' hosting a number of Topics. A
285 Platform at 'xmpp-grid-client@mile-host.example' would query the
286 Broker about its available Topics by sending an XMPP "disco#items"
287 request to the Broker:
289
293
294
296 The Broker responds with the Topics it hosts:
298
302
303
306
309
310
312 In order to determine the exact nature of each Topic (i.e., in order
313 to find topics that publish incidents in the IODEF format), a
314 Platform would send an XMPP "disco#info" request to each Topic:
316
322
323 The Broker responds with the "disco#info" description, which SHOULD
324 include an XMPP Data Form [XEP-0004] including a 'pubsub#type' field
325 that specifies the supported namespace (in this example, the IODEF
326 namespace defined in [RFC7970]):
328
332
334
335
336
337
338 http://jabber.org/protocol/pubsub#meta-data
339
340
341 urn:ietf:params:xml:ns:iodef-2.0
342
343
344
345
347 6. Publish-Subscribe
349 Using the XMPP publish-subscribe extension [XEP-0030], a Consumer
350 subscribes to a Topic and a Provider publishes information to that
351 Topic, which the Broker then distributes to all subscribed Consumers.
353 First, a Provider would create a Topic as follows:
355
359
360
361
362
364 Note: The foregoing example is the minimal protocol needed to create
365 a Topic with the default node configuration on the XMPP publish-
366 subscribe service specified in the 'to' address of the creation
367 request stanza. Depending on security requirements, the Provider
368 might need to request a non-default configuration for the node; see
369 [XEP-0060] for detailed examples.
371 Unless an error occurs (see [XEP-0060] for various error flows), the
372 Broker responds with success:
374
379 Second, a Consumer would subscribe as follows:
381
385
386
388
389
391 Unless an error occurs (see [XEP-0060] for various error flows), the
392 Broker responds with success:
394
398
399
403
404
406 Third, a Provider would publish an incident as follows:
408
412
413
414 -
415
421
422 492382
423 2015-07-18T09:00:00-05:00
424
425
426 contact@csirt.example.com
427
428
429
430
431
432
433
434
436 (The payload in the foregoing example is from [RFC7970]; payloads for
437 additional use cases can be found in [RFC8274].)
439 The Broker would then deliver that incident report to all Consumers
440 who are subscribe to the Topic:
442
446
447
448 -
449
455
456 492382
457 2015-07-18T09:00:00-05:00
458
459
460 contact@csirt.example.com
461
462
463
464
465
466
467
468
470 7. IANA Considerations
472 This document has no actions for IANA.
474 8. Security Considerations
476 An XMPP-Grid Controller serves as an controlling broker for XMPP-Grid
477 Platforms such as Enforcement Points, Policy Servers, CMDBs, and
478 Sensors, using a publish-subscribe-search model of information
479 exchange and lookup. By increasing the ability of XMPP-Grid
480 Platforms to learn about and respond to security-relevant events and
481 data, XMPP-Grid can improve the timeliness and utility of the
482 security system. However, this integrated security system can also
483 be exploited by attackers if they can compromise it. Therefore,
484 strong security protections for XMPP-Grid are essential.
486 This section provides a security analysis of the XMPP-Grid data
487 transfer protocol and the architectural elements that employ it,
488 specifically with respect to their use of this protocol. Three
489 subsections define the trust model (which elements are trusted to do
490 what), the threat model (attacks that can be mounted on the system),
491 and the countermeasures (ways to address or mitigate the threats
492 previously identified).
494 8.1. Trust Model
496 The first step in analyzing the security of the XMPP-Grid transport
497 protocol is to describe the trust model, listing what each
498 architectural element is trusted to do. The items listed here are
499 assumptions, but provisions are made in the Threat Model and
500 Countermeasures sections for elements that fail to perform as they
501 were trusted to do.
503 8.1.1. Network
505 The network used to carry XMPP-Grid messages (i.e., the underlying
506 network transport layer over which XMPP runs) is trusted to:
508 o Perform best effort delivery of network traffic
510 The network used to carry XMPP-Grid messages is not expected
511 (trusted) to:
513 o Provide confidentiality or integrity protection for messages sent
514 over it
516 o Provide timely or reliable service
518 8.1.2. XMPP-Grid Platforms
520 Authorized XMPP-Grid Platforms are trusted to:
522 o Preserve the confidentiality of sensitive data retrieved via the
523 XMPP-Grid Controller
525 8.1.3. XMPP-Grid Controller
527 The XMPP-Grid Controller (including its associated Broker) is trusted
528 to:
530 o Broker requests for data and enforce authorization of access to
531 this data throughout its lifecycle
533 o Perform service requests in a timely and accurate manner
535 o Create and maintain accurate operational attributes
536 o Only reveal data to and accept service requests from authorized
537 parties
539 The XMPP-Grid Controller is not expected (trusted) to:
541 o Verify the truth (correctness) of data
543 8.1.4. Certification Authority
545 The Certification Authority (CA) that issues certificates for the
546 XMPP-Grid Controller and/or XMPP-Grid Platforms (or each CA, if there
547 are several) is trusted to:
549 o Ensure that only proper certificates are issued and that all
550 certificates are issued in accordance with the CA's policies
552 o Revoke certificates previously issued when necessary
554 o Regularly and securely distribute certificate revocation
555 information
557 o Promptly detect and report any violations of this trust so that
558 they can be handled
560 The CA is not expected (trusted) to:
562 o Issue certificates that go beyond the XMPP-Grid needs or other
563 constraints imposed by a relying party.
565 8.2. Threat Model
567 To secure the XMPP-Grid data transfer protocol and the architectural
568 elements that implement it, this section identifies the attacks that
569 can be mounted against the protocol and elements.
571 8.2.1. Network Attacks
573 A variety of attacks can be mounted using the network. For the
574 purposes of this subsection the phrase "network traffic" can be taken
575 to mean messages and/or parts of messages. Any of these attacks can
576 be mounted by network elements, by parties who control network
577 elements, and (in many cases) by parties who control network-attached
578 devices.
580 o Network traffic can be passively monitored to glean information
581 from any unencrypted traffic
583 o Even if all traffic is encrypted, valuable information can be
584 gained by traffic analysis (volume, timing, source and destination
585 addresses, etc.)
587 o Network traffic can be modified in transit
589 o Previously transmitted network traffic can be replayed
591 o New network traffic can be added
593 o Network traffic can be blocked, perhaps selectively
595 o A "Man In The Middle" (MITM) attack can be mounted where an
596 attacker interposes itself between two communicating parties and
597 poses as the other end to either party or impersonates the other
598 end to either or both parties
600 o Resist attacks (including denial of service and other attacks from
601 XMPP-Grid Platforms)
603 o Undesired network traffic can be sent in an effort to overload an
604 architectural component, thus mounting a denial of service attack
606 8.2.2. XMPP-Grid Platforms
608 An unauthorized XMPP-Grid Platform (one which is not recognized by
609 the XMPP-Grid Controller or is recognized but not authorized to
610 perform any actions) cannot mount any attacks other than those listed
611 in the Network Attacks section above.
613 An authorized XMPP-Grid Platform, on the other hand, can mount many
614 attacks. These attacks might occur because the XMPP-Grid Platform is
615 controlled by a malicious, careless, or incompetent party (whether
616 because its owner is malicious, careless, or incompetent or because
617 the XMPP-Grid Platform has been compromised and is now controlled by
618 a party other than its owner). They might also occur because the
619 XMPP-Grid Platform is running malicious software; because the XMPP-
620 Grid Platform is running buggy software (which can fail in a state
621 that floods the network with traffic); or because the XMPP-Grid
622 Platform has been configured improperly. From a security standpoint,
623 it generally makes no difference why an attack is initiated. The
624 same countermeasures can be employed in any case.
626 Here is a list of attacks that can be mounted by an authorized XMPP-
627 Grid Platform:
629 o Cause many false alarms or otherwise overload the XMPP-Grid
630 Controller or other elements in the network security system
631 (including human administrators) leading to a denial of service or
632 disabling parts of the network security system
634 o Omit important actions (such as posting incriminating data),
635 resulting in incorrect access
637 o Use confidential information obtained from the XMPP-Grid
638 Controller to enable further attacks (such as using endpoint
639 health check results to exploit vulnerable endpoints)
641 o Advertise data crafted to exploit vulnerabilities in the XMPP-Grid
642 Controller or in other XMPP-Grid Platforms, with a goal of
643 compromising those systems
645 o Issue a search request or set up a subscription that matches an
646 enormous result, leading to resource exhaustion on the XMPP-Grid
647 Controller, the publishing XMPP-Grid Platform, and/or the network
649 o Establish a communication channel using another XMPP-Grid
650 Platform's session-id
652 Dependencies of or vulnerabilities of authorized XMPP-Grid Platforms
653 can be exploited to effect these attacks. Another way to effect
654 these attacks is to gain the ability to impersonate an XMPP-Grid
655 Platform (through theft of the XMPP-Grid Platform's identity
656 credentials or through other means). Even a clock skew between the
657 XMPP-Grid Platform and XMPP-Grid Controller can cause problems if the
658 XMPP-Grid Platform assumes that old XMPP-Grid Platform data deserves
659 to be ignored.
661 8.2.3. XMPP-Grid Controllers
663 An unauthorized XMPP-Grid Controller (one which is not trusted by
664 XMPP-Grid Platforms) cannot mount any attacks other than those listed
665 in the Network Attacks section above.
667 An authorized XMPP-Grid Controller can mount many attacks. Similar
668 to the XMPP-Grid Platform case described above, these attacks might
669 occur because the XMPP-Grid Controller is controlled by a malicious,
670 careless, or incompetent party (either an XMPP-Grid Controller
671 administrator or an attacker who has seized control of the XMPP-Grid
672 Controller). They might also occur because the XMPP-Grid Controller
673 is running malicious software, because the XMPP-Grid Controller is
674 running buggy software (which can fail in a state that corrupts data
675 or floods the network with traffic), or because the XMPP-Grid
676 Controller has been configured improperly.
678 All of the attacks listed for XMPP-Grid Platform above can be mounted
679 by the XMPP-Grid Controller. Detection of these attacks will be more
680 difficult since the XMPP-Grid Controller can create false operational
681 attributes and/or logs that imply some other party created any bad
682 data.
684 Additional XMPP-Grid Controller attacks can include:
686 o Expose different data to different XMPP-Grid Platforms to mislead
687 investigators or cause inconsistent behavior
689 o Mount an even more effective denial of service attack than a
690 single XMPP-Grid Platform could
692 o Obtain and cache XMPP-Grid Platform credentials so they can be
693 used to impersonate XMPP-Grid Platforms even after a breach of the
694 XMPP-Grid Controller is repaired
696 o Obtain and cache XMPP-Grid Controller administrator credentials so
697 they can be used to regain control of the XMPP-Grid Controller
698 after the breach of the XMPP-Grid Controller is repaired
700 Dependencies of or vulnerabilities of the XMPP-Grid Controller can be
701 exploited to obtain control of the XMPP-Grid Controller and effect
702 these attacks.
704 8.2.4. Certification Authority
706 A Certification Authority trusted to issue certificates for the XMPP-
707 Grid Controller and/or XMPP-Grid Platforms can mount several attacks:
709 o Issue certificates for unauthorized parties, enabling them to
710 impersonate authorized parties such as the XMPP-Grid Controller or
711 an XMPP-Grid Platform. This can lead to all the threats that can
712 be mounted by the certificate's subject.
714 o Issue certificates without following all of the CA's policies.
715 Because this can result in issuing certificates that can be used
716 to impersonate authorized parties, this can lead to all the
717 threats that can be mounted by the certificate's subject.
719 o Fail to revoke previously issued certificates that need to be
720 revoked. This can lead to undetected impersonation of the
721 certificate's subject or failure to revoke authorization of the
722 subject, and therefore can lead to all of the threats that can be
723 mounted by that subject.
725 o Fail to regularly and securely distribute certificate revocation
726 information. This can cause a relying party to accept a revoked
727 certificate, leading to undetected impersonation of the
728 certificate's subject or failure to revoke authorization of the
729 subject, and therefore can lead to all of the threats that can be
730 mounted by that subject. It can also cause a relying party to
731 refuse to proceed with a transaction because timely revocation
732 information is not available, even though the transaction should
733 be permitted to proceed.
735 o Allow the CA's private key to be revealed to an unauthorized
736 party. This can lead to all the threats above. Even worse, the
737 actions taken with the private key will not be known to the CA.
739 o Fail to promptly detect and report errors and violations of trust
740 so that relying parties can be promptly notified. This can cause
741 the threats listed earlier in this section to persist longer than
742 necessary, leading to many knock-on effects.
744 8.3. Countermeasures
746 Below are countermeasures for specific attack scenarios to the XMPP-
747 Grid infrastructure.
749 8.3.1. Securing the XMPP-Grid Data Transfer Protocol
751 To address network attacks, the XMPP-Grid data transfer protocol
752 described in this document requires that the XMPP-Grid messages MUST
753 be carried over TLS (minimally TLS 1.2 [RFC5246]) as described in
754 [RFC6120] and updated by [RFC7590]. The XMPP-Grid Platform MUST
755 verify the XMPP-Grid Controller's certificate and determine whether
756 the XMPP-Grid Controller is trusted by this XMPP-Grid Platform before
757 completing the TLS handshake. The XMPP-Grid Controller MUST
758 authenticate the XMPP-Grid Platform either using the SASL EXTERNAL
759 mechanism or using the SASL SCRAM mechanism (with the SCRAM-SHA-
760 256-PLUS variant being preferred over the SCRAM-SHA-256 variant and
761 SHA-256 variants [RFC7677] being preferred over SHA-1 varients
762 [RFC5802]). XMPP-Grid Platforms and XMPP-Grid Controllers using
763 mutual certificate-based authentication SHOULD each verify the
764 revocation status of the other party's certificate. All XMPP-Grid
765 Controllers and XMPP-Grid Platforms MUST implement both SASL EXTERNAL
766 and SASL SCRAM. The selection of which XMPP-Grid Platform
767 authentication technique to use in any particular deployment is left
768 to the administrator.
770 These protocol security measures provide protection against all the
771 network attacks listed in the above document section except denial of
772 service attacks. If protection against these denial of service
773 attacks is desired, ingress filtering, rate limiting per source IP
774 address, and other denial of service mitigation measures can be
775 employed. In addition, an XMPP-Grid Controller MAY automatically
776 disable a misbehaving XMPP-Grid Platform.
778 8.3.2. Securing XMPP-Grid Platforms
780 XMPP-Grid Platforms can be deployed in locations that are susceptible
781 to physical attacks. Physical security measures can be taken to
782 avoid compromise of XMPP-Grid Platforms, but these are not always
783 practical or completely effective. An alternative measure is to
784 configure the XMPP-Grid Controller to provide read-only access for
785 such systems. The XMPP-Grid Controller SHOULD also include a full
786 authorization model so that individual XMPP-Grid Platforms can be
787 configured to have only the privileges that they need. The XMPP-Grid
788 Controller MAY provide functional templates so that the administrator
789 can configure a specific XMPP-Grid Platform as a DHCP server and
790 authorize only the operations and metadata types needed by a DHCP
791 server to be permitted for that XMPP-Grid Platform. These techniques
792 can reduce the negative impacts of a compromised XMPP-Grid Platform
793 without diminishing the utility of the overall system.
795 To handle attacks within the bounds of this authorization model, the
796 XMPP-Grid Controller MAY also include rate limits and alerts for
797 unusual XMPP-Grid Platform behavior. XMPP-Grid Controllers SHOULD
798 make it easy to revoke an XMPP-Grid Platform's authorization when
799 necessary. Another way to detect attacks from XMPP-Grid Platforms is
800 to create fake entries in the available data (honeytokens) which
801 normal XMPP-Grid Platforms will not attempt to access. The XMPP-Grid
802 Controller SHOULD include auditable logs of XMPP-Grid Platform
803 activities.
805 To avoid compromise of XMPP-Grid Platform, XMPP-Grid Platform SHOULD
806 be hardened against attack and minimized to reduce their attack
807 surface. They should be well managed to minimize vulnerabilities in
808 the underlying platform and in systems upon which the XMPP-Grid
809 Platform depends. Personnel with administrative access should be
810 carefully screened and monitored to detect problems as soon as
811 possible.
813 8.3.3. Securing XMPP-Grid Controllers
815 Because of the serious consequences of XMPP-Grid Controller
816 compromise, XMPP-Grid Controllers need to be especially well hardened
817 against attack and minimized to reduce their attack surface. They
818 need to be well managed to minimize vulnerabilities in the underlying
819 platform and in systems upon which the XMPP-Grid Controller depends.
820 Network security measures such as firewalls or intrusion detection
821 systems can be used to monitor and limit traffic to and from the
822 XMPP-Grid Controller. Personnel with administrative access ought to
823 be carefully screened and monitored to detect problems as soon as
824 possible. Administrators SHOULD NOT use password-based
825 authentication but should instead use non-reusable credentials and
826 multi-factor authentication (where available). Physical security
827 measures ought to be employed to prevent physical attacks on XMPP-
828 Grid Controllers.
830 To ease detection of XMPP-Grid Controller compromise should it occur,
831 XMPP-Grid Controller behavior should be monitored to detect unusual
832 behavior (such as a reboot, a large increase in traffic, or different
833 views of an information repository for similar XMPP-Grid Platforms).
834 XMPP-Grid Platforms should log and/or notify administrators when
835 peculiar XMPP-Grid Controller behavior is detected. To aid forensic
836 investigation, permanent read-only audit logs of security-relevant
837 information (especially administrative actions) should be maintained.
838 If XMPP-Grid Controller compromise is detected, a careful analysis
839 should be performed of the impact of this compromise. Any reusable
840 credentials that can have been compromised should be reissued.
842 8.3.4. Broker Access Models for Topics
844 The XMPP publish-subscribe specification [XEP-0060] defines five
845 access models for subscribing to Topics at a Broker: open, presence,
846 roster, authorize, and whitelist. The first model allows
847 uncontrolled access and the next two models are appropriate only in
848 instant-messaging applications. Therefore, a Broker SHOULD support
849 only the authorize model (under which the Topic owner needs to
850 approve all subscription requests and only subscribers can retrieve
851 data items) and the whitelist model (under which only preconfigured
852 Platforms can subscribe or retrieve data items). In order to ease
853 the deployment burden, subscription approvals and whitelist
854 management can be automated (e.g, the Topic "owner" can be a policy
855 server). The choice between "authorize" and "whitelist" as the
856 default access model is a matter for local service policy.
858 8.3.5. Limit on Search Result Size
860 While XMPP-Grid is designed for high scalability to 100,000s of
861 Platforms, an XMPP-Grid Controller MAY establish a limit to the
862 amount of data it is willing to return in search or subscription
863 results. This mitigates the threat of an XMPP-Grid Platform causing
864 resource exhaustion by issuing a search or subscription that leads to
865 an enormous result.
867 8.3.6. Securing the Certification Authority
869 As noted above, compromise of a Certification Authority (CA) trusted
870 to issue certificates for the XMPP-Grid Controller and/or XMPP-Grid
871 Platforms is a major security breach. Many guidelines for proper CA
872 security have been developed: the CA/Browser Forum's Baseline
873 Requirements, the AICPA/CICA Trust Service Principles, etc. The CA
874 operator and relying parties should agree on an appropriately
875 rigorous security practices to be used.
877 Even with the most rigorous security practices, a CA can be
878 compromised. If this compromise is detected quickly, relying parties
879 can remove the CA from their list of trusted CAs, and other CAs can
880 revoke any certificates issued to the CA. However, CA compromise may
881 go undetected for some time, and there's always the possibility that
882 a CA is being operated improperly or in a manner that is not in the
883 interests of the relying parties. For this reason, relying parties
884 may wish to "pin" a small number of particularly critical
885 certificates (such as the certificate for the XMPP-Grid Controller).
886 Once a certificate has been pinned, the relying party will not accept
887 another certificate in its place unless the Administrator explicitly
888 commands it to do so. This does not mean that the relying party will
889 not check the revocation status of pinned certificates. However, the
890 Administrator can still be consulted if a pinned certificate is
891 revoked, since the CA and revocation process are not completely
892 trusted.
894 8.4. Summary
896 XMPP-Grid's considerable value as a broker for security-sensitive
897 data exchange distribution also makes the protocol and the network
898 security elements that implement it a target for attack. Therefore,
899 strong security has been included as a basic design principle within
900 the XMPP-Grid design process.
902 The XMPP-Grid data transfer protocol provides strong protection
903 against a variety of different attacks. In the event that an XMPP-
904 Grid Platform or XMPP-Grid Controller is compromised, the effects of
905 this compromise have been reduced and limited with the recommended
906 role-based authorization model and other provisions, and best
907 practices for managing and protecting XMPP-Grid systems have been
908 described. Taken together, these measures should provide protection
909 commensurate with the threat to XMPP-Grid systems, thus ensuring that
910 they fulfill their promise as a network security clearing-house.
912 9. Privacy Considerations
914 XMPP-Grid Platforms can publish information about endpoint health,
915 network access, events (which can include information about what
916 services an endpoint is accessing), roles and capabilities, and the
917 identity of the end user operating the endpoint. Any of this
918 published information can be queried by other XMPP-Grid Platforms and
919 could potentially be used to correlate network activity to a
920 particular end user.
922 Dynamic and static information brokered by an XMPP-Grid Controller,
923 ostensibly for purposes of correlation by XMPP-Grid Platforms for
924 intrusion detection, could be misused by a broader set of XMPP-Grid
925 Platforms which hitherto have been performing specific roles with
926 strict well-defined separation of duties.
928 Care needs to be taken by deployers of XMPP-Grid to ensure that the
929 information published by XMPP-Grid Platforms does not violate
930 agreements with end users or local and regional laws and regulations.
931 This can be accomplished either by configuring XMPP-Grid Platforms to
932 not publish certain information or by restricting access to sensitive
933 data to trusted XMPP-Grid Platforms. That is, the easiest means to
934 ensure privacy or protect sensitive data, is to omit or not share it
935 at all.
937 Another consideration for deployers is to enable end-to-end
938 encryption to ensure the data is protected from the data layer to
939 data layer and thus protect it from the transport layer.
941 10. Acknowledgements
943 The authors would like to acknowledge the contributions, authoring
944 and/or editing of the following people: Joseph Salowey, Lisa
945 Lorenzin, Clifford Kahn, Henk Birkholz, Jessica Fitzgerald-McKay,
946 Steve Hanna, and Steve Venema. In addition, we want to thank Takeshi
947 Takahashi, Panos Kampanakis, Adam Montville, Chris Inacio, and Dave
948 Cridland for reviewing and providing valuable comments.
950 11. References
952 11.1. Normative References
954 [I-D.ietf-sacm-terminology]
955 Birkholz, H., Lu, J., Strassner, J., and N. Cam-Winget,
956 "Secure Automation and Continuous Monitoring (SACM)
957 Terminology", draft-ietf-sacm-terminology-14 (work in
958 progress), December 2017.
960 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
961 Requirement Levels", BCP 14, RFC 2119,
962 DOI 10.17487/RFC2119, March 1997, .
965 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
966 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
967 March 2011, .
969 [RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer
970 Security (TLS) in the Extensible Messaging and Presence
971 Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June
972 2015, .
974 [RFC7677] Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple
975 Authentication and Security Layer (SASL) Mechanisms",
976 RFC 7677, DOI 10.17487/RFC7677, November 2015,
977 .
979 [XEP-0004]
980 Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and
981 P. Saint-Andre, "Data Forms", XSF XEP 0004, August 2007.
983 [XEP-0030]
984 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint-
985 Andre, "Service Discovery", XSF XEP 0030, July 2010.
987 [XEP-0060]
988 Millard, P., Saint-Andre, P., and R. Meijer, "Publish-
989 Subscribe", XSF XEP 0060, December 2017.
991 11.2. Informative References
993 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
994 (TLS) Protocol Version 1.2", RFC 5246,
995 DOI 10.17487/RFC5246, August 2008, .
998 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
999 "Salted Challenge Response Authentication Mechanism
1000 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802,
1001 DOI 10.17487/RFC5802, July 2010, .
1004 [RFC7970] Danyliw, R., "The Incident Object Description Exchange
1005 Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
1006 November 2016, .
1008 [RFC8274] Kampanakis, P. and M. Suzuki, "Incident Object Description
1009 Exchange Format Usage Guidance", RFC 8274,
1010 DOI 10.17487/RFC8274, November 2017, .
1013 Authors' Addresses
1015 Nancy Cam-Winget (editor)
1016 Cisco Systems
1017 3550 Cisco Way
1018 San Jose, CA 95134
1019 USA
1021 Email: ncamwing@cisco.com
1023 Syam Appala
1024 Cisco Systems
1025 3550 Cisco Way
1026 San Jose, CA 95134
1027 USA
1029 Email: syam1@cisco.com
1031 Scott Pope
1032 Cisco Systems
1033 5400 Meadows Road
1034 Suite 300
1035 Lake Oswego, OR 97035
1036 USA
1038 Email: scottp@cisco.com
1040 Peter Saint-Andre
1041 Mozilla
1043 Email: stpeter@mozilla.com