idnits 2.17.1
draft-ietf-mile-xmpp-grid-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 26 instances of too long lines in the document, the longest
one being 25 characters in excess of 72.
** The abstract seems to contain references ([RFC7590]), which it
shouldn't. Please replace those with straight textual mentions of the
documents in question.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (July 3, 2017) is 2488 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)
== Unused Reference: 'I-D.ietf-mile-rolie' is defined on line 1006, but no
explicit reference was found in the text
== Unused Reference: 'RFC6546' is defined on line 1029, but no explicit
reference was found in the text
-- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0030'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0060'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0268'
== Outdated reference: A later version (-16) exists of
draft-ietf-mile-rolie-07
-- Obsolete informational reference (is this intentional?): RFC 2818
(Obsoleted by RFC 9110)
-- Obsolete informational reference (is this intentional?): RFC 5246
(Obsoleted by RFC 8446)
Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 6 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: January 4, 2018 Cisco Systems
6 July 3, 2017
8 Using XMPP Protocol and its Extensions for Use with IODEF
9 draft-ietf-mile-xmpp-grid-03
11 Abstract
13 This document describes how the Extensible Messaging and Presence
14 Protocol (XMPP) [RFC7590] can be used as the framework as transport
15 protocol for collecting and distributing any security telemetry
16 information between any network connected device. As an example,
17 this document describes how XMPP can be used to transport the
18 Incident Object Description Exchange Format (IODEF) information.
20 Status of This Memo
22 This Internet-Draft is submitted in full conformance with the
23 provisions of BCP 78 and BCP 79.
25 Internet-Drafts are working documents of the Internet Engineering
26 Task Force (IETF). Note that other groups may also distribute
27 working documents as Internet-Drafts. The list of current Internet-
28 Drafts is at http://datatracker.ietf.org/drafts/current/.
30 Internet-Drafts are draft documents valid for a maximum of six months
31 and may be updated, replaced, or obsoleted by other documents at any
32 time. It is inappropriate to use Internet-Drafts as reference
33 material or to cite them other than as "work in progress."
35 This Internet-Draft will expire on January 4, 2018.
37 Copyright Notice
39 Copyright (c) 2017 IETF Trust and the persons identified as the
40 document authors. All rights reserved.
42 This document is subject to BCP 78 and the IETF Trust's Legal
43 Provisions Relating to IETF Documents
44 (http://trustee.ietf.org/license-info) in effect on the date of
45 publication of this document. Please review these documents
46 carefully, as they describe your rights and restrictions with respect
47 to this document. Code Components extracted from this document must
48 include Simplified BSD License text as described in Section 4.e of
49 the Trust Legal Provisions and are provided without warranty as
50 described in the Simplified BSD License.
52 Table of Contents
54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
55 1.1. Glossary of Terms . . . . . . . . . . . . . . . . . . . . 3
56 1.2. Overview of XMPP-Grid . . . . . . . . . . . . . . . . . . 4
57 1.3. Benefits of XMPP-Grid . . . . . . . . . . . . . . . . . . 5
58 2. XMPP-Grid Architecture . . . . . . . . . . . . . . . . . . . 6
59 2.1. Using XMPP . . . . . . . . . . . . . . . . . . . . . . . 7
60 2.2. XMPP-Grid Requirements for enabling Information Sharing . 8
61 3. Example use of XMPP-Grid for IODEF . . . . . . . . . . . . . 9
62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
64 5.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 11
65 5.1.1. Network . . . . . . . . . . . . . . . . . . . . . . . 12
66 5.1.2. XMPP-Grid Nodes . . . . . . . . . . . . . . . . . . . 12
67 5.1.3. XMPP-Grid Controller . . . . . . . . . . . . . . . . 12
68 5.1.4. Certification Authority . . . . . . . . . . . . . . . 12
69 5.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 13
70 5.2.1. Network Attacks . . . . . . . . . . . . . . . . . . . 13
71 5.2.2. XMPP-Grid Nodes . . . . . . . . . . . . . . . . . . . 14
72 5.2.3. XMPP-Grid Controllers . . . . . . . . . . . . . . . . 15
73 5.2.4. Certification Authority . . . . . . . . . . . . . . . 16
74 5.3. Countermeasures . . . . . . . . . . . . . . . . . . . . . 17
75 5.3.1. Securing the XMPP-Grid Transport Protocol . . . . . . 17
76 5.3.2. Securing XMPP-Grid Nodes . . . . . . . . . . . . . . 18
77 5.3.3. Securing XMPP-Grid Controllers . . . . . . . . . . . 18
78 5.3.4. Limit on search result size . . . . . . . . . . . . . 19
79 5.3.5. Cryptographically random session-id and
80 authentication checks for ARC . . . . . . . . . . . . 19
81 5.3.6. Securing the Certification Authority . . . . . . . . 20
82 5.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 20
83 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
86 8.1. Normative References . . . . . . . . . . . . . . . . . . 21
87 8.2. Informative References . . . . . . . . . . . . . . . . . 22
88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
90 1. Introduction
92 XMPP-Grid is intended for use as a secure transport and
93 communications ecosystem for devices, applications and organizations
94 to interconnect, forming an information grid for the exchange of
95 formatted data (e.g. XML, JSON, etc). This document describes how
96 XMPP [RFC7590] serves as the framework and protocols for securely
97 collecting and distributing security telemetry information between
98 and among network platforms, endpoints, and most any network
99 connected device.
101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
103 document are to be interpreted as described in [RFC2119].
105 1.1. Glossary of Terms
107 Capability Provider
109 Providers who are capable of sharing information on XMPP-Grid.
111 Publisher
113 A capability provider sharing content information to other devices
114 participating on XMPP-Grid.
116 Subscriber
118 A device participating in XMPP-Grid and subscribing or consuming
119 information published by Publishers on XMPP-Grid.
121 Topics
123 Contextual information channel created on XMPP-Grid where a
124 published message by the Publisher will be propagated by XMPP in
125 real-time to a set of subscribed devices.
127 XMPP-Grid
129 Set of standards-based XMPP messages with extensions, intended for
130 use as a transport and communications protocol framework between
131 devices forming an information grid for sharing information.
133 XMPP-Grid Controller
135 Centralized component of XMPP-Grid responsible for managing all
136 control plane operations.
138 XMPP-Grid Node
140 Platform or device that implements XMPP to connect to XMPP-Grid
141 and share or consume security data.
143 1.2. Overview of XMPP-Grid
145 XMPP-Grid employs publish/subscribe/query operations brokered by a
146 controller, which enforces access control in the system. This XMPP-
147 based architecture controls what platforms can connect to the "Grid"
148 to share ("publish") and/or consume ("subscribe" or "query")
149 contextual information ("Topics") such as security data needed to
150 support MILE.
152 Leveraging the XMPP architecture, XMPP-Grid uses the XMPP server to
153 act as a controller, affecting the authentication and authorization
154 of participating XMPP-Grid nodes (Node). Security information may
155 only be published or consumed by authenticated and authorized Nodes
156 using the XMPP publish/subscribe extension defined in [XEP-0060].
158 The components of XMPP-Grid are:
160 o XMPP-Grid Controller (Controller): The Controller manages the
161 control plane of XMPP-Grid operations. As such it authenticates
162 and authorizes platforms connecting to the data exchange grid and
163 controls whether or not they can publish, subscribe or query
164 Topics of security data.
166 o XMPP-Grid Node (Node): A Node is a platform or application that
167 has mutually authenticated with the Controller and obtained
168 authorization by the Controller to share and/or consume security
169 data.
171 o Data Repository: This is the source of security data available on
172 the Grid and may be a network security platform, management
173 console, endpoint, etc. XMPP-Grid does not mandate a specific
174 information model, but instead remains open to transport
175 structured or unstructured data. Data may be supplied by the
176 security platform itself or by an external information repository.
178 o Topic: An XMPP-Grid Topic defines a type of security data that a
179 platform wants to share with other platform(s) and a specified
180 interface by which the data can be obtained.
182 As enabled by the XMPP architecture, XMPP-Grid is used to exchange
183 security context data between systems on a 1-to-1, 1-to-many, or
184 many-to-many basis. Security data shared between these systems may
185 use pre-negotiated non-standard/native data formats or may utilize an
186 optional common information repository with a standardized data
187 format, such as IODEF. XMPP-Grid is data format agnostic and
188 accommodates transport of whatever format the end systems agree upon.
190 XMPP-Grid can operate in the following deployment architectures:
192 o Broker-Flow: An XMPP-Grid control plane brokers the authorization
193 and redirects the Topic subscriber to Topic publisher directly.
194 In this architecture, the Controller only manages the connection;
195 the security data flow is directly between Nodes using data
196 formats negotiated out-of-band.
198 o Centralized Data-Flow: An XMPP-Grid maintains the data within its
199 optional centralized database. In this architecture, the
200 Controller provides a common information structure for use in
201 formatting and storing security context data, such as IODEF, and
202 directly responds to Node publish and Subscribe requests.
204 o Proxy-Flow: An XMPP-Grid is acting as proxy, collecting the data
205 from the publisher(s) and presenting it to the subscriber
206 directly. This is used for ad-hoc queries.
208 Within the deployment architecture, XMPP-Grid may be used in any
209 combination of the following data exchange modes. The flexibility
210 afforded by the different modes enables security information to be
211 exchanged between systems in the method most suitable for serving a
212 given use-case.
214 o Continuous Topic update stream: This mode delivers in real-time
215 any data published to a Topic to the Nodes that are subscribed to
216 that Topic.
218 o Directed query: This mode enables Nodes to request a specific set
219 of security information regarding a specific asset, such as a
220 specific user endpoint.
222 o Bulk historic data query: This mode enables Nodes to request
223 transfer of past output from a Topic over a specific span of time.
225 1.3. Benefits of XMPP-Grid
227 Currently, security information standards such as IODEF [RFC7970]
228 defines a data models that has no explicit transport defined and
229 typically are carried over HTTPS as defined in RID [RFC6545].
231 As security solutions are expanding to expose and share information
232 asynchronously and across network boundaries there is a need for an
233 architecture that facilitates federation, discovery of the different
234 information available, the interfaces used to obtain the information
235 and the need for near real-time exchange of data.
237 Based on XMPP, XMPP-Grid has been defined to meet those requirements.
239 2. XMPP-Grid Architecture
241 XMPP-Grid is an XMPP-based communication fabric that facilitates
242 secure sharing of information between network elements and networked
243 applications connected to the fabric both in real time and on demand
244 (see figure below).
246 +--------------------------------------+
247 | +--------------------------------------+
248 | | +--------------------------------------+
249 | | | |
250 +-| | Node(s) |
251 +-| |
252 +--------------------------------------+
253 / \ / \ / \
254 / C \ / \ / \
255 - o - - d - - -
256 ||n||A | a |B | |C
257 ||t|| | t | | |
258 - r - - a - | |
259 \ o / \ / | |
260 \ l / \ / | |
261 /|---------------------|\ | |
262 /|----/ \--------| d |--|\
263 / / XMPP-Grid \ ctrl | a | \
264 \ \ Controller / plane | t | /
265 \|----\ /--------| a |--|/
266 \|---------------------|/ | |
267 / \ / \ | |
268 / C \ / \ | |
269 - o - - d - | |
270 ||n||A | a |B | |C
271 ||t|| | t | | |
272 - r - - a - - -
273 \ o / \ / \ /
274 \ l / \ / \ /
275 +------------------------------------+
276 | |-+
277 | Node(s) | |
278 | | |-+
279 +------------------------------------+ | |
280 +------------------------------------+ |
281 +------------------------------------+
283 Figure 1: XMPP-Grid Architecture
285 Nodes must connect to the XMPP-Grid controller to authenticate and
286 establish appropriate authorizations, with appropriate authorization
287 privileges. The control plane messaging is established through XMPP
288 and shown as "A" (Control plane interface) in Figure 1. Authorized
289 nodes may then share data either thru the XMPP-Grid Controller (shown
290 as "B" in Figure 1) or directly (shown as "C" in Figure 1). The data
291 messaging enable Nodes to:
293 o Receive real-time events of the published messages from the
294 publisher through Topic subscriptions
296 o Make directed queries to other Nodes in the XMPP-Grid with
297 appropriate authorization from the Controller
299 o Negotiate out-of-band secure file transfer channel with the peer
301 2.1. Using XMPP
303 XMPP is used as the foundation message routing protocol for
304 exchanging security data between systems across XMPP-Grid. XMPP is a
305 communications protocol for message-oriented middleware based on XML.
306 Designed to be extensible, the protocol uses de-centralized client-
307 server architecture where the clients connect to the servers securely
308 and the messages between the clients are routed through the XMPP
309 servers deployed within the cluster. XMPP has been used extensively
310 for publish-subscribe systems, file transfer, video, VoIP, Internet
311 of Things, Smart Grid Software Defined Networks (SDN) and other
312 collaboration and social networking applications. The following are
313 the 4 IETF specifications produced by the XMPP working group:
315 o [RFC7590] Extensible Messaging and Presence Protocol (XMPP): Core
317 o [RFC6121] Extensible Messaging and Presence Protocol (XMPP):
318 Instant Messaging and Presence
320 o [RFC3922] Mapping the Extensible Messaging and Presence Protocol
321 (XMPP) to Common Presence and Instant Messaging (CPIM)
323 o [RFC3923] End-to-End Signing and Object Encryption for the
324 Extensible Messaging and Presence Protocol (XMPP)
326 XMPP offers several of the following salient features for building a
327 security data interexchange protocol:
329 o Open - standards-based, decentralized and federated architecture,
330 with no single point of failure
332 o Security - Supports domain segregations and federation. Offers
333 strong security via Simple Authentication and Security Layer
334 (SASL) [RFC4422] and Transport Layer Security (TLS) [RFC5246].
336 o Real-time event management/exchange - using publish, subscribe
337 notifications
339 o Flexibility and Extensibility - XMPP is XML based and is easily
340 extensible to adapt to new use-cases. Custom functionality can be
341 built on top of it.
343 o Multiple information exchanges - XMPP offers multiple information
344 exchange mechanisms between the participating clients -
346 o
348 * Real-time event notifications through publish and subscribe.
350 * On-demand or directed queries between the clients communicated
351 through the XMPP server
353 * Facilitates out-of-band, direct communication between
354 participating clients
356 o Bi-directional - avoids firewall tunneling and avoids opening up a
357 new connection in each direction between client and server.
359 o Scalable - supports cluster mode deployment with fan-out and
360 message routing
362 o Peer-to-peer communications also enables scale - directed queries
363 and out-of-band file transfer support
365 o XMPP offers Node availability, Node service capability discovery,
366 and Node presence within the XMPP network. Nodes ability to
367 detect the availability, presence and capabilities of other
368 participating nodes eases turnkey deployment.
370 The XMPP extensions used in XMPP-Grid are now part (e.g. publish/
371 subscribe) of the main XMPP specification [RFC7590] and the presence
372 in [RFC6121]. A full list of XMPP Extension Protocols (XEPs)
373 [RFC7590] can be found in http://xmpp.org/extensions/xep-0001.html .
375 2.2. XMPP-Grid Requirements for enabling Information Sharing
377 This section summarizes the requirements and the extensions used to
378 facilitate the secure sharing of information using XMPP. Knowledge
379 of the XMPP Protocol and extensions is required to understand this
380 section.
382 o Authentication and Authorization: Nodes participating in XMPP-Grid
383 MUST mutually authenticate to the controller using XMPP's
384 authentication mechanisms. Authorization is affected by the
385 controller.
387 o Topic Discovery: to facilitate dynamic discovery, Nodes SHOULD
388 support the XMPP Service Discovery [XEP-0030].
390 o Publish/Subscribe: to facilitate unsolicited notifications to new
391 or updated security information, Nodes MUST support the XMPP
392 Publish/Subscribe protocol as defined in [RFC7590].
394 Once a Node has authenticated with the XMPP-Grid controller, it may
395 further register a topic (e.g. information type) to be shared or use
396 the discovery mechanism for determining topics to be consumed.
397 Sharing Information: security information may be shared using
398 registered topics. An example for sharing or consuming the IODEF 1.0
399 is defined in [XEP-0268].
401 3. Example use of XMPP-Grid for IODEF
403 A Node follows the standard XMPP workflow for connecting to the
404 Controller as well as using the XMPP discovery mechanisms to discover
405 the availability to consume IODEF information. The general workflow
406 is summarized in the figure below:
408 |----------------| |----------------| |----------------|
409 | IODEF Client | | XMPP Server | | IODEF Service |
410 | (Subscriber) | | (Controller) | | (Publisher) |
411 |----------------| |----------------| |----------------|
412 | | |
413 | IODEF Client Authentication | |
414 |<---------------------------------->| |
415 | | IODEF Service Authentication |
416 | |<--------------------------------->|
417 | | Create IODEFas a Topic (XEP-0060) |
418 | |<----------------------------------|
419 | | Topic Creation Success |
420 | |---------------------------------->|
421 | Topic Discovery (XEP-0030) | |
422 |----------------------------------->| |
423 | Discovery Response with Topics | |
424 |<-----------------------------------| |
425 | | |
426 | Subscribe to IODEF Topic (XEP-0060)| |
427 |----------------------------------->| |
428 | Subscription Success | |
429 |<-----------------------------------| |
430 | | IODEF Incident Publish (XEP-0268) |
431 | IODEF Incident Publish |<----------------------------------|
432 |<-----------------------------------| |
433 | | |
435 Figure 2: IODEF Example XMPP Workflow
437 An example XMPP discovery request for an IODEF 1.0 topic is shown
438 below:
440
444
445
447 An example XMPP discovery response for an IODEF 1.0 topic is shown
448 below:
450
454
455
458
459
461 4. IANA Considerations
463 IODEF extensions as defined in [XEP-0268] may require IANA
464 considerations and assignment thru the IODEF IANA rules.
466 5. Security Considerations
468 An XMPP-Grid Controller serves as an controlling broker for XMPP-Grid
469 Nodes such as Enforcement Points, Policy Servers, CMDBs, and Sensors,
470 using a publish-subscribe-search model of information exchange and
471 lookup. By increasing the ability of XMPP-Grid Nodes to learn about
472 and respond to security-relevant events and data, XMPP-Grid can
473 improve the timeliness and utility of the security system. However,
474 this integrated security system can also be exploited by attackers if
475 they can compromise it. Therefore, strong security protections for
476 XMPP-Grid are essential.
478 This section provides a security analysis of the XMPP-Grid transport
479 protocol and the architectural elements that employ it, specifically
480 with respect to their use of this protocol. Three subsections define
481 the trust model (which elements are trusted to do what), the threat
482 model (attacks that may be mounted on the system), and the
483 countermeasures (ways to address or mitigate the threats previously
484 identified).
486 5.1. Trust Model
488 The first step in analyzing the security of the XMPP-Grid transport
489 protocol is to describe the trust model, listing what each
490 architectural element is trusted to do. The items listed here are
491 assumptions, but provisions are made in the Threat Model and
492 Countermeasures sections for elements that fail to perform as they
493 were trusted to do.
495 5.1.1. Network
497 The network used to carry XMPP-Grid messages is trusted to:
499 o Perform best effort delivery of network traffic
501 The network used to carry XMPP-Grid messages is not expected
502 (trusted) to:
504 o Provide confidentiality or integrity protection for messages sent
505 over it
507 o Provide timely or reliable service
509 5.1.2. XMPP-Grid Nodes
511 Authorized XMPP-Grid Nodes are trusted to:
513 o Preserve the confidentiality of sensitive data retrieved via the
514 XMPP-Grid Controller
516 5.1.3. XMPP-Grid Controller
518 The XMPP-Grid Controller is trusted to:
520 o Broker requests for data and enforce authorization of access to
521 this data throughout its lifecycle
523 o Perform service requests in a timely and accurate manner
525 o Create and maintain accurate operational attributes
527 o Only reveal data to and accept service requests from authorized
528 parties
530 The XMPP-Grid Controller is not expected (trusted) to:
532 o Verify the truth (correctness) of data
534 5.1.4. Certification Authority
536 The Certification Authority (CA) that issues certificates for the
537 XMPP-Grid Controller and/or XMPP-Grid Nodes (or each CA, if there are
538 several) is trusted to:
540 o Ensure that only proper certificates are issued and that all
541 certificates are issued in accordance with the CA's policies
543 o Revoke certificates previously issued when necessary
545 o Regularly and securely distribute certificate revocation
546 information
548 o Promptly detect and report any violations of this trust so that
549 they can be handled
551 The CA is not expected (trusted) to:
553 o Issue certificates that go beyond the XMPP-Grid needs or other
554 constraints imposed by a relying party.
556 5.2. Threat Model
558 To secure the XMPP-Grid transport protocol and the architectural
559 elements that implement it, this section identifies the attacks that
560 can be mounted against the protocol and elements.
562 5.2.1. Network Attacks
564 A variety of attacks can be mounted using the network. For the
565 purposes of this subsection the phrase "network traffic" should be
566 taken to mean messages and/or parts of messages. Any of these
567 attacks may be mounted by network elements, by parties who control
568 network elements, and (in many cases) by parties who control network-
569 attached devices.
571 o Network traffic may be passively monitored to glean information
572 from any unencrypted traffic
574 o Even if all traffic is encrypted, valuable information can be
575 gained by traffic analysis (volume, timing, source and destination
576 addresses, etc.)
578 o Network traffic may be modified in transit
580 o Previously transmitted network traffic may be replayed
582 o New network traffic may be added
584 o Network traffic may be blocked, perhaps selectively
586 o A "Man In The Middle" (MITM) attack may be mounted where an
587 attacker interposes itself between two communicating parties and
588 poses as the other end to either party or impersonates the other
589 end to either or both parties
591 o Resist attacks (including denial of service and other attacks from
592 XMPP-Grid Nodes)
594 o Undesired network traffic may be sent in an effort to overload an
595 architectural component, thus mounting a denial of service attack
597 5.2.2. XMPP-Grid Nodes
599 An unauthorized XMPP-Grid Nodes (one which is not recognized by the
600 XMPP-Grid Controller or is recognized but not authorized to perform
601 any actions) cannot mount any attacks other than those listed in the
602 Network Attacks section above.
604 An authorized XMPP-Grid Node, on the other hand, can mount many
605 attacks. These attacks might occur because the XMPP-Grid Node is
606 controlled by a malicious, careless, or incompetent party (whether
607 because its owner is malicious, careless, or incompetent or because
608 the XMPP-Grid Node has been compromised and is now controlled by a
609 party other than its owner). They might also occur because the XMPP-
610 Grid Node is running malicious software; because the XMPP-Grid Node
611 is running buggy software (which may fail in a state that floods the
612 network with traffic); or because the XMPP-Grid Node has been
613 configured improperly. From a security standpoint, it generally
614 makes no difference why an attack is initiated. The same
615 countermeasures can be employed in any case.
617 Here is a list of attacks that may be mounted by an authorized XMPP-
618 Grid Node:
620 o Cause many false alarms or otherwise overload the XMPP-Grid
621 Controller or other elements in the network security system
622 (including human administrators) leading to a denial of service or
623 disabling parts of the network security system
625 o Omit important actions (such as posting incriminating data),
626 resulting in incorrect access
628 o Use confidential information obtained from the XMPP-Grid
629 Controller to enable further attacks (such as using endpoint
630 health check results to exploit vulnerable endpoints)
632 o Advertise data crafted to exploit vulnerabilities in the XMPP-Grid
633 Controller or in other XMPP-Grid Nodes, with a goal of
634 compromising those systems
636 o Issue a search request or set up a subscription that matches an
637 enormous result, leading to resource exhaustion on the XMPP-Grid
638 Controller, the publishing XMPP-Grid Node, and/or the network
640 o Establish a communication channel using another XMPP-Grid Node's
641 session-id
643 Dependencies of or vulnerabilities of authorized XMPP-Grid Nodes may
644 be exploited to effect these attacks. Another way to effect these
645 attacks is to gain the ability to impersonate an XMPP-Grid Node
646 (through theft of the XMPP-Grid Node's identity credentials or
647 through other means). Even a clock skew between the XMPP-Grid Node
648 and XMPP-Grid Controller can cause problems if the XMPP-Grid Node
649 assumes that old XMPP-Grid Node data should be ignored.
651 5.2.3. XMPP-Grid Controllers
653 An unauthorized XMPP-Grid Controller (one which is not trusted by
654 XMPP-Grid Nodes) cannot mount any attacks other than those listed in
655 the Network Attacks section above.
657 An authorized XMPP-Grid Controller can mount many attacks. Similar
658 to the XMPP-Grid Node case described above, these attacks might occur
659 because the XMPP-Grid Controller is controlled by a malicious,
660 careless, or incompetent party (either an XMPP-Grid Controller
661 administrator or an attacker who has seized control of the XMPP-Grid
662 Controller). They might also occur because the XMPP-Grid Controller
663 is running malicious software, because the XMPP-Grid Controller is
664 running buggy software (which may fail in a state that corrupts data
665 or floods the network with traffic), or because the XMPP-Grid
666 Controller has been configured improperly.
668 All of the attacks listed for XMPP-Grid Node above can be mounted by
669 the XMPP-Grid Controller. Detection of these attacks will be more
670 difficult since the XMPP-Grid Controller can create false operational
671 attributes and/or logs that imply some other party created any bad
672 data.
674 Additional XMPP-Grid Controller attacks may include:
676 o Expose different data to different XMPP-Grid Nodes to mislead
677 investigators or cause inconsistent behavior
679 o Mount an even more effective denial of service attack than a
680 single XMPP-Grid Node could
682 o Obtain and cache XMPP-Grid Node credentials so they can be used to
683 impersonate XMPP-Grid Nodes even after a breach of the XMPP-Grid
684 Controller is repaired
686 o Obtain and cache XMPP-Grid Controller administrator credentials so
687 they can be used to regain control of the XMPP-Grid Controller
688 after the breach of the XMPP-Grid Controller is repaired
690 Dependencies of or vulnerabilities of the XMPP-Grid Controller may be
691 exploited to obtain control of the XMPP-Grid Controller and effect
692 these attacks.
694 5.2.4. Certification Authority
696 A Certification Authority trusted to issue certificates for the XMPP-
697 Grid Controller and/or XMPP-Grid Nodes can mount several attacks:
699 o Issue certificates for unauthorized parties, enabling them to
700 impersonate authorized parties such as the XMPP-Grid Controller or
701 an XMPP-Grid Node. This can lead to all the threats that can be
702 mounted by the certificate's subject.
704 o Issue certificates without following all of the CA's policies.
705 Because this can result in issuing certificates that may be used
706 to impersonate authorized parties, this can lead to all the
707 threats that can be mounted by the certificate's subject.
709 o Fail to revoke previously issued certificates that need to be
710 revoked. This can lead to undetected impersonation of the
711 certificate's subject or failure to revoke authorization of the
712 subject, and therefore can lead to all of the threats that can be
713 mounted by that subject.
715 o Fail to regularly and securely distribute certificate revocation
716 information. This may cause a relying party to accept a revoked
717 certificate, leading to undetected impersonation of the
718 certificate's subject or failure to revoke authorization of the
719 subject, and therefore can lead to all of the threats that can be
720 mounted by that subject. It can also cause a relying party to
721 refuse to proceed with a transaction because timely revocation
722 information is not available, even though the transaction should
723 be permitted to proceed.
725 o Allow the CA's private key to be revealed to an unauthorized
726 party. This can lead to all the threats above. Even worse, the
727 actions taken with the private key will not be known to the CA.
729 o Fail to promptly detect and report errors and violations of trust
730 so that relying parties can be promptly notified. This can cause
731 the threats listed earlier in this section to persist longer than
732 necessary, leading to many knock-on effects.
734 5.3. Countermeasures
736 Below are countermeasures for specific attack scenarios to the XMPP-
737 Grid infrastructure.
739 5.3.1. Securing the XMPP-Grid Transport Protocol
741 To address network attacks, the XMPP-Grid transport protocol
742 described in this document requires that the XMPP-Grid messages MUST
743 be carried over TLS (minimally TLS 1.2 [RFC5246]) as described in
744 [RFC2818]. The XMPP-Grid Node MUST verify the XMPP-Grid Controller's
745 certificate and determine whether the XMPP-Grid Controller is trusted
746 by this XMPP-Grid Node before completing the TLS handshake. The
747 XMPP-Grid Controller MUST authenticate the XMPP-Grid Node either
748 using mutual certificate-based authentication in the TLS handshake or
749 using Basic Authentication as described in IETF RFC 2617. XMPP-Grid
750 Controller MUST use Simple Authentication and Security Layer (SASL),
751 described in [RFC4422], to support the aforesaid authentication
752 mechanisms. SASL offers authentication mechanism negotiations
753 between the XMPP-Grid Controller and XMPP-Grid node during the
754 connection establishment phase. XMPP-Grid Nodes and XMPP-Grid
755 Controllers using mutual certificate-based authentication SHOULD each
756 verify the revocation status of the other party's certificate. All
757 XMPP-Grid Controllers and XMPP-Grid Nodes MUST implement both mutual
758 certificate-based authentication and Basic Authentication. The
759 selection of which XMPP-Grid Node authentication technique to use in
760 any particular deployment is left to the administrator.
762 An XMPP-Grid Controller MAY also support a local, configurable set of
763 Basic Authentication userid-password pairs. If so, it is
764 implementation dependent whether an XMPP-Grid Controller ends a
765 session when an administrator changes the configured password. Since
766 Basic Authentication has many security disadvantages (especially the
767 transmission of reusable XMPP-Grid Node passwords to the XMPP-Grid
768 Controller), it SHOULD only be used when absolutely necessary. Per
769 the HTTP specification, when basic authentication is in use, an XMPP-
770 Grid Controller MAY respond to any request that lacks credentials
771 with an error code similar to HTTP code 401. An XMPP-Grid Node
772 SHOULD avoid this code by submitting basic auth credentials with
773 every request when basic authentication is in use. If it does not do
774 so, an XMPP-Grid Node MUST respond to this code by resubmitting the
775 same request with credentials (unless the XMPP-Grid Node is shutting
776 down).
778 As XMPP uses TLS as the transport and security mechanisms, it is
779 understood that best practices such as those in
780 [I-D.ietf-uta-tls-bcp] are followed.
782 These protocol security measures provide protection against all the
783 network attacks listed in the above document section except denial of
784 service attacks. If protection against these denial of service
785 attacks is desired, ingress filtering, rate limiting per source IP
786 address, and other denial of service mitigation measures may be
787 employed. In addition, an XMPP-Grid Controller MAY automatically
788 disable a misbehaving XMPP-Grid Node.
790 5.3.2. Securing XMPP-Grid Nodes
792 XMPP-Grid Nodes may be deployed in locations that are susceptible to
793 physical attacks. Physical security measures may be taken to avoid
794 compromise of XMPP-Grid Nodes, but these may not always be practical
795 or completely effective. An alternative measure is to configure the
796 XMPP-Grid Controller to provide read-only access for such systems.
797 The XMPP-Grid Controller SHOULD also include a full authorization
798 model so that individual XMPP-Grid Nodes may be configured to have
799 only the privileges that they need. The XMPP-Grid Controller MAY
800 provide functional templates so that the administrator can configure
801 a specific XMPP-Grid Node as a DHCP server and authorize only the
802 operations and metadata types needed by a DHCP server to be permitted
803 for that XMPP-Grid Node. These techniques can reduce the negative
804 impacts of a compromised XMPP-Grid Node without diminishing the
805 utility of the overall system.
807 To handle attacks within the bounds of this authorization model, the
808 XMPP-Grid Controller MAY also include rate limits and alerts for
809 unusual XMPP-Grid Node behavior. XMPP-Grid Controllers SHOULD make
810 it easy to revoke an XMPP-Grid Node's authorization when necessary.
811 Another way to detect attacks from XMPP-Grid Nodes is to create fake
812 entries in the available data (honeytokens) which normal XMPP-Grid
813 Nodes will not attempt to access. The XMPP-Grid Controller SHOULD
814 include auditable logs of XMPP-Grid Node activities.
816 To avoid compromise of XMPP-Grid Node, XMPP-Grid Node SHOULD be
817 hardened against attack and minimized to reduce their attack surface.
818 They should be well managed to minimize vulnerabilities in the
819 underlying platform and in systems upon which the XMPP-Grid Node
820 depends. Personnel with administrative access should be carefully
821 screened and monitored to detect problems as soon as possible.
823 5.3.3. Securing XMPP-Grid Controllers
825 Because of the serious consequences of XMPP-Grid Controller
826 compromise, XMPP-Grid Controllers SHOULD be especially well hardened
827 against attack and minimized to reduce their attack surface. They
828 should be well managed to minimize vulnerabilities in the underlying
829 platform and in systems upon which the XMPP-Grid Controller depends.
831 Network security measures such as firewalls or intrusion detection
832 systems may be used to monitor and limit traffic to and from the
833 XMPP-Grid Controller. Personnel with administrative access should be
834 carefully screened and monitored to detect problems as soon as
835 possible. Administrators should not use password-based
836 authentication but should instead use non-reusable credentials and
837 multi-factor authentication (where available). Physical security
838 measures SHOULD be employed to prevent physical attacks on XMPP-Grid
839 Controllers.
841 To ease detection of XMPP-Grid Controller compromise should it occur,
842 XMPP-Grid Controller behavior should be monitored to detect unusual
843 behavior (such as a reboot, a large increase in traffic, or different
844 views of an information repository for similar XMPP-Grid Nodes).
845 XMPP-Grid Nodes should log and/or notify administrators when peculiar
846 XMPP-Grid Controller behavior is detected. To aid forensic
847 investigation, permanent read-only audit logs of security-relevant
848 information (especially administrative actions) should be maintained.
849 If XMPP-Grid Controller compromise is detected, a careful analysis
850 should be performed of the impact of this compromise. Any reusable
851 credentials that may have been compromised should be reissued.
853 5.3.4. Limit on search result size
855 While XMPP-Grid is designed for high scalability to 100,000s of
856 Nodes, an XMPP-Grid Controller MAY establish a limit to the amount of
857 data it is willing to return in search or subscription results. This
858 mitigates the threat of an XMPP-Grid Node causing resource exhaustion
859 by issuing a search or subscription that leads to an enormous result.
861 5.3.5. Cryptographically random session-id and authentication checks
862 for ARC
864 An XMPP-Grid Controller SHOULD ensure that the XMPP-Grid Node
865 establishing an Authenticated Results Chain (ARC) is the same XMPP-
866 Grid Node as the XMPP-Grid Node that established the corresponding
867 Synchronization Source Identifier (SSRC). The XMPP-Grid Controller
868 SHOULD employ both of the following strategies:
870 o session-ids SHOULD be cryptographically random
872 o The HTTPS transport for the SSRC and the ARC SHOULD be
873 authenticated using the same credentials. SSL session resumption
874 MAY be used to establish the ARC based on the SSRC SSL session.
876 5.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 Nodes 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 may 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 may still be consulted if a pinned certificate is
900 revoked, since the CA and revocation process are not completely
901 trusted.
903 5.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 transport protocol provides strong protection against a
912 variety of different attacks. In the event that an XMPP-Grid Node or
913 XMPP-Grid Controller is compromised, the effects of this compromise
914 have been reduced and limited with the recommended role-based
915 authorization model and other provisions, and best practices for
916 managing and protecting XMPP-Grid systems have been described. Taken
917 together, these measures should provide protection commensurate with
918 the threat to XMPP-Grid systems, thus ensuring that they fulfill
919 their promise as a network security clearing-house.
921 6. Privacy Considerations
923 XMPP-Grid Nodes may publish information about endpoint health,
924 network access, events (which may 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 may be queried by other XMPP-Grid Nodes 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 Nodes for
933 intrusion detection, could be misused by a broader set of XMPP-Grid
934 Nodes which hitherto have been performing specific roles with strict
935 well-defined separation of duties.
937 Care should be taken by deployers of XMPP-Grid to ensure that the
938 information published by XMPP-Grid Nodes does not violate agreements
939 with end users or local and regional laws and regulations. This can
940 be accomplished either by configuring XMPP-Grid Nodes to not publish
941 certain information or by restricting access to sensitive data to
942 trusted XMPP-Grid Nodes. That is, the easiest means to ensure
943 privacy or protect sensitive data, is to omit or not share it at all.
945 Another consideration for deployers is to enable end-to-end
946 encryption to ensure the data is protected from the data layer to
947 data layer and thus protect it from the transport layer.
949 7. Acknowledgements
951 The authors would like to acknowledge the contributions, authoring
952 and/or editing of the following people: Joseph Salowey, Lisa
953 Lorenzin, Clifford Kahn, Henk Birkholz, Jessica Fitzgerald-McKay,
954 Steve Hanna, and Steve Venema. In addition, we want to thank Takeshi
955 Takahashi, Panos Kampanakis, Adam Montville and Chris Inacio for
956 reviewing and providing valuable comments.
958 8. References
960 8.1. Normative References
962 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
963 Requirement Levels", BCP 14, RFC 2119,
964 DOI 10.17487/RFC2119, March 1997,
965 .
967 [RFC3922] Saint-Andre, P., "Mapping the Extensible Messaging and
968 Presence Protocol (XMPP) to Common Presence and Instant
969 Messaging (CPIM)", RFC 3922, DOI 10.17487/RFC3922, October
970 2004, .
972 [RFC3923] Saint-Andre, P., "End-to-End Signing and Object Encryption
973 for the Extensible Messaging and Presence Protocol
974 (XMPP)", RFC 3923, DOI 10.17487/RFC3923, October 2004,
975 .
977 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
978 Authentication and Security Layer (SASL)", RFC 4422,
979 DOI 10.17487/RFC4422, June 2006,
980 .
982 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence
983 Protocol (XMPP): Instant Messaging and Presence",
984 RFC 6121, DOI 10.17487/RFC6121, March 2011,
985 .
987 [RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer
988 Security (TLS) in the Extensible Messaging and Presence
989 Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June
990 2015, .
992 [XEP-0030]
993 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint-
994 Andre, "Service Discovery", XSF XEP 0030, July 2010.
996 [XEP-0060]
997 Millard, P. and P. Saint-Andre, "Publish-Subscribe",
998 XSF XEP 0060, December 2016.
1000 [XEP-0268]
1001 Hefczyc, A., Jensen, F., Remond, M., Saint-Andre, P., and
1002 M. Wild, "Service Discovery", XSF XEP 0268, MY 2012.
1004 8.2. Informative References
1006 [I-D.ietf-mile-rolie]
1007 Field, J., Banghart, S., and D. Waltermire, "Resource-
1008 Oriented Lightweight Information Exchange", draft-ietf-
1009 mile-rolie-07 (work in progress), May 2017.
1011 [I-D.ietf-uta-tls-bcp]
1012 Sheffer, Y., Holz, R., and P. Saint-Andre,
1013 "Recommendations for Secure Use of TLS and DTLS", draft-
1014 ietf-uta-tls-bcp-11 (work in progress), February 2015.
1016 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
1017 DOI 10.17487/RFC2818, May 2000,
1018 .
1020 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
1021 (TLS) Protocol Version 1.2", RFC 5246,
1022 DOI 10.17487/RFC5246, August 2008,
1023 .
1025 [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)",
1026 RFC 6545, DOI 10.17487/RFC6545, April 2012,
1027 .
1029 [RFC6546] Trammell, B., "Transport of Real-time Inter-network
1030 Defense (RID) Messages over HTTP/TLS", RFC 6546,
1031 DOI 10.17487/RFC6546, April 2012,
1032 .
1034 [RFC7970] Danyliw, R., "The Incident Object Description Exchange
1035 Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
1036 November 2016, .
1038 Authors' Addresses
1040 Nancy Cam-Winget (editor)
1041 Cisco Systems
1042 3550 Cisco Way
1043 San Jose, CA 95134
1044 USA
1046 Email: ncamwing@cisco.com
1048 Syam Appala
1049 Cisco Systems
1050 3550 Cisco Way
1051 San Jose, CA 95134
1052 USA
1054 Email: syam1@cisco.com
1055 Scott Pope
1056 Cisco Systems
1057 5400 Meadows Road
1058 Suite 300
1059 Lake Oswego, OR 97035
1060 USA
1062 Email: scottp@cisco.com