[mile] Benjamin Kaduk's Discuss on draft-ietf-mile-xmpp-grid-09: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 24 January 2019 03:59 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: mile@ietf.org
Delivered-To: mile@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32283131073; Wed, 23 Jan 2019 19:59:21 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-mile-xmpp-grid@ietf.org, mile@ietf.org, mile-chairs@tools.ietf.org, Takeshi Takahashi <takeshi_takahashi@nict.go.jp>, mile-chairs@ietf.org, takeshi_takahashi@nict.go.jp, mile@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.90.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154830236119.7369.16213460588216390150.idtracker@ietfa.amsl.com>
Date: Wed, 23 Jan 2019 19:59:21 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/cT91YwyKCOqBI6HZ5GHhK6id3IA>
Subject: [mile] Benjamin Kaduk's Discuss on draft-ietf-mile-xmpp-grid-09: (with DISCUSS and COMMENT)
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mile/>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Jan 2019 03:59:21 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-mile-xmpp-grid-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mile-xmpp-grid/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

In the vein of Alissa's comments, I think this document does not adequately
present the normative requirements for an implementation of the "XMPP
Grid".  As far as I can tell, these requirements are just relating to the
communications security measures used to protect XMPP traffic, per Section
8.3.  (Adhering to the MTI and MTN requirements of RFC 6120 does not seem
like a new requirement.)  The main bulk of the document consists of
examples that show how to use standard XMPP functionality to discover
pubsub streams that convey data (types) that are of relevance for the types
of behavior that MILE is interested in (e.g., security incident reporting
and discovery), with inline mention of which XMPP features are used to
negotiate and discover the streams in question.  (Several of my comments
are related to this Discuss point.)

I also think this document does not adequately justify restricting to just
the EXTERNAL and SCRAM families of SASL mechanisms; there are other
mechanisms in use that provide equivalent or better security properties,
and this sort of unjustified restriction is detrimental to the evolution of
the Internet.

The current requirements on SASL mechanisms also seem inconsistent with the
claims in the threat model that the controller can obtain credentials to
allow impersonation of platforms; RFC 5802 (SCRAM) is quite explicit that
"The server does not gain the ability to impersonate the client to other
servers", and my understanding is that usage of EXTERNAL is generally not
susceptible to this threat.  (A bit more discussion in the COMMENT section.)

