[Docs] [txt|pdf|xml] [Tracker] [Email] [Nits]

Versions: 00 01 02

SACM                                                     J. Salowey, Ed.
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                             L. Lorenzin
Expires: January 3, 2015                                         C. Kahn
                                                  Juniper Networks, Inc.
                                                                 S. Pope
                                                               S. Appala
                                                               A. Woland
                                                           N. Cam-Winget
                                                           Cisco Systems
                                                            July 2, 2014


     XMPP Protocol Extensions for Use in SACM Information Transport
                    draft-salowey-sacm-xmpp-grid-00

Abstract

   This document defines a transport protocol for use with the Security
   Automation and Continuous Monitoring (SACM) Architecture.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 3, 2015.

Copyright Notice

   Copyright (c) 2014 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
   (http://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



Salowey, et al.          Expires January 3, 2015                [Page 1]


Internet-Draft                  XMPP Grid                      July 2014


   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
     1.1.  What is XMPP-Grid?  . . . . . . . . . . . . . . . . . . .   3
     1.2.  Overview of XMPP-Grid . . . . . . . . . . . . . . . . . .   4
     1.3.  Benefits of XMPP-Grid . . . . . . . . . . . . . . . . . .   7
     1.4.  Example Workflow  . . . . . . . . . . . . . . . . . . . .   8
   2.  Applicability of XMPP-Grid to SACM Use Cases  . . . . . . . .   9
     2.1.  Applicability of XMPP-Grid to SACM Usage Scenarios  . . .  10
       2.1.1.  SACM Definition and Publication of Automatable
               Configuration Checklists  . . . . . . . . . . . . . .  10
       2.1.2.  SACM Automated Checklist Verification . . . . . . . .  10
       2.1.3.  SACM Detection of Posture Deviations  . . . . . . . .  11
       2.1.4.  SACM Endpoint Information Analysis and Reporting  . .  11
       2.1.5.  SACM Asynchronous Compliance/Vulnerability Assessment
               at Ice Station Zebra  . . . . . . . . . . . . . . . .  12
       2.1.6.  SACM Identification and Retrieval of Guidance . . . .  12
       2.1.7.  SACM Guidance Change Detection  . . . . . . . . . . .  12
   3.  XMPP-Grid Architecture  . . . . . . . . . . . . . . . . . . .  13
     3.1.  XMPP Overview . . . . . . . . . . . . . . . . . . . . . .  13
     3.2.  XMPP-Grid Protocol Extensions to XMPP . . . . . . . . . .  15
     3.3.  XMPP-Grid Controller Protocol Flow  . . . . . . . . . . .  15
     3.4.  XMPP-Grid Node Connection Protocol Flow . . . . . . . . .  17
       3.4.1.  Authentication  . . . . . . . . . . . . . . . . . . .  18
       3.4.2.  Registration  . . . . . . . . . . . . . . . . . . . .  18
       3.4.3.  Authorization . . . . . . . . . . . . . . . . . . . .  20
     3.5.  XMPP-Grid Topics Protocol Flow  . . . . . . . . . . . . .  23
       3.5.1.  Topic Versioning  . . . . . . . . . . . . . . . . . .  24
       3.5.2.  Topic Discovery . . . . . . . . . . . . . . . . . . .  24
       3.5.3.  Subtopics and Message Filters . . . . . . . . . . . .  24
     3.6.  XMPP-Grid Protocol Details  . . . . . . . . . . . . . . .  27
   4.  XMPP-Grid Compatibility with IF-MAP Information Model . . . .  33
     4.1.  MAP Server as XMPP-Grid Subscriber for Metadata
           Aggregation . . . . . . . . . . . . . . . . . . . . . . .  35
     4.2.  MAP Server as XMPP-Grid Publisher for Metadata
           Dissemination . . . . . . . . . . . . . . . . . . . . . .  37
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  37
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  37
     6.1.  Trust Model . . . . . . . . . . . . . . . . . . . . . . .  38
       6.1.1.  Network . . . . . . . . . . . . . . . . . . . . . . .  38
       6.1.2.  XMPP-Grid Nodes . . . . . . . . . . . . . . . . . . .  38
       6.1.3.  XMPP-Grid Controller  . . . . . . . . . . . . . . . .  38
       6.1.4.  Certification Authority . . . . . . . . . . . . . . .  39



Salowey, et al.          Expires January 3, 2015                [Page 2]


Internet-Draft                  XMPP Grid                      July 2014


     6.2.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  39
       6.2.1.  Network Attacks . . . . . . . . . . . . . . . . . . .  39
       6.2.2.  XMPP-Grid Nodes . . . . . . . . . . . . . . . . . . .  40
       6.2.3.   XMPP-Grid Controllers  . . . . . . . . . . . . . . .  41
       6.2.4.  Certification Authority . . . . . . . . . . . . . . .  42
     6.3.  Countermeasures . . . . . . . . . . . . . . . . . . . . .  43
       6.3.1.  Securing the XMPP-Grid Transport Protocol . . . . . .  43
       6.3.2.  Securing XMPP-Grid Nodes  . . . . . . . . . . . . . .  44
       6.3.3.  Securing XMPP-Grid Controllers  . . . . . . . . . . .  45
       6.3.4.  Limit on search result size . . . . . . . . . . . . .  45
       6.3.5.  Cryptographically random session-id and
               authentication checks for ARC . . . . . . . . . . . .  46
       6.3.6.  Securing the Certification Authority  . . . . . . . .  46
     6.4.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .  46
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  47
   8.  Evolution of XMPP-Grid  . . . . . . . . . . . . . . . . . . .  47
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  48
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  48
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  48
     10.2.  Informative References . . . . . . . . . . . . . . . . .  49
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  49

1.  Introduction

   This document describes the extensions made to Extensible Messaging
   and Presence Protocol (XMPP) [RFC6120]that enables use of XMPP as a
   transport protocol for collecting and distributing security telemetry
   information between and among network platforms, endpoints, and most
   any network connected device.  Proposed use of this transport
   protocol is for serving use-cases outlined by the Security Automation
   and Continuous Monitoring (SACM) working group with the IETF.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   Many of the terms used in this document are defined in
   [I-D.ietf-sacm-terminology].

   This document is being discussed on the sacm@ietf.org mailing list.

1.1.  What is XMPP-Grid?

   XMPP-Grid is a set of standards-based XMPP messages with extensions.
   It is intended for use as a transport and communications protocol
   framework for devices that interconnect with each other, forming an
   information grid for serving SACM use-cases.




Salowey, et al.          Expires January 3, 2015                [Page 3]


Internet-Draft                  XMPP Grid                      July 2014


   XMPP-Grid enables secure, bi-directional multi-vendor exchange of
   contextual information between IT infrastructure platforms such as
   security monitoring and detection systems, network policy platforms,
   asset and configuration management, identity and access management
   platforms.  XMPP-Grid can serve to exchange any contextual security
   information, the relevance and scope for SACM is to use XMPP-Grid to
   exchange Posture Assessment Information; thus this draft shall use
   the terms interchangeably.  XMPP-Grid is built on top of XMPP
   [RFC6120], [RFC6121] which is an open IETF standard messaging routing
   protocol used in commercial platforms such as Google Voice, Jabber
   IM, Microsoft Messenger, AOL IM and a variety of IoT and XML message
   routing services.  XMPP is also being considered as a means to
   transport IODEF [RFC5070].  XMPP-Grid is designed for orchestration
   of data sharing between security platforms on a many-to-many basis
   for millions of end systems.

   XMPP-Grid provides a security data sharing framework that enables
   multiple vendors to integrate to XMPP-Grid once, then both share and
   consume data bi-directionally with many IT infrastructure platforms
   and applications from a single consistent framework akin to a
   network-wide information bus.  This reduces the need to develop to
   explicit, multiple platform-specific interfaces, thereby increasing
   the breadth of platforms that can interface and share security data.
   XMPP-Grid is also configurable thereby enabling partners to share
   only security data they want to share and consume only information
   relevant to their platform or use-case and to customize information
   shared without revising the interfaces.  XMPP-Grid is data-agnostic
   enabling it to operate with virtually any data type or information
   model, but does offer optional interoperability with the Interface
   for Metadata Access Points (IF-MAP) [IF-MAP] or with IODEF, which are
   commonly used information repositories for security data sharing.

1.2.  Overview of XMPP-Grid

   XMPP-Grid employs publish/subscribe/query operations brokered by a
   controller, which enforces access control in the system.  This
   architecture controls what platforms can connect to the "grid" to
   share ("publish") and/or consume ("subscribe" or "query") contextual
   information ("Topics") (described in Section 3.3 and 3.5) such as
   security data needed to support SACM use-cases.  The control of
   publish/subscribe/query operations is architecturally distinct from
   the actual sharing of the contextual information.  Control functions
   are split into a logical control plane, whereas information exchange
   is considered a logical data plane.  This separation enables
   scalability and customizability.

   XMPP-Grid defines an infrastructure protocol that hides the nuances
   of the XMPP data plane protocol and makes the information sharing



Salowey, et al.          Expires January 3, 2015                [Page 4]


Internet-Draft                  XMPP Grid                      July 2014


   models extensible with simple intuitive interfaces.  XMPP-Grid Nodes
   connect to the Grid using the XMPP-Grid Protocol.  The XMPP-Grid
   Protocol makes use of the XMPP transport protocol and introduces an
   application layer protocol leveraging XML and XMPP extensions to
   define the protocol.

   The components of XMPP-Grid are:

   o  XMPP-Grid Controller (Controller): The Controller manages the
      control plane of XMPP-Grid operations.  As such it authenticates
      and authorizes platforms connecting to the data exchange grid and
      controls whether or not they can publish, subscribe or query
      Topics of security data.

   o  XMPP-Grid Connection Agent (Connection Agent): The Connection
      Agent enables the adopting Node to communicate with the Controller
      and other vendor platforms that have adopted XMPP-Grid.  Through
      this communication privileges of the connecting platform--
      authorization to connect, publish, subscribe, query--are
      established.  The Connection Agent is typically implemented as a
      client library.

   o  XMPP-Grid Node (Node): A Node is a platform that has implemented
      the Connection Agent so that it can connect to an XMPP-Grid
      deployment to share and/or consume security data.

   o  Data Repository: This is the source of security data available on
      the Grid and may be a network security platform, management
      console, endpoint, etc.  XMPP-Grid does not mandate a specific
      information model, but instead remains open to transport
      structured or unstructured data.  Data may be supplied by the
      security platform itself or by an external information repository.

   o  Topic: An XMPP-Grid Topic defines a type of security data that a
      platform wants to share with other platform(s).

   The operations carried out by XMPP-Grid to exchange security data
   are:

   o  Grid Connect: This is a Controller operation that authenticates a
      Node that has implemented the Connection Agent to establish a
      connection with the XMPP-Grid.  Once authenticated, authorization
      policies on the Controller establish a Node's privileges on the
      XMPP-Grid such as the right to undertake publish, subscribe or
      query operations explained below.

   o  Publish Topic: Security information is made available when a XMPP-
      Grid enabled platform "publishes" a "Topic".  This operation is



Salowey, et al.          Expires January 3, 2015                [Page 5]


Internet-Draft                  XMPP Grid                      July 2014


      authorized by the Controller and communicated to the connecting
      platform via the Connection Agent.

   o  Topic Discovery: Nodes on a XMPP-Grid discover Topics of security
      data relevant to them by searching the Topic directory available
      within the XMPP-Grid deployment.  The Controller maintains such a
      Topic directory for every instance of XMPP-Grid.

   o  Subscribe to Topic: A Node seeking to consume security information
      "subscribes" to a Topic that provides the security information it
      seeks to serve its use-case.  This operation has its authorization
      checked by the Controller and communicated with the connecting
      platform via the Connection Agent.

   o  Query: This operation enables a Node to request a specific set of
      security data regarding a specific asset (such as a specific user
      endpoint) or bulk output history from a Topic over a specific span
      of time.  Such queries can be carried out node-to-node or by
      querying a central data repository.  Query structure is adaptable
      to match the information model in use.

   XMPP-Grid is used to exchange security context data between systems
   on a 1-to-1, 1-to-many, or many-to-many basis.  Security data shared
   between these systems may use pre-negotiated non-standard/native data
   formats or may utilize an optional common information repository with
   a standardized data format, as may be specified by SACM.  XMPP-Grid
   is data format agnostic and accommodates transport of whatever format
   the end systems agree upon.

   XMPP-Grid can operate in the following deployment architectures:

   o  Broker-Flow: An XMPP-Grid control plane brokers the authorization
      and redirects the Topic subscriber to Topic publisher directly.
      In this architecture, the Controller only manages the connection;
      the security data flow is directly between Nodes using data
      formats negotiated out-of-band.

   o  Centralized Data-Flow: An XMPP-Grid maintains the data within its
      optional centralized database.  In this architecture, the
      Controller provides a common information structure for use in
      formatting and storing security context data, such as IF-MAP, and
      directly responds to Node publish and Subscribe requests.

   o  Proxy-Flow: An XMPP-Grid is acting as proxy, collecting the data
      from the publisher(s) and presenting it to the subscriber
      directly.  This is used for ad-hoc queries.





Salowey, et al.          Expires January 3, 2015                [Page 6]


Internet-Draft                  XMPP Grid                      July 2014


   Within the deployment architecture, XMPP-Grid may be used in any
   combination of the following data exchange modes.  The flexibility
   afforded by the different modes enables security information to be
   exchanged between systems in the method most suitable for serving a
   given use-case.

   o  Continuous Topic update stream: This mode delivers in real-time
      any data published to a Topic to the Nodes that are subscribed to
      that Topic.

   o  Directed query: This mode enables Nodes to request a specific set
      of security information regarding a specific asset, such as a
      specific user endpoint.

   o  Bulk historic data query: This mode enables Nodes to request
      transfer of past output from a Topic over a specific span of time.

1.3.  Benefits of XMPP-Grid

   Benefits of XMPP-Grid can be summarized on two fronts: 1) end-user
   benefits, 2) benefits for adopting vendors.

   Benefits for end-users deploying security services based on XMPP-Grid
   security context information sharing capabilities are derived from
   the results that come with standardization including:

   o  Consolidating relevant security event data from multiple systems
      to the "right console at the right time".

   o  Cross-vendor interoperability out-of-the-box, when using a
      standard data format.

   o  Coordinated security response across multiple products from
      multiple vendors, ranging from endpoint security to AAA, NAC, IDS/
      IPS, Data Loss Prevention, firewalls to infrastructure such as
      SIEM, CMDB, physical access control systems.

   o  Customer product choice and flexibility.  No need to buy all
      security products from one vendor.

   Adopting XMPP-Grid security data sharing capabilities provides a
   number of benefits for adopting vendors, especially when compared to
   proprietary interfaces, such as:

   o  Integrate the XMPP-Grid Connection Agent once to interface with
      many platforms, simultaneously by subscribing or publishing
      relevant security data




