MILE N. Cam-Winget, Ed.
Internet-Draft S. Appala
Intended status: Standards Track S. Pope
Expires: May 3, 2018 Cisco Systems
P. Saint-Andre
Jabber.org
October 30, 2017
Using XMPP for Security Information Exchange
draft-ietf-mile-xmpp-grid-04
Abstract
This document describes how to use the Extensible Messaging and
Presence Protocol (XMPP) as a transport for collecting and
distributing security-relevant information between network-connected
devices. To illustrate the principles involved, this document
describes such a usage for the Incident Object Description Exchange
Format (IODEF).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Cam-Winget, et al. Expires May 3, 2018 [Page 1]
Internet-Draft XMPP Grid October 2017
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Service Discovery . . . . . . . . . . . . . . . . . . . . . . 6
6. IODEF Example . . . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 9
8.1.1. Network . . . . . . . . . . . . . . . . . . . . . . . 10
8.1.2. XMPP-Grid Platforms . . . . . . . . . . . . . . . . . 10
8.1.3. XMPP-Grid Controller . . . . . . . . . . . . . . . . 10
8.1.4. Certification Authority . . . . . . . . . . . . . . . 10
8.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 11
8.2.1. Network Attacks . . . . . . . . . . . . . . . . . . . 11
8.2.2. XMPP-Grid Platforms . . . . . . . . . . . . . . . . . 12
8.2.3. XMPP-Grid Controllers . . . . . . . . . . . . . . . . 13
8.2.4. Certification Authority . . . . . . . . . . . . . . . 14
8.3. Countermeasures . . . . . . . . . . . . . . . . . . . . . 15
8.3.1. Securing the XMPP-Grid Transport Protocol . . . . . . 15
8.3.2. Securing XMPP-Grid Platforms . . . . . . . . . . . . 16
8.3.3. Securing XMPP-Grid Controllers . . . . . . . . . . . 16
8.3.4. Limit on search result size . . . . . . . . . . . . . 17
8.3.5. Cryptographically random session-id and
authentication checks for ARC . . . . . . . . . . . . 17
8.3.6. Securing the Certification Authority . . . . . . . . 18
8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
This document describes "XMPP-Grid": a method for using the
Extensible Messaging and Presence Protocol (XMPP) [RFC6120] as a
transport for collecting and distributing security-relevant
information among network platforms, endpoints, and any other
network-connected device. Among other services, XMPP provides a
Cam-Winget, et al. Expires May 3, 2018 [Page 2]
Internet-Draft XMPP Grid October 2017
publish-subscribe service that acts as a broker, providing control-
plane functions by which entities can discover available information
to be published or consumed. Although such information can take the
form of any structured data (XML, JSON, etc.), this document uses the
Incident Object Description Exchange Format (IODEF) [RFC7970] to
illustrate the principles of XMPP-Grid.
2. Terminology
This document uses XMPP terminology defined in [RFC6120] and
[XEP-0060] as well as Security Automation and Continuous Monitoring
(SACM) terminology defined in [I-D.ietf-sacm-terminology]. Because
the intended audience for this document consists of those who
implement and deploy security reporting systems, in general the SACM
terms are used here (however, mappings are provided for the benefit
of XMPP developers and operators).
Broker: As defined in [I-D.ietf-sacm-terminology], a Broker is a
specific type of controller containing control plane functions; as
used here, the term refers to an XMPP publish-subscribe service.
Broker Flow: A method by which security-related information is
published and consumed in a mediated fashion through a Broker. In
this flow, the Broker handles authorization of Subscribers and
Publishers to Topics, receives messages from Publishers, and
delivers published messages to Subscribers.
Consumer: As defined in [I-D.ietf-sacm-terminology], a Consumer is a
component that contains functions to receive information from
other components; as used here, the term refers to an XMPP
publish-subscribe Subscriber.
Controller: As defined in [I-D.ietf-sacm-terminology], a controller
is a "component containing control plane functions that manage and
facilitate information sharing or execute on security functions";
as used here, the term refers to either an XMPP server, which
provides both core message delivery [RFC6120] used by publish-
subscribe entities.
Node: The term used in the XMPP publish-subscribe specification
[XEP-0060] for a Topic.
Platform: Any entity that implements connects to the XMPP-Grid in
order to publisher or consume security-related data.
Provider: As defined in [I-D.ietf-sacm-terminology], a Provider is a
component that contains functions to provide information to other
Cam-Winget, et al. Expires May 3, 2018 [Page 3]
Internet-Draft XMPP Grid October 2017
components; as used here, the term refers to an XMPP publish-
subscribe Publisher.
Publisher: The term used in the XMPP publish-subscribe specification
[XEP-0060] for a Provider.
Publish-Subscribe Service: A Broker that implements the XMPP
publish-subscribe extension [XEP-0060].
Subscriber: The term used in the XMPP publish-subscribe
specification [XEP-0060] for a Consumer.
Topic: A contextual information channel created on a Broker at which
messages generated by a Publisher will be propagated by XMPP in
real time to one or more Subscribers. Each Topic is limited to a
type and format of security data (e.g., IODEF) that a platform
wants to share with other platform(s) and a specified interface by
which the data can be obtained.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Architecture
The following figure illustrates the architecture of XMPP-Grid.
Cam-Winget, et al. Expires May 3, 2018 [Page 4]
Internet-Draft XMPP Grid October 2017
+--------------------------------------+
| +--------------------------------------+
| | +--------------------------------------+
| | | |
+-| | Platforms |
+-| |
+--------------------------------------+
/ \ / \ / \
/ C \ / \ / \
- o - - d - - -
||n||A | a |B | |C
||t|| | t | | |
- r - - a - | |
\ o / \ / | |
\ l / \ / | |
/|---------------------|\ | |
/|----/ \--------| d |--|\
/ / Controller \ ctrl | a | \
\ \ & Broker / plane | t | /
\|----\ /--------| a |--|/
\|---------------------|/ | |
/ \ / \ | |
/ C \ / \ | |
- o - - d - | |
||n||A | a |B | |C
||t|| | t | | |
- r - - a - - -
\ o / \ / \ /
\ l / \ / \ /
+------------------------------------+
| |-+
| Platforms | |
| | |-+
+------------------------------------+ | |
+------------------------------------+ |
+------------------------------------+
Figure 1: XMPP-Grid Architecture
Platforms connect to the Controller (XMPP server) to authenticate and
and then establish appropriate authorizations and relationships
(e.g., Publisher or Subscriber) at the Broker (XMPP publish-subscribe
service). The control plane messaging is established through XMPP
and shown as "A" (control plane interface) in Figure 1. Authorized
nodes may then share data either thru the Broker (shown as "B" in
Figure 1) or in some cases directly (shown as "C" in Figure 1). This
document focuses primarily on the Broker Flow for information sharing
(although "direct flow" interactions can be used for specialized
Cam-Winget, et al. Expires May 3, 2018 [Page 5]
Internet-Draft XMPP Grid October 2017
purposes such as bulk data transfer, methods for doing so are outside
the scope of this document).
4. Workflow
A typical XMPP-Grid workflow is as follows:
a. A Platform with a source of security data requests connection to
the XMPP-Grid via a Controller (XMPP server).
b. The Controller authenticates the Platform.
c. The Platform establishes authorized privileges (e.g. privilege to
publish and/or subscribe to security data Topics) with a Broker.
d. The Platform may publish security-related data to a Topic,
subscribe to a Topic, query a Topic, or any combination of these
operations.
e. A Publisher unicasts its Topic updates to the Grid in real time
through a Broker. The Broker handles replication and
distribution of the Topic to Subscribers. A Publisher may
publish the same or different data to multiple Topics.
f. Any Platform on the Grid may subscribe to any Topics published to
the Grid (as permitted by authorization policy), and (as
Subscribers) will then receive a continuous, real-time stream of
updates from the Topics to which they are subscribed.
5. Service Discovery
Using the XMPP service discovery extension [XEP-0030], a Controller
enables Platforms to discover what information may be consumed
through the Broker (publish-subscribe service). For instance, the
Controller might provide a Broker at 'broker.security-grid.example',
where 'security-grid.example' is the Controller host. Below is an
example for how a Platform can query for available information from
the XMPP-Controller:
<iq type='get'
from='xmpp-grid-client@mile-host.example/postures'
to='broker.security-grid.example'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
The XMPP-Controller responds with the different types of information
it can publish:
Cam-Winget, et al. Expires May 3, 2018 [Page 6]
Internet-Draft XMPP Grid October 2017
<iq type='result'
from='broker.security-grid.example'
to='xmpp-grid-client@mile-host.example/postures'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#items'
node='secinfo'>
<item node='NEA1'
name='endpoint-posture'
jid='broker.security-grid.example'/>
<item node='MILEHost'
name='iodef-1.0'
jid='broker.security-grid.example'/>
</query>
</iq>
6. IODEF Example
A Platform follows the standard XMPP workflow for connecting to the
Controller as well as using the XMPP discovery mechanisms to discover
the availability to consume IODEF information. The general workflow
is summarized in the figure below:
Cam-Winget, et al. Expires May 3, 2018 [Page 7]
Internet-Draft XMPP Grid October 2017
+----------------+ +----------------+ +----------------+
| IODEF Client | | XMPP Server | | IODEF Service |
| (Subscriber) | | (Controller) | | (Publisher) |
+----------------+ +----------------+ +----------------+
| | |
| IODEF Client | |
| Authentication | |
|<------------------------>| |
| | IODEF Service |
| | Authentication |
| |<----------------------->|
| | Create IODEF as a Topic |
| | (XEP-0060) |
| |<------------------------|
| | Topic Creation Success |
| |------------------------>|
| Topic Discovery | |
| (XEP-0030) | |
|------------------------->| |
| Discovery Response | |
| with Topics | |
|<-------------------------| |
| | |
| Subscribe to IODEF Topic | |
| (XEP-0060) | |
|------------------------->| |
| Subscription Success | |
|<-------------------------| |
| | IODEF Incident Publish |
| IODEF Incident Publish |<------------------------|
|<-------------------------| |
| | |
Figure 2: IODEF Example Workflow
An example XMPP discovery request for an IODEF 1.0 topic is shown
below:
<iq type='get'
from='iodefclientabc@company.example'
to='pubsub.company.example'
id='nodes1'>
<query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
An example XMPP discovery response for an IODEF 1.0 topic is shown
below:
Cam-Winget, et al. Expires May 3, 2018 [Page 8]
Internet-Draft XMPP Grid October 2017
<iq type='result'
from='pubsub.company.example'
to='iodefclientabc@company.example'
id='nodes1'>
<query xmlns='http://jabber.org/protocol/disco#items'>
<item jid='pubsub.company.example'
node='incident'
name='IODEF incident report'/>
</query>
</iq>
7. IANA Considerations
This document has no actions for IANA.
8. Security Considerations
An XMPP-Grid Controller serves as an controlling broker for XMPP-Grid
Platforms such as Enforcement Points, Policy Servers, CMDBs, and
Sensors, using a publish-subscribe-search model of information
exchange and lookup. By increasing the ability of XMPP-Grid
Platforms to learn about and respond to security-relevant events and
data, XMPP-Grid can improve the timeliness and utility of the
security system. However, this integrated security system can also
be exploited by attackers if they can compromise it. Therefore,
strong security protections for XMPP-Grid are essential.
This section provides a security analysis of the XMPP-Grid transport
protocol and the architectural elements that employ it, specifically
with respect to their use of this protocol. Three subsections define
the trust model (which elements are trusted to do what), the threat
model (attacks that may be mounted on the system), and the
countermeasures (ways to address or mitigate the threats previously
identified).
8.1. Trust Model
The first step in analyzing the security of the XMPP-Grid transport
protocol is to describe the trust model, listing what each
architectural element is trusted to do. The items listed here are
assumptions, but provisions are made in the Threat Model and
Countermeasures sections for elements that fail to perform as they
were trusted to do.
Cam-Winget, et al. Expires May 3, 2018 [Page 9]
Internet-Draft XMPP Grid October 2017
8.1.1. Network
The network used to carry XMPP-Grid messages is trusted to:
o Perform best effort delivery of network traffic
The network used to carry XMPP-Grid messages is not expected
(trusted) to:
o Provide confidentiality or integrity protection for messages sent
over it
o Provide timely or reliable service
8.1.2. XMPP-Grid Platforms
Authorized XMPP-Grid Platforms are trusted to:
o Preserve the confidentiality of sensitive data retrieved via the
XMPP-Grid Controller
8.1.3. XMPP-Grid Controller
The XMPP-Grid Controller is trusted to:
o Broker requests for data and enforce authorization of access to
this data throughout its lifecycle
o Perform service requests in a timely and accurate manner
o Create and maintain accurate operational attributes
o Only reveal data to and accept service requests from authorized
parties
The XMPP-Grid Controller is not expected (trusted) to:
o Verify the truth (correctness) of data
8.1.4. Certification Authority
The Certification Authority (CA) that issues certificates for the
XMPP-Grid Controller and/or XMPP-Grid Platforms (or each CA, if there
are several) is trusted to:
o Ensure that only proper certificates are issued and that all
certificates are issued in accordance with the CA's policies
Cam-Winget, et al. Expires May 3, 2018 [Page 10]
Internet-Draft XMPP Grid October 2017
o Revoke certificates previously issued when necessary
o Regularly and securely distribute certificate revocation
information
o Promptly detect and report any violations of this trust so that
they can be handled
The CA is not expected (trusted) to:
o Issue certificates that go beyond the XMPP-Grid needs or other
constraints imposed by a relying party.
8.2. Threat Model
To secure the XMPP-Grid transport protocol and the architectural
elements that implement it, this section identifies the attacks that
can be mounted against the protocol and elements.
8.2.1. Network Attacks
A variety of attacks can be mounted using the network. For the
purposes of this subsection the phrase "network traffic" should be
taken to mean messages and/or parts of messages. Any of these
attacks may be mounted by network elements, by parties who control
network elements, and (in many cases) by parties who control network-
attached devices.
o Network traffic may be passively monitored to glean information
from any unencrypted traffic
o Even if all traffic is encrypted, valuable information can be
gained by traffic analysis (volume, timing, source and destination
addresses, etc.)
o Network traffic may be modified in transit
o Previously transmitted network traffic may be replayed
o New network traffic may be added
o Network traffic may be blocked, perhaps selectively
o A "Man In The Middle" (MITM) attack may be mounted where an
attacker interposes itself between two communicating parties and
poses as the other end to either party or impersonates the other
end to either or both parties
Cam-Winget, et al. Expires May 3, 2018 [Page 11]
Internet-Draft XMPP Grid October 2017
o Resist attacks (including denial of service and other attacks from
XMPP-Grid Platforms)
o Undesired network traffic may be sent in an effort to overload an
architectural component, thus mounting a denial of service attack
8.2.2. XMPP-Grid Platforms
An unauthorized XMPP-Grid Platforms (one which is not recognized by
the XMPP-Grid Controller or is recognized but not authorized to
perform any actions) cannot mount any attacks other than those listed
in the Network Attacks section above.
An authorized XMPP-Grid Platform, on the other hand, can mount many
attacks. These attacks might occur because the XMPP-Grid Platform is
controlled by a malicious, careless, or incompetent party (whether
because its owner is malicious, careless, or incompetent or because
the XMPP-Grid Platform has been compromised and is now controlled by
a party other than its owner). They might also occur because the
XMPP-Grid Platform is running malicious software; because the XMPP-
Grid Platform is running buggy software (which may fail in a state
that floods the network with traffic); or because the XMPP-Grid
Platform has been configured improperly. From a security standpoint,
it generally makes no difference why an attack is initiated. The
same countermeasures can be employed in any case.
Here is a list of attacks that may be mounted by an authorized XMPP-
Grid Platform:
o Cause many false alarms or otherwise overload the XMPP-Grid
Controller or other elements in the network security system
(including human administrators) leading to a denial of service or
disabling parts of the network security system
o Omit important actions (such as posting incriminating data),
resulting in incorrect access
o Use confidential information obtained from the XMPP-Grid
Controller to enable further attacks (such as using endpoint
health check results to exploit vulnerable endpoints)
o Advertise data crafted to exploit vulnerabilities in the XMPP-Grid
Controller or in other XMPP-Grid Platforms, with a goal of
compromising those systems
o Issue a search request or set up a subscription that matches an
enormous result, leading to resource exhaustion on the XMPP-Grid
Controller, the publishing XMPP-Grid Platform, and/or the network
Cam-Winget, et al. Expires May 3, 2018 [Page 12]
Internet-Draft XMPP Grid October 2017
o Establish a communication channel using another XMPP-Grid
Platform's session-id
Dependencies of or vulnerabilities of authorized XMPP-Grid Platforms
may be exploited to effect these attacks. Another way to effect
these attacks is to gain the ability to impersonate an XMPP-Grid
Platform (through theft of the XMPP-Grid Platform's identity
credentials or through other means). Even a clock skew between the
XMPP-Grid Platform and XMPP-Grid Controller can cause problems if the
XMPP-Grid Platform assumes that old XMPP-Grid Platform data should be
ignored.
8.2.3. XMPP-Grid Controllers
An unauthorized XMPP-Grid Controller (one which is not trusted by
XMPP-Grid Platforms) cannot mount any attacks other than those listed
in the Network Attacks section above.
An authorized XMPP-Grid Controller can mount many attacks. Similar
to the XMPP-Grid Platform case described above, these attacks might
occur because the XMPP-Grid Controller is controlled by a malicious,
careless, or incompetent party (either an XMPP-Grid Controller
administrator or an attacker who has seized control of the XMPP-Grid
Controller). They might also occur because the XMPP-Grid Controller
is running malicious software, because the XMPP-Grid Controller is
running buggy software (which may fail in a state that corrupts data
or floods the network with traffic), or because the XMPP-Grid
Controller has been configured improperly.
All of the attacks listed for XMPP-Grid Platform above can be mounted
by the XMPP-Grid Controller. Detection of these attacks will be more
difficult since the XMPP-Grid Controller can create false operational
attributes and/or logs that imply some other party created any bad
data.
Additional XMPP-Grid Controller attacks may include:
o Expose different data to different XMPP-Grid Platforms to mislead
investigators or cause inconsistent behavior
o Mount an even more effective denial of service attack than a
single XMPP-Grid Platform could
o Obtain and cache XMPP-Grid Platform credentials so they can be
used to impersonate XMPP-Grid Platforms even after a breach of the
XMPP-Grid Controller is repaired
Cam-Winget, et al. Expires May 3, 2018 [Page 13]
Internet-Draft XMPP Grid October 2017
o Obtain and cache XMPP-Grid Controller administrator credentials so
they can be used to regain control of the XMPP-Grid Controller
after the breach of the XMPP-Grid Controller is repaired
Dependencies of or vulnerabilities of the XMPP-Grid Controller may be
exploited to obtain control of the XMPP-Grid Controller and effect
these attacks.
8.2.4. Certification Authority
A Certification Authority trusted to issue certificates for the XMPP-
Grid Controller and/or XMPP-Grid Platforms can mount several attacks:
o Issue certificates for unauthorized parties, enabling them to
impersonate authorized parties such as the XMPP-Grid Controller or
an XMPP-Grid Platform. This can lead to all the threats that can
be mounted by the certificate's subject.
o Issue certificates without following all of the CA's policies.
Because this can result in issuing certificates that may be used
to impersonate authorized parties, this can lead to all the
threats that can be mounted by the certificate's subject.
o Fail to revoke previously issued certificates that need to be
revoked. This can lead to undetected impersonation of the
certificate's subject or failure to revoke authorization of the
subject, and therefore can lead to all of the threats that can be
mounted by that subject.
o Fail to regularly and securely distribute certificate revocation
information. This may cause a relying party to accept a revoked
certificate, leading to undetected impersonation of the
certificate's subject or failure to revoke authorization of the
subject, and therefore can lead to all of the threats that can be
mounted by that subject. It can also cause a relying party to
refuse to proceed with a transaction because timely revocation
information is not available, even though the transaction should
be permitted to proceed.
o Allow the CA's private key to be revealed to an unauthorized
party. This can lead to all the threats above. Even worse, the
actions taken with the private key will not be known to the CA.
o Fail to promptly detect and report errors and violations of trust
so that relying parties can be promptly notified. This can cause
the threats listed earlier in this section to persist longer than
necessary, leading to many knock-on effects.
Cam-Winget, et al. Expires May 3, 2018 [Page 14]
Internet-Draft XMPP Grid October 2017
8.3. Countermeasures
Below are countermeasures for specific attack scenarios to the XMPP-
Grid infrastructure.
8.3.1. Securing the XMPP-Grid Transport Protocol
To address network attacks, the XMPP-Grid transport protocol
described in this document requires that the XMPP-Grid messages MUST
be carried over TLS (minimally TLS 1.2 [RFC5246]) as described in
[RFC6120] and updated by [RFC7590]. The XMPP-Grid Platform MUST
verify the XMPP-Grid Controller's certificate and determine whether
the XMPP-Grid Controller is trusted by this XMPP-Grid Platform before
completing the TLS handshake. The XMPP-Grid Controller MUST
authenticate the XMPP-Grid Platform either using mutual certificate-
based authentication in the TLS handshake or using Basic
Authentication as described in IETF RFC 2617. XMPP-Grid Controller
MUST use Simple Authentication and Security Layer (SASL), described
in [RFC4422], to support the aforesaid authentication mechanisms.
SASL offers authentication mechanism negotiations between the XMPP-
Grid Controller and XMPP-Grid node during the connection
establishment phase. XMPP-Grid Platforms and XMPP-Grid Controllers
using mutual certificate-based authentication SHOULD each verify the
revocation status of the other party's certificate. All XMPP-Grid
Controllers and XMPP-Grid Platforms MUST implement both mutual
certificate-based authentication and Basic Authentication. The
selection of which XMPP-Grid Platform authentication technique to use
in any particular deployment is left to the administrator.
An XMPP-Grid Controller MAY also support a local, configurable set of
Basic Authentication userid-password pairs. If so, it is
implementation dependent whether an XMPP-Grid Controller ends a
session when an administrator changes the configured password. Since
Basic Authentication has many security disadvantages (especially the
transmission of reusable XMPP-Grid Platform passwords to the XMPP-
Grid Controller), it SHOULD only be used when absolutely necessary.
Per the HTTP specification, when basic authentication is in use, an
XMPP-Grid Controller MAY respond to any request that lacks
credentials with an error code similar to HTTP code 401. An XMPP-
Grid Platform SHOULD avoid this code by submitting basic auth
credentials with every request when basic authentication is in use.
If it does not do so, an XMPP-Grid Platform MUST respond to this code
by resubmitting the same request with credentials (unless the XMPP-
Grid Platform is shutting down).
Best practices for the use of TLS in XMPP are defined in [RFC7590].
Cam-Winget, et al. Expires May 3, 2018 [Page 15]
Internet-Draft XMPP Grid October 2017
These protocol security measures provide protection against all the
network attacks listed in the above document section except denial of
service attacks. If protection against these denial of service
attacks is desired, ingress filtering, rate limiting per source IP
address, and other denial of service mitigation measures may be
employed. In addition, an XMPP-Grid Controller MAY automatically
disable a misbehaving XMPP-Grid Platform.
8.3.2. Securing XMPP-Grid Platforms
XMPP-Grid Platforms may be deployed in locations that are susceptible
to physical attacks. Physical security measures may be taken to
avoid compromise of XMPP-Grid Platforms, but these may not always be
practical or completely effective. An alternative measure is to
configure the XMPP-Grid Controller to provide read-only access for
such systems. The XMPP-Grid Controller SHOULD also include a full
authorization model so that individual XMPP-Grid Platforms may be
configured to have only the privileges that they need. The XMPP-Grid
Controller MAY provide functional templates so that the administrator
can configure a specific XMPP-Grid Platform as a DHCP server and
authorize only the operations and metadata types needed by a DHCP
server to be permitted for that XMPP-Grid Platform. These techniques
can reduce the negative impacts of a compromised XMPP-Grid Platform
without diminishing the utility of the overall system.
To handle attacks within the bounds of this authorization model, the
XMPP-Grid Controller MAY also include rate limits and alerts for
unusual XMPP-Grid Platform behavior. XMPP-Grid Controllers SHOULD
make it easy to revoke an XMPP-Grid Platform's authorization when
necessary. Another way to detect attacks from XMPP-Grid Platforms is
to create fake entries in the available data (honeytokens) which
normal XMPP-Grid Platforms will not attempt to access. The XMPP-Grid
Controller SHOULD include auditable logs of XMPP-Grid Platform
activities.
To avoid compromise of XMPP-Grid Platform, XMPP-Grid Platform SHOULD
be hardened against attack and minimized to reduce their attack
surface. They should be well managed to minimize vulnerabilities in
the underlying platform and in systems upon which the XMPP-Grid
Platform depends. Personnel with administrative access should be
carefully screened and monitored to detect problems as soon as
possible.
8.3.3. Securing XMPP-Grid Controllers
Because of the serious consequences of XMPP-Grid Controller
compromise, XMPP-Grid Controllers SHOULD be especially well hardened
against attack and minimized to reduce their attack surface. They
Cam-Winget, et al. Expires May 3, 2018 [Page 16]
Internet-Draft XMPP Grid October 2017
should be well managed to minimize vulnerabilities in the underlying
platform and in systems upon which the XMPP-Grid Controller depends.
Network security measures such as firewalls or intrusion detection
systems may be used to monitor and limit traffic to and from the
XMPP-Grid Controller. Personnel with administrative access should be
carefully screened and monitored to detect problems as soon as
possible. Administrators should not use password-based
authentication but should instead use non-reusable credentials and
multi-factor authentication (where available). Physical security
measures SHOULD be employed to prevent physical attacks on XMPP-Grid
Controllers.
To ease detection of XMPP-Grid Controller compromise should it occur,
XMPP-Grid Controller behavior should be monitored to detect unusual
behavior (such as a reboot, a large increase in traffic, or different
views of an information repository for similar XMPP-Grid Platforms).
XMPP-Grid Platforms should log and/or notify administrators when
peculiar XMPP-Grid Controller behavior is detected. To aid forensic
investigation, permanent read-only audit logs of security-relevant
information (especially administrative actions) should be maintained.
If XMPP-Grid Controller compromise is detected, a careful analysis
should be performed of the impact of this compromise. Any reusable
credentials that may have been compromised should be reissued.
8.3.4. Limit on search result size
While XMPP-Grid is designed for high scalability to 100,000s of
Platforms, an XMPP-Grid Controller MAY establish a limit to the
amount of data it is willing to return in search or subscription
results. This mitigates the threat of an XMPP-Grid Platform causing
resource exhaustion by issuing a search or subscription that leads to
an enormous result.
8.3.5. Cryptographically random session-id and authentication checks
for ARC
An XMPP-Grid Controller SHOULD ensure that the XMPP-Grid Platform
establishing an Authenticated Results Chain (ARC) is the same XMPP-
Grid Platform as the XMPP-Grid Platform that established the
corresponding Synchronization Source Identifier (SSRC). The XMPP-
Grid Controller SHOULD employ both of the following strategies:
o session-ids SHOULD be cryptographically random
o The HTTPS transport for the SSRC and the ARC SHOULD be
authenticated using the same credentials. SSL session resumption
MAY be used to establish the ARC based on the SSRC SSL session.
Cam-Winget, et al. Expires May 3, 2018 [Page 17]
Internet-Draft XMPP Grid October 2017
8.3.6. Securing the Certification Authority
As noted above, compromise of a Certification Authority (CA) trusted
to issue certificates for the XMPP-Grid Controller and/or XMPP-Grid
Platforms is a major security breach. Many guidelines for proper CA
security have been developed: the CA/Browser Forum's Baseline
Requirements, the AICPA/CICA Trust Service Principles, etc. The CA
operator and relying parties should agree on an appropriately
rigorous security practices to be used.
Even with the most rigorous security practices, a CA may be
compromised. If this compromise is detected quickly, relying parties
can remove the CA from their list of trusted CAs, and other CAs can
revoke any certificates issued to the CA. However, CA compromise may
go undetected for some time, and there's always the possibility that
a CA is being operated improperly or in a manner that is not in the
interests of the relying parties. For this reason, relying parties
may wish to "pin" a small number of particularly critical
certificates (such as the certificate for the XMPP-Grid Controller).
Once a certificate has been pinned, the relying party will not accept
another certificate in its place unless the Administrator explicitly
commands it to do so. This does not mean that the relying party will
not check the revocation status of pinned certificates. However, the
Administrator may still be consulted if a pinned certificate is
revoked, since the CA and revocation process are not completely
trusted.
8.4. Summary
XMPP-Grid's considerable value as a broker for security-sensitive
data exchange distribution also makes the protocol and the network
security elements that implement it a target for attack. Therefore,
strong security has been included as a basic design principle within
the XMPP-Grid design process.
The XMPP-Grid transport protocol provides strong protection against a
variety of different attacks. In the event that an XMPP-Grid
Platform or XMPP-Grid Controller is compromised, the effects of this
compromise have been reduced and limited with the recommended role-
based authorization model and other provisions, and best practices
for managing and protecting XMPP-Grid systems have been described.
Taken together, these measures should provide protection commensurate
with the threat to XMPP-Grid systems, thus ensuring that they fulfill
their promise as a network security clearing-house.
Cam-Winget, et al. Expires May 3, 2018 [Page 18]
Internet-Draft XMPP Grid October 2017
9. Privacy Considerations
XMPP-Grid Platforms may publish information about endpoint health,
network access, events (which may include information about what
services an endpoint is accessing), roles and capabilities, and the
identity of the end user operating the endpoint. Any of this
published information may be queried by other XMPP-Grid Platforms and
could potentially be used to correlate network activity to a
particular end user.
Dynamic and static information brokered by an XMPP-Grid Controller,
ostensibly for purposes of correlation by XMPP-Grid Platforms for
intrusion detection, could be misused by a broader set of XMPP-Grid
Platforms which hitherto have been performing specific roles with
strict well-defined separation of duties.
Care should be taken by deployers of XMPP-Grid to ensure that the
information published by XMPP-Grid Platforms does not violate
agreements with end users or local and regional laws and regulations.
This can be accomplished either by configuring XMPP-Grid Platforms to
not publish certain information or by restricting access to sensitive
data to trusted XMPP-Grid Platforms. That is, the easiest means to
ensure privacy or protect sensitive data, is to omit or not share it
at all.
Another consideration for deployers is to enable end-to-end
encryption to ensure the data is protected from the data layer to
data layer and thus protect it from the transport layer.
10. Acknowledgements
The authors would like to acknowledge the contributions, authoring
and/or editing of the following people: Joseph Salowey, Lisa
Lorenzin, Clifford Kahn, Henk Birkholz, Jessica Fitzgerald-McKay,
Steve Hanna, and Steve Venema. In addition, we want to thank Takeshi
Takahashi, Panos Kampanakis, Adam Montville, Chris Inacio, and Dave
Cridland for reviewing and providing valuable comments.
11. References
11.1. Normative References
[I-D.ietf-sacm-terminology]
Birkholz, H., Lu, J., Strassner, J., and N. Cam-Winget,
"Secure Automation and Continuous Monitoring (SACM)
Terminology", draft-ietf-sacm-terminology-13 (work in
progress), July 2017.
Cam-Winget, et al. Expires May 3, 2018 [Page 19]
Internet-Draft XMPP Grid October 2017
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>.
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422,
DOI 10.17487/RFC4422, June 2006, <https://www.rfc-
editor.org/info/rfc4422>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer
Security (TLS) in the Extensible Messaging and Presence
Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June
2015, <https://www.rfc-editor.org/info/rfc7590>.
[XEP-0030]
Hildebrand, J., Millard, P., Eatmon, R., and P. Saint-
Andre, "Service Discovery", XSF XEP 0030, July 2010.
[XEP-0060]
Millard, P. and P. Saint-Andre, "Publish-Subscribe",
XSF XEP 0060, December 2016.
11.2. Informative References
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
editor.org/info/rfc5246>.
[RFC7970] Danyliw, R., "The Incident Object Description Exchange
Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
November 2016, <https://www.rfc-editor.org/info/rfc7970>.
Authors' Addresses
Nancy Cam-Winget (editor)
Cisco Systems
3550 Cisco Way
San Jose, CA 95134
USA
Email: ncamwing@cisco.com
Cam-Winget, et al. Expires May 3, 2018 [Page 20]
Internet-Draft XMPP Grid October 2017
Syam Appala
Cisco Systems
3550 Cisco Way
San Jose, CA 95134
USA
Email: syam1@cisco.com
Scott Pope
Cisco Systems
5400 Meadows Road
Suite 300
Lake Oswego, OR 97035
USA
Email: scottp@cisco.com
Peter Saint-Andre
Jabber.org
P.O. Box 787
Parker, CO 80134
USA
Email: stpeter@jabber.org
Cam-Winget, et al. Expires May 3, 2018 [Page 21]