The secdir reviewer rightly points out that this document does not discuss
the implications of (non-) use of XMPP pubsub message persistence, which
affect either availability of historic data or the privacy/security
requirements properties of the controller and the system as a whole.
(This relates to Ben's discuss point (1).)
The secdir review also notes that the full implications of the
participants' access to plaintext data are not covered.  (This also relates
to Ben's discuss point (2).) Some of them are covered by existing text,
e.g., the trust model's instistence that the platforms preserve the
confidentiality of sensitive data, but others are not.  (I attempt to note
these cases in the COMMENT section.)

Section 6 notes that "Depending on security requirements, the Provider
might need to request a non-default configuration for the node; see
[XEP-0060] for detailed examples." I think you need to either list out some
of the examples or give a section reference from XEP-0060; the obvious
places about creating or configuring a node don't seem to have this sort of
discussion of security requirements and implications.  The secdir
reviewer's note about an example that demonstrates the recommended
configuration is quite apt as well.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1

In the vein of Alissa's comments, I think this section is missing a
high-level technical view, perhaps something like:

  The XMPP Grid does not introduce any new protocols or technologies, but
  rather describes a scheme by which XMPP pubsub functionality is used to
  quickly and efficiently distribute information relating to security
  incidents and their detection, potentially scaling to 100,000s of
  subscribers.  XMPP service discovery allows for entities to learn about
  content distributed via the XMPP Grid via the registered "pubsub#type"
  identifiers, which also indicate the format of the data being distributed.

It could also benefit from some more text placing this tool within the
broader MILE scope.

Section 4

The Platform in item (a) is only listed as having a source of security
data, in which case I would expect the "typical" workflow to only involve
it needing to publish, and not necessarily to subscribe or query.  While I
recognize that a typical workflow will include both publishing and
subscribing, it may be worth mentioning that this Platform also desires to
receive some information as well as having a source for it.

Section 5

   The Broker responds with the "disco#info" description, which SHOULD
   include an XMPP Data Form [XEP-0004] including a 'pubsub#type' field
   that specifies the supported namespace (in this example, the IODEF
   namespace defined in [RFC7970]):

Isn't this more of a "the MILE XMPP grid won't work at all if you don't
include a pubsub#type field that indicates iodef payloads"?  I could see
doing this as descriptive text about what happens, or as a MUST, but the
SHOULD just doesn't seem right.

Section 8

   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.  [...]

This jumps in quite quickly, using these terms that have not previously
been defined and are part of a broader architecture that is not directly
relevant to understanding this protocol.  Is it necessary to mention them
just in passing like this without other discussion?

Section 8.1.3

The controller is also trusted to preserve the integrity (and
confidentiality against unauthorized parties) of the data flowing through
it.

Section 8.2.2

The authorized platform could advertise data that is incorrect with the
intent to lead to incorrect actions by the recipients, without needing to
exploit vulnerabilities in other systems or compromising them.

Section 8.2.3

   o  Mount an even more effective denial of service attack than a
      single XMPP-Grid Platform could

There seem to be a number of ways in which the DoS effectiveness could be
increased by a controller (compared to a platform), whether by inducing the
many platforms to perform the same operation in an amplification-style
attack, completely refusing to pass any traffic at all, sending floods of
traffic to (certain) platforms or other targets, or otherwise.  Do we care
to make a distinction among them, or is that not helpful at this level of
granularity?

   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

This would require that platforms are using things like SASL PLAIN
authentication, and would not be possible if TLS mutual authentication or
some other proof-of-possession-based authentication scheme is used for
client authentication and authorization.  It seems important to reiterate
this distinction and point out the risks inherent in transmitting passwords
to the remote party for verification.

Furthermore, since Section 8.3.1 instructs us that we can only use SASL
EXTERNAL or SCRAM, this sort of credential scraping would only occur if the
EXTERNAL mechanism used permits it (which I believe to be somewhat
unlikely), or if clients were misconfigured to allow non-permitted SASL
mechanisms (which is, unfortunately, fairly likely to be the case
somewhere).  This behavior, particularly the risk of client
misconfiguration, should be called out somewhere in the security
considerations.

   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

(This also requires the use of non-proof-of-possession authentication
schemes.)

Section 8.3.1

   be carried over TLS (minimally TLS 1.2 [RFC8446]) as described in
   [RFC6120] and updated by [RFC7590].  The XMPP-Grid Platform MUST

Citing RFC 8446 (TLS 1.3) for TLS 1.2 is rather strange.

                    The selection of which XMPP-Grid Platform
   authentication technique to use in any particular deployment is left
   to the administrator.

But from a very short list of options!  Why do we need to prevent the usage
of other, equally secure, SASL mechanisms, for example, all the GSS-API
mechanisms available via GS2 bridging?

Section 8.3.2

                                                           The XMPP-Grid
   Controller MAY provide functional templates so that the administrator
   can configure a specific XMPP-Grid Platform as a DHCP [RFC2131]
   server and authorize only the operations and metadata types needed by
   a DHCP server to be permitted for that XMPP-Grid Platform.  [...]

Why is DHCP so privilged to be the only application protocol called out
explicitly here?  It seems that this is just an example and the same
profiling/resterictions could be applied for any application protocol.

   unusual XMPP-Grid Platform behavior.  XMPP-Grid Controllers SHOULD
   make it easy to revoke an XMPP-Grid Platform's authorization when

I don't think "SHOULD make it easy" is particularly actionable for
a normative requirement.  Similarly for "SHOULD be hardened" in the next
paragraph.

Section 8.3.3

              Administrators SHOULD NOT use password-based
   authentication but should instead use non-reusable credentials and
   multi-factor authentication (where available).  [...]

[see previous remarks about permitted SASL mechanisms]

Section 8.3.5

   While XMPP-Grid is designed for high scalability to 100,000s of
   Platforms, [...]

Where is this documented?

Section 8.3.6

nit?: I would not really describe CT as a "guideline for proper CA
security", but rather a tool for discovering failures to maintain proper CA
security.

I think we need to be careful about recommending pinning, since it
introduces a new DoS vector when there is a legitimate need to change
certificates.  If we're talking about pinning, we would presumably also
want to recommend against pinning EE certificates and only intermediate or
root CAs, and to have monitoring for imminent expiration events.

Section 9

   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.

It's probably worth a(nother?) reminder that the mechanisms for doing so
are out of scope for this document.