Salowey, et al.          Expires January 3, 2015                [Page 7]


Internet-Draft                  XMPP Grid                      July 2014


   o  Security information shared is configurable (via Topics) based on
      relevance to specific use-cases and platforms

   o  Only sharing relevant data enables both publishing and subscribing
      platforms to scale their security data sharing by eliminating
      excess, irrelevant data

   o  Integrated authorization and security ensures only appropriate
      XMPP-Grid operations are executed by permitted platforms

   o  Ability to share security data in native or structured formats
      enables data model flexibility for adopting vendors

   o  Flexibility, adaptability to evolve to address new use cases over
      time.  Utilize data-agnostic transport protocol or the extensible
      schema that allows for easy support for vendor-specific data.

1.4.  Example Workflow

                            ______________
                            | XMPP-Grid  |
                 Authorize /| Controller |\Authorize
                          / |____________| \
                    ________/      ^        \_________
"I have location"  |Location|      |        |  APP   |"I have app info"
"I need app & ID.."|________|\     |       /|________|"I need loc & dev"
                              \    |      /
                              _\___|_____/_____
                               |Continuous Flow|
                         <-----|---------------|------>
                               | Directed Query|
                               --/------|-----\-
                                /       |      \
                               /        |       \
                    __________/         |        \__________
 "I have sec events"|  SIEM  |          V         |  PAP   |"I have ID & dev"
   "I need ID & dev"|________|   ______________   |________|"I need loc & MDM"
                                 | Device Mgr |
                                 |____________|
                               "I have MDM Info!"
                              "I need location..."


   Figure 1: Typical XMPP-Grid Workflow

   a.  XMPP-Grid Controller establishes a grid for platforms wanting to
       exchange security data.




Salowey, et al.          Expires January 3, 2015                [Page 8]


Internet-Draft                  XMPP Grid                      July 2014


   b.  A platform (Node) with a source of security data requests
       connection to the Grid.

   c.  Controller authenticates and establishes authorized privileges
       (e.g. privilege to publish and/or subscribe to security data
       Topics) for the requesting Node.

   d.  Node may either publish a security data Topic, subscribe to a
       security data Topic, query a Node or Topic, or any combination of
       these operations.

   e.  Publishing Nodes unicast Topic updates to the Grid in real-time.
       The Grid handles replication and distribution of the Topic to
       subscribing Nodes.  A Node may publish multiple Topics, thereby
       allowing for customized relevance of the security data shared.

   f.  Subscribing Nodes receive continuous real-time stream of updates
       to the Topic to which they are subscribed.

   g.  Any Node on the Grid may subscribe to any Topics published to the
       Grid (as permitted by authorization policy), thereby allowing for
       one-to-one, one-to-many and many-to-many meshed security data
       sharing between Nodes.

2.  Applicability of XMPP-Grid to SACM Use Cases

   This section discusses the applicability of XMPP-Grid to the usage
   scenarios defined in [I-D.ietf-sacm-use-cases].

   Within the SACM use-cases, the working group has outlined four use-
   cases and seven usage-scenarios.  XMPP-Grid is applicable to each one
   of the use-cases and usage-scenarios by following one of the three
   main logical flows of XMPP-Grid as outlined in section 1.1.1.  The
   three flows are summarized here:

   o  Broker-Flow: XMPP-Grid brokers the authorization and redirects the
      Topic subscriber to Topic publisher directly.

   o  Centralized Data-Flow: XMPP-Grid is maintaining the data within
      its optional centralized database.

   o  Proxy-Flow: XMPP-Grid is acting as proxy, collecting the data from
      the publisher(s) and presenting it to the subscriber directly.
      This is used for ad-hoc queries.

   Each of the seven defined usage-scenarios is listed below, along with
   a summary of how XMPP-Grid is applicable to each use-case.




Salowey, et al.          Expires January 3, 2015                [Page 9]


Internet-Draft                  XMPP Grid                      July 2014


   It is important to note that XMPP-Grid is data model agnostic, and
   may use any information model to structure data between systems.  The
   most common standardized security information model deployed
   currently is IF-MAP, which XMPP-Grid interoperates with today.

2.1.  Applicability of XMPP-Grid to SACM Usage Scenarios

2.1.1.  SACM Definition and Publication of Automatable Configuration
        Checklists

   XMPP-Grid is fully applicable to the usage-scenario 2.2.1 as defined
   within the SACM use-cases document.  As a vendor creates a new guide,
   they would publish an entry describing the existence of the checklist
   to the applicable Topic within XMPP-Grid.  For the purposes of this
   explanation, the Topic name will be "Guide".

   Grid Nodes who are subscribed to the Topic, will receive the
   notification of the Topic update.  In response or on-demand, the Node
   will query XMPP-Grid in order to initiate the downloading of the new
   guide(s).  The Grid Controller authorizes the download and proceeds
   to retrieve the guide(s) from the publisher, and transfers that
   download to the subscriber.

   Similarly, when an administrator publishes a new checklist, they
   would publish an entry describing the existence of the checklist to
   the applicable Topic within XMPP-Grid.  For the purposes of this
   explanation, the Topic name will be "Checklist".

   Grid Nodes who are subscribed to the Topic, will receive the
   notification of the Topic update.  In response or on-demand, the
   participating entity will query XMPP-Grid in order to initiate the
   downloading of the new checklist(s).  The Grid Controller authorizes
   the download and proceeds to retrieve the checklist(s) from the
   publisher, and transfers that download to the subscriber.  This is an
   example of XMPP-Grid in Proxy-Flow mode.

2.1.2.  SACM Automated Checklist Verification

   An Endpoint Management System (EMS) publishes a Topic to XMPP-Grid
   defining itself as an owner of Endpoint Data.  Other network services
   that are interested in endpoint data may subscribe to the Topic on
   Endpoint Data, which is authorized by the XMPP-Grid.

   A Baseline Service is subscribed to the Endpoint Data Topic, and has
   a need for that updated endpoint data.  The Baseline Service
   (subscriber) requests the data from the XMPP-Grid, which authorizes
   the retrieval and informs the subscriber of the existence of data on




Salowey, et al.          Expires January 3, 2015               [Page 10]


Internet-Draft                  XMPP Grid                      July 2014


   the EMS directly.  In this instance, the data transfer has been
   authorized and occurs directly between the subscriber and the EMS.

   The subscriber has now created new checklists and published the
   information to the checklist Topic in XMPP-Grid.  A PDP is subscribed
   to the Checklist Topic, and is notified of the new checklists.  The
   PDP requests the data from the XMPP-Grid, which in-turn authorizes
   the download and brokers the direct communication between the
   Baseline Service and the PDP Directly.

   This usage scenario is an example of XMPP-Grid in the Broker-Flow.
   It is also showing that single entities may act as both publisher and
   subscriber with the XMPP-Grid simultaneously.

2.1.3.  SACM Detection of Posture Deviations

   A user disables the firewall on a managed endpoint, which in-turn
   sends a notice to its managing Compliance Service.  The Compliance
   Service publishes and alert to the "Alert Topic" in XMPP-Grid.  There
   is an Assessment Service, which subscribes to the Alert Topic, and is
   therefore notified of the alert.  The Assessment service consumes
   that alert directly from the XMPP-Grid and triggers an immediate
   assessment of the endpoint.

   This is an example of XMPP-Grid centralized-data flow.  While XMPP-
   Grid is information model agnostic, in this scenario IF-MAP could be
   used as the centralized data repository with XMPP-Grid providing the
   transport in/out of the IF-MAP database..

2.1.4.  SACM Endpoint Information Analysis and Reporting

   There are endpoints that are uploading large quantities of data to a
   Suspicious Server on Internet.  The admin queries XMPP-Grid for the
   posture of the endpoints.  The XMPP-Grid responds with all the
   publishers of that information along with the authorization to query
   for the data.  The admin application is now able to query the data
   sources directly, which indicates that the applicable endpoints all
   have certain applications installed.  The admin is now able to pivot
   the query and receive information on all other endpoints that have
   the same application installed.

   This usage scenario is an example of XMPP-Grid Broker-Flow.









Salowey, et al.          Expires January 3, 2015               [Page 11]


Internet-Draft                  XMPP Grid                      July 2014


2.1.5.  SACM Asynchronous Compliance/Vulnerability Assessment at Ice
        Station Zebra

   A University Team at Ice Station Zebra registers their Equipment with
   an Asset Management System.  The university puts together a
   collection request for all deployed assets, and sends the query to
   the XMPP-Grid.  The collection request is queued at the XMPP-Grid for
   the next window of connectivity when the request is sent to the
   deployed assets.  The remote endpoints fulfill the request and queue
   the results for the next return opportunity.  The results are sent
   back to the university, where they are compared against what is in
   the Asset Management System already.

   This is an example of XMPP-Grid centralized-data flow.  While XMPP-
   Grid is information model agnostic, in this scenario IF-MAP could be
   used as the centralized data repository with XMPP-Grid providing the
   transport in/out of the IF-MAP database.

2.1.6.  SACM Identification and Retrieval of Guidance

   There are multiple configuration services in the environment, each
   populating a "guide" Topic in XMPP-Grid.  The operator queries XMPP-
   Grid in order to discover and consolidate a single list to be
   compared.  The XMPP-Grid replies with list of data stores, and
   authorization to perform the queries directly to those data stores.

   As the Admin/Operator defines search criteria, the operator is able
   to query the data stores directly for that content, only returning to
   the centralized XMPP-Grid when authorization is required.

   This usage scenario is an example of XMPP-Grid in the Broker-Flow

