Tech-invite   3GPPspecs   IETFRFCs   SIP   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   None  Group: MILE

RFC 8600

Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange

Pages: 28
Proposed STD
Part 1 of 2 – Pages 1 to 13
None   None   Next

Top   ToC   RFC8600 - Page 1
Internet Engineering Task Force (IETF)                N. Cam-Winget, Ed.
Request for Comments: 8600                                     S. Appala
Category: Standards Track                                        S. Pope
ISSN: 2070-1721                                            Cisco Systems
                                                          P. Saint-Andre
                                                                 Mozilla
                                                               June 2019


        Using Extensible Messaging and Presence Protocol (XMPP)
                   for Security Information Exchange

Abstract

   This document describes how to use the Extensible Messaging and
   Presence Protocol (XMPP) to collect and distribute security incident
   reports and other security-relevant information between network-
   connected devices, primarily for the purpose of communication among
   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

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8600.
Top   ToC   RFC8600 - Page 2
Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Workflow  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Service Discovery . . . . . . . . . . . . . . . . . . . . . .   8
   6.  Publish-Subscribe . . . . . . . . . . . . . . . . . . . . . .  10
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
     8.1.  Trust Model . . . . . . . . . . . . . . . . . . . . . . .  14
     8.2.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  16
     8.3.  Countermeasures . . . . . . . . . . . . . . . . . . . . .  20
     8.4.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .  23
   9.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  24
   10. Operations and Management Considerations  . . . . . . . . . .  25
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  25
     11.2.  Informative References . . . . . . . . . . . . . . . . .  27
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  27
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28
Top   ToC   RFC8600 - Page 3
1.  Introduction

   This document defines an architecture, i.e., "XMPP-Grid", as a method
   for using the Extensible Messaging and Presence Protocol (XMPP)
   [RFC6120] to collect and distribute security incident reports and
   other security-relevant information among network platforms,
   endpoints, and any other network-connected device, primarily for the
   purpose of communication among Computer Security Incident Response
   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
   structured data (XML, JSON, etc.), this document illustrates the
   principles of XMPP-Grid with examples that use the Incident Object
   Description Exchange Format (IODEF) [RFC7970].  That is, while other
   security information formats can be shared using XMPP, this document
   uses IODEF as one such example format that can be published and
   consumed using XMPP.

2.  Terminology

   This document uses XMPP terminology defined in [RFC6120] and
   [XEP-0060].  Because the intended audience for this document is those
   who implement and deploy security reporting systems, mappings are
   provided for the benefit of XMPP developers and operators.

   Broker:  A specific type of controller containing control-plane
      functions; as used here, the term refers to an XMPP publish-
      subscribe service.

   Broker Flow:  A method by which security incident reports and other
      security-relevant information are published and consumed in a
      mediated fashion through a Broker.  In this flow, the Broker
      handles authorization of Consumers and Providers to Topics,
      receives messages from Providers, and delivers published messages
      to Consumers.

   Consumer:  An entity that contains functions to receive information
      from other components; as used here, the term refers to an XMPP
      publish-subscribe Subscriber.
Top   ToC   RFC8600 - Page 4
   Controller:  A component containing control-plane functions that
      manage and facilitate information sharing or execute on security
      functions; as used here, the term refers to an XMPP server, which
      provides core message delivery [RFC6120] used by publish-subscribe
      entities.

   Node:  The XMPP term for a Topic.

   Platform:  Any entity that connects to the XMPP-Grid in order to
      publish or consume security-relevant information.

   Provider:  An entity that contains functions to provide information
      to other components; as used here, the term refers to an XMPP
      publish-subscribe Publisher.

   Topic:  A contextual information channel created on a Broker on which
      messages generated by a Provider are propagated in real time to
      one or more Consumers.  Each Topic is limited to a specific type
      and format of security data (e.g., IODEF namespace) and provides
      an XMPP interface by which the data can be obtained.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.
