Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange
draft-ietf-mile-xmpp-grid-11

[Ballot comment]
I have discussed my concerns with the authors and am satisfied that my concerns
will be addressed; in the interest of expediency I am clearing my ballot position
now, so as to not introduce unneeded delay.
Thank you for helping to address my points!

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

[Ballot comment]
Thanks for addressing my DISCUSS points in email. I am clearing now under the assumption the right things will happen in the draft text.

My original non-blocking comments are listed below for reference. I leave it to the authors and AD to decide if any further actions are needed.

*** Substantive Comments ***

Figure 1: I fail to understand the meaning intended by extending "data plane" to the right under the peer-to-peer data flow.

§3: It would be nice to somehow include authentication and authorization in Figure 1.

§4: Figure 2 shows the consumer delaying the topic list request until after the provider has created the topic. I realize that's just for illustrative purposes, but I wonder what would have happened if the consumer requested the topic list sooner? Would it ever learn about the new topic?  Do you have thoughts about how often new topics will be created in the field?

§5: "a Platform would send an XMPP "disco#info" request to each Topic:"
Have people thought about how this might work if there are a _lot_ of topics?

§8.1.3: Is the controller trusted to see data and to be able to modify that data? Or more to the point: It _can_ do those things. Is it trusted to not improperly use, store, or share data, and to not improperly modify data? (See further comments below)

§8.3.2:
- Can you elaborate on the concept of honey tokens?

- The requirement that the grid controllers SHOULD keep auditable logs of platform behavior has privacy implications that need to be discussed in the privacy considerations. In particular, could there be some guidance around not logging more information than is needed for the purpose?

§8.3.3: "permanent read-only audit logs of security-relevant
information (especially administrative actions) should be maintained."
Really permanent, as in forever?  (also, should that "should" be a "SHOULD"?)

§8.3.5: I wonder if this guidance creates a new DoS opportunity. Could a malicious provider insert so much data into a topic to make it impossible to receive data from that topic due to these size limits?  (That brings up a question: Can multiple providers insert data to the same topic?)

§8.3.6: Can you cite something or otherwise elaborate on certificate pinning?







*** Editorial Comments:

§2: In most of the definitions, you treat the XMPP-specific terminology inside the definition of the abstract term. Was there a reason to treat "Node" differently?

§3: "be a Provider or
Consumer of interested Topics at the Broker"
I'm not sure topics are capable of being interested. Perhaps "topics of interest"?

§4:
- list item "e":  What does "in real time" mean in the context of a provider submitting data to the grid?

- "XMPP-Grid implementations MUST adhere to the mandatory-to-implement
and mandatory-to-negotiate features as defined in [RFC6120]."
It's not generally necessary to say that an implementation MUST implement the mandatory bits of a spec. That's up to that spec to do itself.

- "The Service Discovery per [XEP-0030] SHOULD be implemented"
There appears to be a missing word after "Discovery". Or perhaps the use of "The" is incorrect. (i.e. "The Service Discovery Mechanism" vs "Service Discovery")

§8.1.4: It's a bit confusing to find CA security considerations before any mention that there are CAs involved.

§8.2.2: "... if the XMPP-Grid Platform assumes that old XMPP-Grid Platform data deserves to be ignored."
"deserves" has connotations that I don't think apply here. I suspect you probably mean "... should be ignored", but were trying to avoid the non-normative use of "should". Such use is fine given the draft uses the RFC 8174 boilerplate for normative keywords.

§8.3.X: There are a number of statements that systems need to be "well managed", "hardened against attack", and "reduce their attack surface".  Some of them use normative language. These seem like glittering generalities, unless specific practices can be recommended or cited.


§8.3.1:  "(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]"
Should that be stated normatively?

§8.3.3: "Administrators SHOULD NOT use password-based
authentication but should..."
Should the second "should" be a "SHOULD"?

[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4730


I have marked a number of places where I do not consider this fully
specified.

DETAIL
S 4.
>              |                      | Request Topic Creation  |
>              |                      | (XEP-0060)              |
>              |                      |<------------------------|
>              |                      | Topic Creation Success  |
>              |                      | (XEP-0060)              |
>              |                      |------------------------>|

Why Isn't XEP-0060 a normative reference?


S 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]):

This seems underspecified.  What does the consumer look at to
"determine the exact nature of each topic"? This text implies it's the
'pubsub#type' but doesn't quite say so. I am imagining changing this
SHOULD to a MUST and then stating how the consumer behaves.



