< draft-ietf-mile-xmpp-grid-09.txt   draft-ietf-mile-xmpp-grid-10.txt >
MILE N. Cam-Winget, Ed. MILE N. Cam-Winget, Ed.
Internet-Draft S. Appala Internet-Draft S. Appala
Intended status: Standards Track S. Pope Intended status: Standards Track S. Pope
Expires: July 2, 2019 Cisco Systems Expires: September 12, 2019 Cisco Systems
P. Saint-Andre P. Saint-Andre
Mozilla Mozilla
December 29, 2018 March 11, 2019
Using XMPP for Security Information Exchange Using XMPP for Security Information Exchange
draft-ietf-mile-xmpp-grid-09 draft-ietf-mile-xmpp-grid-10
Abstract Abstract
This document describes how to use the Extensible Messaging and This document describes how to use the Extensible Messaging and
Presence Protocol (XMPP) to collect and distribute security-relevant Presence Protocol (XMPP) to collect and distribute security incident
information between network-connected devices. To illustrate the reports and other security-relevant information between network-
principles involved, this document describes such a usage for the connected devices, primarily for the purpose of communication among
Incident Object Description Exchange Format (IODEF). Computer Security Incident Response Teams and associated entities.
To illustrate the principles involved, this document describes such a
usage for the Incident Object Description Exchange Format (IODEF).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 2, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Service Discovery . . . . . . . . . . . . . . . . . . . . . . 7 5. Service Discovery . . . . . . . . . . . . . . . . . . . . . . 7
6. Publish-Subscribe . . . . . . . . . . . . . . . . . . . . . . 8 6. Publish-Subscribe . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 13
8.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 13 8.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 14
8.3. Countermeasures . . . . . . . . . . . . . . . . . . . . . 17 8.3. Countermeasures . . . . . . . . . . . . . . . . . . . . . 18
8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 21
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
10. Operations and Management Considerations . . . . . . . . . . 21 10. Operations and Management Considerations . . . . . . . . . . 23
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Normative References . . . . . . . . . . . . . . . . . . 22 12.1. Normative References . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . 23 12.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
This document describes "XMPP-Grid": a method for using the This document defines an architecture, i.e., "XMPP-Grid", as a method
Extensible Messaging and Presence Protocol (XMPP) [RFC6120] to for using the Extensible Messaging and Presence Protocol (XMPP)
collect and distribute security-relevant information among network [RFC6120] to collect and distribute security incident reports and
platforms, endpoints, and any other network-connected device. Among other security-relevant information among network platforms,
other things, XMPP provides a publish-subscribe service [XEP-0060] endpoints, and any other network-connected device, primarily for the
that acts as a broker, enabling control-plane functions by which purpose of communication among Computer Security Incident Response
entities can discover available information to be published or Teams and associated entities. In effect, this document specifies an
Applicability Statement ([RFC2026], Section 3.2) that defines how to
use XMPP for the exchange of security notifications on a controlled-
access network among authorized entities.
Among other things, XMPP provides a publish-subscribe service
[XEP-0060] that acts as a broker, enabling control-plane functions by
which entities can discover available information to be published or
consumed. Although such information can take the form of any consumed. Although such information can take the form of any
structured data (XML, JSON, etc.), this document illustrates the structured data (XML, JSON, etc.), this document illustrates the
principles of XMPP-Grid with examples that use the Incident Object principles of XMPP-Grid with examples that use the Incident Object
Description Exchange Format (IODEF) [RFC7970]. That is, while other Description Exchange Format (IODEF) [RFC7970]. That is, while other
security information formats can be shared using XMPP, this document security information formats can be shared using XMPP, this document
uses IODEF as one such example format that can be published and uses IODEF as one such example format that can be published and
consumed using XMPP. consumed using XMPP.
2. Terminology 2. Terminology
This document uses XMPP terminology defined in [RFC6120] and This document uses XMPP terminology defined in [RFC6120] and
[XEP-0060]. Because the intended audience for this document is those [XEP-0060]. Because the intended audience for this document is those
who implement and deploy security reporting systems, mappings are who implement and deploy security reporting systems, mappings are
provided for the benefit of XMPP developers and operators. provided for the benefit of XMPP developers and operators.
Broker: A specific type of controller containing control plane Broker: A specific type of controller containing control plane
functions; as used here, the term refers to an XMPP publish- functions; as used here, the term refers to an XMPP publish-
subscribe service. subscribe service.
Broker Flow: A method by which security-related information is Broker Flow: A method by which security incident reports and other
published and consumed in a mediated fashion through a Broker. In security-relevant information is published and consumed in a
this flow, the Broker handles authorization of Consumers and mediated fashion through a Broker. In this flow, the Broker
Providers to Topics, receives messages from Providers, and handles authorization of Consumers and Providers to Topics,
delivers published messages to Consumers. receives messages from Providers, and delivers published messages
to Consumers.
Consumer: An entity that contains functions to receive information Consumer: An entity that contains functions to receive information
from other components; as used here, the term refers to an XMPP from other components; as used here, the term refers to an XMPP
publish-subscribe Subscriber. publish-subscribe Subscriber.
Controller: A "component containing control plane functions that Controller: A "component containing control plane functions that
manage and facilitate information sharing or execute on security manage and facilitate information sharing or execute on security
functions"; as used here, the term refers to an XMPP server, which functions"; as used here, the term refers to an XMPP server, which
provides core message delivery [RFC6120] used by publish-subscribe provides core message delivery [RFC6120] used by publish-subscribe
entities. entities.
Node: The XMPP term for a Topic. Node: The XMPP term for a Topic.
Platform: Any entity that connects to the XMPP-Grid in order to Platform: Any entity that connects to the XMPP-Grid in order to
publish or consume security-related data. publish or consume security-relevant information.
Provider: An entity that contains functions to provide information Provider: An entity that contains functions to provide information
to other components; as used here, the term refers to an XMPP to other components; as used here, the term refers to an XMPP
publish-subscribe Publisher. publish-subscribe Publisher.
Topic: A contextual information channel created on a Broker at which Topic: A contextual information channel created on a Broker at which
messages generated by a Provider are propagated in real time to messages generated by a Provider are propagated in real time to
one or more Consumers. Each Topic is limited to a specific type one or more Consumers. Each Topic is limited to a specific type
and format of security data (e.g. IODEF namespace) and provides and format of security data (e.g. IODEF namespace) and provides
an XMPP interface by which the data can be obtained. an XMPP interface by which the data can be obtained.
skipping to change at page 4, line 50 skipping to change at page 5, line 7
| Platforms | | | Platforms | |
| | |-+ | | |-+
+------------------------------------+ | | +------------------------------------+ | |
+------------------------------------+ | +------------------------------------+ |
+------------------------------------+ +------------------------------------+
Figure 1: XMPP-Grid Architecture Figure 1: XMPP-Grid Architecture
Platforms connect to the Controller (XMPP server) to authenticate and Platforms connect to the Controller (XMPP server) to authenticate and
then establish appropriate authorizations to be a Provider or then establish appropriate authorizations to be a Provider or
Consumer of interested Topics at the Broker. The control plane Consumer of topics of interest at the Broker. The control plane
messaging is established through XMPP and shown as "A" (control plane messaging is established through XMPP and shown as "A" (control plane
interface) in Figure 1. Authorized nodes can then share data either interface) in Figure 1. Authorized Platforms can then share data
through the Broker (shown as "B" in Figure 1) or in some cases either through the Broker (shown as "B" in Figure 1) or in some cases
directly (shown as "C" in Figure 1). This document focuses primarily directly (shown as "C" in Figure 1). This document focuses primarily
on the Broker Flow for information sharing ("direct flow" on the Broker Flow for information sharing ("direct flow"
interactions can be used for specialized purposes such as bulk data interactions can be used for specialized purposes such as bulk data
transfer, but methods for doing so are outside the scope of this transfer, but methods for doing so are outside the scope of this
document). document).
4. Workflow 4. Workflow
A typical XMPP-Grid workflow is as follows: Implementations of XMPP-Grid workflow adhere to the following
workflow:
a. A Platform with a source of security data requests connection to a. A Platform with a source of security data requests connection to
the XMPP-Grid via a Controller. the XMPP-Grid via a Controller.
b. The Controller authenticates the Platform. b. The Controller authenticates the Platform.
c. The Platform establishes authorized privileges (e.g. privilege to c. The Platform establishes authorized privileges (e.g. privilege to
publish and/or subscribe to one or more Topics) with a Broker. publish and/or subscribe to one or more Topics) with a Broker.
d. The Platform can publish security-related data to a Topic, d. The Platform can publish security incident reports and other
subscribe to a Topic, query a Topic, or any combination of these security-relevant information to a Topic, subscribe to a Topic,
operations. query a Topic, or any combination of these operations.
e. A Provider unicasts its Topic updates to the Grid in real time e. A Provider unicasts its Topic updates to the Grid in real time
through a Broker. The Broker handles replication and through a Broker. The Broker handles replication and
distribution of the Topic to Consumers. A Provider can publish distribution of the Topic to Consumers. A Provider can publish
the same or different data to multiple Topics. the same or different data to multiple Topics.
f. Any Platform on the Grid can subscribe to any Topics published to f. Any Platform on the Grid can subscribe to any Topics published to
the Grid (as permitted by authorization policy), and (as the Grid (as permitted by authorization policy), and (as
Consumers) will then receive a continual, real-time stream of Consumers) will then receive a continual, real-time stream of
updates from the Topics to which it is subscribed. updates from the Topics to which it is subscribed.
skipping to change at page 7, line 8 skipping to change at page 7, line 8
| Receive IODEF |<------------------------| | Receive IODEF |<------------------------|
| Incident (XEP-0060) | | | Incident (XEP-0060) | |
|<---------------------| | |<---------------------| |
| | | | | |
Figure 2: IODEF Example Workflow Figure 2: IODEF Example Workflow
XMPP-Grid implementations MUST adhere to the mandatory-to-implement XMPP-Grid implementations MUST adhere to the mandatory-to-implement
and mandatory-to-negotiate features as defined in [RFC6120]. and mandatory-to-negotiate features as defined in [RFC6120].
Similarly, implementations MUST implement [XEP-0060] to facilitate Similarly, implementations MUST implement [XEP-0060] to facilitate
the asynchronous sharing for information. The Service Discovery per the asynchronous sharing for information. Implementations SHOULD
[XEP-0030] SHOULD be implemented to facilitate the means to implement Service Discovery as defined in [XEP-0030] to facilitate
dynamically discover the available information and namespaces the means to dynamically discover the available information and
(Topics) to be published or consumed. namespaces (Topics) to be published or consumed. Implementations
should take caution if their deployments allow for a large number of
topics. The Result Set Management as defined in [XEP-0059], SHOULD
be used to allow the requesting entity to explicitly request Service
Discovery result sets to be returned in pages or limited size, if the
discovery results are larger in size. Note that the control plane
may optionally also implement [XEP-0203] to facilitate delayed
delivery of messages to the connected consumer as described in
[XEP-0060]. Since information may be timely and sensitive,
capability providers should communicate to the controller whether its
messages can be cached for delayed delivery during configuration;
such function is out of scope for this document.
The following sections provide protocol examples for the service The following sections provide protocol examples for the service
discovery and publish-subscribe parts of the workflow. discovery and publish-subscribe parts of the workflow.
5. Service Discovery 5. Service Discovery
Using the XMPP service discovery extension [XEP-0030], a Controller Using the XMPP service discovery extension [XEP-0030], a Controller
enables Platforms to discover what information can be consumed enables Platforms to discover what information can be consumed
through the Broker, and at which Topics. As an example, the through the Broker, and at which Topics. Platforms could use
Controller at 'security-grid.example' might provide a Broker at [XEP-0059] to restrict the size of the result sets the Controller
returns in Service Discovery response. As an example, the Controller
at 'security-grid.example' might provide a Broker at
'broker.security-grid.example' hosting a number of Topics. A 'broker.security-grid.example' hosting a number of Topics. A
Platform at 'xmpp-grid-client@mile-host.example' would query the Platform at 'xmpp-grid-client@mile-host.example' would query the
Broker about its available Topics by sending an XMPP "disco#items" Broker about its available Topics by sending an XMPP "disco#items"
request to the Broker: request to the Broker:
<iq type='get' <iq type='get'
from='xmpp-grid-client@mile-host.example/2EBE702A97D6' from='xmpp-grid-client@mile-host.example/2EBE702A97D6'
to='broker.security-grid.example' to='broker.security-grid.example'
id='B3C17F7B-B9EF-4ABA-B08D-805DA9F34626'> id='B3C17F7B-B9EF-4ABA-B08D-805DA9F34626'>
<query xmlns='http://jabber.org/protocol/disco#items'/> <query xmlns='http://jabber.org/protocol/disco#items'/>
skipping to change at page 8, line 13 skipping to change at page 8, line 31
Platform would send an XMPP "disco#info" request to each Topic: Platform would send an XMPP "disco#info" request to each Topic:
<iq type='get' <iq type='get'
from='xmpp-grid-client@mile-host.example/2EBE702A97D6' from='xmpp-grid-client@mile-host.example/2EBE702A97D6'
to='broker.security-grid.example' to='broker.security-grid.example'
id='D367D4ED-2795-489C-A83E-EAAFA07A0356' id='D367D4ED-2795-489C-A83E-EAAFA07A0356'
<query xmlns='http://jabber.org/protocol/disco#info' <query xmlns='http://jabber.org/protocol/disco#info'
node='MILEHost'/> node='MILEHost'/>
</iq> </iq>
The Broker responds with the "disco#info" description, which SHOULD The Broker responds with the "disco#info" description, which MUST
include an XMPP Data Form [XEP-0004] including a 'pubsub#type' field include an XMPP Data Form [XEP-0004] including a 'pubsub#type' field
that specifies the supported namespace (in this example, the IODEF that specifies the supported namespace (in this example, the IODEF
namespace defined in [RFC7970]): namespace defined in [RFC7970]):
<iq type='result' <iq type='result'
from='broker.security-grid.example' from='broker.security-grid.example'
to='xmpp-grid-client@mile-host.example/2EBE702A97D6' to='xmpp-grid-client@mile-host.example/2EBE702A97D6'
id='D367D4ED-2795-489C-A83E-EAAFA07A0356'/> id='D367D4ED-2795-489C-A83E-EAAFA07A0356'/>
<query xmlns='http://jabber.org/protocol/disco#info' <query xmlns='http://jabber.org/protocol/disco#info'
node='MILEHost'> node='MILEHost'>
<identity category='pubsub' type='leaf'/> <identity category='pubsub' type='leaf'/>
<feature var='http://jabber.org/protocol/pubsub'/> <feature var='http://jabber.org/protocol/pubsub'/>
<x xmlns='jabber:x:data' type='result'> <x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'> <field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#meta-data</value> <value>http://jabber.org/protocol/pubsub#meta-data</value>
</field> </field>
<field var='pubsub#type' label='Payload type' type='text-single'> <field var='pubsub#type' label='Payload type' type='text-single'>
<value>urn:ietf:params:xml:ns:iodef-2.0</value> <value>urn:ietf:params:xml:ns:iodef-2.0</value>
</field> </field>
</x> </x>
</query> </query>
</iq> </iq>
The Platform discovers the topics by obtaining the Broker's response
and obtaining the namespaces returned in the "pubsub#type" field (in
the foregoing example, IODEF 2.0).
6. Publish-Subscribe 6. Publish-Subscribe
Using the XMPP publish-subscribe extension [XEP-0030], a Consumer Using the XMPP publish-subscribe extension [XEP-0060], a Consumer
subscribes to a Topic and a Provider publishes information to that subscribes to a Topic and a Provider publishes information to that
Topic, which the Broker then distributes to all subscribed Consumers. Topic, which the Broker then distributes to all subscribed Consumers.
First, a Provider would create a Topic as follows: First, a Provider would create a Topic as follows:
<iq type='set' <iq type='set'
from='datasource@provider.example/F12C2EFC9BB0' from='datasource@provider.example/F12C2EFC9BB0'
to='broker.security-grid.example' to='broker.security-grid.example'
id='A67507DF-2F22-4937-8D30-88D2F7DBA279'> id='A67507DF-2F22-4937-8D30-88D2F7DBA279'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'> <pubsub xmlns='http://jabber.org/protocol/pubsub'>
skipping to change at page 9, line 4 skipping to change at page 9, line 44
First, a Provider would create a Topic as follows: First, a Provider would create a Topic as follows:
<iq type='set' <iq type='set'
from='datasource@provider.example/F12C2EFC9BB0' from='datasource@provider.example/F12C2EFC9BB0'
to='broker.security-grid.example' to='broker.security-grid.example'
id='A67507DF-2F22-4937-8D30-88D2F7DBA279'> id='A67507DF-2F22-4937-8D30-88D2F7DBA279'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'> <pubsub xmlns='http://jabber.org/protocol/pubsub'>
<create node='MILEHost'/> <create node='MILEHost'/>
</pubsub> </pubsub>
</iq> </iq>
Note: The foregoing example is the minimal protocol needed to create Note: The foregoing example is the minimal protocol needed to create
a Topic with the default node configuration on the XMPP publish- a Topic with the default node configuration on the XMPP publish-
subscribe service specified in the 'to' address of the creation subscribe service specified in the 'to' address of the creation
request stanza. Depending on security requirements, the Provider request stanza. Depending on security requirements, the Provider
might need to request a non-default configuration for the node; see might need to request a non-default configuration for the node; see
[XEP-0060] for detailed examples. [XEP-0060] for detailed examples. To also help with the Topic
configuration, the Provider may also optionally include
configurations parameters such as:
<configure>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#node_config</value>
</field>
<field var='pubsub#access_model'><value>authorize</value></field>
<field var='pubsub#persist_items'><value>1</value></field>
<field var='pubsub#send_last_published_item'><value>never</value></field>
</x>
</configure>
The above configuration indicates the Topic is configured to enable
the XMPP-Controller to manage the subscriptions, be in persistent
mode and disables the Broker from cacheing the last item published.
Please refer to [XEP-0060] a more detailed description of these
configuration and other available configuration options.
Unless an error occurs (see [XEP-0060] for various error flows), the Unless an error occurs (see [XEP-0060] for various error flows), the
Broker responds with success: Broker responds with success:
<iq type='result' <iq type='result'
from='broker.security-grid.example' from='broker.security-grid.example'
to='datasource@provider.example/F12C2EFC9BB0' to='datasource@provider.example/F12C2EFC9BB0'
id='A67507DF-2F22-4937-8D30-88D2F7DBA279'/> id='A67507DF-2F22-4937-8D30-88D2F7DBA279'/>
Second, a Consumer would subscribe as follows: Second, a Consumer would subscribe as follows:
skipping to change at page 9, line 46 skipping to change at page 11, line 17
to='xmpp-grid-client@mile-host.example/2EBE702A97D6' to='xmpp-grid-client@mile-host.example/2EBE702A97D6'
id='9C6EEE9E-F09A-4418-8D68-3BA6AF852522'> id='9C6EEE9E-F09A-4418-8D68-3BA6AF852522'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'> <pubsub xmlns='http://jabber.org/protocol/pubsub'>
<subscription <subscription
node='MILEHost' node='MILEHost'
jid='xmpp-grid-client@mile-host.example' jid='xmpp-grid-client@mile-host.example'
subscription='subscribed'/> subscription='subscribed'/>
</pubsub> </pubsub>
</iq> </iq>
Third, a Provider would publish an incident as follows: Third, a Provider would publish an incident to the broker using the
MILEHost topic as follows:
<iq type='set' <iq type='set'
from='datasource@provider.example/F12C2EFC9BB0' from='datasource@provider.example/F12C2EFC9BB0'
to='broker.security-grid.example' to='broker.security-grid.example'
id='2A17D283-0DAE-4A6C-85A9-C10B1B40928C'> id='2A17D283-0DAE-4A6C-85A9-C10B1B40928C'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'> <pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='MILEHost'> <publish node='MILEHost'>
<item id='8bh1g27skbga47fh9wk7'> <item id='8bh1g27skbga47fh9wk7'>
<IODEF-Document version="2.00" xml:lang="en" <IODEF-Document version="2.00" xml:lang="en"
xmlns="urn:ietf:params:xml:ns:iodef-2.0" xmlns="urn:ietf:params:xml:ns:iodef-2.0"
skipping to change at page 10, line 37 skipping to change at page 11, line 52
</IODEF-Document> </IODEF-Document>
</item> </item>
</publish> </publish>
</pubsub> </pubsub>
</iq> </iq>
(The payload in the foregoing example is from [RFC7970]; payloads for (The payload in the foregoing example is from [RFC7970]; payloads for
additional use cases can be found in [RFC8274].) additional use cases can be found in [RFC8274].)
The Broker would then deliver that incident report to all Consumers The Broker would then deliver that incident report to all Consumers
who are subscribe to the Topic: who are subscribed to the Topic:
<message <message
from='broker.security-grid.example' from='broker.security-grid.example'
to='xmpp-grid-client@mile-host.example/2EBE702A97D6' to='xmpp-grid-client@mile-host.example/2EBE702A97D6'
id='37B3921D-4F7F-450F-A589-56119A88BC2E'> id='37B3921D-4F7F-450F-A589-56119A88BC2E'>
<event xmlns='http://jabber.org/protocol/pubsub#event'> <event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='MILEHost'> <items node='MILEHost'>
<item id='iah37s61s964gquqy47aksbx9453ks77'> <item id='iah37s61s964gquqy47aksbx9453ks77'>
<IODEF-Document version="2.00" xml:lang="en" <IODEF-Document version="2.00" xml:lang="en"
xmlns="urn:ietf:params:xml:ns:iodef-2.0" xmlns="urn:ietf:params:xml:ns:iodef-2.0"
skipping to change at page 11, line 43 skipping to change at page 12, line 43
7. IANA Considerations 7. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
8. Security Considerations 8. Security Considerations
An XMPP-Grid Controller serves as an controlling broker for XMPP-Grid An XMPP-Grid Controller serves as an controlling broker for XMPP-Grid
Platforms such as Enforcement Points, Policy Servers, CMDBs, and Platforms such as Enforcement Points, Policy Servers, CMDBs, and
Sensors, using a publish-subscribe-search model of information Sensors, using a publish-subscribe-search model of information
exchange and lookup. By increasing the ability of XMPP-Grid exchange and lookup. By increasing the ability of XMPP-Grid
Platforms to learn about and respond to security-relevant events and Platforms to learn about and respond to security incident reports and
data, XMPP-Grid can improve the timeliness and utility of the other security-relevant information, XMPP-Grid can improve the
security system. However, this integrated security system can also timeliness and utility of the security system. However, this
be exploited by attackers if they can compromise it. Therefore, integrated security system can also be exploited by attackers if they
strong security protections for XMPP-Grid are essential. can compromise it. Therefore, strong security protections for XMPP-
Grid are essential.
This section provides a security analysis of the XMPP-Grid data As XMPP is the core of this document, the security considerations of
transfer protocol and the architectural elements that employ it, [RFC6120] applies. In addition, as XMPP-Grid defines a specific
instance, this section provides a security analysis of the XMPP-Grid
data transfer protocol and the architectural elements that employ it,
specifically with respect to their use of this protocol. Three specifically with respect to their use of this protocol. Three
subsections define the trust model (which elements are trusted to do subsections define the trust model (which elements are trusted to do
what), the threat model (attacks that can be mounted on the system), what), the threat model (attacks that can be mounted on the system),
and the countermeasures (ways to address or mitigate the threats and the countermeasures (ways to address or mitigate the threats
previously identified). previously identified).
8.1. Trust Model 8.1. Trust Model
The first step in analyzing the security of the XMPP-Grid transport The first step in analyzing the security of the XMPP-Grid transport
protocol is to describe the trust model, listing what each protocol is to describe the trust model, listing what each
skipping to change at page 12, line 48 skipping to change at page 14, line 4
8.1.3. XMPP-Grid Controller 8.1.3. XMPP-Grid Controller
The XMPP-Grid Controller (including its associated Broker) is trusted The XMPP-Grid Controller (including its associated Broker) is trusted
to: to:
o Broker requests for data and enforce authorization of access to o Broker requests for data and enforce authorization of access to
this data throughout its lifecycle this data throughout its lifecycle
o Perform service requests in a timely and accurate manner o Perform service requests in a timely and accurate manner
o Create and maintain accurate operational attributes o Create and maintain accurate operational attributes
o Only reveal data to and accept service requests from authorized o Only reveal data to and accept service requests from authorized
parties parties
The XMPP-Grid Controller is not expected (trusted) to: The XMPP-Grid Controller is not expected (trusted) to:
o Verify the truth (correctness) of data o Verify the truth (correctness) of data
8.1.4. Certification Authority 8.1.4. Certification Authority
The Certification Authority (CA) that issues certificates for the To allow XMPP-Grid Platforms to mutually authenticate with XMPP-Grid
XMPP-Grid Controller and/or XMPP-Grid Platforms (or each CA, if there Controllers, it is expected that a Certification Authority (CA) is
are several) is trusted to: employed to issue certificates. Such a CA (or each CA, if there are
several) is trusted to:
o Ensure that only proper certificates are issued and that all o Ensure that only proper certificates are issued and that all
certificates are issued in accordance with the CA's policies certificates are issued in accordance with the CA's policies
o Revoke certificates previously issued when necessary o Revoke certificates previously issued when necessary
o Regularly and securely distribute certificate revocation o Regularly and securely distribute certificate revocation
information information
o Promptly detect and report any violations of this trust so that o Promptly detect and report any violations of this trust so that
skipping to change at page 15, line 29 skipping to change at page 16, line 31
o Establish a communication channel using another XMPP-Grid o Establish a communication channel using another XMPP-Grid
Platform's session-id Platform's session-id
Dependencies of or vulnerabilities of authorized XMPP-Grid Platforms Dependencies of or vulnerabilities of authorized XMPP-Grid Platforms
can be exploited to effect these attacks. Another way to effect can be exploited to effect these attacks. Another way to effect
these attacks is to gain the ability to impersonate an XMPP-Grid these attacks is to gain the ability to impersonate an XMPP-Grid
Platform (through theft of the XMPP-Grid Platform's identity Platform (through theft of the XMPP-Grid Platform's identity
credentials or through other means). Even a clock skew between the 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 and XMPP-Grid Controller can cause problems if the
XMPP-Grid Platform assumes that old XMPP-Grid Platform data deserves XMPP-Grid Platform assumes that old XMPP-Grid Platform data should be
to be ignored. ignored.
8.2.3. XMPP-Grid Controllers 8.2.3. XMPP-Grid Controllers
An unauthorized XMPP-Grid Controller (one which is not trusted by An unauthorized XMPP-Grid Controller (one which is not trusted by
XMPP-Grid Platforms) cannot mount any attacks other than those listed XMPP-Grid Platforms) cannot mount any attacks other than those listed
in the Network Attacks section above. in the Network Attacks section above.
An authorized XMPP-Grid Controller can mount many attacks. Similar An authorized XMPP-Grid Controller can mount many attacks. Similar
to the XMPP-Grid Platform case described above, these attacks might to the XMPP-Grid Platform case described above, these attacks might
occur because the XMPP-Grid Controller is controlled by a malicious, occur because the XMPP-Grid Controller is controlled by a malicious,
skipping to change at page 16, line 23 skipping to change at page 17, line 27
single XMPP-Grid Platform could single XMPP-Grid Platform could
o Obtain and cache XMPP-Grid Platform credentials so they can be o Obtain and cache XMPP-Grid Platform credentials so they can be
used to impersonate XMPP-Grid Platforms even after a breach of the used to impersonate XMPP-Grid Platforms even after a breach of the
XMPP-Grid Controller is repaired XMPP-Grid Controller is repaired
o Obtain and cache XMPP-Grid Controller administrator credentials so o Obtain and cache XMPP-Grid Controller administrator credentials so
they can be used to regain control of the XMPP-Grid Controller they can be used to regain control of the XMPP-Grid Controller
after the breach of the XMPP-Grid Controller is repaired after the breach of the XMPP-Grid Controller is repaired
o Eavesdrop, inject or modify the data being transferred between
provider and consumer
Dependencies of or vulnerabilities of the XMPP-Grid Controller can be Dependencies of or vulnerabilities of the XMPP-Grid Controller can be
exploited to obtain control of the XMPP-Grid Controller and effect exploited to obtain control of the XMPP-Grid Controller and effect
these attacks. these attacks.
8.2.4. Certification Authority 8.2.4. Certification Authority
A Certification Authority trusted to issue certificates for the XMPP- A Certification Authority trusted to issue certificates for the XMPP-
Grid Controller and/or XMPP-Grid Platforms can mount several attacks: Grid Controller and/or XMPP-Grid Platforms can mount several attacks:
o Issue certificates for unauthorized parties, enabling them to o Issue certificates for unauthorized parties, enabling them to
skipping to change at page 17, line 29 skipping to change at page 18, line 36
8.3. Countermeasures 8.3. Countermeasures
Below are countermeasures for specific attack scenarios to the XMPP- Below are countermeasures for specific attack scenarios to the XMPP-
Grid infrastructure. Grid infrastructure.
8.3.1. Securing the XMPP-Grid Data Transfer Protocol 8.3.1. Securing the XMPP-Grid Data Transfer Protocol
To address network attacks, 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 described in this document requires that the XMPP-Grid messages MUST
be carried over TLS (minimally TLS 1.2 [RFC8446]) as described in be carried over TLS (minimally TLS 1.2 [RFC8446]) as described in
[RFC6120] and updated by [RFC7590]. The XMPP-Grid Platform MUST [RFC6120] and updated by [RFC7590]. The XMPP-Grid Controller and
verify the XMPP-Grid Controller's certificate and determine whether XMPP-Grid Platforms SHOULD mutually authenticate. The XMPP-Grid
the XMPP-Grid Controller is trusted by this XMPP-Grid Platform before Platform MUST verify the XMPP-Grid Controller's certificate and
completing the TLS handshake. The XMPP-Grid Controller MUST determine whether the XMPP-Grid Controller is trusted by this XMPP-
authenticate the XMPP-Grid Platform either using the SASL EXTERNAL Grid Platform before completing the TLS handshake. To ensure
mechanism [RFC4422] or using the SASL SCRAM mechanism (with the interoperability, implementations MUST implement at least one of
SCRAM-SHA-256-PLUS variant being preferred over the SCRAM-SHA-256 either the SASL EXTERNAL mechanism [RFC4422] or the SASL SCRAM
variant and SHA-256 variants [RFC7677] being preferred over SHA-1 mechanism. When using the SASL SCRAM mechanism, the SCRAM-SHA-
varients [RFC5802]). XMPP-Grid Platforms and XMPP-Grid Controllers 256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant;
using mutual certificate-based authentication SHOULD each verify the and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1
revocation status of the other party's certificate. All XMPP-Grid variants [RFC5802]). XMPP-Grid Platforms and XMPP-Grid Controllers
Controllers and XMPP-Grid Platforms MUST implement both SASL EXTERNAL using certificate-based authentication SHOULD each verify the
and SASL SCRAM. The selection of which XMPP-Grid Platform revocation status of the other party's certificate. The selection of
authentication technique to use in any particular deployment is left which XMPP-Grid Platform authentication technique to use in any
to the administrator. particular deployment is left to the administrator.
These protocol security measures provide protection against all the These protocol security measures provide protection against all the
network attacks listed in the above document section except denial of network attacks listed in the above document section except denial of
service attacks. If protection against these denial of service service attacks. If protection against these denial of service
attacks is desired, ingress filtering, rate limiting per source IP attacks is desired, ingress filtering, rate limiting per source IP
address, and other denial of service mitigation measures can be address, and other denial of service mitigation measures can be
employed. In addition, an XMPP-Grid Controller MAY automatically employed. In addition, an XMPP-Grid Controller MAY automatically
disable a misbehaving XMPP-Grid Platform. disable a misbehaving XMPP-Grid Platform.
8.3.2. Securing XMPP-Grid Platforms 8.3.2. Securing XMPP-Grid Platforms
skipping to change at page 18, line 26 skipping to change at page 19, line 34
can configure a specific XMPP-Grid Platform as a DHCP [RFC2131] can configure a specific XMPP-Grid Platform as a DHCP [RFC2131]
server and authorize only the operations and metadata types needed by server and authorize only the operations and metadata types needed by
a DHCP server to be permitted for that XMPP-Grid Platform. These a DHCP server to be permitted for that XMPP-Grid Platform. These
techniques can reduce the negative impacts of a compromised XMPP-Grid techniques can reduce the negative impacts of a compromised XMPP-Grid
Platform without diminishing the utility of the overall system. Platform without diminishing the utility of the overall system.
To handle attacks within the bounds of this authorization model, the To handle attacks within the bounds of this authorization model, the
XMPP-Grid Controller MAY also include rate limits and alerts for XMPP-Grid Controller MAY also include rate limits and alerts for
unusual XMPP-Grid Platform behavior. XMPP-Grid Controllers SHOULD unusual XMPP-Grid Platform behavior. XMPP-Grid Controllers SHOULD
make it easy to revoke an XMPP-Grid Platform's authorization when make it easy to revoke an XMPP-Grid Platform's authorization when
necessary. Another way to detect attacks from XMPP-Grid Platforms is necessary. The XMPP-Grid Controller SHOULD include auditable logs of
to create fake entries in the available data (honeytokens) which XMPP-Grid Platform activities.
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 To avoid compromise of XMPP-Grid Platform, XMPP-Grid Platform SHOULD
be hardened against attack and minimized to reduce their attack be hardened against attack and minimized to reduce their attack
surface. They should be well managed to minimize vulnerabilities in surface. They should be well managed to minimize vulnerabilities in
the underlying platform and in systems upon which the XMPP-Grid the underlying platform and in systems upon which the XMPP-Grid
Platform depends. Personnel with administrative access should be Platform depends. Personnel with administrative access should be
carefully screened and monitored to detect problems as soon as carefully screened and monitored to detect problems as soon as
possible. possible.
8.3.3. Securing XMPP-Grid Controllers 8.3.3. Securing XMPP-Grid Controllers
skipping to change at page 18, line 52 skipping to change at page 20, line 8
Because of the serious consequences of XMPP-Grid Controller Because of the serious consequences of XMPP-Grid Controller
compromise, XMPP-Grid Controllers need to be especially well hardened compromise, XMPP-Grid Controllers need to be especially well hardened
against attack and minimized to reduce their attack surface. They against attack and minimized to reduce their attack surface. They
need to be well managed to minimize vulnerabilities in the underlying need to be well managed to minimize vulnerabilities in the underlying
platform and in systems upon which the XMPP-Grid Controller depends. platform and in systems upon which the XMPP-Grid Controller depends.
Network security measures such as firewalls or intrusion detection Network security measures such as firewalls or intrusion detection
systems can be used to monitor and limit traffic to and from the systems can be used to monitor and limit traffic to and from the
XMPP-Grid Controller. Personnel with administrative access ought to XMPP-Grid Controller. Personnel with administrative access ought to
be carefully screened and monitored to detect problems as soon as be carefully screened and monitored to detect problems as soon as
possible. Administrators SHOULD NOT use password-based possible. Administrators SHOULD NOT use password-based
authentication but should instead use non-reusable credentials and authentication but SHOULD instead use non-reusable credentials and
multi-factor authentication (where available). Physical security multi-factor authentication (where available). Physical security
measures ought to be employed to prevent physical attacks on XMPP- measures ought to be employed to prevent physical attacks on XMPP-
Grid Controllers. Grid Controllers.
To ease detection of XMPP-Grid Controller compromise should it occur, To ease detection of XMPP-Grid Controller compromise should it occur,
XMPP-Grid Controller behavior should be monitored to detect unusual XMPP-Grid Controller behavior should be monitored to detect unusual
behavior (such as a reboot, a large increase in traffic, or different behavior (such as a reboot, a large increase in traffic, or different
views of an information repository for similar XMPP-Grid Platforms). views of an information repository for similar XMPP-Grid Platforms).
XMPP-Grid Platforms should log and/or notify administrators when It is a matter of local policy whether XMPP-Grid Platforms log and/or
peculiar XMPP-Grid Controller behavior is detected. To aid forensic notify administrators when peculiar XMPP-Grid Controller behavior is
investigation, permanent read-only audit logs of security-relevant detected, and whether read-only audit logs of security-relevant
information (especially administrative actions) should be maintained. information (especially administrative actions) are maintained;
If XMPP-Grid Controller compromise is detected, a careful analysis however, such behavior is encouraged to aid in forensic analysis.
should be performed of the impact of this compromise. Any reusable Furthermore, if compromise of an XMPP-Grid Controller is detected, a
credentials that can have been compromised should be reissued. careful analysis should be performed and any reusable credentials
that can have been compromised should be reissued.
To address the potential for the XMPP-Grid controller to eavesdrop,
modify or inject data, it would be desirable to deploy end-to-end
encryption between the provider and the consumer(s). Unfortunately,
because there is no standardized method for encryption of one-to-many
messages within XMPP, techniques for enforcing end-to-end encryption
are out of scope for this specification.
8.3.4. Broker Access Models for Topics 8.3.4. Broker Access Models for Topics
The XMPP publish-subscribe specification [XEP-0060] defines five The XMPP publish-subscribe specification [XEP-0060] defines five
access models for subscribing to Topics at a Broker: open, presence, access models for subscribing to Topics at a Broker: open, presence,
roster, authorize, and whitelist. The first model allows roster, authorize, and whitelist. The first model allows
uncontrolled access and the next two models are appropriate only in uncontrolled access and the next two models are appropriate only in
instant-messaging applications. Therefore, a Broker SHOULD support instant-messaging applications. Therefore, a Broker SHOULD support
only the authorize model (under which the Topic owner needs to only the authorize model (under which the Topic owner needs to
approve all subscription requests and only subscribers can retrieve approve all subscription requests and only subscribers can retrieve
skipping to change at page 19, line 41 skipping to change at page 21, line 10
the deployment burden, subscription approvals and whitelist the deployment burden, subscription approvals and whitelist
management can be automated (e.g, the Topic "owner" can be a policy management can be automated (e.g, the Topic "owner" can be a policy
server). The choice between "authorize" and "whitelist" as the server). The choice between "authorize" and "whitelist" as the
default access model is a matter for local service policy. default access model is a matter for local service policy.
8.3.5. Limit on Search Result Size 8.3.5. Limit on Search Result Size
While XMPP-Grid is designed for high scalability to 100,000s of While XMPP-Grid is designed for high scalability to 100,000s of
Platforms, an XMPP-Grid Controller MAY establish a limit to the Platforms, an XMPP-Grid Controller MAY establish a limit to the
amount of data it is willing to return in search or subscription amount of data it is willing to return in search or subscription
results. This mitigates the threat of an XMPP-Grid Platform causing results. Platforms could use [XEP-0059] to restrict the size of the
resource exhaustion by issuing a search or subscription that leads to result sets the Controller returns in search or subscription results
an enormous result. or topics' service discovery. 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.6. Securing the Certification Authority 8.3.6. Securing the Certification Authority
As noted above, compromise of a Certification Authority (CA) trusted As noted above, compromise of a Certification Authority (CA) trusted
to issue certificates for the XMPP-Grid Controller and/or XMPP-Grid to issue certificates for the XMPP-Grid Controller and/or XMPP-Grid
Platforms is a major security breach. Many guidelines for proper CA Platforms is a major security breach. Many guidelines for proper CA
security have been developed: the CA/Browser Forum's Baseline security have been developed: the CA/Browser Forum's Baseline
Requirements, the AICPA/CICA Trust Service Principles, the IETF's Requirements, the AICPA/CICA Trust Service Principles, the IETF's
Certificate Transparency [RFC6962] etc. The CA operator and relying Certificate Transparency [RFC6962] etc. The CA operator and relying
parties should agree on an appropriately rigorous security practices parties should agree on an appropriately rigorous security practices
skipping to change at page 20, line 23 skipping to change at page 21, line 42
a CA is being operated improperly or in a manner that is not in the 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 interests of the relying parties. For this reason, relying parties
may wish to "pin" a small number of particularly critical may wish to "pin" a small number of particularly critical
certificates (such as the certificate for the XMPP-Grid Controller). certificates (such as the certificate for the XMPP-Grid Controller).
Once a certificate has been pinned, the relying party will not accept Once a certificate has been pinned, the relying party will not accept
another certificate in its place unless the Administrator explicitly another certificate in its place unless the Administrator explicitly
commands it to do so. This does not mean that the relying party will commands it to do so. This does not mean that the relying party will
not check the revocation status of pinned certificates. However, the not check the revocation status of pinned certificates. However, the
Administrator can still be consulted if a pinned certificate is Administrator can still be consulted if a pinned certificate is
revoked, since the CA and revocation process are not completely revoked, since the CA and revocation process are not completely
trusted. trusted. By "pinning" one or a small set of certificates, the
relying party has the effective XMPP-Grid Controller(s) authorized to
connect to.
8.4. Summary 8.4. Summary
XMPP-Grid's considerable value as a broker for security-sensitive XMPP-Grid's considerable value as a broker for security-sensitive
data exchange distribution also makes the protocol and the network data exchange distribution also makes the protocol and the network
security elements that implement it a target for attack. Therefore, security elements that implement it a target for attack. Therefore,
strong security has been included as a basic design principle within strong security has been included as a basic design principle within
the XMPP-Grid design process. the XMPP-Grid design process.
The XMPP-Grid data transfer protocol provides strong protection The XMPP-Grid data transfer protocol provides strong protection
skipping to change at page 21, line 20 skipping to change at page 22, line 40
Care needs to be taken by deployers of XMPP-Grid to ensure that the Care needs to be taken by deployers of XMPP-Grid to ensure that the
information published by XMPP-Grid Platforms does not violate information published by XMPP-Grid Platforms does not violate
agreements with end users or local and regional laws and regulations. agreements with end users or local and regional laws and regulations.
This can be accomplished either by configuring XMPP-Grid Platforms to This can be accomplished either by configuring XMPP-Grid Platforms to
not publish certain information or by restricting access to sensitive not publish certain information or by restricting access to sensitive
data to trusted XMPP-Grid Platforms. That is, the easiest means to 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 ensure privacy or protect sensitive data, is to omit or not share it
at all. at all.
Similarly, care must be taken by deployers and XMPP-Grid Controller
implementations as they implement the appropriate auditing tools. In
particular, any information, such as logs must be sensitive to the
type of information stored to ensure that the information does not
violate privacy and agreements with end users or local and regional
laws and regulations.
Another consideration for deployers is to enable end-to-end Another consideration for deployers is to enable end-to-end
encryption to ensure the data is protected from the data layer to encryption to ensure the data is protected from the data layer to
data layer and thus protect it from the transport layer. data layer and thus protect it from the transport layer. The means
to achieve end-to-end encrpytion is beyond the scope of this
document.
10. Operations and Management Considerations 10. Operations and Management Considerations
In order to facilitate the management of Providers and the onboarding In order to facilitate the management of Providers and the onboarding
of Consumers, it is helpful to generate the following ahead of time: of Consumers, it is helpful to generate the following ahead of time:
o Agreement between the operators of Provider services and the o Agreement between the operators of Provider services and the
implementers of Consumer software regarding identifiers for common implementers of Consumer software regarding identifiers for common
Topics (e.g., these could be registered with the XMPP Software Topics (e.g., these could be registered with the XMPP Software
Foundation's registry of well-known nodes for service discovery Foundation's registry of well-known nodes for service discovery
skipping to change at page 22, line 11 skipping to change at page 23, line 41
and/or editing of the following people: Joseph Salowey, Lisa and/or editing of the following people: Joseph Salowey, Lisa
Lorenzin, Clifford Kahn, Henk Birkholz, Jessica Fitzgerald-McKay, Lorenzin, Clifford Kahn, Henk Birkholz, Jessica Fitzgerald-McKay,
Steve Hanna, and Steve Venema. In addition, we want to thank Takeshi Steve Hanna, and Steve Venema. In addition, we want to thank Takeshi
Takahashi, Panos Kampanakis, Adam Montville, Chris Inacio, and Dave Takahashi, Panos Kampanakis, Adam Montville, Chris Inacio, and Dave
Cridland for reviewing and providing valuable comments. Cridland for reviewing and providing valuable comments.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
<https://www.rfc-editor.org/info/rfc2026>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422, Authentication and Security Layer (SASL)", RFC 4422,
DOI 10.17487/RFC4422, June 2006, DOI 10.17487/RFC4422, June 2006,
<https://www.rfc-editor.org/info/rfc4422>. <https://www.rfc-editor.org/info/rfc4422>.
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
"Salted Challenge Response Authentication Mechanism
(SCRAM) SASL and GSS-API Mechanisms", RFC 5802,
DOI 10.17487/RFC5802, July 2010,
<https://www.rfc-editor.org/info/rfc5802>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
March 2011, <https://www.rfc-editor.org/info/rfc6120>. March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer [RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer
Security (TLS) in the Extensible Messaging and Presence Security (TLS) in the Extensible Messaging and Presence
Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June
2015, <https://www.rfc-editor.org/info/rfc7590>. 2015, <https://www.rfc-editor.org/info/rfc7590>.
[RFC7677] Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple [RFC7677] Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple
skipping to change at page 22, line 47 skipping to change at page 24, line 42
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[XEP-0004] [XEP-0004]
Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and
P. Saint-Andre, "Data Forms", XSF XEP 0004, August 2007. P. Saint-Andre, "Data Forms", XSF XEP 0004, August 2007.
[XEP-0030] [XEP-0030]
Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- Hildebrand, J., Millard, P., Eatmon, R., and P. Saint-
Andre, "Service Discovery", XSF XEP 0030, July 2010. Andre, "Service Discovery", XSF XEP 0030, July 2010.
[XEP-0059]
Paterson, I., Saint-Andre, P., Mercier, V., and J.
Seguineau, "Result Set Management", XSF XEP 0059,
September 2006.
[XEP-0060] [XEP-0060]
Millard, P., Saint-Andre, P., and R. Meijer, "Publish- Millard, P., Saint-Andre, P., and R. Meijer, "Publish-
Subscribe", XSF XEP 0060, December 2017. Subscribe", XSF XEP 0060, December 2017.
[XEP-0203]
Saint-Andre, P., "Delayed Delivery", XSF XEP 0203,
December 2009.
12.2. Informative References 12.2. Informative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997, RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>. <https://www.rfc-editor.org/info/rfc2131>.
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
"Salted Challenge Response Authentication Mechanism
(SCRAM) SASL and GSS-API Mechanisms", RFC 5802,
DOI 10.17487/RFC5802, July 2010,
<https://www.rfc-editor.org/info/rfc5802>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<https://www.rfc-editor.org/info/rfc6962>. <https://www.rfc-editor.org/info/rfc6962>.
[RFC7970] Danyliw, R., "The Incident Object Description Exchange [RFC7970] Danyliw, R., "The Incident Object Description Exchange
Format Version 2", RFC 7970, DOI 10.17487/RFC7970, Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
November 2016, <https://www.rfc-editor.org/info/rfc7970>. November 2016, <https://www.rfc-editor.org/info/rfc7970>.
[RFC8274] Kampanakis, P. and M. Suzuki, "Incident Object Description [RFC8274] Kampanakis, P. and M. Suzuki, "Incident Object Description
Exchange Format Usage Guidance", RFC 8274, Exchange Format Usage Guidance", RFC 8274,
 End of changes. 47 change blocks. 
121 lines changed or deleted 208 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/