Top   ToC   RFC8600 - Page 5
3.  Architecture

   The following figure illustrates the architecture of XMPP-Grid.

             +--------------------------------------+
             | +--------------------------------------+
             | | +--------------------------------------+
             | | |                                      |
             +-| |             Platforms                |
               +-|                                      |
                 +--------------------------------------+
                   /   \         /   \            /   \
                  /  C  \       /     \          /     \
                  -  o  -       -  d  -          -     -
                   ||n||A        | a  |B          |   |C
                   ||t||         | t  |           |   |
                  -  r  -       -  a  -           |   |
                  \  o  /       \     /           |   |
                   \ l /         \   /            |   |
                /|---------------------|\         |   |
         /|----/                         \--------| d |--|\
        /     /        Controller         \ ctrl  | a |    \
        \     \        & Broker           / plane | t |    /
         \|----\                         /--------| a |--|/
                \|---------------------|/         |   |
                   /   \         /   \            |   |
                  /  C  \       /     \           |   |
                  -  o  -       -  d  -           |   |
                   ||n||A        | a |B           |   |C
                   ||t||         | t |            |   |
                  -  r  -       -  a  -          -     -
                  \  o  /       \     /          \     /
                   \ l /         \   /            \   /
                 +------------------------------------+
                 |                                    |-+
                 |            Platforms               | |
                 |                                    | |-+
                 +------------------------------------+ | |
                   +------------------------------------+ |
                     +------------------------------------+

                     Figure 1: XMPP-Grid Architecture

   Platforms connect to the Controller (XMPP server) to authenticate and
   then establish appropriate authorizations to be a Provider or
   Consumer of topics of interest at the Broker.  The control-plane
   messaging is established through XMPP and is shown as "A" (control-
   plane interface) in Figure 1.  Authorized Platforms can then share
Top   ToC   RFC8600 - Page 6
   data 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 on the Broker Flow for information sharing ("direct flow"
   interactions can be used for specialized purposes, such as bulk data
   transfer, but methods for doing so are outside the scope of this
   document).

4.  Workflow

   Implementations of XMPP-Grid adhere to the following workflow:

   a.  A Platform with a source of security data requests connection to
       the XMPP-Grid via a Controller.

   b.  The Controller authenticates the Platform.

   c.  The Platform establishes authorized privileges (e.g., privilege
       to publish and/or subscribe to one or more Topics) with a Broker.

   d.  The Platform can publish security incident reports and other
       security-relevant information to a Topic, subscribe to a Topic,
       query a Topic, or perform any combination of these operations.

   e.  A Provider unicasts its Topic updates to the Grid in real time
       through a Broker.  The Broker handles replication and
       distribution of the Topic to Consumers.  A Provider can publish
       the same or different data to multiple Topics.

   f.  Any Platform on the Grid can subscribe to any Topic published to
       the Grid (as permitted by the authorization policy) and (as
       Consumers) will then receive a continual, real-time stream of
       updates from the Topics to which it is subscribed.

   The general workflow is summarized in the figure below.
Top   ToC   RFC8600 - Page 7
   +--------------+        +------------+           +---------------+
   | IODEF Client |        | Controller |           | IODEF Service |
   |  (Consumer)  |        |  & Broker  |           |  (Provider)   |
   +--------------+        +------------+           +---------------+
           |                      |                         |
           |  Establish XMPP      |                         |
           |  Client Session      |                         |
           |  (RFC 6120)          |                         |
           |--------------------->|                         |
           |                      | Establish XMPP          |
           |                      | Client Session          |
           |                      | (RFC 6120)              |
           |                      |<------------------------|
           |                      | Request Topic Creation  |
           |                      | (XEP-0060)              |
           |                      |<------------------------|
           |                      | Topic Creation Success  |
           |                      | (XEP-0060)              |
           |                      |------------------------>|
           | Request Topic List   |                         |
           | (XEP-0030)           |                         |
           |--------------------->|                         |
           | Return Topic List    |                         |
           | (XEP-0030)           |                         |
           |<---------------------|                         |
           |                      |                         |
           | Query Each Topic     |                         |
           | (XEP-0030)           |                         |
           |--------------------->|                         |
           | Return Topic Data    |                         |
           | Including Topic Type |                         |
           | (XEP-0030)           |                         |
           |<---------------------|                         |
           |                      |                         |
           | Subscribe to IODEF   |                         |
           | Topic (XEP-0060)     |                         |
           |--------------------->|                         |
           | Subscription Success |                         |
           | (XEP-0060)           |                         |
           |<---------------------|                         |
           |                      | Publish IODEF Incident  |
           |                      | (XEP-0060)              |
           | Receive IODEF        |<------------------------|
           | Incident (XEP-0060)  |                         |
           |<---------------------|                         |
           |                      |                         |

                     Figure 2: IODEF Example Workflow
