idnits 2.17.1
draft-ietf-mile-xmpp-grid-04.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 (October 30, 2017) is 2369 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-13
** 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-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 (==), 4 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: May 3, 2018 Cisco Systems
6 P. Saint-Andre
7 Jabber.org
8 October 30, 2017
10 Using XMPP for Security Information Exchange
11 draft-ietf-mile-xmpp-grid-04
13 Abstract
15 This document describes how to use the Extensible Messaging and
16 Presence Protocol (XMPP) as a transport for collecting and
17 distributing security-relevant information between network-connected
18 devices. To illustrate the principles involved, this document
19 describes such a usage for the Incident Object Description Exchange
20 Format (IODEF).
22 Status of This Memo
24 This Internet-Draft is submitted in full conformance with the
25 provisions of BCP 78 and BCP 79.
27 Internet-Drafts are working documents of the Internet Engineering
28 Task Force (IETF). Note that other groups may also distribute
29 working documents as Internet-Drafts. The list of current Internet-
30 Drafts is at http://datatracker.ietf.org/drafts/current/.
32 Internet-Drafts are draft documents valid for a maximum of six months
33 and may be updated, replaced, or obsoleted by other documents at any
34 time. It is inappropriate to use Internet-Drafts as reference
35 material or to cite them other than as "work in progress."
37 This Internet-Draft will expire on May 3, 2018.
39 Copyright Notice
41 Copyright (c) 2017 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (http://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
49 to this document. Code Components extracted from this document must
50 include Simplified BSD License text as described in Section 4.e of
51 the Trust Legal Provisions and are provided without warranty as
52 described in the Simplified BSD License.
54 Table of Contents
56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
58 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
59 4. Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . 6
60 5. Service Discovery . . . . . . . . . . . . . . . . . . . . . . 6
61 6. IODEF Example . . . . . . . . . . . . . . . . . . . . . . . . 7
62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
64 8.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 9
65 8.1.1. Network . . . . . . . . . . . . . . . . . . . . . . . 10
66 8.1.2. XMPP-Grid Platforms . . . . . . . . . . . . . . . . . 10
67 8.1.3. XMPP-Grid Controller . . . . . . . . . . . . . . . . 10
68 8.1.4. Certification Authority . . . . . . . . . . . . . . . 10
69 8.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 11
70 8.2.1. Network Attacks . . . . . . . . . . . . . . . . . . . 11
71 8.2.2. XMPP-Grid Platforms . . . . . . . . . . . . . . . . . 12
72 8.2.3. XMPP-Grid Controllers . . . . . . . . . . . . . . . . 13
73 8.2.4. Certification Authority . . . . . . . . . . . . . . . 14
74 8.3. Countermeasures . . . . . . . . . . . . . . . . . . . . . 15
75 8.3.1. Securing the XMPP-Grid Transport Protocol . . . . . . 15
76 8.3.2. Securing XMPP-Grid Platforms . . . . . . . . . . . . 16
77 8.3.3. Securing XMPP-Grid Controllers . . . . . . . . . . . 16
78 8.3.4. Limit on search result size . . . . . . . . . . . . . 17
79 8.3.5. Cryptographically random session-id and
80 authentication checks for ARC . . . . . . . . . . . . 17
81 8.3.6. Securing the Certification Authority . . . . . . . . 18
82 8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 18
83 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
84 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
86 11.1. Normative References . . . . . . . . . . . . . . . . . . 19
87 11.2. Informative References . . . . . . . . . . . . . . . . . 20
88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
90 1. Introduction
92 This document describes "XMPP-Grid": a method for using the
93 Extensible Messaging and Presence Protocol (XMPP) [RFC6120] as a
94 transport for collecting and distributing security-relevant
95 information among network platforms, endpoints, and any other
96 network-connected device. Among other services, XMPP provides a
97 publish-subscribe service that acts as a broker, providing control-
98 plane functions by which entities can discover available information
99 to be published or consumed. Although such information can take the
100 form of any structured data (XML, JSON, etc.), this document uses the
101 Incident Object Description Exchange Format (IODEF) [RFC7970] to
102 illustrate the principles of XMPP-Grid.
104 2. Terminology
106 This document uses XMPP terminology defined in [RFC6120] and
107 [XEP-0060] as well as Security Automation and Continuous Monitoring
108 (SACM) terminology defined in [I-D.ietf-sacm-terminology]. Because
109 the intended audience for this document consists of those who
110 implement and deploy security reporting systems, in general the SACM
111 terms are used here (however, mappings are provided for the benefit
112 of XMPP developers and operators).
114 Broker: As defined in [I-D.ietf-sacm-terminology], a Broker is a
115 specific type of controller containing control plane functions; as
116 used here, the term refers to an XMPP publish-subscribe service.
118 Broker Flow: A method by which security-related information is
119 published and consumed in a mediated fashion through a Broker. In
120 this flow, the Broker handles authorization of Subscribers and
121 Publishers to Topics, receives messages from Publishers, and
122 delivers published messages to Subscribers.
124 Consumer: As defined in [I-D.ietf-sacm-terminology], a Consumer is a
125 component that contains functions to receive information from
126 other components; as used here, the term refers to an XMPP
127 publish-subscribe Subscriber.
129 Controller: As defined in [I-D.ietf-sacm-terminology], a controller
130 is a "component containing control plane functions that manage and
131 facilitate information sharing or execute on security functions";
132 as used here, the term refers to either an XMPP server, which
133 provides both core message delivery [RFC6120] used by publish-
134 subscribe entities.
136 Node: The term used in the XMPP publish-subscribe specification
137 [XEP-0060] for a Topic.
139 Platform: Any entity that implements connects to the XMPP-Grid in
140 order to publisher or consume security-related data.
142 Provider: As defined in [I-D.ietf-sacm-terminology], a Provider is a
143 component that contains functions to provide information to other
144 components; as used here, the term refers to an XMPP publish-
145 subscribe Publisher.
147 Publisher: The term used in the XMPP publish-subscribe specification
148 [XEP-0060] for a Provider.
150 Publish-Subscribe Service: A Broker that implements the XMPP
151 publish-subscribe extension [XEP-0060].
153 Subscriber: The term used in the XMPP publish-subscribe
154 specification [XEP-0060] for a Consumer.
156 Topic: A contextual information channel created on a Broker at which
157 messages generated by a Publisher will be propagated by XMPP in
158 real time to one or more Subscribers. Each Topic is limited to a
159 type and format of security data (e.g., IODEF) that a platform
160 wants to share with other platform(s) and a specified interface by
161 which the data can be obtained.
163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
165 document are to be interpreted as described in [RFC2119].
167 3. Architecture
169 The following figure illustrates the architecture of XMPP-Grid.
171 +--------------------------------------+
172 | +--------------------------------------+
173 | | +--------------------------------------+
174 | | | |
175 +-| | Platforms |
176 +-| |
177 +--------------------------------------+
178 / \ / \ / \
179 / C \ / \ / \
180 - o - - d - - -
181 ||n||A | a |B | |C
182 ||t|| | t | | |
183 - r - - a - | |
184 \ o / \ / | |
185 \ l / \ / | |
186 /|---------------------|\ | |
187 /|----/ \--------| d |--|\
188 / / Controller \ ctrl | a | \
189 \ \ & Broker / plane | t | /
190 \|----\ /--------| a |--|/
191 \|---------------------|/ | |
192 / \ / \ | |
193 / C \ / \ | |
194 - o - - d - | |
195 ||n||A | a |B | |C
196 ||t|| | t | | |
197 - r - - a - - -
198 \ o / \ / \ /
199 \ l / \ / \ /
200 +------------------------------------+
201 | |-+
202 | Platforms | |
203 | | |-+
204 +------------------------------------+ | |
205 +------------------------------------+ |
206 +------------------------------------+
208 Figure 1: XMPP-Grid Architecture
210 Platforms connect to the Controller (XMPP server) to authenticate and
211 and then establish appropriate authorizations and relationships
212 (e.g., Publisher or Subscriber) at the Broker (XMPP publish-subscribe
213 service). The control plane messaging is established through XMPP
214 and shown as "A" (control plane interface) in Figure 1. Authorized
215 nodes may then share data either thru the Broker (shown as "B" in
216 Figure 1) or in some cases directly (shown as "C" in Figure 1). This
217 document focuses primarily on the Broker Flow for information sharing
218 (although "direct flow" interactions can be used for specialized
219 purposes such as bulk data transfer, methods for doing so are outside
220 the scope of this document).
222 4. Workflow
224 A typical XMPP-Grid workflow is as follows:
226 a. A Platform with a source of security data requests connection to
227 the XMPP-Grid via a Controller (XMPP server).
229 b. The Controller authenticates the Platform.
231 c. The Platform establishes authorized privileges (e.g. privilege to
232 publish and/or subscribe to security data Topics) with a Broker.
234 d. The Platform may publish security-related data to a Topic,
235 subscribe to a Topic, query a Topic, or any combination of these
236 operations.
238 e. A Publisher unicasts its Topic updates to the Grid in real time
239 through a Broker. The Broker handles replication and
240 distribution of the Topic to Subscribers. A Publisher may
241 publish the same or different data to multiple Topics.
243 f. Any Platform on the Grid may subscribe to any Topics published to
244 the Grid (as permitted by authorization policy), and (as
245 Subscribers) will then receive a continuous, real-time stream of
246 updates from the Topics to which they are subscribed.
248 5. Service Discovery
250 Using the XMPP service discovery extension [XEP-0030], a Controller
251 enables Platforms to discover what information may be consumed
252 through the Broker (publish-subscribe service). For instance, the
253 Controller might provide a Broker at 'broker.security-grid.example',
254 where 'security-grid.example' is the Controller host. Below is an
255 example for how a Platform can query for available information from
256 the XMPP-Controller:
258
262
263
265 The XMPP-Controller responds with the different types of information
266 it can publish:
268
272
274
277
280
281
283 6. IODEF Example
285 A Platform follows the standard XMPP workflow for connecting to the
286 Controller as well as using the XMPP discovery mechanisms to discover
287 the availability to consume IODEF information. The general workflow
288 is summarized in the figure below:
290 +----------------+ +----------------+ +----------------+
291 | IODEF Client | | XMPP Server | | IODEF Service |
292 | (Subscriber) | | (Controller) | | (Publisher) |
293 +----------------+ +----------------+ +----------------+
294 | | |
295 | IODEF Client | |
296 | Authentication | |
297 |<------------------------>| |
298 | | IODEF Service |
299 | | Authentication |
300 | |<----------------------->|
301 | | Create IODEF as a Topic |
302 | | (XEP-0060) |
303 | |<------------------------|
304 | | Topic Creation Success |
305 | |------------------------>|
306 | Topic Discovery | |
307 | (XEP-0030) | |
308 |------------------------->| |
309 | Discovery Response | |
310 | with Topics | |
311 |<-------------------------| |
312 | | |
313 | Subscribe to IODEF Topic | |
314 | (XEP-0060) | |
315 |------------------------->| |
316 | Subscription Success | |
317 |<-------------------------| |
318 | | IODEF Incident Publish |
319 | IODEF Incident Publish |<------------------------|
320 |<-------------------------| |
321 | | |
323 Figure 2: IODEF Example Workflow
325 An example XMPP discovery request for an IODEF 1.0 topic is shown
326 below:
328
332
333
335 An example XMPP discovery response for an IODEF 1.0 topic is shown
336 below:
338
342
343
346
347
349 7. IANA Considerations
351 This document has no actions for IANA.
353 8. Security Considerations
355 An XMPP-Grid Controller serves as an controlling broker for XMPP-Grid
356 Platforms such as Enforcement Points, Policy Servers, CMDBs, and
357 Sensors, using a publish-subscribe-search model of information
358 exchange and lookup. By increasing the ability of XMPP-Grid
359 Platforms to learn about and respond to security-relevant events and
360 data, XMPP-Grid can improve the timeliness and utility of the
361 security system. However, this integrated security system can also
362 be exploited by attackers if they can compromise it. Therefore,
363 strong security protections for XMPP-Grid are essential.
365 This section provides a security analysis of the XMPP-Grid transport
366 protocol and the architectural elements that employ it, specifically
367 with respect to their use of this protocol. Three subsections define
368 the trust model (which elements are trusted to do what), the threat
369 model (attacks that may be mounted on the system), and the
370 countermeasures (ways to address or mitigate the threats previously
371 identified).
373 8.1. Trust Model
375 The first step in analyzing the security of the XMPP-Grid transport
376 protocol is to describe the trust model, listing what each
377 architectural element is trusted to do. The items listed here are
378 assumptions, but provisions are made in the Threat Model and
379 Countermeasures sections for elements that fail to perform as they
380 were trusted to do.
382 8.1.1. Network
384 The network used to carry XMPP-Grid messages is trusted to:
386 o Perform best effort delivery of network traffic
388 The network used to carry XMPP-Grid messages is not expected
389 (trusted) to:
391 o Provide confidentiality or integrity protection for messages sent
392 over it
394 o Provide timely or reliable service
396 8.1.2. XMPP-Grid Platforms
398 Authorized XMPP-Grid Platforms are trusted to:
400 o Preserve the confidentiality of sensitive data retrieved via the
401 XMPP-Grid Controller
403 8.1.3. XMPP-Grid Controller
405 The XMPP-Grid Controller is trusted to:
407 o Broker requests for data and enforce authorization of access to
408 this data throughout its lifecycle
410 o Perform service requests in a timely and accurate manner
412 o Create and maintain accurate operational attributes
414 o Only reveal data to and accept service requests from authorized
415 parties
417 The XMPP-Grid Controller is not expected (trusted) to:
419 o Verify the truth (correctness) of data
421 8.1.4. Certification Authority
423 The Certification Authority (CA) that issues certificates for the
424 XMPP-Grid Controller and/or XMPP-Grid Platforms (or each CA, if there
425 are several) is trusted to:
427 o Ensure that only proper certificates are issued and that all
428 certificates are issued in accordance with the CA's policies
430 o Revoke certificates previously issued when necessary
432 o Regularly and securely distribute certificate revocation
433 information
435 o Promptly detect and report any violations of this trust so that
436 they can be handled
438 The CA is not expected (trusted) to:
440 o Issue certificates that go beyond the XMPP-Grid needs or other
441 constraints imposed by a relying party.
443 8.2. Threat Model
445 To secure the XMPP-Grid transport protocol and the architectural
446 elements that implement it, this section identifies the attacks that
447 can be mounted against the protocol and elements.
449 8.2.1. Network Attacks
451 A variety of attacks can be mounted using the network. For the
452 purposes of this subsection the phrase "network traffic" should be
453 taken to mean messages and/or parts of messages. Any of these
454 attacks may be mounted by network elements, by parties who control
455 network elements, and (in many cases) by parties who control network-
456 attached devices.
458 o Network traffic may be passively monitored to glean information
459 from any unencrypted traffic
461 o Even if all traffic is encrypted, valuable information can be
462 gained by traffic analysis (volume, timing, source and destination
463 addresses, etc.)
465 o Network traffic may be modified in transit
467 o Previously transmitted network traffic may be replayed
469 o New network traffic may be added
471 o Network traffic may be blocked, perhaps selectively
473 o A "Man In The Middle" (MITM) attack may be mounted where an
474 attacker interposes itself between two communicating parties and
475 poses as the other end to either party or impersonates the other
476 end to either or both parties
478 o Resist attacks (including denial of service and other attacks from
479 XMPP-Grid Platforms)
481 o Undesired network traffic may be sent in an effort to overload an
482 architectural component, thus mounting a denial of service attack
484 8.2.2. XMPP-Grid Platforms
486 An unauthorized XMPP-Grid Platforms (one which is not recognized by
487 the XMPP-Grid Controller or is recognized but not authorized to
488 perform any actions) cannot mount any attacks other than those listed
489 in the Network Attacks section above.
491 An authorized XMPP-Grid Platform, on the other hand, can mount many
492 attacks. These attacks might occur because the XMPP-Grid Platform is
493 controlled by a malicious, careless, or incompetent party (whether
494 because its owner is malicious, careless, or incompetent or because
495 the XMPP-Grid Platform has been compromised and is now controlled by
496 a party other than its owner). They might also occur because the
497 XMPP-Grid Platform is running malicious software; because the XMPP-
498 Grid Platform is running buggy software (which may fail in a state
499 that floods the network with traffic); or because the XMPP-Grid
500 Platform has been configured improperly. From a security standpoint,
501 it generally makes no difference why an attack is initiated. The
502 same countermeasures can be employed in any case.
504 Here is a list of attacks that may be mounted by an authorized XMPP-
505 Grid Platform:
507 o Cause many false alarms or otherwise overload the XMPP-Grid
508 Controller or other elements in the network security system
509 (including human administrators) leading to a denial of service or
510 disabling parts of the network security system
512 o Omit important actions (such as posting incriminating data),
513 resulting in incorrect access
515 o Use confidential information obtained from the XMPP-Grid
516 Controller to enable further attacks (such as using endpoint
517 health check results to exploit vulnerable endpoints)
519 o Advertise data crafted to exploit vulnerabilities in the XMPP-Grid
520 Controller or in other XMPP-Grid Platforms, with a goal of
521 compromising those systems
523 o Issue a search request or set up a subscription that matches an
524 enormous result, leading to resource exhaustion on the XMPP-Grid
525 Controller, the publishing XMPP-Grid Platform, and/or the network
527 o Establish a communication channel using another XMPP-Grid
528 Platform's session-id
530 Dependencies of or vulnerabilities of authorized XMPP-Grid Platforms
531 may be exploited to effect these attacks. Another way to effect
532 these attacks is to gain the ability to impersonate an XMPP-Grid
533 Platform (through theft of the XMPP-Grid Platform's identity
534 credentials or through other means). Even a clock skew between the
535 XMPP-Grid Platform and XMPP-Grid Controller can cause problems if the
536 XMPP-Grid Platform assumes that old XMPP-Grid Platform data should be
537 ignored.
539 8.2.3. XMPP-Grid Controllers
541 An unauthorized XMPP-Grid Controller (one which is not trusted by
542 XMPP-Grid Platforms) cannot mount any attacks other than those listed
543 in the Network Attacks section above.
545 An authorized XMPP-Grid Controller can mount many attacks. Similar
546 to the XMPP-Grid Platform case described above, these attacks might
547 occur because the XMPP-Grid Controller is controlled by a malicious,
548 careless, or incompetent party (either an XMPP-Grid Controller
549 administrator or an attacker who has seized control of the XMPP-Grid
550 Controller). They might also occur because the XMPP-Grid Controller
551 is running malicious software, because the XMPP-Grid Controller is
552 running buggy software (which may fail in a state that corrupts data
553 or floods the network with traffic), or because the XMPP-Grid
554 Controller has been configured improperly.
556 All of the attacks listed for XMPP-Grid Platform above can be mounted
557 by the XMPP-Grid Controller. Detection of these attacks will be more
558 difficult since the XMPP-Grid Controller can create false operational
559 attributes and/or logs that imply some other party created any bad
560 data.
562 Additional XMPP-Grid Controller attacks may include:
564 o Expose different data to different XMPP-Grid Platforms to mislead
565 investigators or cause inconsistent behavior
567 o Mount an even more effective denial of service attack than a
568 single XMPP-Grid Platform could
570 o Obtain and cache XMPP-Grid Platform credentials so they can be
571 used to impersonate XMPP-Grid Platforms even after a breach of the
572 XMPP-Grid Controller is repaired
574 o Obtain and cache XMPP-Grid Controller administrator credentials so
575 they can be used to regain control of the XMPP-Grid Controller
576 after the breach of the XMPP-Grid Controller is repaired
578 Dependencies of or vulnerabilities of the XMPP-Grid Controller may be
579 exploited to obtain control of the XMPP-Grid Controller and effect
580 these attacks.
582 8.2.4. Certification Authority
584 A Certification Authority trusted to issue certificates for the XMPP-
585 Grid Controller and/or XMPP-Grid Platforms can mount several attacks:
587 o Issue certificates for unauthorized parties, enabling them to
588 impersonate authorized parties such as the XMPP-Grid Controller or
589 an XMPP-Grid Platform. This can lead to all the threats that can
590 be mounted by the certificate's subject.
592 o Issue certificates without following all of the CA's policies.
593 Because this can result in issuing certificates that may be used
594 to impersonate authorized parties, this can lead to all the
595 threats that can be mounted by the certificate's subject.
597 o Fail to revoke previously issued certificates that need to be
598 revoked. This can lead to undetected impersonation of the
599 certificate's subject or failure to revoke authorization of the
600 subject, and therefore can lead to all of the threats that can be
601 mounted by that subject.
603 o Fail to regularly and securely distribute certificate revocation
604 information. This may cause a relying party to accept a revoked
605 certificate, leading to undetected impersonation of the
606 certificate's subject or failure to revoke authorization of the
607 subject, and therefore can lead to all of the threats that can be
608 mounted by that subject. It can also cause a relying party to
609 refuse to proceed with a transaction because timely revocation
610 information is not available, even though the transaction should
611 be permitted to proceed.
613 o Allow the CA's private key to be revealed to an unauthorized
614 party. This can lead to all the threats above. Even worse, the
615 actions taken with the private key will not be known to the CA.
617 o Fail to promptly detect and report errors and violations of trust
618 so that relying parties can be promptly notified. This can cause
619 the threats listed earlier in this section to persist longer than
620 necessary, leading to many knock-on effects.
622 8.3. Countermeasures
624 Below are countermeasures for specific attack scenarios to the XMPP-
625 Grid infrastructure.
627 8.3.1. Securing the XMPP-Grid Transport Protocol
629 To address network attacks, the XMPP-Grid transport protocol
630 described in this document requires that the XMPP-Grid messages MUST
631 be carried over TLS (minimally TLS 1.2 [RFC5246]) as described in
632 [RFC6120] and updated by [RFC7590]. The XMPP-Grid Platform MUST
633 verify the XMPP-Grid Controller's certificate and determine whether
634 the XMPP-Grid Controller is trusted by this XMPP-Grid Platform before
635 completing the TLS handshake. The XMPP-Grid Controller MUST
636 authenticate the XMPP-Grid Platform either using mutual certificate-
637 based authentication in the TLS handshake or using Basic
638 Authentication as described in IETF RFC 2617. XMPP-Grid Controller
639 MUST use Simple Authentication and Security Layer (SASL), described
640 in [RFC4422], to support the aforesaid authentication mechanisms.
641 SASL offers authentication mechanism negotiations between the XMPP-
642 Grid Controller and XMPP-Grid node during the connection
643 establishment phase. XMPP-Grid Platforms and XMPP-Grid Controllers
644 using mutual certificate-based authentication SHOULD each verify the
645 revocation status of the other party's certificate. All XMPP-Grid
646 Controllers and XMPP-Grid Platforms MUST implement both mutual
647 certificate-based authentication and Basic Authentication. The
648 selection of which XMPP-Grid Platform authentication technique to use
649 in any particular deployment is left to the administrator.
651 An XMPP-Grid Controller MAY also support a local, configurable set of
652 Basic Authentication userid-password pairs. If so, it is
653 implementation dependent whether an XMPP-Grid Controller ends a
654 session when an administrator changes the configured password. Since
655 Basic Authentication has many security disadvantages (especially the
656 transmission of reusable XMPP-Grid Platform passwords to the XMPP-
657 Grid Controller), it SHOULD only be used when absolutely necessary.
658 Per the HTTP specification, when basic authentication is in use, an
659 XMPP-Grid Controller MAY respond to any request that lacks
660 credentials with an error code similar to HTTP code 401. An XMPP-
661 Grid Platform SHOULD avoid this code by submitting basic auth
662 credentials with every request when basic authentication is in use.
663 If it does not do so, an XMPP-Grid Platform MUST respond to this code
664 by resubmitting the same request with credentials (unless the XMPP-
665 Grid Platform is shutting down).
667 Best practices for the use of TLS in XMPP are defined in [RFC7590].
669 These protocol security measures provide protection against all the
670 network attacks listed in the above document section except denial of
671 service attacks. If protection against these denial of service
672 attacks is desired, ingress filtering, rate limiting per source IP
673 address, and other denial of service mitigation measures may be
674 employed. In addition, an XMPP-Grid Controller MAY automatically
675 disable a misbehaving XMPP-Grid Platform.
677 8.3.2. Securing XMPP-Grid Platforms
679 XMPP-Grid Platforms may be deployed in locations that are susceptible
680 to physical attacks. Physical security measures may be taken to
681 avoid compromise of XMPP-Grid Platforms, but these may not always be
682 practical or completely effective. An alternative measure is to
683 configure the XMPP-Grid Controller to provide read-only access for
684 such systems. The XMPP-Grid Controller SHOULD also include a full
685 authorization model so that individual XMPP-Grid Platforms may be
686 configured to have only the privileges that they need. The XMPP-Grid
687 Controller MAY provide functional templates so that the administrator
688 can configure a specific XMPP-Grid Platform as a DHCP server and
689 authorize only the operations and metadata types needed by a DHCP
690 server to be permitted for that XMPP-Grid Platform. These techniques
691 can reduce the negative impacts of a compromised XMPP-Grid Platform
692 without diminishing the utility of the overall system.
694 To handle attacks within the bounds of this authorization model, the
695 XMPP-Grid Controller MAY also include rate limits and alerts for
696 unusual XMPP-Grid Platform behavior. XMPP-Grid Controllers SHOULD
697 make it easy to revoke an XMPP-Grid Platform's authorization when
698 necessary. Another way to detect attacks from XMPP-Grid Platforms is
699 to create fake entries in the available data (honeytokens) which
700 normal XMPP-Grid Platforms will not attempt to access. The XMPP-Grid
701 Controller SHOULD include auditable logs of XMPP-Grid Platform
702 activities.
704 To avoid compromise of XMPP-Grid Platform, XMPP-Grid Platform SHOULD
705 be hardened against attack and minimized to reduce their attack
706 surface. They should be well managed to minimize vulnerabilities in
707 the underlying platform and in systems upon which the XMPP-Grid
708 Platform depends. Personnel with administrative access should be
709 carefully screened and monitored to detect problems as soon as
710 possible.
712 8.3.3. Securing XMPP-Grid Controllers
714 Because of the serious consequences of XMPP-Grid Controller
715 compromise, XMPP-Grid Controllers SHOULD be especially well hardened
716 against attack and minimized to reduce their attack surface. They
717 should be well managed to minimize vulnerabilities in the underlying
718 platform and in systems upon which the XMPP-Grid Controller depends.
719 Network security measures such as firewalls or intrusion detection
720 systems may be used to monitor and limit traffic to and from the
721 XMPP-Grid Controller. Personnel with administrative access should be
722 carefully screened and monitored to detect problems as soon as
723 possible. Administrators should not use password-based
724 authentication but should instead use non-reusable credentials and
725 multi-factor authentication (where available). Physical security
726 measures SHOULD be employed to prevent physical attacks on XMPP-Grid
727 Controllers.
729 To ease detection of XMPP-Grid Controller compromise should it occur,
730 XMPP-Grid Controller behavior should be monitored to detect unusual
731 behavior (such as a reboot, a large increase in traffic, or different
732 views of an information repository for similar XMPP-Grid Platforms).
733 XMPP-Grid Platforms should log and/or notify administrators when
734 peculiar XMPP-Grid Controller behavior is detected. To aid forensic
735 investigation, permanent read-only audit logs of security-relevant
736 information (especially administrative actions) should be maintained.
737 If XMPP-Grid Controller compromise is detected, a careful analysis
738 should be performed of the impact of this compromise. Any reusable
739 credentials that may have been compromised should be reissued.
741 8.3.4. Limit on search result size
743 While XMPP-Grid is designed for high scalability to 100,000s of
744 Platforms, an XMPP-Grid Controller MAY establish a limit to the
745 amount of data it is willing to return in search or subscription
746 results. This mitigates the threat of an XMPP-Grid Platform causing
747 resource exhaustion by issuing a search or subscription that leads to
748 an enormous result.
750 8.3.5. Cryptographically random session-id and authentication checks
751 for ARC
753 An XMPP-Grid Controller SHOULD ensure that the XMPP-Grid Platform
754 establishing an Authenticated Results Chain (ARC) is the same XMPP-
755 Grid Platform as the XMPP-Grid Platform that established the
756 corresponding Synchronization Source Identifier (SSRC). The XMPP-
757 Grid Controller SHOULD employ both of the following strategies:
759 o session-ids SHOULD be cryptographically random
761 o The HTTPS transport for the SSRC and the ARC SHOULD be
762 authenticated using the same credentials. SSL session resumption
763 MAY be used to establish the ARC based on the SSRC SSL session.
765 8.3.6. Securing the Certification Authority
767 As noted above, compromise of a Certification Authority (CA) trusted
768 to issue certificates for the XMPP-Grid Controller and/or XMPP-Grid
769 Platforms is a major security breach. Many guidelines for proper CA
770 security have been developed: the CA/Browser Forum's Baseline
771 Requirements, the AICPA/CICA Trust Service Principles, etc. The CA
772 operator and relying parties should agree on an appropriately
773 rigorous security practices to be used.
775 Even with the most rigorous security practices, a CA may be
776 compromised. If this compromise is detected quickly, relying parties
777 can remove the CA from their list of trusted CAs, and other CAs can
778 revoke any certificates issued to the CA. However, CA compromise may
779 go undetected for some time, and there's always the possibility that
780 a CA is being operated improperly or in a manner that is not in the
781 interests of the relying parties. For this reason, relying parties
782 may wish to "pin" a small number of particularly critical
783 certificates (such as the certificate for the XMPP-Grid Controller).
784 Once a certificate has been pinned, the relying party will not accept
785 another certificate in its place unless the Administrator explicitly
786 commands it to do so. This does not mean that the relying party will
787 not check the revocation status of pinned certificates. However, the
788 Administrator may still be consulted if a pinned certificate is
789 revoked, since the CA and revocation process are not completely
790 trusted.
792 8.4. Summary
794 XMPP-Grid's considerable value as a broker for security-sensitive
795 data exchange distribution also makes the protocol and the network
796 security elements that implement it a target for attack. Therefore,
797 strong security has been included as a basic design principle within
798 the XMPP-Grid design process.
800 The XMPP-Grid transport protocol provides strong protection against a
801 variety of different attacks. In the event that an XMPP-Grid
802 Platform or XMPP-Grid Controller is compromised, the effects of this
803 compromise have been reduced and limited with the recommended role-
804 based authorization model and other provisions, and best practices
805 for managing and protecting XMPP-Grid systems have been described.
806 Taken together, these measures should provide protection commensurate
807 with the threat to XMPP-Grid systems, thus ensuring that they fulfill
808 their promise as a network security clearing-house.
810 9. Privacy Considerations
812 XMPP-Grid Platforms may publish information about endpoint health,
813 network access, events (which may include information about what
814 services an endpoint is accessing), roles and capabilities, and the
815 identity of the end user operating the endpoint. Any of this
816 published information may be queried by other XMPP-Grid Platforms and
817 could potentially be used to correlate network activity to a
818 particular end user.
820 Dynamic and static information brokered by an XMPP-Grid Controller,
821 ostensibly for purposes of correlation by XMPP-Grid Platforms for
822 intrusion detection, could be misused by a broader set of XMPP-Grid
823 Platforms which hitherto have been performing specific roles with
824 strict well-defined separation of duties.
826 Care should be taken by deployers of XMPP-Grid to ensure that the
827 information published by XMPP-Grid Platforms does not violate
828 agreements with end users or local and regional laws and regulations.
829 This can be accomplished either by configuring XMPP-Grid Platforms to
830 not publish certain information or by restricting access to sensitive
831 data to trusted XMPP-Grid Platforms. That is, the easiest means to
832 ensure privacy or protect sensitive data, is to omit or not share it
833 at all.
835 Another consideration for deployers is to enable end-to-end
836 encryption to ensure the data is protected from the data layer to
837 data layer and thus protect it from the transport layer.
839 10. Acknowledgements
841 The authors would like to acknowledge the contributions, authoring
842 and/or editing of the following people: Joseph Salowey, Lisa
843 Lorenzin, Clifford Kahn, Henk Birkholz, Jessica Fitzgerald-McKay,
844 Steve Hanna, and Steve Venema. In addition, we want to thank Takeshi
845 Takahashi, Panos Kampanakis, Adam Montville, Chris Inacio, and Dave
846 Cridland for reviewing and providing valuable comments.
848 11. References
850 11.1. Normative References
852 [I-D.ietf-sacm-terminology]
853 Birkholz, H., Lu, J., Strassner, J., and N. Cam-Winget,
854 "Secure Automation and Continuous Monitoring (SACM)
855 Terminology", draft-ietf-sacm-terminology-13 (work in
856 progress), July 2017.
858 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
859 Requirement Levels", BCP 14, RFC 2119,
860 DOI 10.17487/RFC2119, March 1997, .
863 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
864 Authentication and Security Layer (SASL)", RFC 4422,
865 DOI 10.17487/RFC4422, June 2006, .
868 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
869 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
870 March 2011, .
872 [RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer
873 Security (TLS) in the Extensible Messaging and Presence
874 Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June
875 2015, .
877 [XEP-0030]
878 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint-
879 Andre, "Service Discovery", XSF XEP 0030, July 2010.
881 [XEP-0060]
882 Millard, P. and P. Saint-Andre, "Publish-Subscribe",
883 XSF XEP 0060, December 2016.
885 11.2. Informative References
887 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
888 (TLS) Protocol Version 1.2", RFC 5246,
889 DOI 10.17487/RFC5246, August 2008, .
892 [RFC7970] Danyliw, R., "The Incident Object Description Exchange
893 Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
894 November 2016, .
896 Authors' Addresses
898 Nancy Cam-Winget (editor)
899 Cisco Systems
900 3550 Cisco Way
901 San Jose, CA 95134
902 USA
904 Email: ncamwing@cisco.com
905 Syam Appala
906 Cisco Systems
907 3550 Cisco Way
908 San Jose, CA 95134
909 USA
911 Email: syam1@cisco.com
913 Scott Pope
914 Cisco Systems
915 5400 Meadows Road
916 Suite 300
917 Lake Oswego, OR 97035
918 USA
920 Email: scottp@cisco.com
922 Peter Saint-Andre
923 Jabber.org
924 P.O. Box 787
925 Parker, CO 80134
926 USA
928 Email: stpeter@jabber.org