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

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 23 Jan 2019 19:59:21 -0800

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.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 24 Jan 2019 12:04:31 +0000

Hi Benjamin,

Thank you for your comments.

I will let editors reply to your comments, but I will quickly comment one part of your DISCUSS:

I think you and Alissa are right that the document needs to be clearer on whether it just relies on RFC 6120 and various XEP requirements or whether it adds any of its own.

> the EXTERNAL and SCRAM families of SASL mechanisms;

I want to push back on this. The document is adding new requirement on top of what RFC 6120 requires, this is effectively new mandatory to implement SASL mechanisms for use XMPP with grids. Ideally this would be a single SASL mechanism, but I think one password based and one X.509 based is a good compromise here.

 there are other
> and this sort of unjustified restriction is detrimental to the evolution of

Let's not exaggerate here. If you want to suggest one or two alternative choices for mandatory to implement SASL mechanism for XMPP grids, I think you need to make a better argument in front of the WG.

> susceptible to this threat.  (A bit more discussion in the COMMENT section.)

I agree that this needs to be reviewed.

Best Regards,
Alexey

---

From: Dave Cridland <[email-masked]>
Date: Thu, 24 Jan 2019 12:43:17 +0000

On Thu, 24 Jan 2019 at 12:04, Alexey Melnikov <[email-masked]>
wrote:

> I want to push back on this. The document is adding new requirement on top
> of what RFC 6120 requires, this is effectively new mandatory to implement
> SASL mechanisms for use XMPP with grids. Ideally this would be a single
> SASL mechanism, but I think one password based and one X.509 based is a
> good compromise here.
>
>
So I see Benjamin's point here. The document does introduce a new MTI SASL
mechanism cohort of EXTERNAL, SCRAM-SHA1, and SCRAM-SHA-256. This is fine,
but one has to wonder why we don't do this universally - I might try to
address this. (RFC 6120 has an MTI of SCRAM-SHA1, EXTERNAL, and PLAIN+TLS
for comparison).

But as Benjamin says, it also mandates their exclusive usage. From §8.3.1:

   completing the TLS handshake.  The XMPP-Grid Controller MUST
   authenticate the XMPP-Grid Platform either using the SASL EXTERNAL
   mechanism [RFC4422] or using the SASL SCRAM mechanism (with the
   SCRAM-SHA-256-PLUS variant being preferred over the SCRAM-SHA-256
   variant and SHA-256 variants [RFC7677] being preferred over SHA-1
   varients [RFC5802]).  XMPP-Grid Platforms and XMPP-Grid Controllers

(Also, typo in "varients").

There are, indeed, other SASL mechanisms which could be used to good effect
here - and indeed weaker ones that might be appropriate in some
circumstances. But, as written, the document prohibits these.

Dave.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 24 Jan 2019 13:04:51 +0000

Hi Dave,

On Thu, Jan 24, 2019, at 12:43 PM, Dave Cridland wrote:
> On Thu, 24 Jan 2019 at 12:04, Alexey Melnikov
> <[email-masked]> wrote:>> Hi Benjamin,
>> > I also think this document does not adequately justify restricting
>> > to just>>  > the EXTERNAL and SCRAM families of SASL mechanisms;
>> 
>>  I want to push back on this. The document is adding new requirement
>>  on top of what RFC 6120 requires, this is effectively new mandatory
>>  to implement SASL mechanisms for use XMPP with grids. Ideally this
>>  would be a single SASL mechanism, but I think one password based and
>>  one X.509 based is a good compromise here.>> 
> 
> So I see Benjamin's point here. The document does introduce a new MTI
> SASL mechanism cohort of EXTERNAL, SCRAM-SHA1, and SCRAM-SHA-256. This
> is fine, but one has to wonder why we don't do this universallyI think any effort to update RFC 6120 needs to proceed independently: it
can't hold this document hostage.
> - I might try to address this. (RFC 6120 has an MTI of SCRAM-SHA1,
>   EXTERNAL, and PLAIN+TLS for comparison).> 
> But as Benjamin says, it also mandates their exclusive usage.
> From §8.3.1:> 
>    authenticate the XMPP-Grid Platform either using the SASL EXTERNAL>    mechanism [RFC4422] or using the SASL SCRAM mechanism (with the
>    varients [RFC5802]).  XMPP-Grid Platforms and XMPP-Grid Controllers> 
> There are, indeed, other SASL mechanisms which could be used to good
> effect here - and indeed weaker ones that might be appropriate in some
I suspect prohibition of others is not intentional. So what is the best
way of addressing this? Change the MUST to the SHOULD and possibly
change "MUST authenticate" to "SHOULD support"?
Best Regards,
Alexey

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 24 Jan 2019 08:39:11 -0600

> I want to push back on this. The document is adding new requirement on top of what RFC 6120 requires, this is effectively new mandatory to implement SASL mechanisms for use XMPP with grids. Ideally…

Dave has correctly inferred that my objection is to the "mandatory to use"
-- these are fine mandatory-to-implement choices.  I think we could move
away from the "MUST authenticate [...] using" language to a combination of
"MUST authenticate using a mechanism that provides strong authentication,
transport encryption, ...", and "in order to establish a common baseline
for XMPP-Grid usage, participants MUST implement [EXTERNAL and SCRAM]".

> Let's not exaggerate here. If you want to suggest one or two alternative choices for mandatory to implement SASL mechanism for XMPP grids, I think you need to make a better argument in front of the…

(possibly OBE) My point here is something like "suppose I already have
Kerberos set up, or whatever the latest hotness in authentication is.  Why
do I have to set up some SCRAM infrastructure or try to shim my thing into
EXTERNAL instead of using it as native SASL?"

-Benjamin

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 24 Jan 2019 08:39:11 -0600

-Benjamin