| SACM | J. Salowey, Ed. |
| Internet-Draft | Cisco Systems |
| Intended status: Standards Track | L. Lorenzin |
| Expires: April 29, 2015 | Pulse Secure |
| C. Kahn | |
| Juniper Networks, Inc. | |
| S. Pope | |
| S. Appala | |
| A. Woland | |
| N. Cam-Winget | |
| Cisco Systems | |
| October 26, 2014 |
XMPP Protocol Extensions for Use in SACM Information Transport
draft-salowey-sacm-xmpp-grid-01
This document defines a transport protocol for use with the Security Automation and Continuous Monitoring (SACM) Architecture.
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 April 29, 2015.
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 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.
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] and new ones referenced in this draft.
This document is being discussed on the sacm@ietf.org mailing list.
AAA
CA
Capability Provider
CMDB
IDS
IPS
JID
MDM
NAC
PDP
PEP
Presence
Publisher
SIEM
Subscriber
Sub-Topics
Topics
VoIP
XMPP-Grid
XMPP-Grid Controller
XMPP-Grid Connection Agent
XMPP-Grid Node
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.
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.
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 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:
The operations carried out by XMPP-Grid to exchange security data are:
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:
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.
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:
Adopting XMPP-Grid security data sharing capabilities provides a number of benefits for adopting vendors, especially when compared to proprietary interfaces, such as:
______________
| 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
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:
Each of the seven defined usage-scenarios is listed below, along with a summary of how XMPP-Grid is applicable to each use-case.
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.
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.
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 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.
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..
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.
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.
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
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.
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 |
| Controller | | Controller | | Controller |
| | | | | |
--------------- --------------- ---------------
| | |
| | |
--------------- --------------- ---------------
| XMPP Server | | XMPP Server | | XMPP Server |
| |---------| |--------| |
| | | | | |
--------------- --------------- ---------------
Figure 2: XMPP Server and XMPP-Grid Cluster Architecture
The connected Nodes, with appropriate authorization privileges, can:
This model enables flexible API usage depending on the Nodes' contextual and time-sensitivity needs of security information.
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 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:
XMPP offers several of the following salient features for building a security data interexchange protocol:
The XMPP extensions used in XMPP-Grid are now part (e.g. publish/subscribe) of the main XMPP specification [RFC6120] and the presence in [RFC6121]. A full list of XMPP Extension Protocols (XEPs) [RFC6120] can be found in http://xmpp.org/extensions/xep-0001.html .
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.
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.
---------------- ---------------- ----------------
| 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 | | | |<--------------------------|
| | | | |
--- | | 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 -
Nodes connecting to XMPP-Grid go through the phases of authentication, registration and authorization before they can participate in information exchange on XMPP-Grid.
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.
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.
----------------- ---------------------------
| | | 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
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
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.
----------------- ----------------- -----------------
| 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.
----------------- ----------------- -----------------
| 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.
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:
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.
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.
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 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 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
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>
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>
<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>
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>
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>
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>
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>
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 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:
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.
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.
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 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
MAP Server could publish the MAP graph attribute changes to interested subscribers such as Flow Controllers, Sensors in the following ways
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.
IANA Considerations to be determined
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.
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).
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.
The network used to carry XMPP-Grid messages is trusted to:
The network used to carry XMPP-Grid messages is not expected (trusted) to:
Authorized XMPP-Grid Nodes are trusted to:
The XMPP-Grid Controller is trusted to:
The XMPP-Grid Controller is not expected (trusted) to:
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:
The CA is not expected (trusted) to:
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.
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.
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:
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.
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 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:
Dependencies of or vulnerabilities of the XMPP-Grid Controller may be exploited to obtain control of the XMPP-Grid Controller and effect these attacks.
A Certification Authority trusted to issue certificates for the XMPP-Grid Controller and/or XMPP-Grid Nodes can mount several attacks:
Below are countermeasures for specific attack scenarios to the XMPP-Grid infrastructure.
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 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.
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. 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.
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.
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.
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:
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.
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.
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.
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.
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 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.
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.
| [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. |