2.1.7.  SACM Guidance Change Detection

   An Operator identifies content that they desire to assess, and
   subscribes to that content Topic with XMPP-Grid.  When a change to
   that content occurs, the Operator is notified.  Additionally, the
   operator may be sent a query response.  Any Data Collection and
   evaluation Activities will also trigger an update to the operator
   (subscriber).

   This usage scenario is an example of XMPP-Grid centralized-data flow.
   While XMPP-Grid is information model agnostic, in this scenario IF-
   MAP could be used as the centralized data repository with XMPP-Grid
   providing the transport in/out of the IF-MAP database.






Salowey, et al.          Expires January 3, 2015               [Page 12]


Internet-Draft                  XMPP Grid                      July 2014


3.  XMPP-Grid Architecture

   XMPP-Grid is a communication fabric that facilitates secure sharing
   of information between network elements and networked applications
   connected to the fabric both in real time and on demand.

   XMPP-Grid uses XMPP servers that operate as a cluster with message
   routing between them, for data plane communication.  XMPP-Grid uses a
   control plane element, the XMPP-Grid Controller, that is an external
   component of XMPP for centralized policy-based control plane.


   ---------------         ---------------        ---------------
   |  XMPP-Grid  |         |  XMPP-Grid  |        |  XMPP-Grid  |
   |  Controler  |         |  Controler  |        |  Controler  |
   |             |         |             |        |             |
   ---------------         ---------------        ---------------
         |                        |                      |
         |                        |                      |
   ---------------         ---------------        ---------------
   | XMPP Server |         | XMPP Server |        | XMPP Server |
   |             |---------|             |--------|             |
   |             |         |             |        |             |
   ---------------         ---------------        ---------------


   Figure 2: XMPP Server and XMPP-Grid Cluster Architecture

   The connected Nodes, with appropriate authorization privileges, can:

   o  Receive real-time events of the published messages from the
      publisher through Topic subscriptions

   o  Make directed queries to other Nodes in the XMPP-Grid with
      appropriate authorization from the Controller

   o  Negotiate out-of-band secure file transfer channel with the peer

   This model enables flexible API usage depending on the Nodes'
   contextual and time-sensitivity needs of security information.

3.1.  XMPP Overview

   XMPP is used as the foundation message routing protocol for
   exchanging security data between systems across XMPP-Grid.  XMPP is a
   communications protocol for message-oriented middleware based on XML.
   Designed to be extensible, the protocol uses de-centralized client-
   server architecture where the clients connect to the servers securely



Salowey, et al.          Expires January 3, 2015               [Page 13]


Internet-Draft                  XMPP Grid                      July 2014


   and the messages between the clients are routed through the XMPP
   servers deployed within the cluster.  XMPP has been used extensively
   for publish-subscribe systems, file transfer, video, VoIP, Internet
   of Things, Smart Grid Software Defined Networks (SDN) and other
   collaboration and social networking applications.  The following are
   the 4 IETF specifications produced by XMPP working group:

   o  [RFC6120] Extensible Messaging and Presence Protocol (XMPP): Core

   o  [RFC6121] Extensible Messaging and Presence Protocol (XMPP):
      Instant Messaging and Presence

   o  [RFC3922] Mapping the Extensible Messaging and Presence Protocol
      (XMPP) to Common Presence and Instant Messaging (CPIM)

   o  [RFC3923] End-to-End Signing and Object Encryption for the
      Extensible Messaging and Presence Protocol (XMPP)

   XMPP offers several of the following salient features for building a
   security data interexchange protocol:

   o  Open - standards-based, decentralized and federated architecture,
      with no single point of failure

   o  Security - Supports domain segregations and federation.  Offers
      strong security via Simple Authentication and Security Layer
      (SASL) and Transport Layer Security (TLS).

   o  Real-time event management/exchange - using publish, subscribe
      notifications

   o  Flexibility and Extensibility - XMPP is XML based and is easily
      extensible to adapt to new use-cases.  Custom functionality can be
      built on top of it.

   o  Multiple information exchanges - XMPP offers multiple information
      exchange mechanisms between the participating clients -

   o

      *  Real-time event notifications through publish and subscribe.

      *  On-demand or directed queries between the clients communicated
         through the XMPP server

      *  Facilitates out-of-band, direct communication between
         participating clients




Salowey, et al.          Expires January 3, 2015               [Page 14]


Internet-Draft                  XMPP Grid                      July 2014


   o  Bi-directional - avoids firewall tunneling and avoids opening up a
      new connection in each direction between client and server.

   o  Scalable - supports cluster mode deployment with fan-out and
      message routing

   o  Peer-to-peer communications also enables scale - directed queries
      and out-of-band file transfer support

   o  XMPP offers Node availability, Node service capability discovery,
      and Node presence within the XMPP network.  Nodes ability to
      detect the availability, presence and capabilities of other
      participating nodes eases turnkey deployment.

3.2.  XMPP-Grid Protocol Extensions to XMPP

   XMPP-Grid defines an infrastructure protocol that hides the nuances
   of the XMPP data plane protocol and makes the information sharing
   models extensible with simple intuitive APIs.  XMPP-Grid Nodes
   connect to the Grid using the XMPP-Grid Protocol.  The XMPP-Grid
   Protocol makes use of the XMPP transport protocol and introduces an
   application layer protocol leveraging XML and XMPP extensions to
   define the protocol.  The capability providers on the Grid extend the
   XMPP-Grid Protocol infrastructure model and define capability
   specific models and schemas, allowing a cleaner separation of
   infrastructure and capabilities that can run on the infrastructure.

3.3.  XMPP-Grid Controller Protocol Flow

   At the heart of the XMPP-Grid network, the XMPP-Grid Controller
   serves as the centralized policy-based control plane element managing
   all Node authentications, authorizations, capabilities/Topics and
   their subscription list.  XMPP-Grid Controller manages all control
   aspects of the Node communication (including management) with the
   XMPP-Grid and other participating Nodes with mutual trust and
   authorizations' enforcement.  XMPP-Grid Controller is a component of
   XMPP server and programs the data plane XMPP server with Node
   accounts, account status, XMPP Topics that are dynamically created
   and Topic subscriptions.  This is analogous to File Transfer Protocol
   (FTP) that has control and data plane communication phases.  Once the
   Node requests are authenticated and authorized in the control plane
   phase by the Controller, the Controller removes itself from the data
   flow.  All data plane communication then occurs between the Nodes,
   publishers and subscribers of XMPP Topics happen at the XMPP data
   plane layer.


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



Salowey, et al.          Expires January 3, 2015               [Page 15]


Internet-Draft                  XMPP Grid                      July 2014


      | Publi- | Node |     | Grid  | XMPP  |           | Node | Sub-   |
      | sher   |client|     | Ctrlr | Srvr  |           |client| scriber|
      |        |      |     |       |       |           |      |        |
      -----------------     -----------------           -----------------
        | Authen & allow Grid Ctrlr Comm |                           |
        |<------------------------------>|                           |
        |                     |          |                           |
        |                     |Publisher |                           |
        |                     |   Auth   |                           |
        |                     |  Status  |                           |
        |                     |<---------|                           |
        |                     |          |                           |
        |                     |          | Authen & allow Grid Ctrlr |
        |                     |          | Communication             |
        |                     |          |<------------------------->|
        |                     |          |                           |
        |                     |Subscriber|                           |
        |                     |   Auth   |                           |
        |                     | Status & |                           |
        |                     | Account  |                           |
        |                     |<---------|                           |
        |                     |          |                           |
        | Author Publisher to |          |                           |
        |  Topic Sequence     |          |                           |
---     |<------------------->|          |                           |
 C |    |                     |          |                           |
 O |    |                     | Add      |                           |
 N |    |                     |Publisher |                           |
 T |    |                     | to Topic |                           |
 R |    |                     |--------->|                           |
 O |    |                     |          |                           |
 L |    |                     | Author Subscriber to Topic Sequence  |
---     |                     |<------------------------------------>|
        |                     |          |                           |
        |                     | Add      |                           |
        |                     |Subscriber|                           |
        |                     | to Topic |                           |
        |                     |--------->|                           |
----------------------------------------------------------------------
       |                      |          |                           |
       |    Publish Message to Topic     |                           |
---    |-------------------------------->|                           |
   |   |                      |          |                           |
 I |   |   Publish Success           Published Message to Subscriber |
 N |   |<----------------------------------------------------------->|
 F |   |                      |          |                           |
 R |   |                      |          |     Subscribe Success     |
 A |   |                      |          |<--------------------------|



Salowey, et al.          Expires January 3, 2015               [Page 16]


Internet-Draft                  XMPP Grid                      July 2014


   |   |                      |          |                           |
---    |                      | Topic & Publisher Discovery Request  |
       |                      |<-------------------------------------|
       |                      |          |                           |
       |                      | Topic & Publisher JID Response       |
       |                      |------------------------------------->|
       |                      |          |                           |
       |                      | Out-of-Band Bulk Dnld Query Reqeust  |
       |                      |<-------------------------------------|
       |                      |          |                           |
       |                      | Out-of-Band Bulk Dnld Query Author   |
       |                      |------------------------------------->|
       |                                 |                           |
       | Out-of-Band Data Bulk Byte Stream                           |
       |<----------------------------------------------------------->|



   Figure 3: XMPP Controller Message Flow

   Through a centralized authorization model, XMPP-Grid Controller
   provides -

   o  Visibility into "who is connecting", "who is accessing what"

   o  Node account management with provisions to add, delete or disable
      accounts, and with provisions to auto or manual approve Node
      account approval requests during the Node registration phase

   o  Centralized, policy-based authorization, providing "who can do
      what" for publish-subscribe, directed peer-to-peer queries or for
      bulk out-of-band transfers between participating Nodes

   o  Topics and subscription list management with provision to enable
      or disable Topics

   o  Dynamic creation of sub-Topics within the main Topic depending on
      attributes of interest from the requesting Node

   o  Ability to perform message filters on the published messages

3.4.  XMPP-Grid Node Connection Protocol Flow

   Nodes connecting to XMPP-Grid go through the phases of
   authentication, registration and authorization before they can
   participate in information exchange on XMPP-Grid.





Salowey, et al.          Expires January 3, 2015               [Page 17]


Internet-Draft                  XMPP Grid                      July 2014


3.4.1.  Authentication

   The communication between the Node and the XMPP-Grid Controller is
   cryptographically encrypted using TLS.  XMPP-Grid uses X.509
   certificate-based mutual authentication between the Nodes and
   Controller.  Internally, XMPP uses Simple Authentication and Security
   Layer (SASL)[RFC4422] External mechanism to authenticate and
   establish secure tunnel with the Nodes, allowing the XMPP-Grid
   Controller to rely on this capability offered by XMPP.  If the Node
   certificate does not pass the validation process, the connection
   establishment is terminated with the error messages defined by the
   XMPP standard.  On successful authentication, XMPP SASL component
   extracts the Node certificate and Node username to the Controller for
   registration.

3.4.2.  Registration

   Once a Node has been authenticated and a secure tunnel has been
   successfully established, the Nodes will register their accounts with
   the Controller and Nodes provide their username to the Controller as
   part of the registration request.  XMPP-Grid supports manual
   registration (requires explicit approval of the Node account) and
   mutual authentication trust-based auto-approval registration in order
   to provide additional trust and usability options to the
   administrator.  The administrator may map the Nodes to the Node
   groups to add additional level of validation and trust, and enforce
   Node group based authorization.  This allows the certificate-
   username-group trust to get uniquely establishment for each Node and
   duplicate registration requests using the same username will be
   rejected.

   During the registration process, the Controller restricts all Node
   communication with the XMPP-Grid and only Node to Controller
   communication is allowed.  Once the Node is successfully registered,
   the Controller lifts the restriction and allows the Nodes to
   communicate on XMPP-Grid after it passes the authorization phase.  It
   should be noted that the registered and authorized Nodes could
   publish, subscribe or query to multiple XMPP Topics between login and
   logout to XMPP-Grid.  Multiple Node applications running on a Node
   could use one XMPP-Grid Node to connect to XMPP-Grid.  The XMPP-Grid
   Node should support Node applications' subscription to Topics and
   should multiplex messages on its connection to XMPP-Grid.  If a Node
   application wants to be identified explicitly on XMPP-Grid, a new
   XMPP-Grid Node connection to XMPP-Grid is required.







