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

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-mile-xmpp-grid-10: 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:
----------------------------------------------------------------------

Thank you for updating to describe this document as essentially an RFC206-style
applicability statement; that helps a lot to frame what it is intending to deliver,
and the other updates are improvements as well.

That said, I think a couple of my DISCUSS  points remain applicable:

Section 8.2.3 still has text about how an XMPP Grid Controller could obtain
XMPP-Grid Platform credentials and impersonate the XMPP Grid Platform
even after the breach of the XMPP Grid Controller is repaired.  The current
MTI SASL mechanisms  do not give the controller that ability, and it's only
bad mechanisms like PLAIN that involve sending cleartext passwords/bearer
tokens to the server that give an attacker that compromises the controller
this ability.  I think we need to clarify that this depends on the SASL mechanism
used, and that the MTI mechanisms are not vulnerable to this attack.  Suggested change:

OLD:
   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
NEW:
   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.  Some SASL mechanisms (including
      the mandatory-to-implement SCRAM and EXTERNAL with TLS mutual
      certificate-based authentication) do not admit this class of attack, but
      others (such as PLAIN) are susceptible.


The secdir review 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 repeat here the
portions of the COMMENT section that seem relevant:

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.

Suggested additions:

Section 8.1.3:

   o Preserve the integrity (and confidentiality against unauthorized parties)
     of the data flowing through it.

Section 8.2.2

   Advertise false data that leads to incorrect (e.g., potentially attacker-controlled
   or -induced) behavior of XMPP-Grid Platforms, by virtue of applying correct procdeures
   to the falsified input.


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