Top   ToC   RFC8600 - Page 8
   XMPP-Grid implementations MUST adhere to the mandatory-to-implement
   and mandatory-to-negotiate features as defined in [RFC6120].
   Similarly, implementations MUST implement the publish-subscribe
   extension [XEP-0060] to facilitate the asynchronous sharing of
   information.  Implementations SHOULD implement Service Discovery as
   defined in [XEP-0030] to facilitate the means to dynamically discover
   the available information and namespaces (Topics) to be published or
   consumed.  Care should be taken with implementations 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 a 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 a function is out of scope for
   this document.

   The following sections provide protocol examples for the service
   discovery and publish-subscribe parts of the workflow.

5.  Service Discovery

   Using the XMPP service discovery extension [XEP-0030], a Controller
   enables Platforms to discover what information can be consumed
   through the Broker and at which Topics.  Platforms could use
   [XEP-0059] to restrict the size of the result sets the Controller
   returns in a Service Discovery response.  As an example, the
   Controller at 'security-grid.example' might provide a Broker at
   'broker.security-grid.example', which hosts a number of Topics.  A
   Platform at 'xmpp-grid-client@mile-host.example' would query the
   Broker about its available Topics by sending an XMPP "disco#items"
   request to the Broker:

   <iq type='get'
       from='xmpp-grid-client@mile-host.example/2EBE702A97D6'
       to='broker.security-grid.example'
       id='B3C17F7B-B9EF-4ABA-B08D-805DA9F34626'>
     <query xmlns='http://jabber.org/protocol/disco#items'/>
   </iq>
Top   ToC   RFC8600 - Page 9
   The Broker responds with the Topics it hosts:

   <iq type='result'
       from='broker.security-grid.example'
       to='xmpp-grid-client@mile-host.example/2EBE702A97D6'
       id='B3C17F7B-B9EF-4ABA-B08D-805DA9F34626'>
     <query xmlns='http://jabber.org/protocol/disco#items'>
       <item node='NEA1'
             name='Endpoint Posture Information'
             jid='broker.security-grid.example'/>
       <item node='MILEHost'
             name='MILE Host Data'
             jid='broker.security-grid.example'/>
     </query>
   </iq>

   In order to determine the exact nature of each Topic (i.e., in order
   to find Topics that publish incidents in the IODEF format), a
   Platform would send an XMPP "disco#info" request to each Topic:

   <iq type='get'
       from='xmpp-grid-client@mile-host.example/2EBE702A97D6'
       to='broker.security-grid.example'
       id='D367D4ED-2795-489C-A83E-EAAFA07A0356'>
     <query xmlns='http://jabber.org/protocol/disco#info'
            node='MILEHost'/>
   </iq>
Top   ToC   RFC8600 - Page 10
   The Broker responds with the "disco#info" description, which MUST
   include an XMPP data form [XEP-0004] with a 'pubsub#type' field that
   specifies the supported namespace (in this example, the IODEF
   namespace defined in [RFC7970]):

  <iq type='result'
      from='broker.security-grid.example'
      to='xmpp-grid-client@mile-host.example/2EBE702A97D6'
      id='D367D4ED-2795-489C-A83E-EAAFA07A0356'>
    <query xmlns='http://jabber.org/protocol/disco#info'
         node='MILEHost'>
      <identity category='pubsub' type='leaf'/>
      <feature var='http://jabber.org/protocol/pubsub'/>
      <x xmlns='jabber:x:data' type='result'>
       <field var='FORM_TYPE' type='hidden'>
        <value>http://jabber.org/protocol/pubsub#meta-data</value>
       </field>
       <field var='pubsub#type' label='Payload type' type='text-single'>
        <value>urn:ietf:params:xml:ns:iodef-2.0</value>
       </field>
      </x>
    </query>
  </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

   Using the XMPP publish-subscribe extension [XEP-0060], a Consumer
   subscribes to a Topic, and a Provider publishes information to that
   Topic, which the Broker then distributes to all subscribed Consumers.

   First, a Provider would create a Topic as follows:

   <iq type='set'
       from='datasource@provider.example/F12C2EFC9BB0'
       to='broker.security-grid.example'
       id='A67507DF-2F22-4937-8D30-88D2F7DBA279'>
     <pubsub xmlns='http://jabber.org/protocol/pubsub'>
       <create node='MILEHost'/>
     </pubsub>
   </iq>

   Note: The foregoing example is the minimum protocol needed to create
   a Topic with the default node configuration on the XMPP publish-
   subscribe service specified in the 'to' address of the creation