Salowey, et al.          Expires January 3, 2015               [Page 18]


Internet-Draft                  XMPP Grid                      July 2014


       -----------------                         ---------------------------
        |               |                         |  Grid     |   XMPP      |
        |    Node       |                         | Controller|  Server     |
        |               |                         |           |             |
        -----------------                         ---------------------------
                |                                       |                |
           _____|                                       |                |
          |     |                                       |                |
Register  |     |                                       |                |
          |---->|                                       |                |
                | TLS Connect(username, cert)           |                |
                |<------------------------------------------------------>|
                |                                       |                |
                |                                       | Track          |
                |                                       |(username,cert) |
                |                                       |<---------------|
                |Register(username)                     |                |
                |-------------------------------------->|                |
                |                                       |___             |
                |                                       |   | Approve &  |
                |                                       |   | Authorize  |
                |                                       |<--| Account    |
                |                                       |                |
                |                                       |Create User     |
                |                                       |Account         |
                |                                       |(username)      |
                |                                       |--------------->|
                |        Registration Successful        |                |
                |<--------------------------------------|                |
                |                                       |                |
                |  Login()                              |                |
                |-------------------------------------->|                |
                |                                       |                |
                |  Pub/Sub/Query                        |                |
                |<------------------------------------------------------>|
                |                                       |                |
                |                                       |                |
                |  Logout()                             |                |
                |-------------------------------------->|                |
                |                                       |                |


   Figure 4: XMPP-Grid Node Registration








Salowey, et al.          Expires January 3, 2015               [Page 19]


Internet-Draft                  XMPP Grid                      July 2014


3.4.3.  Authorization

   The registered Nodes send subscription requests to the Controller.
   The Controller, depending on the defined authorization privileges,
   grants permissions to subscribe and/or publish to a Topic at the
   registration time.  The Controller updates the XMPP data plane server
   with the new subscriber information and its capability.  Node
   identity extracted from the request, group to which the Node is
   assigned during account approval and Topic/capability to which the
   permission is sought could be some of the ways to authorize Nodes and
   their requests in XMPP-Grid.  Similarly, the Controller authorizes
   directed peer-to-peer or out-of-band requests from a requesting peer.
   The destination peer has options to query back the Controller to
   retrieve and enforce granular authorizations such as read-only,
   write-only, read/write.

   In a Query Authorization flow, the capability provider responding to
   the query is responsible for enforcing the authorization decision.
   It retrieves "is authorized" from the XMPP-Grid Controller.  Based on
   the result, the service either allows or disallows the flow from
   continuing.


      -----------------        -----------------         -----------------
     |  Subscriber     |      |    XMPP-Grid    |       |   Publisher     |
     |                 |      |                 |       |                 |
      -----------------        -----------------         -----------------
              |                        |                         |
              |                        |                         |
              |                  query request                   |
              |------------------------------------------------->|
              |                        |                         |____
              |                        |                         |    | extract
              |                        |                         |    | identity
              |                        |                         |<---
              |                        |                         |
              |                        |     is authorized?      |
              |                        |   (identity, service)   |
              |                        |<------------------------|
              |                        |                         |
              |                  query response                  |
              |<-------------------------------------------------|
              |                        |                         |



   Figure 5: Node Query Authorization Flow




Salowey, et al.          Expires January 3, 2015               [Page 20]


Internet-Draft                  XMPP Grid                      July 2014


   For Publish Authorization, prior to allowing a publish request by a
   user, the XMPP-Grid Controller calls the rule evaluation engine
   directly for "is authorized".  Based this result, the Controller
   either allows or disallowed the flow from continuing.

      -----------------        -----------------         -----------------
     |   Publisher     |      |    XMPP-Grid    |       |      XMPP       |
     |                 |      |    Controller   |       |     Server      |
      -----------------        -----------------         -----------------
              |                        |                         |
              |       publish          |                         |
              |----------------------->|____                     |
              |                        |   |  extract            |
              |                        |   |  identity           |
              |                        |<---                     |
              |                        |                         |
              |                        |____                     |
              |                        |   |   is authorized?    |
              |                        |   | (identity,publish)  |
              |                        |<---                     |
              |                        |                         |
              |                        |        publish          |
              |                        |------------------------>|
              |                        |                         |




   Figure 6: Node Publish Authorization Flow

   For Subscribe Authorization, prior to allowing a subscribe request by
   a user, the XMPP-Grid Controller calls the rule evaluation engine
   directly for "is authorized".  Based this result, the Controller
   either allows or disallowed the flow from continuing.

















Salowey, et al.          Expires January 3, 2015               [Page 21]


Internet-Draft                  XMPP Grid                      July 2014


      -----------------        -----------------         -----------------
     |   Subscriber    |      |    XMPP-Grid    |       |      XMPP       |
     |                 |      |    Controller   |       |     Server      |
      -----------------        -----------------         -----------------
              |                        |                         |
              |      subscribe         |                         |
              |----------------------->|____                     |
              |                        |   |  extract            |
              |                        |   |  identity           |
              |                        |<---                     |
              |                        |                         |
              |                        |____                     |
              |                        |   |   is authorized?    |
              |                        |   | (identity,publish)  |
              |                        |<---                     |
              |                        |                         |
              |                        |       subscribe         |
              |                        |------------------------>|
              |                        |                         |



   Figure 7: Node Subscribe Authorization Flow

   Bulk Data Query differs from other data transfer modes.  Unlike with
   other modes of communication that operate in-band with the XMPP-Grid,
   bulk downloads occur out-of-band (over a different protocol, outside
   of the connection that was established with the XMPP-Grid
   Controller).  Previously discussed authorization mechanisms are
   therefore not appropriate in this context.





















Salowey, et al.          Expires January 3, 2015               [Page 22]


Internet-Draft                  XMPP Grid                      July 2014


      -----------------        -----------------         -----------------
     |   Subscriber    |      |    XMPP-Grid    |       |    Publisher    |
     |                 |      |    Controller   |       |                 |
      -----------------        -----------------         -----------------
              |                        |                         |
              |                    request                       |
              |------------------------------------------------->|
              |                        |                         |____ extract
              |                        |                         |   | cert
              |                        |                         |   | chain
              |                        |                         |<---
              |                        |    is authorized        |
              |                        | (cert chain, service)   |
              |                        |<------------------------|
              |                        |                         |
              |                    response                      |
              |<-------------------------------------------------|
              |                        |                         |


   Figure 8: Node Bulk Data Query Flow

   Instead the bulk download service sends the certificate chain used by
   a Node in the TLS connection to the XMPP-Grid Controller for purposes
   of authenticating and authorizing the Node.  Upon receiving a request
   with a certificate chain, the Controller checks the issuing
   certificate against the trust store, looks up the identity associated
   with the certificate, evaluates the rules, and returns "is
   authorized" to the service.  Then the service can either allow or
   disallow the flow from continuing.

3.5.  XMPP-Grid Topics Protocol Flow

   For each capability, XMPP-Grid supports extensibility through XML
   schemas where the providers (publishers) of the capabilities define
   the schemas for the data exchanged.  The capability provider shall
   also define the version, the available queries and notifications that
   it can support.  The capability provider publishes the messages to
   one or more XMPP Topics, that it requests XMPP-Grid to create
   dynamically, depending on:

   a.  If the capability provider has mutually exclusive schemas,
       different Topics will be created where the capability provider
       will be a publisher to each Topic with a separate schema.

   b.  For a given Topic, if the subscribers wants to receive filtered
       attributes or attribute values in capability provider's published
       data, XMPP-Grid Controller creates sub Topics to the main Topic



Salowey, et al.          Expires January 3, 2015               [Page 23]


Internet-Draft                  XMPP Grid                      July 2014


       based on the message filters expressed.  XMPP-Grid Controller
       enrolls the capability provider as the publisher and the
       requesting subscribers based on the message filter criteria they
       express.  The capability provider will be the publisher to both
       the main Topic and the sub-Topics.

   c.  In the case mentioned in (b) above, it is possible for the
       capability provider to just publish on the main Topic and have
       the XMPP-Grid Controller filter the published messages on the
       Controller-side and deliver attributes and attribute values of
       interest to the subscribers.  Controller-side message filter
       application and the specify mechanisms such as XPATH that can be
       used for parsing the messages is beyond the scope of this
       specification.

3.5.1.  Topic Versioning

   XMPP-Grid supports versioning to support forward and backward
   compatible information models.  The providers of capability include
   the version number in the messages they publish and the receiving
   Nodes can interpret the Topic version and process the attributes
   accordingly.  The expectation is any new version of a capability must
   be of additive updates only.  In other words, existing elements and
   attributes cannot be changed, only new elements or attributes can be
   added.  This will enable nodes with older capability be able to
   process newer version.  The extra new elements or attributes will be
   ignored.  Instead of using the same Topic for all versions, it is
   possible in XMPP-Grid to programmatically create separate Topics for
   each version and allow them to be discovered and subscribed by the
   Nodes.

   In XMPP-Grid, versioning support applies equally to both publish/
   subscribe, directed and out-of-band queries.

3.5.2.  Topic Discovery

   The Nodes connected to XMPP-Grid can query the Controller and get the
   list of all capabilities/Topics running on XMPP-Grid.  The XML
   samples provided in XMPP-Grid Protocol section above provide
   illustrations of Capability Query and Capability Provider Query.

3.5.3.  Subtopics and Message Filters

   XMPP-Grid supports semantic message filtering for Topics.  The
   content being published by a provider can be semantically grouped
   into categories based on domain, location of endpoints for example.
   The provider of a capability specifies whether it supports semantic




Salowey, et al.          Expires January 3, 2015               [Page 24]


Internet-Draft                  XMPP Grid                      July 2014


   filtering or not to the Controller at the subscribe time to the Topic
   under consideration.

   XMPP-Grid subscribers query the Controller and obtain the filtering
   options available for each capability, and express their message
   filtering criteria at subscription time.  The Controller, for each
   unique filter criteria specified by the subscribers, creates a new
   sub Topic under the main capability Topic.  All the subscribers with
   the same filtering criteria will be subscribed to the Subtopic.  The
   set of filter criteria for a capability will be predefined by the
   capability provider and could be based on the well-defined attributes
   of the message.


  -----------------         ---------------------------        --------------
  |               |         |  Grid     |   XMPP      |        | Capability |
  |    Node       |         | Controller|  Server     |        |   Provider |
  |               |         |           |             |        |            |
  -----------------         ---------------------------        --------------
         |                    |                      |               |
         |Subscribe with filter                      |               |
         |------------------->|____                  |               |
         |                    |    | translate &     |               |
         |                    |    | validate        |               |
         |                    |<---- filter          |               |
         |                    |____                  |               |
         |                    |    | Check if sub-topic              |
         |                    |    | for filter      |               |
         |                    |<---  exists          |               |
         |                    |                      |               |
         |                    |Create subtopic if doesn't exist      |
         |                    |--------------------->|               |
         |                    |                      |               |
         |                    |Add Pub & Sub to Sub-Topic            |
         |                    |--------------------->|               |
         |                    |                      |               |
         |                    |Notify Publisher      |               |
         |                    |------------------------------------->|
         | Subscribe Success  |                      |               |
         |<-------------------|                      |               |
         |                    |                      |               |


   Figure 9: Subtopics and Information Filter Subscribe Operations Flow

   The publisher will be responsible for applying the filter on the
   message and publishing the message on the Topic and the Subtopic
   based on the filter criteria.  Filtering logic will be on the



Salowey, et al.          Expires January 3, 2015               [Page 25]