S 8.3.1.
>      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
>      using mutual certificate-based authentication SHOULD each verify the
>      revocation status of the other party's certificate.  All XMPP-Grid

I am having trouble reading these two sentences together. Is the
implication that I must use SCRAM and may also use mutual certificate
auth?

[Ballot comment]
S 5.
>                          name='Endpoint Posture Information'
>                jid='broker.security-grid.example'/>
>                          name='MILE Host Data'
>                jid='broker.security-grid.example'/>

Assuming I am understanding this correctly, there's no machine-
readable description of the topics; they are just freeform
descriptions and then some human has to decide what to consume.
Assuming that's correct you should state it upfront.


S 6.
>              jid='xmpp-grid-client@mile-host.example'
>              subscription='subscribed'/>
>       
>     
> 
>      Third, a Provider would publish an incident as follows:

The "as follows" here also seems underspecified. You need to define
exactly where the payload goes and what permitted payloads are.


S 6.
>       
>     
>   
> 
>      (The payload in the foregoing example is from [RFC7970]; payloads for
>      additional use cases can be found in [RFC8274].)

Just to be clear: there's no negotiation here or even advertisement of
payload types? The Consumer just takes whatever it gets?


S 6.
> 
>      (The payload in the foregoing example is from [RFC7970]; payloads for
>      additional use cases can be found in [RFC8274].)
> 
>      The Broker would then deliver that incident report to all Consumers
>      who are subscribe to the Topic:

Nit: "are subscribed"


S 8.1.4.
> 
>  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:

Well, any trusted CA, whether or not it is actually issuing
certificates.


S 8.2.1.
>      o  Network traffic can 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.)

This text is kind of misleading because below you require TLS.


S 8.2.1.
>      o  Network traffic can be blocked, perhaps selectively
> 
>      o  A "Man In The Middle" (MITM) attack can 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

How would this be possible? Is it only in the case of unencrypted
transport or something else?


S 8.3.1.
> 
>  8.3.1.  Securing the XMPP-Grid Data Transfer Protocol
> 
>      To address network attacks, the XMPP-Grid data transfer protocol
>      described in this document requires that the XMPP-Grid messages MUST
>      be carried over TLS (minimally TLS 1.2 [RFC8446]) as described in

It would have been useful to state this earlier.


S 8.3.1.
>  8.3.1.  Securing the XMPP-Grid Data Transfer Protocol
> 
>      To address network attacks, the XMPP-Grid data transfer protocol
>      described in this document requires that the XMPP-Grid messages MUST
>      be carried over TLS (minimally TLS 1.2 [RFC8446]) as described in
>      [RFC6120] and updated by [RFC7590].  The XMPP-Grid Platform MUST

Perhaps you should require 1.3 at this point?


S 8.3.1.
>      authentication technique to use in any particular deployment is left
>      to the administrator.
> 
>      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

This is a bit hard to read in context. It seems almost like you wrote
the "network attacks" section as if TLS wasn't required and then added
the TLS requirement? In any case, if all those attacks are prevented,
I would rewrite that section


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

"Ignacio", right?

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

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

[Ballot comment]
Thank you for writing this.

I would have liked to have seen even more on why XMPP versus any of the other distribution systems, but that's just an editorial comment.

[Ballot comment]
Please respond to the Gen-ART review.

I'm not quite seeing what part of this is a standards-track specification. The workflow in Section 4 is described as "typical" but not normative and the exchanges listed in sections 5 and 6 are listed as examples. For a standards-track specification I would have expected something more like "Implementations of XMPP-Grid adhere to the following workflow ..." and for service discovery and pub-sub to be described as *the* way to do those things in XMPP-Grid, not just illustrated by examples. Otherwise this seems like it could be an informational document.

In the subsections of Section 8.3 I can't readily discern why some of the requirements that relate to protections outside the protocol stack are listed with normative keywords and some are not. It seems like none of them having normative weight would make more sense, or perhaps there is an explanation I'm missing?

[Ballot comment]
Thanks for such a well-written and clear document. I particularly liked the
extensive and methodical security analysis. I have two substantive comments
about the mechanism that I'd like to have a conversation about prior to moving
towards publication. I am balloting "yes" in anticipation of coming to an
understanding around these two topics.

---------------------------------------------------------------------------

§6:

>  (The payload in the foregoing example is from [RFC7970]; payloads for
>  additional use cases can be found in [RFC8274].)

This format appears to be only exemplary, rather than a requirement of the
mechanism. At the same time, these formats appear to be oriented toward
automatic processing. The presence of a schema indication in the top-level
element of the report does at least allow distinction between different report
formats, but that doesn't allow software to handle a schema that it doesn't
otherwise understand. How does a subscriber know which topics have schema
that they can handle?