Top   ToC   RFC8600 - Page 11
   request stanza.  Depending on security requirements, the Provider
   might need to request a non-default configuration for the node; see
   [XEP-0060] for detailed examples.  To also help with the Topic
   configuration, the Provider may also optionally include configuration
   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 so that the
   Broker will a) explicitly approve subscription requests, b)
   persistently store all messages posted to the Topic, and c) not
   deliver the most recently published when an entity initially
   subscribes to the Topic.  Please refer to [XEP-0060] for a more
   detailed description of this configuration and other available
   configuration options.

   Unless an error occurs (see [XEP-0060] for various error flows), the
   Broker responds with success:

   <iq type='result'
       from='broker.security-grid.example'
       to='datasource@provider.example/F12C2EFC9BB0'
       id='A67507DF-2F22-4937-8D30-88D2F7DBA279'/>

   Second, a Consumer would subscribe as follows:

   <iq type='set'
       from='xmpp-grid-client@mile-host.example/2EBE702A97D6'
       to='broker.security-grid.example'
       id='9C6EEE9E-F09A-4418-8D68-3BA6AF852522'>
     <pubsub xmlns='http://jabber.org/protocol/pubsub'>
       <subscribe node='MILEHost'
                  jid='xmpp-grid-client@mile-host.example'/>
     </pubsub>
   </iq>
Top   ToC   RFC8600 - Page 12
   Unless an error occurs (see [XEP-0060] for various error flows), the
   Broker makes an appropriate authorization decision.  If access is
   granted, it responds with success:

   <iq type='result'
       from='broker.security-grid.example'
       to='xmpp-grid-client@mile-host.example/2EBE702A97D6'
       id='9C6EEE9E-F09A-4418-8D68-3BA6AF852522'>
     <pubsub xmlns='http://jabber.org/protocol/pubsub'>
       <subscription
           node='MILEHost'
           jid='xmpp-grid-client@mile-host.example'
           subscription='subscribed'/>
     </pubsub>
   </iq>

   Third, a Provider would publish an incident to the Broker using the
   MILEHost Topic as follows:

  <iq type='set'
      from='datasource@provider.example/F12C2EFC9BB0'
      to='broker.security-grid.example'
      id='2A17D283-0DAE-4A6C-85A9-C10B1B40928C'>
    <pubsub xmlns='http://jabber.org/protocol/pubsub'>
      <publish node='MILEHost'>
        <item id='8bh1g27skbga47fh9wk7'>
          <IODEF-Document version="2.00" xml:lang="en"
            xmlns="urn:ietf:params:xml:ns:iodef-2.0"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation=
              "http://www.iana.org/assignments/xml-registry/
               schema/iodef-2.0.xsd">
            <Incident purpose="reporting" restriction="private">
              <IncidentID name="csirt.example.com">492382</IncidentID>
              <GenerationTime>2015-07-18T09:00:00-05:00</GenerationTime>
              <Contact type="organization" role="creator">
                <Email>
                  <EmailTo>contact@csirt.example.com</EmailTo>
                </Email>
              </Contact>
            </Incident>
          </IODEF-Document>
        </item>
      </publish>
    </pubsub>
  </iq>
Top   ToC   RFC8600 - Page 13
   (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 subscribed to the Topic:

  <message
      from='broker.security-grid.example'
      to='xmpp-grid-client@mile-host.example/2EBE702A97D6'
      id='37B3921D-4F7F-450F-A589-56119A88BC2E'>
    <event xmlns='http://jabber.org/protocol/pubsub#event'>
      <items node='MILEHost'>
        <item id='iah37s61s964gquqy47aksbx9453ks77'>
          <IODEF-Document version="2.00" xml:lang="en"
            xmlns="urn:ietf:params:xml:ns:iodef-2.0"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation=
              "http://www.iana.org/assignments/xml-registry/
               schema/iodef-2.0.xsd">
            <Incident purpose="reporting" restriction="private">
              <IncidentID name="csirt.example.com">492382</IncidentID>
              <GenerationTime>2015-07-18T09:00:00-05:00</GenerationTime>
              <Contact type="organization" role="creator">
                <Email>
                  <EmailTo>contact@csirt.example.com</EmailTo>
                </Email>
              </Contact>
            </Incident>
          </IODEF-Document>
        </item>
      </items>
    </event>
  </message>

   Note that [XEP-0060] uses the XMPP "<message />" stanza for delivery
   of content.  To ensure that messages are delivered to the Consumer
   even if the Consumer is not online at the same time that the
   Publisher generates the message, an XMPP-Grid Controller MUST support
   "offline messaging" delivery semantics as specified in [RFC6121], the
   best practices of which are further explained in [XEP-0160].

7.  IANA Considerations

   This document has no actions for IANA.


Next Section