Internet-Draft                  XMPP Grid                      July 2014


   publisher, as the publisher understands the message content.  XMPP-
   Grid fabric is oblivious to the message content.

   To avoid proliferation of new Subtopics, the capability provider
   could express the configurable limit on the number of Subtopics that
   can be created for its capability at registration time.  The XMPP-
   Grid Controller will perform periodic cleanup of Subtopics whenever
   their subscription list reduces to 0.

   In XMPP-Grid, message filters are provided to all APIs i.e. publish/
   subscribe and directed query.

  -----------------         ---------------------------        --------------
  |  Capability   |         |  Grid     |   XMPP      |        |            |
  |   Provider    |         | Controller|  Server     |        |   Node     |
  |               |         |           |             |        |            |
  -----------------         ---------------------------        --------------
         |                    |                      |               |
         | Register as Publisher                     |               |
         |------------------->|                      |               |
         |                    |Add Publisher to main |               |
         |                    |topic & all subtopics |               |
         |                    |--------------------->|               |
         |Return registration |                      |               |
         |success & list of   |                      |               |
         |subtopics with      |                      |               |
         |filtering criteria  |                      |               |
         |<-------------------|                      |               |
         |                    |                      |               |
         |Publish message to  |                      |               |
         |main topic          |                      |               |
         |------------------->|                      |               |
Check    |____                |Publish message to    |               |
filtering|   |                |main topic            |               |
criteria &   |                |--------------------->|               |
identity |<---                |                      |               |
         |                    |                      |               |
         |Publish message to  |                      |               |
         |subtopic that matched filter               |               |
         |------------------------------------------>|               |
         |                    |                      |   Notify      |
         |                    |                      |-------------->|

   Figure 10: Subtopic Publish Operations Flow







Salowey, et al.          Expires January 3, 2015               [Page 26]


Internet-Draft                  XMPP Grid                      July 2014


3.6.  XMPP-Grid Protocol Details

   The XMPP-Grid Protocol provides provides an abstraction layer over
   and above XMPP messages with the intent to provide intuitive
   interfaces to the Nodes connecting to XMPP-Grid.  Nodes connecting to
   XMPP-Grid use the following interfaces (provided as XML samples)
   offered by XMPP-Grid protocol to connect and participate in
   information exchange on XMPP-Grid:

   o Register the Node to XMPP-Grid: Node identified as
   "Node2@domain.com/mac" sends the following Registration request to
   XMPP-Grid controller.

            <iq id="ay0tK-4" to="grid_Controller.jabber"
                from="Node2@domain.com/syam-mac" type="get">
            <grid xmlns='gi' type='request'>
            <AccountQuery xmlns='com.domain.gi.gcl.Controller'>
            <register></register></AccountQuery>
            </grid>
            </iq>

   o Node login to XMPP-Grid: NThe following XML sample shows the Login
   request from Node "Node2@domain.com/mac" to XMPP-Grid controller and
   Login response returned by the XMPP-Grid controller to the Node.


       // Request
       <iq id="ay0tK-5" to="grid_Controller.jabber"
           from="Node2@domain.com/mac" type="get">
         <grid xmlns='gi' type='request'>
           <AccountQuery xmlns='com.domain.gi.gcl.Controller'>
             <login></login>
           </AccountQuery>
         </grid>
       </iq>

       // Response
       <iq xmlns="jabber:client" to=" Node2@domain.com/mac"
           from="grid_Controller.jabber" type="result" id="ay0tK-5">
         <grid xmlns="gi" type="response">
           <AccountQuery xmlns="com.domain.gi.gcl.Controller">
             <login xmlns="">
               <value xmlns:ns2="gi" xmlns:xsi=" xsi:nil="true" />
             </login>
           </AccountQuery>
         </grid>
       </iq>




Salowey, et al.          Expires January 3, 2015               [Page 27]


Internet-Draft                  XMPP Grid                      July 2014


   o Node logout from XMPP-Grid: The following XML sample shows the
   Logout request sent by Node "Node2@domain.com/mac" to XMPP-Grid
   controller.


            <iq id="o47m2-8" to="grid_Controller.jabber"
                from="Node2@domain.com/mac" type="get">
            <grid xmlns='gi' type='request'>
            <AccountQuery xmlns='com.domain.gi.gcl.Controller'>
            <logout></logout>
            </AccountQuery>
            </grid>
            </iq>

   o Capability Discovery Query: The following XML sample shows the
   Capability Discovery query request from Node "Node2@domain.com/mac"
   to XMPP-Grid controller.  The XMPP-Grid controller returns the list
   of capabilities supported by XMPP-Grid and their versions as a
   response to the Node's request.

  // Request
  <iq id="tVKqm-6" to="grid_Controller.jabber"
      from="Node2@domain.com/mac" type="get">
      <grid xmlns="xgrid" type="request">
          <ns2:getCapabilityListRequest xmlns:ns2=" xmlns:ns4="
          xmlns:ns3=" xmlns:ns5=" xmlns:ns6=" xmlns:ns7=" />
      </grid>
  </iq>

  // Response
  <iq from="grid_Controller.jabber" id="tVKqm-6"
      to="Node2@domain.com/mac" type="result" xmlns="jabber:client">
      <grid type="response" xmlns="xgrid">
          <ns2:getCapabilityListResponse xmlns:ns2=" xmlns:ns3="
          xmlns:ns4=" xmlns:ns5=" xmlns:ns6=" xmlns:ns7=">
              <ns2:capability xmlns:xsi=
                  " xsi:type="ns5:TrustSecMetaDataCapability">
                  <ns2:id>0</ns2:id>
                  <ns2:name>TrustSecMetaDataCapability-1.0</ns2:name>
                  <ns2:version>1.0</ns2:version>
              </ns2:capability>
              <ns2:capability
          xmlns:xsi=" xsi:type="ns5:EndpointProfileMetaDataCapability">
                  <ns2:id>0</ns2:id>
                  <ns2:name>
               EndpointProfileMetaDataCapability-1.0</ns2:name>
                  <ns2:version>1.0</ns2:version>
              </ns2:capability>



Salowey, et al.          Expires January 3, 2015               [Page 28]


Internet-Draft                  XMPP Grid                      July 2014


              <ns2:capability xmlns:xsi=
                  " xsi:type="ns5:IdentityGroupCapability">
                  <ns2:id>0</ns2:id>
                  <ns2:name>IdentityGroupCapability-1.0</ns2:name>
                  <ns2:version>1.0</ns2:version>
              </ns2:capability>
              <ns2:capability xmlns:ns9=" xmlns:xsi="
                  xsi:type="ns9:TDAnalysisServiceCapability">
                  <ns2:id>0</ns2:id>
                  <ns2:name>TDAnalysisServiceCapability-1.0</ns2:name>
                  <ns2:version>1.0</ns2:version>
              </ns2:capability>
              <ns2:capability xmlns:xsi=" xsi:type="
                  ns7:NetworkCaptureCapability">
                  <ns2:id>0</ns2:id>
                  <ns2:name>NetworkCaptureCapability-1.0</ns2:name>
                  <ns2:version>1.0</ns2:version>
              </ns2:capability>
              <ns2:capability xmlns:xsi=
                  " xsi:type="ns6:EndpointProtectionServiceCapability">
                  <ns2:id>0</ns2:id>
                  <ns2:name>
                      EndpointProtectionServiceCapability-1.0</ns2:name>
                  <ns2:version>1.0</ns2:version>
              </ns2:capability>
              <ns2:capability xmlns:xsi=
                " xsi:type="ns4:GridControllerAdminServiceCapability">
                  <ns2:id>0</ns2:id>
                  <ns2:name>
               GridControllerAdminServiceCapability-1.0</ns2:name>
                  <ns2:version>1.0</ns2:version>
              </ns2:capability>
              <ns2:capability xmlns:xsi=
                  " xsi:type="ns5:SessionDirectoryCapability">
                  <ns2:id>0</ns2:id>
                  <ns2:name>SessionDirectoryCapability-1.0</ns2:name>
                  <ns2:version>1.0</ns2:version>
              </ns2:capability>
          </ns2:getCapabilityListResponse>
      </grid>
  </iq>










Salowey, et al.          Expires January 3, 2015               [Page 29]


Internet-Draft                  XMPP Grid                      July 2014


   o Specific Capability Provider Query: The following XML sample shows
   the Capability Provider hostname query request from Node
   "Node2@domain.com/mac" to XMPP-Grid controller.  XMPP-Grid controller
   returns the hostname of the specific Capability Provider as a
   response to the Node's request.


  // Request
  <iq id="996IL-8" to="grid_Controller.jabber"
      from="Node2@domain.com/mac" type="get">
    <grid xmlns='gi' type='request'>
      <DiscoveryQuery xmlns='com.domain.gi.gcl.Controller'>
        <find><param xsi:type="xs:string" xmlns:ns2="gi" xmlns:xs
             =" xmlns:xsi=">com.domain.ise.session.SessionQuery
        </param></find>
      </DiscoveryQuery>
    </grid>
  </iq>

  // Response
  <iq from='grid_Controller.jabber' id='996IL-8'
      to='Node2@domain.com/mac' type='result'
      xmlns='jabber:client'>
    <grid type='response' xmlns='gi'>
      <DiscoveryQuery xmlns='com.domain.gi.gcl.Controller'>
        <find xmlns=''><value xmlns:ns3='http://jaxb.dev.java.net/array'
                  xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
                  xsi:type='ns3:stringArray'>
        <item>ise@syam-06.domain.com/syam-mac</item></value></find>
      </DiscoveryQuery>
    </grid>
  </iq>



















Salowey, et al.          Expires January 3, 2015               [Page 30]


Internet-Draft                  XMPP Grid                      July 2014


   o Register as a publisher to the Topic: The following XML sample
   shows the Register as a Publisher request from a Node
   "Node2@domain.com/mac" to XMPP-Grid controller.

       <iq id="fD65a-6" to="grid_Controller.jabber"
           from="Node2@domain.com/mac" type="get">
           <grid xmlns="xgrid" type="request">
               <ns2:initPublishRequest xmlns:ns2=" xmlns:ns4=
                " xmlns:ns3=" xmlns:ns5=" xmlns:ns6=" xmlns:ns7=">
                   <ns2:capability xsi:type="ns5:SessionCapability"
                       xmlns:xsi=">
                       <ns2:id>0</ns2:id>
                       <ns2:version>1.0</ns2:version>
                   </ns2:capability>
               </ns2:initPublishRequest>
           </grid>
       </iq>


































Salowey, et al.          Expires January 3, 2015               [Page 31]


Internet-Draft                  XMPP Grid                      July 2014


   o Register as a subscriber to the Topic: The following XML sample
   shows a subscription request made by Node "Node2@domain.com/mac" for
   "SessionCapability" Topic to XMPP-Grid controller.  On success,
   determined by the Node's authorization privilege, XMPP-Grid
   controller returns the Topic name, version and the Publishers'
   hostname as a response to the Node's request.


    // Subscribe Request
    <iq id="lQJIT-6" to="grid_Controller.jabber"
        from="Node2@domain.com/mac" type="get">
        <grid xmlns="xgrid" type="request">
            <ns2:subscribeRequest xmlns:ns2=" xmlns:ns4=" xmlns:ns3
             =" xmlns:ns5=" xmlns:ns6=" xmlns:ns7=">
                <ns2:capability xsi:type="ns5:SessionCapability"
                xmlns:xsi=">
                    <ns2:id>0</ns2:id>
                    <ns2:version>1.0</ns2:version>
                </ns2:capability>
            </ns2:subscribeRequest>
        </grid>
    </iq>

    // Subscribe Response
    <iq from="grid_Controller.jabber" id=" lQJIT-6"
        to="Node2@domain.com/mac" type="result" xmlns="jabber:client">
        <grid type="response" xmlns="xgrid">
            <ns2:subscribeResponse xmlns:ns2=
                       " xmlns:ns3=" xmlns:ns4=" xmlns:ns5="
                       xmlns:ns6=" xmlns:ns7=">
                <ns2:topicName>SessionCapability-1.0</ns2:topicName>
                <ns2:xmppDetails>
                    <ns2:jid>ise-mnt-XMPP-Grid-004@xgrid.domain.com/gcl
            </ns2:jid>
                    <ns2:jid>ise-mnt-XMPP-Grid-005@xgrid.domain.com/gcl
            </ns2:jid>
                </ns2:xmppDetails>
            </ns2:subscribeResponse>
        </grid>
    </iq>