---------------------------------------------------------------------------

§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 not clear what implementors are expected to do with this recommendation.
Options presumably include RFC 3923, XEP-0380, XEP-0373, XEP-0364, XEP-0027, or
maybe something I'm not aware of. I note that the XEPs I mention are
Historical, Obsolete, Experimental, and Deferred, none of which seem appropriate
for use. And it's my understanding that XMPP implementors are... to put it very
mildly, not enthusiastic about RFC 3923.

If I've missed an appropriate mechanism, please cite it as an example of how the
recommendation can be implemented. If not, please add text indicating that a
means for end-to-end encryption is a matter for future study.

[Ballot comment]

*** Substantive Comments ***

Figure 1: I fail to understand the meaning intended by extending "data plane" to the right under the peer-to-peer data flow.

§3: It would be nice to somehow include authentication and authorization in Figure 1.

§4: Figure 2 shows the consumer delaying the topic list request until after the provider has created the topic. I realize that's just for illustrative purposes, but I wonder what would have happened if the consumer requested the topic list sooner? Would it ever learn about the new topic?  Do you have thoughts about how often new topics will be created in the field?

§5: "a Platform would send an XMPP "disco#info" request to each Topic:"
Have people thought about how this might work if there are a _lot_ of topics?

§8.1.3: Is the controller trusted to see data and to be able to modify that data? Or more to the point: It _can_ do those things. Is it trusted to not improperly use, store, or share data, and to not improperly modify data? (See further comments below)

§8.3.2:
- Can you elaborate on the concept of honey tokens?

- The requirement that the grid controllers SHOULD keep auditable logs of platform behavior has privacy implications that need to be discussed in the privacy considerations. In particular, could there be some guidance around not logging more information than is needed for the purpose?

§8.3.3: "permanent read-only audit logs of security-relevant
information (especially administrative actions) should be maintained."
Really permanent, as in forever?  (also, should that "should" be a "SHOULD"?)

§8.3.5: I wonder if this guidance creates a new DoS opportunity. Could a malicious provider insert so much data into a topic to make it impossible to receive data from that topic due to these size limits?  (That brings up a question: Can multiple providers insert data to the same topic?)

§8.3.6: Can you cite something or otherwise elaborate on certificate pinning?







*** Editorial Comments:

§2: In most of the definitions, you treat the XMPP-specific terminology inside the definition of the abstract term. Was there a reason to treat "Node" differently?

§3: "be a Provider or
Consumer of interested Topics at the Broker"
I'm not sure topics are capable of being interested. Perhaps "topics of interest"?

§4:
- list item "e":  What does "in real time" mean in the context of a provider submitting data to the grid?

- "XMPP-Grid implementations MUST adhere to the mandatory-to-implement
and mandatory-to-negotiate features as defined in [RFC6120]."
It's not generally necessary to say that an implementation MUST implement the mandatory bits of a spec. That's up to that spec to do itself.

- "The Service Discovery per [XEP-0030] SHOULD be implemented"
There appears to be a missing word after "Discovery". Or perhaps the use of "The" is incorrect. (i.e. "The Service Discovery Mechanism" vs "Service Discovery")

§8.1.4: It's a bit confusing to find CA security considerations before any mention that there are CAs involved.

§8.2.2: "... if the XMPP-Grid Platform assumes that old XMPP-Grid Platform data deserves to be ignored."
"deserves" has connotations that I don't think apply here. I suspect you probably mean "... should be ignored", but were trying to avoid the non-normative use of "should". Such use is fine given the draft uses the RFC 8174 boilerplate for normative keywords.

§8.3.X: There are a number of statements that systems need to be "well managed", "hardened against attack", and "reduce their attack surface".  Some of them use normative language. These seem like glittering generalities, unless specific practices can be recommended or cited.


§8.3.1:  "(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]"
Should that be stated normatively?

§8.3.3: "Administrators SHOULD NOT use password-based
authentication but should..."
Should the second "should" be a "SHOULD"?

[Ballot discuss]
Hi, thanks for the readable approach to this. I like the plain English approach to the security considerations, in particular. But I do have some comments, including a couple that I think needs to be resolved before progressing the draft:

1) I was surprised not to see a discussion of the "never-meet" problem. That is, what happens if a provider and a consumer never connect with the controller at the same time. Is the controller expected to store-and-forward items submitted to a topic prior to when the consumer connects? IIRC (and I apologize that I did not have time to refresh my memory on the referenced XEPs), that sort of behavior is optional under XEP-0060. Is it required for this use case? Is support for delayed delivery (xep-0203) or something similar required? Or perhaps platforms are expected to keep long-lived connections?

2) The security considerations suggest that the use of TLS mitigates  all of the "network attacks". However, the potential or eavesdropping or data modification are only mentioned in terms of such "network attacks". It is also possible for the controller (aka XMPP server) to do those things unless some sort of e2e protection is used. This is not discussed in the sections about how the controller is trusted, nor is it discussed in the countermeasures sections. There is a mention of e2e protection in the privacy considerations, but I think that really needs treatment under the security considerations.

[Ballot discuss]
Hi, thanks for the readable approach to this. I like the plain English approach to the security considerations, in particular. But I do have some comments, including one I think needs to be resolved before progressing the draft:

1) I was surprised not to see a discussion of the "never-meet" problem. That is, what happens if a provider and a consumer never connect with the controller at the same time. Is the controller expected to store-and-forward items submitted to a topic prior to when the consumer connects? IIRC (and I apologize that I did not have time to refresh my memory on the referenced XEPs), that sort of behavior is optional under XEP-0060. Is it required for this use case? Is support for delayed delivery (xep-0203) or something similar required? Or perhaps platforms are expected to keep long-lived connections?

2) The security considerations suggest that the use of TLS mitigates  all of the "network attacks". However, the potential or eavesdropping or data modification are only mentioned in terms of such "network attacks". It is also possible for the controller (aka XMPP server) to do those things unless some sort of e2e protection is used. This is not discussed in the sections about how the controller is trusted, nor is it discussed in the countermeasures sections. There is a mention of e2e protection in the privacy considerations, but I think that really needs treatment under the security considerations.

[Ballot comment]

*** Substantive Comments ***

General: I expected to find a discussion of the "never

Figure 1: I fail to understand the meaning intended by extending "data plane" to the right under the peer-to-peer data flow.

§3: It would be nice to somehow include authentication and authorization in Figure 1.

§4: Figure 2 shows the consumer delaying the topic list request until after the provider has created the topic. I realize that's just for illustrative purposes, but I wonder what would have happened if the consumer requested the topic list sooner? Would it ever learn about the new topic?  Do you have thoughts about how often new topics will be created in the field?

§5: "a Platform would send an XMPP "disco#info" request to each Topic:"
Have people thought about how this might work if there are a _lot_ of topics?

§8.1.3: Is the controller trusted to see data and to be able to modify that data? Or more to the point: It _can_ do those things. Is it trusted to not improperly use, store, or share data, and to not improperly modify data? (See further comments below)

§8.3.2:
- Can you elaborate on the concept of honey tokens?

- The requirement that the grid controllers SHOULD keep auditable logs of platform behavior has privacy implications that need to be discussed in the privacy considerations. In particular, could there be some guidance around not logging more information than is needed for the purpose?

§8.3.3: "permanent read-only audit logs of security-relevant
information (especially administrative actions) should be maintained."
Really permanent, as in forever?  (also, should that "should" be a "SHOULD"?)

§8.3.5: I wonder if this guidance creates a new DoS opportunity. Could a malicious provider insert so much data into a topic to make it impossible to receive data from that topic due to these size limits?  (That brings up a question: Can multiple providers insert data to the same topic?)

§8.3.6: Can you cite something or otherwise elaborate on certificate pinning?







*** Editorial Comments:

§2: In most of the definitions, you treat the XMPP-specific terminology inside the definition of the abstract term. Was there a reason to treat "Node" differently?

§3: "be a Provider or
Consumer of interested Topics at the Broker"
I'm not sure topics are capable of being interested. Perhaps "topics of interest"?

§4:
- list item "e":  What does "in real time" mean in the context of a provider submitting data to the grid?

- "XMPP-Grid implementations MUST adhere to the mandatory-to-implement
and mandatory-to-negotiate features as defined in [RFC6120]."
It's not generally necessary to say that an implementation MUST implement the mandatory bits of a spec. That's up to that spec to do itself.

- "The Service Discovery per [XEP-0030] SHOULD be implemented"
There appears to be a missing word after "Discovery". Or perhaps the use of "The" is incorrect. (i.e. "The Service Discovery Mechanism" vs "Service Discovery")

§8.1.4: It's a bit confusing to find CA security considerations before any mention that there are CAs involved.

