idnits 2.17.1
draft-ietf-mile-xmpp-grid-06.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 (June 26, 2018) is 2124 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: December 28, 2018 Cisco Systems
6 P. Saint-Andre
7 Mozilla
8 June 26, 2018
10 Using XMPP for Security Information Exchange
11 draft-ietf-mile-xmpp-grid-06
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 December 28, 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 (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 . . . . . . . . . . . . . . . . . . . 21
68 10. Operations and Management Considerations . . . . . . . . . . 21
69 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
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].
89 2. Terminology
91 This document uses XMPP terminology defined in [RFC6120] and
92 [XEP-0060] as well as Security Automation and Continuous Monitoring
93 (SACM) terminology defined in [I-D.ietf-sacm-terminology]. Because
94 the intended audience for this document is those who implement and
95 deploy security reporting systems, in general the SACM terms are used
96 (however, mappings are provided for the benefit of XMPP developers
97 and operators).
99 Broker: In SACM, a specific type of controller containing control
100 plane functions; as used here, the term refers to an XMPP publish-
101 subscribe service.
103 Broker Flow: In SACM, a method by which security-related information
104 is published and consumed in a mediated fashion through a Broker.
105 In 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: In SACM, an entity that contains functions to receive
110 information from other components; as used here, the term refers
111 to an XMPP publish-subscribe Subscriber.
113 Controller: In SACM, a "component containing control plane functions
114 that manage and facilitate information sharing or execute on
115 security functions"; as used here, the term refers to an XMPP
116 server, which provides core message delivery [RFC6120] used by
117 publish-subscribe 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: In SACM, an entity that contains functions to provide
125 information to other components; as used here, the term refers to
126 an XMPP publish-subscribe Publisher.
128 Publisher: The XMPP term for a Provider.
130 Publish-Subscribe Service: The XMPP term for the kind Broker
131 discussed here.
133 Subscriber: The XMPP term for a Consumer.
135 Topic: A contextual information channel created on a Broker at which
136 messages generated by a Provider are propagated in real time to
137 one or more Consumers. Each Topic is limited to a specific type
138 and format of security data (e.g., IODEF) and provides an XMPP
139 interface by which the data can be obtained.
141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
143 document are to be interpreted as described in [RFC2119].
145 3. Architecture
147 The following figure illustrates the architecture of XMPP-Grid.
149 +--------------------------------------+
150 | +--------------------------------------+
151 | | +--------------------------------------+
152 | | | |
153 +-| | Platforms |
154 +-| |
155 +--------------------------------------+
156 / \ / \ / \
157 / C \ / \ / \
158 - o - - d - - -
159 ||n||A | a |B | |C
160 ||t|| | t | | |
161 - r - - a - | |
162 \ o / \ / | |
163 \ l / \ / | |
164 /|---------------------|\ | |
165 /|----/ \--------| d |--|\
166 / / Controller \ ctrl | a | \
167 \ \ & Broker / plane | t | /
168 \|----\ /--------| a |--|/
169 \|---------------------|/ | |
170 / \ / \ | |
171 / C \ / \ | |
172 - o - - d - | |
173 ||n||A | a |B | |C
174 ||t|| | t | | |
175 - r - - a - - -
176 \ o / \ / \ /
177 \ l / \ / \ /
178 +------------------------------------+
179 | |-+
180 | Platforms | |
181 | | |-+
182 +------------------------------------+ | |
183 +------------------------------------+ |
184 +------------------------------------+
186 Figure 1: XMPP-Grid Architecture
188 Platforms connect to the Controller (XMPP server) to authenticate and
189 then establish appropriate authorizations and relationships (e.g.,
190 Provider or Consumer) at the Broker. The control plane messaging is
191 established through XMPP and shown as "A" (control plane interface)
192 in Figure 1. Authorized nodes can then share data either thru the
193 Broker (shown as "B" in Figure 1) or in some cases directly (shown as
194 "C" in Figure 1). This document focuses primarily on the Broker Flow
195 for information sharing ("direct flow" interactions can be used for
196 specialized purposes such as bulk data transfer, but methods for
197 doing so are outside the scope of this document).
199 4. Workflow
201 A typical XMPP-Grid workflow is as follows:
203 a. A Platform with a source of security data requests connection to
204 the XMPP-Grid via a Controller (XMPP server).
206 b. The Controller authenticates the Platform.
208 c. The Platform establishes authorized privileges (e.g. privilege to
209 publish and/or subscribe to security data Topics) with a Broker.
211 d. The Platform can publish security-related data to a Topic,
212 subscribe to a Topic, query a Topic, or any combination of these
213 operations.
215 e. A Provider unicasts its Topic updates to the Grid in real time
216 through a Broker. The Broker handles replication and
217 distribution of the Topic to Consumers. A Provider can publish
218 the same or different data to multiple Topics.
220 f. Any Platform on the Grid can subscribe to any Topics published to
221 the Grid (as permitted by authorization policy), and as Consumers
222 will then receive a continual, real-time stream of updates from
223 the Topics to which it is subscribed.
225 The general workflow is summarized in the figure below:
227 +--------------+ +------------+ +---------------+
228 | IODEF Client | | Controller | | IODEF Service |
229 | (Consumer) | | & Broker | | (Provider) |
230 +--------------+ +------------+ +---------------+
231 | | |
232 | Establish XMPP | |
233 | Client Session | |
234 | (RFC 6120) | |
235 |--------------------->| |
236 | | Establish XMPP |
237 | | Client Session |
238 | | (RFC 6120) |
239 | |<------------------------|
240 | | Request Topic Creation |
241 | | (XEP-0060) |
242 | |<------------------------|
243 | | Topic Creation Success |
244 | | (XEP-0060) |
245 | |------------------------>|
246 | Request Topic List | |
247 | (XEP-0030) | |
248 |--------------------->| |
249 | Return Topic List | |
250 | (XEP-0030) | |
251 |<---------------------| |
252 | | |
253 | Query Each Topic | |
254 | (XEP-0030) | |
255 |--------------------->| |
256 | Return Topic Data | |
257 | Including Topic Type | |
258 | (XEP-0030) | |
259 |<---------------------| |
260 | | |
261 | Subscribe to IODEF | |
262 | Topic (XEP-0060) | |
263 |--------------------->| |
264 | Subscription Success | |
265 | (XEP-0060) | |
266 |<---------------------| |
267 | | Publish IODEF Incident |
268 | | (XEP-0060) |
269 | Receive IODEF |<------------------------|
270 | Incident (XEP-0060) | |
271 |<---------------------| |
272 | | |
274 Figure 2: IODEF Example Workflow
276 XMPP-Grid implementations MUST adhere to the mandatory-to-implement
277 and mandatory-to-negotiate features as defined in [RFC6120].
278 Similarly, implementations MUST implement [XEP-0060] to facilitate
279 the asynchronous sharing for information. The Service Discovery per
280 [XEP-0030] SHOULD be implemented to facilitate the means to
281 dynamically discover the available information (Topics) to be
282 published or consumes.
284 The following sections provide protocol examples for the service
285 discovery and publish-subscribe parts of the workflow.
287 5. Service Discovery
289 Using the XMPP service discovery extension [XEP-0030], a Controller
290 enables Platforms to discover what information can be consumed
291 through the Broker, and at which Topics. As an example, the
292 Controller at 'security-grid.example' might provide a Broker at
293 'broker.security-grid.example' hosting a number of Topics. A
294 Platform at 'xmpp-grid-client@mile-host.example' would query the
295 Broker about its available Topics by sending an XMPP "disco#items"
296 request to the Broker:
298
302
303
305 The Broker responds with the Topics it hosts:
307
311
312
315
318
319
321 In order to determine the exact nature of each Topic (i.e., in order
322 to find topics that publish incidents in the IODEF format), a
323 Platform would send an XMPP "disco#info" request to each Topic:
325
331
333 The Broker responds with the "disco#info" description, which SHOULD
334 include an XMPP Data Form [XEP-0004] including a 'pubsub#type' field
335 that specifies the supported namespace (in this example, the IODEF
336 namespace defined in [RFC7970]):
338
342
344
345
346
347
348 http://jabber.org/protocol/pubsub#meta-data
349
350
351 urn:ietf:params:xml:ns:iodef-2.0
352
353
354
355
357 6. Publish-Subscribe
359 Using the XMPP publish-subscribe extension [XEP-0030], a Consumer
360 subscribes to a Topic and a Provider publishes information to that
361 Topic, which the Broker then distributes to all subscribed Consumers.
363 First, a Provider would create a Topic as follows:
365
369
370
371
372
373 Note: The foregoing example is the minimal protocol needed to create
374 a Topic with the default node configuration on the XMPP publish-
375 subscribe service specified in the 'to' address of the creation
376 request stanza. Depending on security requirements, the Provider
377 might need to request a non-default configuration for the node; see
378 [XEP-0060] for detailed examples.
380 Unless an error occurs (see [XEP-0060] for various error flows), the
381 Broker responds with success:
383
388 Second, a Consumer would subscribe as follows:
390
394
395
397
398
400 Unless an error occurs (see [XEP-0060] for various error flows), the
401 Broker responds with success:
403
407
408
412
413
415 Third, a Provider would publish an incident as follows:
417
421
422
423 -
424
430
431 492382
432 2015-07-18T09:00:00-05:00
433
434
435 contact@csirt.example.com
436
437
438
439
440
441
442
443
445 (The payload in the foregoing example is from [RFC7970]; payloads for
446 additional use cases can be found in [RFC8274].)
448 The Broker would then deliver that incident report to all Consumers
449 who are subscribe to the Topic:
451
455
456
457 -
458
464
465 492382
466 2015-07-18T09:00:00-05:00
467
468
469 contact@csirt.example.com
470
471
472
473
474
475
476
477
479 7. IANA Considerations
481 This document has no actions for IANA.
483 8. Security Considerations
485 An XMPP-Grid Controller serves as an controlling broker for XMPP-Grid
486 Platforms such as Enforcement Points, Policy Servers, CMDBs, and
487 Sensors, using a publish-subscribe-search model of information
488 exchange and lookup. By increasing the ability of XMPP-Grid
489 Platforms to learn about and respond to security-relevant events and
490 data, XMPP-Grid can improve the timeliness and utility of the
491 security system. However, this integrated security system can also
492 be exploited by attackers if they can compromise it. Therefore,
493 strong security protections for XMPP-Grid are essential.
495 This section provides a security analysis of the XMPP-Grid data
496 transfer protocol and the architectural elements that employ it,
497 specifically with respect to their use of this protocol. Three
498 subsections define the trust model (which elements are trusted to do
499 what), the threat model (attacks that can be mounted on the system),
500 and the countermeasures (ways to address or mitigate the threats
501 previously identified).
503 8.1. Trust Model
505 The first step in analyzing the security of the XMPP-Grid transport
506 protocol is to describe the trust model, listing what each
507 architectural element is trusted to do. The items listed here are
508 assumptions, but provisions are made in the Threat Model and
509 Countermeasures sections for elements that fail to perform as they
510 were trusted to do.
512 8.1.1. Network
514 The network used to carry XMPP-Grid messages (i.e., the underlying
515 network transport layer over which XMPP runs) is trusted to:
517 o Perform best effort delivery of network traffic
519 The network used to carry XMPP-Grid messages is not expected
520 (trusted) to:
522 o Provide confidentiality or integrity protection for messages sent
523 over it
525 o Provide timely or reliable service
527 8.1.2. XMPP-Grid Platforms
529 Authorized XMPP-Grid Platforms are trusted to:
531 o Preserve the confidentiality of sensitive data retrieved via the
532 XMPP-Grid Controller
534 8.1.3. XMPP-Grid Controller
536 The XMPP-Grid Controller (including its associated Broker) is trusted
537 to:
539 o Broker requests for data and enforce authorization of access to
540 this data throughout its lifecycle
542 o Perform service requests in a timely and accurate manner
544 o Create and maintain accurate operational attributes
545 o Only reveal data to and accept service requests from authorized
546 parties
548 The XMPP-Grid Controller is not expected (trusted) to:
550 o Verify the truth (correctness) of data
552 8.1.4. Certification Authority
554 The Certification Authority (CA) that issues certificates for the
555 XMPP-Grid Controller and/or XMPP-Grid Platforms (or each CA, if there
556 are several) is trusted to:
558 o Ensure that only proper certificates are issued and that all
559 certificates are issued in accordance with the CA's policies
561 o Revoke certificates previously issued when necessary
563 o Regularly and securely distribute certificate revocation
564 information
566 o Promptly detect and report any violations of this trust so that
567 they can be handled
569 The CA is not expected (trusted) to:
571 o Issue certificates that go beyond the XMPP-Grid needs or other
572 constraints imposed by a relying party.
574 8.2. Threat Model
576 To secure the XMPP-Grid data transfer protocol and the architectural
577 elements that implement it, this section identifies the attacks that
578 can be mounted against the protocol and elements.
580 8.2.1. Network Attacks
582 A variety of attacks can be mounted using the network. For the
583 purposes of this subsection the phrase "network traffic" can be taken
584 to mean messages and/or parts of messages. Any of these attacks can
585 be mounted by network elements, by parties who control network
586 elements, and (in many cases) by parties who control network-attached
587 devices.
589 o Network traffic can be passively monitored to glean information
590 from any unencrypted traffic
592 o Even if all traffic is encrypted, valuable information can be
593 gained by traffic analysis (volume, timing, source and destination
594 addresses, etc.)
596 o Network traffic can be modified in transit
598 o Previously transmitted network traffic can be replayed
600 o New network traffic can be added
602 o Network traffic can be blocked, perhaps selectively
604 o A "Man In The Middle" (MITM) attack can be mounted where an
605 attacker interposes itself between two communicating parties and
606 poses as the other end to either party or impersonates the other
607 end to either or both parties
609 o Resist attacks (including denial of service and other attacks from
610 XMPP-Grid Platforms)
612 o Undesired network traffic can be sent in an effort to overload an
613 architectural component, thus mounting a denial of service attack
615 8.2.2. XMPP-Grid Platforms
617 An unauthorized XMPP-Grid Platform (one which is not recognized by
618 the XMPP-Grid Controller or is recognized but not authorized to
619 perform any actions) cannot mount any attacks other than those listed
620 in the Network Attacks section above.
622 An authorized XMPP-Grid Platform, on the other hand, can mount many
623 attacks. These attacks might occur because the XMPP-Grid Platform is
624 controlled by a malicious, careless, or incompetent party (whether
625 because its owner is malicious, careless, or incompetent or because
626 the XMPP-Grid Platform has been compromised and is now controlled by
627 a party other than its owner). They might also occur because the
628 XMPP-Grid Platform is running malicious software; because the XMPP-
629 Grid Platform is running buggy software (which can fail in a state
630 that floods the network with traffic); or because the XMPP-Grid
631 Platform has been configured improperly. From a security standpoint,
632 it generally makes no difference why an attack is initiated. The
633 same countermeasures can be employed in any case.
635 Here is a list of attacks that can be mounted by an authorized XMPP-
636 Grid Platform:
638 o Cause many false alarms or otherwise overload the XMPP-Grid
639 Controller or other elements in the network security system
640 (including human administrators) leading to a denial of service or
641 disabling parts of the network security system
643 o Omit important actions (such as posting incriminating data),
644 resulting in incorrect access
646 o Use confidential information obtained from the XMPP-Grid
647 Controller to enable further attacks (such as using endpoint
648 health check results to exploit vulnerable endpoints)
650 o Advertise data crafted to exploit vulnerabilities in the XMPP-Grid
651 Controller or in other XMPP-Grid Platforms, with a goal of
652 compromising those systems
654 o Issue a search request or set up a subscription that matches an
655 enormous result, leading to resource exhaustion on the XMPP-Grid
656 Controller, the publishing XMPP-Grid Platform, and/or the network
658 o Establish a communication channel using another XMPP-Grid
659 Platform's session-id
661 Dependencies of or vulnerabilities of authorized XMPP-Grid Platforms
662 can be exploited to effect these attacks. Another way to effect
663 these attacks is to gain the ability to impersonate an XMPP-Grid
664 Platform (through theft of the XMPP-Grid Platform's identity
665 credentials or through other means). Even a clock skew between the
666 XMPP-Grid Platform and XMPP-Grid Controller can cause problems if the
667 XMPP-Grid Platform assumes that old XMPP-Grid Platform data deserves
668 to be ignored.
670 8.2.3. XMPP-Grid Controllers
672 An unauthorized XMPP-Grid Controller (one which is not trusted by
673 XMPP-Grid Platforms) cannot mount any attacks other than those listed
674 in the Network Attacks section above.
676 An authorized XMPP-Grid Controller can mount many attacks. Similar
677 to the XMPP-Grid Platform case described above, these attacks might
678 occur because the XMPP-Grid Controller is controlled by a malicious,
679 careless, or incompetent party (either an XMPP-Grid Controller
680 administrator or an attacker who has seized control of the XMPP-Grid
681 Controller). They might also occur because the XMPP-Grid Controller
682 is running malicious software, because the XMPP-Grid Controller is
683 running buggy software (which can fail in a state that corrupts data
684 or floods the network with traffic), or because the XMPP-Grid
685 Controller has been configured improperly.
687 All of the attacks listed for XMPP-Grid Platform above can be mounted
688 by the XMPP-Grid Controller. Detection of these attacks will be more
689 difficult since the XMPP-Grid Controller can create false operational
690 attributes and/or logs that imply some other party created any bad
691 data.
693 Additional XMPP-Grid Controller attacks can include:
695 o Expose different data to different XMPP-Grid Platforms to mislead
696 investigators or cause inconsistent behavior
698 o Mount an even more effective denial of service attack than a
699 single XMPP-Grid Platform could
701 o Obtain and cache XMPP-Grid Platform credentials so they can be
702 used to impersonate XMPP-Grid Platforms even after a breach of the
703 XMPP-Grid Controller is repaired
705 o Obtain and cache XMPP-Grid Controller administrator credentials so
706 they can be used to regain control of the XMPP-Grid Controller
707 after the breach of the XMPP-Grid Controller is repaired
709 Dependencies of or vulnerabilities of the XMPP-Grid Controller can be
710 exploited to obtain control of the XMPP-Grid Controller and effect
711 these attacks.
713 8.2.4. Certification Authority
715 A Certification Authority trusted to issue certificates for the XMPP-
716 Grid Controller and/or XMPP-Grid Platforms can mount several attacks:
718 o Issue certificates for unauthorized parties, enabling them to
719 impersonate authorized parties such as the XMPP-Grid Controller or
720 an XMPP-Grid Platform. This can lead to all the threats that can
721 be mounted by the certificate's subject.
723 o Issue certificates without following all of the CA's policies.
724 Because this can result in issuing certificates that can be used
725 to impersonate authorized parties, this can lead to all the
726 threats that can be mounted by the certificate's subject.
728 o Fail to revoke previously issued certificates that need to be
729 revoked. This can lead 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.
734 o Fail to regularly and securely distribute certificate revocation
735 information. This can cause a relying party to accept a revoked
736 certificate, leading to undetected impersonation of the
737 certificate's subject or failure to revoke authorization of the
738 subject, and therefore can lead to all of the threats that can be
739 mounted by that subject. It can also cause a relying party to
740 refuse to proceed with a transaction because timely revocation
741 information is not available, even though the transaction should
742 be permitted to proceed.
744 o Allow the CA's private key to be revealed to an unauthorized
745 party. This can lead to all the threats above. Even worse, the
746 actions taken with the private key will not be known to the CA.
748 o Fail to promptly detect and report errors and violations of trust
749 so that relying parties can be promptly notified. This can cause
750 the threats listed earlier in this section to persist longer than
751 necessary, leading to many knock-on effects.
753 8.3. Countermeasures
755 Below are countermeasures for specific attack scenarios to the XMPP-
756 Grid infrastructure.
758 8.3.1. Securing the XMPP-Grid Data Transfer Protocol
760 To address network attacks, the XMPP-Grid data transfer protocol
761 described in this document requires that the XMPP-Grid messages MUST
762 be carried over TLS (minimally TLS 1.2 [RFC5246]) as described in
763 [RFC6120] and updated by [RFC7590]. The XMPP-Grid Platform MUST
764 verify the XMPP-Grid Controller's certificate and determine whether
765 the XMPP-Grid Controller is trusted by this XMPP-Grid Platform before
766 completing the TLS handshake. The XMPP-Grid Controller MUST
767 authenticate the XMPP-Grid Platform either using the SASL EXTERNAL
768 mechanism or using the SASL SCRAM mechanism (with the SCRAM-SHA-
769 256-PLUS variant being preferred over the SCRAM-SHA-256 variant and
770 SHA-256 variants [RFC7677] being preferred over SHA-1 varients
771 [RFC5802]). XMPP-Grid Platforms and XMPP-Grid Controllers using
772 mutual certificate-based authentication SHOULD each verify the
773 revocation status of the other party's certificate. All XMPP-Grid
774 Controllers and XMPP-Grid Platforms MUST implement both SASL EXTERNAL
775 and SASL SCRAM. The selection of which XMPP-Grid Platform
776 authentication technique to use in any particular deployment is left
777 to the administrator.
779 These protocol security measures provide protection against all the
780 network attacks listed in the above document section except denial of
781 service attacks. If protection against these denial of service
782 attacks is desired, ingress filtering, rate limiting per source IP
783 address, and other denial of service mitigation measures can be
784 employed. In addition, an XMPP-Grid Controller MAY automatically
785 disable a misbehaving XMPP-Grid Platform.
787 8.3.2. Securing XMPP-Grid Platforms
789 XMPP-Grid Platforms can be deployed in locations that are susceptible
790 to physical attacks. Physical security measures can be taken to
791 avoid compromise of XMPP-Grid Platforms, but these are not always
792 practical or completely effective. An alternative measure is to
793 configure the XMPP-Grid Controller to provide read-only access for
794 such systems. The XMPP-Grid Controller SHOULD also include a full
795 authorization model so that individual XMPP-Grid Platforms can be
796 configured to have only the privileges that they need. The XMPP-Grid
797 Controller MAY provide functional templates so that the administrator
798 can configure a specific XMPP-Grid Platform as a DHCP server and
799 authorize only the operations and metadata types needed by a DHCP
800 server to be permitted for that XMPP-Grid Platform. These techniques
801 can reduce the negative impacts of a compromised XMPP-Grid Platform
802 without diminishing the utility of the overall system.
804 To handle attacks within the bounds of this authorization model, the
805 XMPP-Grid Controller MAY also include rate limits and alerts for
806 unusual XMPP-Grid Platform behavior. XMPP-Grid Controllers SHOULD
807 make it easy to revoke an XMPP-Grid Platform's authorization when
808 necessary. Another way to detect attacks from XMPP-Grid Platforms is
809 to create fake entries in the available data (honeytokens) which
810 normal XMPP-Grid Platforms will not attempt to access. The XMPP-Grid
811 Controller SHOULD include auditable logs of XMPP-Grid Platform
812 activities.
814 To avoid compromise of XMPP-Grid Platform, XMPP-Grid Platform SHOULD
815 be hardened against attack and minimized to reduce their attack
816 surface. They should be well managed to minimize vulnerabilities in
817 the underlying platform and in systems upon which the XMPP-Grid
818 Platform depends. Personnel with administrative access should be
819 carefully screened and monitored to detect problems as soon as
820 possible.
822 8.3.3. Securing XMPP-Grid Controllers
824 Because of the serious consequences of XMPP-Grid Controller
825 compromise, XMPP-Grid Controllers need to be especially well hardened
826 against attack and minimized to reduce their attack surface. They
827 need to be well managed to minimize vulnerabilities in the underlying
828 platform and in systems upon which the XMPP-Grid Controller depends.
829 Network security measures such as firewalls or intrusion detection
830 systems can be used to monitor and limit traffic to and from the
831 XMPP-Grid Controller. Personnel with administrative access ought to
832 be carefully screened and monitored to detect problems as soon as
833 possible. Administrators SHOULD NOT use password-based
834 authentication but should instead use non-reusable credentials and
835 multi-factor authentication (where available). Physical security
836 measures ought to be employed to prevent physical attacks on XMPP-
837 Grid Controllers.
839 To ease detection of XMPP-Grid Controller compromise should it occur,
840 XMPP-Grid Controller behavior should be monitored to detect unusual
841 behavior (such as a reboot, a large increase in traffic, or different
842 views of an information repository for similar XMPP-Grid Platforms).
843 XMPP-Grid Platforms should log and/or notify administrators when
844 peculiar XMPP-Grid Controller behavior is detected. To aid forensic
845 investigation, permanent read-only audit logs of security-relevant
846 information (especially administrative actions) should be maintained.
847 If XMPP-Grid Controller compromise is detected, a careful analysis
848 should be performed of the impact of this compromise. Any reusable
849 credentials that can have been compromised should be reissued.
851 8.3.4. Broker Access Models for Topics
853 The XMPP publish-subscribe specification [XEP-0060] defines five
854 access models for subscribing to Topics at a Broker: open, presence,
855 roster, authorize, and whitelist. The first model allows
856 uncontrolled access and the next two models are appropriate only in
857 instant-messaging applications. Therefore, a Broker SHOULD support
858 only the authorize model (under which the Topic owner needs to
859 approve all subscription requests and only subscribers can retrieve
860 data items) and the whitelist model (under which only preconfigured
861 Platforms can subscribe or retrieve data items). In order to ease
862 the deployment burden, subscription approvals and whitelist
863 management can be automated (e.g, the Topic "owner" can be a policy
864 server). The choice between "authorize" and "whitelist" as the
865 default access model is a matter for local service policy.
867 8.3.5. Limit on Search Result Size
869 While XMPP-Grid is designed for high scalability to 100,000s of
870 Platforms, an XMPP-Grid Controller MAY establish a limit to the
871 amount of data it is willing to return in search or subscription
872 results. This mitigates the threat of an XMPP-Grid Platform causing
873 resource exhaustion by issuing a search or subscription that leads to
874 an enormous result.
876 8.3.6. Securing the Certification Authority
878 As noted above, compromise of a Certification Authority (CA) trusted
879 to issue certificates for the XMPP-Grid Controller and/or XMPP-Grid
880 Platforms is a major security breach. Many guidelines for proper CA
881 security have been developed: the CA/Browser Forum's Baseline
882 Requirements, the AICPA/CICA Trust Service Principles, etc. The CA
883 operator and relying parties should agree on an appropriately
884 rigorous security practices to be used.
886 Even with the most rigorous security practices, a CA can be
887 compromised. If this compromise is detected quickly, relying parties
888 can remove the CA from their list of trusted CAs, and other CAs can
889 revoke any certificates issued to the CA. However, CA compromise may
890 go undetected for some time, and there's always the possibility that
891 a CA is being operated improperly or in a manner that is not in the
892 interests of the relying parties. For this reason, relying parties
893 may wish to "pin" a small number of particularly critical
894 certificates (such as the certificate for the XMPP-Grid Controller).
895 Once a certificate has been pinned, the relying party will not accept
896 another certificate in its place unless the Administrator explicitly
897 commands it to do so. This does not mean that the relying party will
898 not check the revocation status of pinned certificates. However, the
899 Administrator can still be consulted if a pinned certificate is
900 revoked, since the CA and revocation process are not completely
901 trusted.
903 8.4. Summary
905 XMPP-Grid's considerable value as a broker for security-sensitive
906 data exchange distribution also makes the protocol and the network
907 security elements that implement it a target for attack. Therefore,
908 strong security has been included as a basic design principle within
909 the XMPP-Grid design process.
911 The XMPP-Grid data transfer protocol provides strong protection
912 against a variety of different attacks. In the event that an XMPP-
913 Grid Platform or XMPP-Grid Controller is compromised, the effects of
914 this compromise have been reduced and limited with the recommended
915 role-based authorization model and other provisions, and best
916 practices for managing and protecting XMPP-Grid systems have been
917 described. Taken together, these measures should provide protection
918 commensurate with the threat to XMPP-Grid systems, thus ensuring that
919 they fulfill their promise as a network security clearing-house.
921 9. Privacy Considerations
923 XMPP-Grid Platforms can publish information about endpoint health,
924 network access, events (which can include information about what
925 services an endpoint is accessing), roles and capabilities, and the
926 identity of the end user operating the endpoint. Any of this
927 published information can be queried by other XMPP-Grid Platforms and
928 could potentially be used to correlate network activity to a
929 particular end user.
931 Dynamic and static information brokered by an XMPP-Grid Controller,
932 ostensibly for purposes of correlation by XMPP-Grid Platforms for
933 intrusion detection, could be misused by a broader set of XMPP-Grid
934 Platforms which hitherto have been performing specific roles with
935 strict well-defined separation of duties.
937 Care needs to be taken by deployers of XMPP-Grid to ensure that the
938 information published by XMPP-Grid Platforms does not violate
939 agreements with end users or local and regional laws and regulations.
940 This can be accomplished either by configuring XMPP-Grid Platforms to
941 not publish certain information or by restricting access to sensitive
942 data to trusted XMPP-Grid Platforms. That is, the easiest means to
943 ensure privacy or protect sensitive data, is to omit or not share it
944 at all.
946 Another consideration for deployers is to enable end-to-end
947 encryption to ensure the data is protected from the data layer to
948 data layer and thus protect it from the transport layer.
950 10. Operations and Management Considerations
952 In order to facilitate the management of Providers and the onboarding
953 of Consumers, it is helpful to generate the following ahead of time:
955 o Agreement between the operators of Provider services and the
956 implementers of Consumer software regarding identifiers for common
957 Topics (e.g., these could be registered with the XMPP Software
958 Foundation's registry of well-known nodes for service discovery
959 and publish-subscribe located at ).
962 o Security certificates (including appropriate certificate chains)
963 for Controllers, including identification of any Providers
964 associated with the Controllers (which might be located at
965 subdomains).
967 o Consistent and secure access control policies for publishing and
968 subscribing to Topics.
970 These matters are out of scope for this document but ought to be
971 addressed by the XMPP-Grid community.
973 11. Acknowledgements
975 The authors would like to acknowledge the contributions, authoring
976 and/or editing of the following people: Joseph Salowey, Lisa
977 Lorenzin, Clifford Kahn, Henk Birkholz, Jessica Fitzgerald-McKay,
978 Steve Hanna, and Steve Venema. In addition, we want to thank Takeshi
979 Takahashi, Panos Kampanakis, Adam Montville, Chris Inacio, and Dave
980 Cridland for reviewing and providing valuable comments.
982 12. References
984 12.1. Normative References
986 [I-D.ietf-sacm-terminology]
987 Birkholz, H., Lu, J., Strassner, J., and N. Cam-Winget,
988 "Secure Automation and Continuous Monitoring (SACM)
989 Terminology", draft-ietf-sacm-terminology-14 (work in
990 progress), December 2017.
992 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
993 Requirement Levels", BCP 14, RFC 2119,
994 DOI 10.17487/RFC2119, March 1997,
995 .
997 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
998 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
999 March 2011, .
1001 [RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer
1002 Security (TLS) in the Extensible Messaging and Presence
1003 Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June
1004 2015, .
1006 [RFC7677] Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple
1007 Authentication and Security Layer (SASL) Mechanisms",
1008 RFC 7677, DOI 10.17487/RFC7677, November 2015,
1009 .
1011 [XEP-0004]
1012 Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and
1013 P. Saint-Andre, "Data Forms", XSF XEP 0004, August 2007.
1015 [XEP-0030]
1016 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint-
1017 Andre, "Service Discovery", XSF XEP 0030, July 2010.
1019 [XEP-0060]
1020 Millard, P., Saint-Andre, P., and R. Meijer, "Publish-
1021 Subscribe", XSF XEP 0060, December 2017.
1023 12.2. Informative References
1025 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
1026 (TLS) Protocol Version 1.2", RFC 5246,
1027 DOI 10.17487/RFC5246, August 2008,
1028 .
1030 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
1031 "Salted Challenge Response Authentication Mechanism
1032 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802,
1033 DOI 10.17487/RFC5802, July 2010,
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 Authors' Addresses
1047 Nancy Cam-Winget (editor)
1048 Cisco Systems
1049 3550 Cisco Way
1050 San Jose, CA 95134
1051 USA
1053 Email: ncamwing@cisco.com
1055 Syam Appala
1056 Cisco Systems
1057 3550 Cisco Way
1058 San Jose, CA 95134
1059 USA
1061 Email: syam1@cisco.com
1062 Scott Pope
1063 Cisco Systems
1064 5400 Meadows Road
1065 Suite 300
1066 Lake Oswego, OR 97035
1067 USA
1069 Email: scottp@cisco.com
1071 Peter Saint-Andre
1072 Mozilla
1074 Email: stpeter@mozilla.com