Salowey, et al.          Expires January 3, 2015               [Page 32]


Internet-Draft                  XMPP Grid                      July 2014


   o Peer-to-Peer Directed Query: The following XML sample shows a peer-
   to-peer directed query request made by Node "Node2@domain.com/mac" to
   other XMPP-Grid participating Node "grid_Controller.jabber", seeking
   identity group information for a specific user "user1".
   "grid_Controller.jabber" returns the list of identity groups "user1"
   belongs as a response to the request.


      // Query Request
      <iq id="kR0YY-8" to="grid_Controller.jabber"
            from="Node2@domain.com/mac" type="get">
          <grid xmlns="xgrid" type="request">
              <ns5:getIdentityGroupRequest xmlns:ns2=" xmlns:ns4="
              xmlns:ns3=" xmlns:ns5=" xmlns:ns6=" xmlns:ns7=">
                  <ns5:user>
                      <ns2:name>user1</ns2:name>
                  </ns5:user>
              </ns5:getIdentityGroupRequest>
          </grid>
      </iq>

      // Query Response
      <iq from="grid_Controller.jabber"
          id=" kR0YY-8" to="Node2@domain.com/mac" type="result">
          <grid type="response" xmlns="xgrid">
              <ns5:getIdentityGroupResponse xmlns:ns2=" xmlns:ns3=
              " xmlns:ns4=" xmlns:ns5=" xmlns:ns6=" xmlns:ns7=">
                  <ns5:user>
                      <ns2:name>user1</ns2:name>
                      <ns3:groupList>
                          <ns3:object>
                              <ns2:name>User Identity Groups:Employee
                  </ns2:name>
                              <ns3:type>Identity</ns3:type>
                          </ns3:object>
                      </ns3:groupList>
                  </ns5:user>
              </ns5:getIdentityGroupResponse>
          </grid>
      </iq>

4.  XMPP-Grid Compatibility with IF-MAP Information Model

   As mentioned throughout this document, XMPP-Grid is information model
   and data format agnostic, as it focuses on transport of security
   context data.  There are, however, deployment scenarios where
   accessing data in a common format in a consistent information model
   will be required for serving SACM use-cases.  The most prevalent



Salowey, et al.          Expires January 3, 2015               [Page 33]