§8.2.2: "... if the XMPP-Grid Platform assumes that old XMPP-Grid Platform data deserves to be ignored."
"deserves" has connotations that I don't think apply here. I suspect you probably mean "... should be ignored", but were trying to avoid the non-normative use of "should". Such use is fine given the draft uses the RFC 8174 boilerplate for normative keywords.

§8.3.X: There are a number of statements that systems need to be "well managed", "hardened against attack", and "reduce their attack surface".  Some of them use normative language. These seem like glittering generalities, unless specific practices can be recommended or cited.


§8.3.1:  "(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]"
Should that be stated normatively?

§8.3.3: "Administrators SHOULD NOT use password-based
authentication but should..."
Should the second "should" be a "SHOULD"?

[Ballot comment]
Thanks for the good and extensive analysis in the security considerations sections. I would probably say  that we often/usually only see discussions in the security consideration section about the counter-measures (and partly attacks), but not really about the trust and thread model. I think that is probably the case because the basic trust and thread model, as you also describe it, is mostly valid for many communication protocols we specify in the IETF. As such, to make the security considerations more crisp, you could consider moving section 8.1 and 8.2 to the appendix instead. However, that's just an editorial idea and fully at your discretion.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-mile-xmpp-grid-09, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-01-14):

From: The IESG
To: IETF-Announce
CC: draft-ietf-mile-xmpp-grid@ietf.org, mile-chairs@tools.ietf.org, takeshi_takahashi@nict.go.jp, Takeshi Takahashi , mile-chairs@ietf.org, mile@ietf.org, alexey.melnikov@isode.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Using XMPP for Security Information Exchange) to Proposed Standard


The IESG has received a request from the Managed Incident Lightweight
Exchange WG (mile) to consider the following document: - 'Using XMPP for
Security Information Exchange'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-01-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Note that the document depends normatively on the following documents from XSF (see  for more details):

  [XEP-0004]
              Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and
              P. Saint-Andre, "Data Forms", XSF XEP 0004, August 2007.

  [XEP-0030]
              Hildebrand, J., Millard, P., Eatmon, R., and P. Saint-
              Andre, "Service Discovery", XSF XEP 0030, July 2010.

  [XEP-0060]
              Millard, P., Saint-Andre, P., and R. Meijer, "Publish-
              Subscribe", XSF XEP 0060, December 2017.

Abstract

  This document describes how to use the Extensible Messaging and
  Presence Protocol (XMPP) to collect and distribute 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).


The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mile-xmpp-grid/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mile-xmpp-grid/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Standards Track.
This is indicated so in the title page header.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document describes how to use the Extensible Messaging and
  Presence Protocol (XMPP) to collect and distribute 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).

Working Group Summary

  The initial draft was published three years ago. Since then, various
  aspects of this draft has been discussed, and the draft was thoroughly
  revised based on feedback from the audience, including those who
  are familiar with the XMPP base spec. The MILE WG seems to be happy
  with the current form of the document.

Document Quality

  XMPP-GRID works on top of existing XMPP protocol and can use the
  existing XMPP tools.

Personnel

  Takeshi Takahashi is the Document Shepherd and Alexey Melinkov is
  the Responsible Area Director

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd provided his final review as follows:
  https://www.ietf.org/mail-archive/web/mile/current/msg02438.html.
  The issues raised there was addressed in the 07 version of the draft.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  The document shepherd does not have any concerns on this.
  We once had a discussion on the depth of the review, especially from
  the aspect of XMPP base spec. The authors have invited those who are
  familiar with the base spec, and reflected all the comments received
  from them.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  It is always nice to receive more review.
  Having said that, the 3-year discussion on this draft was good
  enough for the draft to move forward.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No further remaining issue can be found in the MILE discussion
  at this moment.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  During three year discussion of this draft, ideas were discussed
  in the WG in a constructive manner. The MILE WG is rather small,
  and that helped the WG as a whole to understand and agree with it.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  This version still contains minor nits, but the editors will reflect
  them in the next version before the IETF last call.

  The boilerplate checks indicate there are 1 error, 0 flaws,
  2 warnings, and 5 comments (all about the references and citations).
  The manual check by the document shephered was done in:
  https://www.ietf.org/mail-archive/web/mile/current/msg02438.html.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  This document does not have any issue that require any external
  formal review, such as MIB Doctor, media type, and URI type reviews.


(13) Have all references within this document been identified as
either normative or informative?

  This document has 8 normative references and 4 informative references

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  This document has no actions for IANA.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  There is no concrete XML code or the likes in this document. The
  snippets shown in this documents are reviewed and no errors were
  found.