Internet-Draft                  XMPP Grid                      July 2014


   standards-based model for such deployments is IF-MAP, thus an XMPP-
   Grid/IF-MAP compatibility discussion is salient for this document.

   The Trusted Network Connect Working Group (TNC-WG) has defined an
   open solution architecture [IF-MAP] that enables network operators to
   enforce policies regarding the security state of endpoints in order
   to determine whether to grant access to a requested network
   infrastructure.  Part of the TNC architecture is IF-MAP, a standard
   interface between the Metadata Access Point and other elements of the
   TNC architecture.  Readers who wish to understand in detail and
   implement IF-MAP are encouraged to review the following documents:

   o  [IF-MAP]Trusted Computing Group, TNC Architecture for
      Interoperability, Revision 1.5, May 2012

   o  [IF-MAP-SOAP]Trusted Computing Group, TNC IF-MAP Binding for SOAP,
      Revision 2.2, March 2014

   o  [IF-MAP-NETSEC]Trusted Computing Group, TNC IF-MAP Metadata for
      Network Security, Revision 1.0, August 2010

   o  [IF-MAP-ICS]Trusted Computing Group, TNC IF-MAP Metadata for ICS,
      Security, Revision 1.0, October 2012

   From a compatibility perspective, XMPP-Grid can substitute the SOAP-
   based IF-MAP standard interface between the MAP server and other
   elements in the network, thereby providing the information transport
   between IF-MAP clients.  This substitution delivers greater
   scalability and timely data, as well as backwards compatibility with
   IF-MAP deployments.  The IF-MAP data data (Topics and Subtopics can
   be created based on IF-MAP data models) and operation models
   (interfaces, message filters could be defined for the Topics and
   Subtopics based on the IF-MAP operations supported for the use-cases
   developed for use-cases such as network security can be overlaid on
   XMPP-Grid transport thereby achieving model consistency for both IF-
   MAP enabled and XMPP-Grid enabled network deployment scenarios.  The
   MAP Server will be the participant in both the IF-MAP enabled network
   and the XMPP-Grid enabled network serving as aggregator and publisher
   of information.












Salowey, et al.          Expires January 3, 2015               [Page 34]


Internet-Draft                  XMPP Grid                      July 2014


       IF-MAP Enabled Devices
          ____________            ___________          _____________
          |__________|_           |         |  IF-MAP  |   Flow    |
          || _________|_          |         |<-------->|Controllers|
          || |         |  IF-MAP  |         |          |___________|
          -|_|   PDP   |<-------->|         |
             |_________|          |         |          _____________
                                  |  MAP    |  IF-MAP  |           |
          ____________            | Server  |<-------->|  Sensors  |
          |__________|_           |         |          |___________|
          || _________|_          |         |          _____________
          || |         |  IF-MAP  |         |  IF-MAP  |           |
          -|_|   PEP   |<-------->|         |<-------->|   Others  |
             |_________|          |_________|          |___________|
                                       ^
                                       |
                                       | Grid
       XMPP-Grid Enabled Devices       |
          ____________            _____V_____          _____________
          |__________|_           |         |   Grid   |   Flow    |
          || _________|_          |         |<-------->|Controllers|
          || |         |   Grid   |         |          |___________|
          -|_|   PDP   |<-------->|  Grid   |
             |_________|          | Server  |          _____________
                                  | Cluster |   Grid   |           |
          ____________            |         |<-------->|  Sensors  |
          |__________|_           |         |          |___________|
          || _________|_          |_________|          _____________
          || |         |                               |           |
          -|_|   PEP   |             GRID              |   Others  |
             |_________|<----------------------------->|___________|


   Figure 11: XMPP-Grid and IF-MAP Interoperability

   The MAP server will be a XMPP-Grid Node connected to the XMPP-Grid
   Controller.  The MAP server will play the role of subscribers and/or
   publishers depending on the MAP graphs and the contextual metadata to
   be aggregated and/or published.

4.1.  MAP Server as XMPP-Grid Subscriber for Metadata Aggregation

   The MAP Server will be a subscriber when aggregating metadata from
   various XMPP-Grid-enabled PEPs and PDPs in the network.  Topics will
   be created in XMPP-Grid depending on the metadata to be aggregated,
   how relational or disjoint the metadata types, metadata-identifier
   linkages in IF-MAP graph are and the publishers of the data such as
   the Access Requestors, PEPs and PDPs.  As discussed in the Topics



Salowey, et al.          Expires January 3, 2015               [Page 35]


Internet-Draft                  XMPP Grid                      July 2014


   section earlier, XMPP-Grid provides the ability to the Capability
   provider to create main Topics and Subtopics.  The MAP server will be
   a subscriber to all of the Topics created for such purposes of
   aggregation.  It is the responsibility of the MAP server to use the
   subscribed metadata to build and manage the MAP graphs.

   XMPP-Grid architecture allows multiple MAP servers to be subscribers
   to the Topics and also other network elements such as Flow
   Controllers and Sensors to directly consume information from the
   sources.  This enables a complete decentralized architecture for IF-
   MAP for metadata aggregation where the MAP Server need not always be
   the sole publisher of metadata for the MAP graph.  With such approach
   it will be possible for time-sensitive subscribers to directly
   consume information from the sources and use the MAP server for query
   and search purposes only, enabling the MAP servers to scale
   significantly.  This also allows aggregation of metadata based on
   domains where MAP server can aggregate and publish metadata based on
   domain, and subscribers could use message filters such as domain,
   location to receive only metadata of interest to them.

Region 1                                                             Region 2
                         ___________      ___________
                         |         |      |         |
                         |  MAP    |      |   MAP   |
                         | Server  |      | Server  |
 ____________            |         |      |         |             ___________
 |__________|_           |_________|      |_________|            _|_________|
 || _________|_               ^                 ^               _|_________||
 || |         |   Grid        |                 |       Grid    |         ||-
 -|_|   PDP   |<-----------|  |Grid         Grid|  |----------->|   PDP   |-
    |_________|            |  |                 |  |            |_________|
 ____________            __V__V_____      ______V__V__            ___________
 |__________|_           |         |      |          |           _|_________|
 || _________|_          |         |      |          |          _|_________||
 || |         |   Grid   |         |      |          |   Grid   |         ||-
 -|_|   PEP   |<-------->|         |      |          |<-------->|   PEP   |-
    |_________|          |         |      |          |          |_________|
 _____________           |  Grid   | Grid |   Grid   |           _____________
 |   Flow    |    Grid   | Server  |<---->|  Server  |    Grid   |   Flow    |
 |Controllers|<--------->|         |      |          |<--------->|Controllers|
 |___________|           |         |      |          |           |___________|
 _____________           |         |      |          |           _____________
 |           |    Grid   |         |      |          |    Grid   |           |
 |  Sensors  |<--------->|         |      |          |<--------->|  Sensors  |
 |___________|           |_________|      |__________|           |___________|


   Figure 12: XMPP-Grid Bridging Multiple IF-MAP Instances



Salowey, et al.          Expires January 3, 2015               [Page 36]


Internet-Draft                  XMPP Grid                      July 2014


4.2.  MAP Server as XMPP-Grid Publisher for Metadata Dissemination

   MAP Server could publish the MAP graph attribute changes to
   interested subscribers such as Flow Controllers, Sensors in the
   following ways

   a.  MAP Server to publish all attribute changes of a MAP graph on a
       main Topic to which the interested network elements participate
       as subscribers.  The subscribers will be able to get real-time
       notifications through Publish-Subscribe and make on-demand peer-
       to-peer directed or bulk queries depending on their authorization
       privileges.

   b.  In addition, MAP server, at registration time with XMPP-Grid,
       could register the MAP graph's filtering criteria as a Publisher
       with XMPP-Grid.  The filtering criteria of a MAP graph could be
       based on a combination of -

       A.  metadata types

       B.  metadata-identifier linkage attributes

       C.  metadata class

       D.  existing IF-MAP search criteria

   As discussed in the Topics section, XMPP-Grid Controller will create
   Subtopics and manage the Subtopics through the lifecycle based on the
   subscription list.  The MAP Server and XMPP-Grid applies the message
   filters to publish-subscribe, directed or bulk queries made by the
   subscribers.

5.  IANA Considerations

   IANA Considerations to be determined

6.  Security Considerations

   A XMPP-Grid Controller serves as an controlling broker for XMPP-Grid
   Nodes such as Enforcement Points, Policy Servers, CMDBs, and Sensors,
   using a publish-subscribe-search model of information exchange and
   lookup.  By increasing the ability of XMPP-Grid Nodes to learn about
   and respond to security-relevant events and data, XMPP-Grid can
   improve the timeliness and utility of the security system.  However,
   this integrated security system can also be exploited by attackers if
   they can compromise it.  Therefore, strong security protections for
   XMPP-Grid are essential.




Salowey, et al.          Expires January 3, 2015               [Page 37]


Internet-Draft                  XMPP Grid                      July 2014


   This section provides a security analysis of the XMPP-Grid transport
   protocol and the architectural elements that employ it, specifically
   with respect to their use of this protocol.  Three subsections define
   the trust model (which elements are trusted to do what), the threat
   model (attacks that may be mounted on the system), and the
   countermeasures (ways to address or mitigate the threats previously
   identified).

6.1.  Trust Model

   The first step in analyzing the security of the XMPP-Grid transport
   protocol is to describe the trust model, listing what each
   architectural element is trusted to do.  The items listed here are
   assumptions, but provisions are made in the Threat Model and
   Countermeasures sections for elements that fail to perform as they
   were trusted to do.

6.1.1.  Network

   The network used to carry XMPP-Grid messages is trusted to:

   o  Perform best effort delivery of network traffic

   The network used to carry XMPP-Grid messages is not expected
   (trusted) to:

   o  Provide confidentiality or integrity protection for messages sent
      over it

   o  Provide timely or reliable service

6.1.2.  XMPP-Grid Nodes

   Authorized XMPP-Grid Nodes are trusted to:

   o  Preserve the confidentiality of sensitive data retrieved via the
      XMPP-Grid Controller

6.1.3.  XMPP-Grid Controller

   The XMPP-Grid Controller is trusted to:

   o  Broker requests for data and enforce authorization of access to
      this data throughout its lifecycle

   o  Perform service requests in a timely and accurate manner

   o  Create and maintain accurate operational attributes



Salowey, et al.          Expires January 3, 2015               [Page 38]


Internet-Draft                  XMPP Grid                      July 2014


   o  Only reveal data to and accept service requests from authorized
      parties

   The XMPP-Grid Controller is not expected (trusted) to:

   o  Verify the truth (correctness) of data

6.1.4.  Certification Authority

   The Certification Authority (CA) that issues certificates for the
   XMPP-Grid Controller and/or XMPP-Grid Nodes (or each CA, if there are
   several) is trusted to:

   o  Protect the confidentiality of the CA's private key

   o  Ensure that only proper certificates are issued and that all
      certificates are issued in accordance with the CA's policies

   o  Revoke certificates previously issued when necessary

   o  Regularly and securely distribute certificate revocation
      information

   o  Promptly detect and report any violations of this trust so that
      they can be handled

   The CA is not expected (trusted) to:

   o  Issue certificates that go beyond name constraints or other
      constraints imposed by a relying party or a cross-certificate

6.2.  Threat Model

   To secure the XMPP-Grid transport protocol and the architectural
   elements that implement it, this section identifies the attacks that
   can be mounted against the protocol and elements.

6.2.1.  Network Attacks

   A variety of attacks can be mounted using the network.  For the
   purposes of this subsection the phrase "network traffic" should be
   taken to mean messages and/or parts of messages.  Any of these
   attacks may be mounted by network elements, by parties who control
   network elements, and (in many cases) by parties who control network-
   attached devices.

   o  Network traffic may be passively monitored to glean information
      from any unencrypted traffic



Salowey, et al.          Expires January 3, 2015               [Page 39]


Internet-Draft                  XMPP Grid                      July 2014


   o  Even if all traffic is encrypted, valuable information can be
      gained by traffic analysis (volume, timing, source and destination
      addresses, etc.)

   o  Network traffic may be modified in transit

   o  Previously transmitted network traffic may be replayed

   o  New network traffic may be added

   o  Network traffic may be blocked, perhaps selectively

   o  A "Man In The Middle" (MITM) attack may 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

   o  Resist attacks (including denial of service and other attacks from
      XMPP-Grid Nodes)

   o  Undesired network traffic may be sent in an effort to overload an
      architectural component, thus mounting a denial of service attack

6.2.2.  XMPP-Grid Nodes

   An unauthorized XMPP-Grid Nodes (one which is not recognized by the
   XMPP-Grid Controller or is recognized but not authorized to perform
   any actions) cannot mount any attacks other than those listed in the
   Network Attacks section above.

   An authorized XMPP-Grid Node, on the other hand, can mount many
   attacks.  These attacks might occur because the XMPP-Grid Node is
   controlled by a malicious, careless, or incompetent party (whether
   because its owner is malicious, careless, or incompetent or because
   the XMPP-Grid Node has been compromised and is now controlled by a
   party other than its owner).  They might also occur because the XMPP-
   Grid Node is running malicious software; because the XMPP-Grid Node
   is running buggy software (which may fail in a state that floods the
   network with traffic); or because the XMPP-Grid Node has been
   configured improperly.  From a security standpoint, it generally
   makes no difference why an attack is initiated.  The same
   countermeasures can be employed in any case.

   Here is a list of attacks that may be mounted by an authorized XMPP-
   Grid Node:

   o  Cause many false alarms or otherwise overload the XMPP-Grid
      Controller or other elements in the network security system



Salowey, et al.          Expires January 3, 2015               [Page 40]


Internet-Draft                  XMPP Grid                      July 2014


      (including human administrators) leading to a denial of service or
      disabling parts of the network security system

   o  Omit important actions (such as posting incriminating data),
      resulting in incorrect access

   o  Use confidential information obtained from the XMPP-Grid
      Controller to enable further attacks (such as using endpoint
      health check results to exploit vulnerable endpoints)

   o  Advertise data crafted to exploit vulnerabilities in the XMPP-Grid
      Controller or in other XMPP-Grid Nodes, with a goal of
      compromising those systems

   o  Issue a search request or set up a subscription that matches an
      enormous result, leading to resource exhaustion on the XMPP-Grid
      Controller, the publishing XMPP-Grid Node, and/or the network

   o  Establish a communication channel using another XMPP-Grid Node's
      session-id

   Dependencies of or vulnerabilities of authorized XMPP-Grid Nodes may
   be exploited to effect these attacks.  Another way to effect these
   attacks is to gain the ability to impersonate a XMPP-Grid Node
   (through theft of the XMPP-Grid Node's identity credentials or
   through other means).  Even a clock skew between the XMPP-Grid Node
   and XMPP-Grid Controller can cause problems if the XMPP-Grid Node
   assumes that old XMPP-Grid Node data should be ignored.

6.2.3.  XMPP-Grid Controllers

   An unauthorized XMPP-Grid Controller (one which is not trusted by
   XMPP-Grid Nodes) cannot mount any attacks other than those listed in
   the Network Attacks section above.

   An authorized XMPP-Grid Controller can mount many attacks.  Similar
   to the XMPP-Grid Node case described above, these attacks might occur
   because the XMPP-Grid Controller is controlled by a malicious,
   careless, or incompetent party (either a XMPP-Grid Controller
   administrator or an attacker who has seized control of the XMPP-Grid
   Controller).  They might also occur because the XMPP-Grid Controller
   is running malicious software, because the XMPP-Grid Controller is
   running buggy software (which may fail in a state that corrupts data
   or floods the network with traffic), or because the XMPP-Grid
   Controller has been configured improperly.

   All of the attacks listed for XMPP-Grid Node above can be mounted by
   the XMPP-Grid Controller.  Detection of these attacks will be more



Salowey, et al.          Expires January 3, 2015               [Page 41]


Internet-Draft                  XMPP Grid                      July 2014


   difficult since the XMPP-Grid Controller can create false operational
   attributes and/or logs that imply some other party created any bad
   data.

   Additional XMPP-Grid Controller attacks may include:

   o  Expose different data to different XMPP-Grid Nodes to mislead
      investigators or cause inconsistent behavior

   o  Mount an even more effective denial of service attack than a
      single XMPP-Grid Node could

   o  Obtain and cache XMPP-Grid Node credentials so they can be used to
      impersonate XMPP-Grid Nodes even after a breach of the XMPP-Grid
      Controller is repaired

   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

   Dependencies of or vulnerabilities of the XMPP-Grid Controller may be
   exploited to obtain control of the XMPP-Grid Controller and effect
   these attacks.

6.2.4.  Certification Authority

   A Certification Authority trusted to issue certificates for the XMPP-
   Grid Controller and/or XMPP-Grid Nodes can mount several attacks:

   o  Issue certificates for unauthorized parties, enabling them to
      impersonate authorized parties such as the XMPP-Grid Controller or
      a XMPP-Grid Node.  This can lead to all the threats that can be
      mounted by the certificate's subject.

   o  Issue certificates without following all of the CA's policies.
      Because this can result in issuing certificates that may be used
      to impersonate authorized parties, this can lead to all the
      threats that can be mounted by the certificate's subject.

   o  Fail to revoke previously issued certificates that need to be
      revoked.  This can lead to undetected impersonation of the
      certificate's subject or failure to revoke authorization of the
      subject, and therefore can lead to all of the threats that can be
      mounted by that subject.

   o  Fail to regularly and securely distribute certificate revocation
      information.  This may cause a relying party to accept a revoked
      certificate, leading to undetected impersonation of the



Salowey, et al.          Expires January 3, 2015               [Page 42]


Internet-Draft                  XMPP Grid                      July 2014


      certificate's subject or failure to revoke authorization of the
      subject, and therefore can lead to all of the threats that can be
      mounted by that subject.  It can also cause a relying party to
      refuse to proceed with a transaction because timely revocation
      information is not available, even though the transaction should
      be permitted to proceed.

   o  Allow the CA's private key to be revealed to an unauthorized
      party.  This can lead to all the threats above.  Even worse, the
      actions taken with the private key will not be known to the CA.

   o  Fail to promptly detect and report errors and violations of trust
      so that relying parties can be promptly notified.  This can cause
      the threats listed earlier in this section to persist longer than
      necessary, leading to many knock-on effects.

6.3.  Countermeasures

   Below are countermeasures for specific attack scenarios to the XMPP-
   Grid infrastructure.

6.3.1.  Securing the XMPP-Grid Transport Protocol

   To address network attacks, the XMPP-Grid transport protocol
   described in this document requires that the XMPP-Grid messages MUST
   be carried over TLS as described in IETF RFC 2818.  The XMPP-Grid
   Node MUST verify the XMPP-Grid Controller's certificate and determine
   whether the XMPP-Grid Controller is trusted by this XMPP-Grid Node
   before completing the TLS handshake.  The XMPP-Grid Controller MUST
   authenticate the XMPP-Grid Node either using mutual certificate-based
   authentication in the TLS handshake or using Basic Authentication as
   described in IETF RFC 2617.  XMPP-Grid Controller MUST use Simple
   Authentication and Security Layer (SASL), described in IETF RFC 4422,
   to support the aforesaid authentication mechanisms.  SASL offers
   authentication mechanism negotiations between the XMPP-Grid
   Controller and XMPP-Grid node during the connection establishment
   phase.  XMPP-Grid Nodes and XMPP-Grid Controllers using mutual
   certificate-based authentication SHOULD each verify the revocation
   status of the other party.  All XMPP-Grid Controllers and XMPP-Grid
   Nodes MUST implement both mutual certificate-based authentication and
   Basic Authentication.  The selection of which XMPP-Grid Node
   authentication technique to use in any particular deployment is left
   to the administrator.

   An XMPP-Grid Controller MAY also support a local, configurable set of
   Basic Authentication userid-password pairs.  If so, it is
   implementation dependent whether a XMPP-Grid Controller ends a
   session when an administrator changes the configured password.  Since



Salowey, et al.          Expires January 3, 2015               [Page 43]


Internet-Draft                  XMPP Grid                      July 2014


   Basic Authentication has many security disadvantages (especially the
   transmission of reusable XMPP-Grid Node passwords to the XMPP-Grid
   Controller), it SHOULD only be used when absolutely necessary.  Per
   the HTTP specification, when basic authentication is in use, a XMPP-
   Grid Controller MAY respond to any request that lacks credentials
   with an error code similar to HTTP code 401.  A XMPP-Grid Node SHOULD
   avoid this code by submitting basic auth credentials with every
   request when basic authentication is in use.  If it does not do so, a
   XMPP-Grid Node MUST respond to this code by resubmitting the same
   request with credentials (unless the XMPP-Grid Node is shutting
   down).

   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
   attacks is desired, ingress filtering, rate limiting per source IP
   address, and other denial of service mitigation measures may be
   employed.  In addition, a XMPP-Grid Controller MAY automatically
   disable a misbehaving XMPP-Grid Node.

6.3.2.  Securing XMPP-Grid Nodes

   XMPP-Grid Nodes may be deployed in locations that are susceptible to
   physical attacks.  Physical security measures may be taken to avoid
   compromise of XMPP-Grid Nodes, but these may not always be practical
   or completely effective.  An alternative measure is to configure the
   XMPP-Grid Controller to provide read-only access for such systems.
   The XMPP-Grid Controller SHOULD also include a full authorization
   model so that individual XMPP-Grid Nodes may be configured to have
   only the privileges that they need.  The XMPP-Grid Controller MAY
   provide functional templates so that the administrator can configure
   a specific XMPP-Grid Node as a DHCP server and authorize only the
   operations and metadata types needed by a DHCP server to be permitted
   for that XMPP-Grid Node.  These techniques can reduce the negative
   impacts of a compromised XMPP-Grid Node without diminishing the
   utility of the overall system.

   To handle attacks within the bounds of this authorization model, the
   XMPP-Grid Controller MAY also include rate limits and alerts for
   unusual XMPP-Grid Node behavior.  XMPP-Grid Controllers SHOULD make
   it easy to revoke a XMPP-Grid Node's authorization when necessary.
   Another way to detect attacks from XMPP-Grid Nodes is to create fake
   entries in the available data (honeytokens) which normal XMPP-Grid
   Nodes will not attempt to access.  The XMPP-Grid Controller SHOULD
   include auditable logs of XMPP-Grid Node activities.

   To avoid compromise of XMPP-Grid Node, XMPP-Grid Node SHOULD be
   hardened against attack and minimized to reduce their attack surface.



Salowey, et al.          Expires January 3, 2015               [Page 44]


Internet-Draft                  XMPP Grid                      July 2014


   They SHOULD go through a TNC handshake to verify the integrity of the
   XMPP-Grid Node, and SHOULD, if feasible, utilize a Trusted Platform
   Module (TPM) for identity and/or integrity measurements of the XMPP-
   Grid Node within a TNC handshake.  They should be well managed to
   minimize vulnerabilities in the underlying platform and in systems
   upon which the XMPP-Grid Node depends.  Personnel with administrative
   access should be carefully screened and monitored to detect problems
   as soon as possible.

6.3.3.  Securing XMPP-Grid Controllers

   Because of the serious consequences of XMPP-Grid Controller
   compromise, XMPP-Grid Controllers SHOULD be especially well hardened
   against attack and minimized to reduce their attack surface.  They
   SHOULD go through a regular TNC handshake to verify the integrity of
   the XMPP-Grid Controller, and SHOULD utilize a Trusted Platform
   Module (TPM) for identity and/or integrity measurements of the XMPP-
   Grid Node within a TNC handshake.  They should be well managed to
   minimize vulnerabilities in the underlying platform and in systems
   upon which the XMPP-Grid Controller depends.  Network security
   measures such as firewalls or intrusion detection systems may be used
   to monitor and limit traffic to and from the XMPP-Grid Controller.
   Personnel with administrative access should be carefully screened and
   monitored to detect problems as soon as possible.  Administrators
   should not use password-based authentication but should instead use
   non-reusable credentials and multi-factor authentication (where
   available).  Physical security measures SHOULD be employed to prevent
   physical attacks on XMPP-Grid Controllers.

   To ease detection of XMPP-Grid Controller compromise should it occur,
   XMPP-Grid Controller behavior should be monitored to detect unusual
   behavior (such as a reboot, a large increase in traffic, or different
   views of an information repository for similar XMPP-Grid Nodes).
   XMPP-Grid Nodes should log and/or notify administrators when peculiar
   XMPP-Grid Controller behavior is detected.  To aid forensic
   investigation, permanent read-only audit logs of security-relevant
   information (especially administrative actions) should be maintained.
   If XMPP-Grid Controller compromise is detected, a careful analysis
   should be performed of the impact of this compromise.  Any reusable
   credentials that may have been compromised should be reissued.

6.3.4.  Limit on search result size

   While XMPP-Grid is designed for high scalability to 100,000s of
   Nodes, an XMPP-Grid Controller MAY establish a limit to the amount of
   data it is willing to return in search or subscription results.  This
   mitigates the threat of a XMPP-Grid Node causing resource exhaustion
   by issuing a search or subscription that leads to an enormous result.



Salowey, et al.          Expires January 3, 2015               [Page 45]


Internet-Draft                  XMPP Grid                      July 2014


6.3.5.  Cryptographically random session-id and authentication checks
        for ARC

   A XMPP-Grid Controller SHOULD ensure that the XMPP-Grid Node
   establishing an ARC is the same XMPP-Grid Node as the XMPP-Grid Node
   that established the corresponding SSRC.  The XMPP-Grid Controller
   SHOULD employ both of the following strategies:

   o  session-ids SHOULD be cryptographically random

   o  The HTTPS transport for the SSRC and the ARC SHOULD be
      authenticated using the same credentials.  SSL session resumption
      MAY be used to establish the ARC based on the SSRC SSL session.

6.3.6.  Securing the Certification Authority

   As noted above, compromise of a Certification Authority (CA) trusted
   to issue certificates for the XMPP-Grid Controller and/or XMPP-Grid
   Nodes is a major security breach.  Many guidelines for proper CA
   security have been developed: the CA/Browser Forum's Baseline
   Requirements, the AICPA/CICA Trust Service Principles, etc.  The CA
   operator and relying parties should agree on an appropriately
   rigorous security practices to be used.

   Even with the most rigorous security practices, a CA may be
   compromised.  If this compromise is detected quickly, relying parties
   can remove the CA from their list of trusted CAs, and other CAs can
   revoke any certificates issued to the CA.  However, CA compromise may
   go undetected for some time, and there's always the possibility that
   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
   may wish to "pin" a small number of particularly critical
   certificates (such as the certificate for the XMPP-Grid Controller).
   Once a certificate has been pinned, the relying party will not accept
   another certificate in its place unless the Administrator explicitly
   commands it to do so.  This does not mean that the relying party will
   not check the revocation status of pinned certificates.  However, the
   Administrator may still be consulted if a pinned certificate is
   revoked, since the CA and revocation process are not completely
   trusted.

6.4.  Summary

   XMPP-Grid's considerable value as a broker for security-sensitive
   data exchange distribution also makes the protocol and the network
   security elements that implement it a target for attack.  Therefore,
   strong security has been included as a basic design principle within
   the XMPP-Grid design process.



Salowey, et al.          Expires January 3, 2015               [Page 46]


Internet-Draft                  XMPP Grid                      July 2014


   The XMPP-Grid transport protocol provides strong protection against a
   variety of different attacks.  In the event that a XMPP-Grid Node or
   XMPP-Grid Controller is compromised, the effects of this compromise
   have been reduced and limited with the recommended role-based
   authorization model and other provisions, and best practices for
   managing and protecting XMPP-Grid systems have been described.  Taken
   together, these measures should provide protection commensurate with
   the threat to XMPP-Grid systems, thus ensuring that they fulfill
   their promise as a network security clearing-house.

7.  Privacy Considerations

   XMPP-Grid Nodes may publish information about endpoint health,
   network access, events (which may include information about what
   services an endpoint is accessing), roles and capabilities, and the
   identity of the end user operating the endpoint.  Any of this
   published information may be queried by other XMPP-Grid Nodes and
   could potentially be used to correlate network activity to a
   particular end user.

   Dynamic and static information brokered by a XMPP-Grid Controller,
   ostensibly for purposes of correlation by XMPP-Grid Nodes for
   intrusion detection, could be misused by a broader set of XMPP-Grid
   Nodes which hitherto have been performing specific roles with strict
   well-defined separation of duties.

   Care should be taken by deployers of XMPP-Grid to ensure that the
   information published by XMPP-Grid Nodes does not violate agreements
   with end users or local and regional laws and regulations.  This can
   be accomplished either by configuring XMPP-Grid Nodes to not publish
   certain information or by restricting access to sensitive data to
   trusted XMPP-Grid Nodes.

8.  Evolution of XMPP-Grid

   XMPP-Grid is the convergence of IF-MAP from the Trusted Computing
   Group and the Platform-Exchange Grid (pxGrid) from Cisco Systems.
   Both frameworks focus on enabling end users to implement multi-vendor
   systems that share security context information that enables
   coordinated defense-in-depth and security automation.

   An ecosystem of vendors has been shipping IF-MAP enabled products
   since 2008 to provide an architecture that supports standardized,
   dynamic security data interexchange among a wide variety of
   networking and security components.  IF-MAP has been continually
   enhanced by the Trusted Computing Group, culminating in the most
   recent version, IF-MAP 2.2, published in March 2014.  IF-MAP has




Salowey, et al.          Expires January 3, 2015               [Page 47]


Internet-Draft                  XMPP Grid                      July 2014


   focused on providing a standardized information model that can be
   utilized for data interoperability between vendors.

   Cisco pxGrid was introduced in 2013 and has since developed a broad-
   based security and networking vendor ecosystem.  pxGrid was developed
   by extending standards-based XMPP message routing.  The goal of
   pxGrid is to specifically address a lack of transport protocols
   available in the industry that deliver highly scalable, many-to-many
   platform security data interexchange in real-time.

   XMPP-Grid brings together the strengths of both IF-MAP and pxGrid.
   IF-MAP provides a mature and standardized information model.  This
   information model is accessible by Cisco pxGrid to transport relevant
   data between systems.  The combined XMPP-Grid delivers a highly
   scalable, real-time data exchange transport protocol with an
   interoperable information model based on the experience from real-
   world, production deployments.

9.  Acknowledgements

   The authors would like to acknowledge the contributions, authoring
   and/or editing of the following people: Henk Birkholz, Jessica
   Fitzgerald-McKay, Steve Hanna, Steve Venema.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3922]  Saint-Andre, P., "Mapping the Extensible Messaging and
              Presence Protocol (XMPP) to Common Presence and Instant
              Messaging (CPIM)", RFC 3922, October 2004.

   [RFC3923]  Saint-Andre, P., "End-to-End Signing and Object Encryption
              for the Extensible Messaging and Presence Protocol
              (XMPP)", RFC 3923, October 2004.

   [RFC4422]  Melnikov, A. and K. Zeilenga, "Simple Authentication and
              Security Layer (SASL)", RFC 4422, June 2006.

   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 6120, March 2011.

   [RFC6121]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Instant Messaging and Presence", RFC
              6121, March 2011.



Salowey, et al.          Expires January 3, 2015               [Page 48]


Internet-Draft                  XMPP Grid                      July 2014


10.2.  Informative References

   [I-D.ietf-sacm-terminology]
              Waltermire, D., Montville, A., Harrington, D., and N. Cam-
              Winget, "Terminology for Security Assessment", draft-ietf-
              sacm-terminology-04 (work in progress), May 2014.

   [I-D.ietf-sacm-use-cases]
              Waltermire, D. and D. Harrington, "Endpoint Security
              Posture Assessment - Enterprise Use Cases", draft-ietf-
              sacm-use-cases-07 (work in progress), April 2014.

   [IF-MAP]   Trusted Computing Group, "TNC Architecture for
              Interoperability, Revision 1.5", May 2012.

   [IF-MAP-ICS]
              Trusted Computing Group, "TNC IF-MAP Metadata for ICS,
              Security, Revision 1.0", October 2012.

   [IF-MAP-NETSEC]
              Trusted Computing Group, "TNC IF-MAP Metadata for Network
              Security, Revision 1.0", August 2010.

   [IF-MAP-SOAP]
              Trusted Computing Group, "TNC IF-MAP Binding for SOAP,
              Revision 2.1", May 2012.

   [RFC5070]  Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
              Object Description Exchange Format", RFC 5070, December
              2007.

Authors' Addresses

   Joseph Salowey (editor)
   Cisco Systems
   2901 3rd Ave
   Seattle, WA  98121
   US

   Email: jsalowey@cisco.com











Salowey, et al.          Expires January 3, 2015               [Page 49]


Internet-Draft                  XMPP Grid                      July 2014


   Lisa Lorenzin
   Juniper Networks, Inc.
   3614 Laurel Creek Way
   Durham, NC  27712
   USA

   Email: llorenzin@juniper.net


   Cliff Kahn
   Juniper Networks, Inc.
   10 Technology Park Drive
   Westford, MA  01886
   USA

   Email: cliffordk@juniper.net


   Scott Pope
   Cisco Systems
   5400 Meadows Road
   Suite 300
   Lake Oswego, OR  97035
   USA

   Email: scottp@cisco.com


   Syam Appala
   Cisco Systems
   80 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: syam1@cisco.com


   Aaron Woland
   Cisco Systems
   1900 South Boulevard
   Charlotte, NC  28203
   USA

   Email: aawoland@cisco.com







Salowey, et al.          Expires January 3, 2015               [Page 50]


Internet-Draft                  XMPP Grid                      July 2014


   Nancy Cam-Winget
   Cisco Systems
   3550 Cisco WAY
   San Jose, CA  95134
   USA

   Email: ncamwing@cisco.com












































Salowey, et al.          Expires January 3, 2015               [Page 51]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/