idnits 2.17.1 draft-salowey-sacm-xmpp-grid-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 103 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 29, 2015) is 3284 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'IF-MAP-ICS' is defined on line 2298, but no explicit reference was found in the text == Unused Reference: 'IF-MAP-NETSEC' is defined on line 2302, but no explicit reference was found in the text == Unused Reference: 'IF-MAP-SOAP' is defined on line 2306, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-06 == Outdated reference: A later version (-10) exists of draft-ietf-sacm-use-cases-09 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5070 (Obsoleted by RFC 7970) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SACM J. Salowey 3 Internet-Draft Tableau Software 4 Intended status: Standards Track L. Lorenzin 5 Expires: October 31, 2015 C. Kahn 6 Pulse Secure 7 S. Pope 8 S. Appala 9 A. Woland 10 N. Cam-Winget, Ed. 11 Cisco Systems 12 April 29, 2015 14 XMPP Protocol Extensions for Use in SACM Information Transport 15 draft-salowey-sacm-xmpp-grid-02 17 Abstract 19 This document defines a transport protocol for use with the Security 20 Automation and Continuous Monitoring (SACM) Architecture. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 31, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Glossary of Terms . . . . . . . . . . . . . . . . . . . . 3 58 1.2. What is XMPP-Grid? . . . . . . . . . . . . . . . . . . . 6 59 1.3. Overview of XMPP-Grid . . . . . . . . . . . . . . . . . . 6 60 1.4. Benefits of XMPP-Grid . . . . . . . . . . . . . . . . . . 9 61 1.5. Example Workflow . . . . . . . . . . . . . . . . . . . . 10 62 2. Applicability of XMPP-Grid to SACM Use Cases . . . . . . . . 12 63 2.1. Applicability of XMPP-Grid to SACM Usage Scenarios . . . 12 64 2.1.1. SACM Definition and Publication of Automatable 65 Configuration Checklists . . . . . . . . . . . . . . 12 66 2.1.2. SACM Automated Checklist Verification . . . . . . . . 13 67 2.1.3. SACM Detection of Posture Deviations . . . . . . . . 13 68 2.1.4. SACM Endpoint Information Analysis and Reporting . . 14 69 2.1.5. SACM Asynchronous Compliance/Vulnerability Assessment 70 at Ice Station Zebra . . . . . . . . . . . . . . . . 14 71 2.1.6. SACM Identification and Retrieval of Guidance . . . . 14 72 2.1.7. SACM Guidance Change Detection . . . . . . . . . . . 15 73 3. XMPP-Grid Architecture . . . . . . . . . . . . . . . . . . . 15 74 3.1. XMPP Overview . . . . . . . . . . . . . . . . . . . . . . 16 75 3.2. XMPP-Grid Protocol Extensions to XMPP . . . . . . . . . . 17 76 3.3. XMPP-Grid Controller Protocol Flow . . . . . . . . . . . 18 77 3.4. XMPP-Grid Node Connection Protocol Flow . . . . . . . . . 20 78 3.4.1. Authentication . . . . . . . . . . . . . . . . . . . 20 79 3.4.2. Registration . . . . . . . . . . . . . . . . . . . . 20 80 3.4.3. Authorization . . . . . . . . . . . . . . . . . . . . 23 81 3.5. XMPP-Grid Topics Protocol Flow . . . . . . . . . . . . . 26 82 3.5.1. Topic Versioning . . . . . . . . . . . . . . . . . . 27 83 3.5.2. Topic Discovery . . . . . . . . . . . . . . . . . . . 27 84 3.5.3. Subtopics and Message Filters . . . . . . . . . . . . 27 85 3.6. XMPP-Grid Protocol Details . . . . . . . . . . . . . . . 30 86 4. XMPP-Grid Compatibility with IF-MAP Information Model . . . . 36 87 4.1. MAP Server as XMPP-Grid Subscriber for Metadata 88 Aggregation . . . . . . . . . . . . . . . . . . . . . . . 38 89 4.2. MAP Server as XMPP-Grid Publisher for Metadata 90 Dissemination . . . . . . . . . . . . . . . . . . . . . . 40 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 40 93 6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 41 94 6.1.1. Network . . . . . . . . . . . . . . . . . . . . . . . 41 95 6.1.2. XMPP-Grid Nodes . . . . . . . . . . . . . . . . . . . 41 96 6.1.3. XMPP-Grid Controller . . . . . . . . . . . . . . . . 41 97 6.1.4. Certification Authority . . . . . . . . . . . . . . . 42 98 6.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 42 99 6.2.1. Network Attacks . . . . . . . . . . . . . . . . . . . 42 100 6.2.2. XMPP-Grid Nodes . . . . . . . . . . . . . . . . . . . 43 101 6.2.3. XMPP-Grid Controllers . . . . . . . . . . . . . . . . 44 102 6.2.4. Certification Authority . . . . . . . . . . . . . . . 45 103 6.3. Countermeasures . . . . . . . . . . . . . . . . . . . . . 46 104 6.3.1. Securing the XMPP-Grid Transport Protocol . . . . . . 46 105 6.3.2. Securing XMPP-Grid Nodes . . . . . . . . . . . . . . 47 106 6.3.3. Securing XMPP-Grid Controllers . . . . . . . . . . . 48 107 6.3.4. Limit on search result size . . . . . . . . . . . . . 49 108 6.3.5. Cryptographically random session-id and 109 authentication checks for ARC . . . . . . . . . . . . 49 110 6.3.6. Securing the Certification Authority . . . . . . . . 49 111 6.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 50 112 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 50 113 8. Evolution of XMPP-Grid . . . . . . . . . . . . . . . . . . . 51 114 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 115 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 116 10.1. Normative References . . . . . . . . . . . . . . . . . . 51 117 10.2. Informative References . . . . . . . . . . . . . . . . . 52 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 120 1. Introduction 122 This document describes the extensions made to Extensible Messaging 123 and Presence Protocol (XMPP) [RFC6120]that enables use of XMPP as a 124 transport protocol for collecting and distributing security telemetry 125 information between and among network platforms, endpoints, and most 126 any network connected device. Proposed use of this transport 127 protocol is for serving use-cases outlined by the Security Automation 128 and Continuous Monitoring (SACM) working group with the IETF. 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 Many of the terms used in this document are defined in 135 [I-D.ietf-sacm-terminology] and new ones referenced in this draft. 137 This document is being discussed on the sacm@ietf.org mailing list. 139 1.1. Glossary of Terms 141 AAA 143 Authentication, Authorization and Accounting. 145 CA 147 Certification Authority. 149 Capability Provider 151 Providers who are capable of sharing information on XMPP-Grid. 153 CMDB 155 Configuration Management Database. 157 IDS 159 Intrusion Detection System. 161 IPS 163 Intrusion Prevention System. 165 JID 167 Jabber Identifier, native address of an XMPP entity. 169 MDM 171 Mobile Device Management. 173 NAC 175 Network Admission Control. 177 PDP 179 Policy Decision Point. 181 PEP 183 Policy Enforcement Point. 185 Presence 187 XMPP-Grid node availability and online status on XMPP-Grid. 189 Publisher 191 A capability provider sharing contet information to other devices 192 participating on XMPP-Grid. 194 SIEM 196 Security Information and Event Management. 198 Subscriber 200 A device participating in XMPP-Grid and subscribing or consuming 201 information published by Publishers on XMPP-Grid. 203 Sub-Topics 205 Topic created by XMPP-Grid Controller under a capability 206 provider's topic based on message filter criteria expressed by 207 subscribers. 209 Topics 211 Contextual information channel created on XMPP-Grid where a 212 published message by the Publisher will be propagated by XMPP in 213 real-time to a set a subscribed devices. 215 VoIP 217 Voice over IP. 219 XMPP-Grid 221 Set of standards-based XMPP messages with extensions, intended for 222 use as a transport and communications protocol framework between 223 devices forming an information grid for serving SACM use-cases. 225 XMPP-Grid Controller 227 Centralized component of XMPP-Grid responsible for managing all 228 control plane operations. 230 XMPP-Grid Connection Agent 232 XMPP-Grid client library that a XMPP-Grid node implements to 233 connect and exchange information with other vendor devices on 234 XMPP-Grid. 236 XMPP-Grid Node 238 Platform or device that implements XMPP-Grid Connection Agent to 239 connect to XMPP-Grid and share or consume security data. 241 1.2. What is XMPP-Grid? 243 XMPP-Grid is a set of standards-based XMPP messages with extensions. 244 It is intended for use as a transport and communications protocol 245 framework for devices that interconnect with each other, forming an 246 information grid for serving SACM use-cases. 248 XMPP-Grid enables secure, bi-directional multi-vendor exchange of 249 contextual information between IT infrastructure platforms such as 250 security monitoring and detection systems, network policy platforms, 251 asset and configuration management, identity and access management 252 platforms. XMPP-Grid can serve to exchange any contextual security 253 information, the relevance and scope for SACM is to use XMPP-Grid to 254 exchange Posture Assessment Information; thus this draft shall use 255 the terms interchangeably. XMPP-Grid is built on top of XMPP 256 [RFC6120], [RFC6121] which is an open IETF standard messaging routing 257 protocol used in commercial platforms such as Google Voice, Jabber 258 IM, Microsoft Messenger, AOL IM and a variety of IoT and XML message 259 routing services. XMPP is also being considered as a means to 260 transport IODEF [RFC5070]. XMPP-Grid is designed for orchestration 261 of data sharing between security platforms on a many-to-many basis 262 for millions of end systems. 264 XMPP-Grid provides a security data sharing framework that enables 265 multiple vendors to integrate to XMPP-Grid once, then both share and 266 consume data bi-directionally with many IT infrastructure platforms 267 and applications from a single consistent framework akin to a 268 network-wide information bus. This reduces the need to develop to 269 explicit, multiple platform-specific interfaces, thereby increasing 270 the breadth of platforms that can interface and share security data. 271 XMPP-Grid is also configurable thereby enabling partners to share 272 only security data they want to share and consume only information 273 relevant to their platform or use-case and to customize information 274 shared without revising the interfaces. XMPP-Grid is data-agnostic 275 enabling it to operate with virtually any data type or information 276 model, but does offer optional interoperability with the Interface 277 for Metadata Access Points (IF-MAP) [IF-MAP] or with IODEF, which are 278 commonly used information repositories for security data sharing. 280 1.3. Overview of XMPP-Grid 282 XMPP-Grid employs publish/subscribe/query operations brokered by a 283 controller, which enforces access control in the system. This 284 architecture controls what platforms can connect to the "grid" to 285 share ("publish") and/or consume ("subscribe" or "query") contextual 286 information ("Topics") (described in Section 3.3 and 3.5) such as 287 security data needed to support SACM use-cases. The control of 288 publish/subscribe/query operations is architecturally distinct from 289 the actual sharing of the contextual information. Control functions 290 are split into a logical control plane, whereas information exchange 291 is considered a logical data plane. This separation enables 292 scalability and customizability. 294 XMPP-Grid defines an infrastructure protocol that hides the nuances 295 of the XMPP data plane protocol and makes the information sharing 296 models extensible with simple intuitive interfaces. XMPP-Grid Nodes 297 connect to the Grid using the XMPP-Grid Protocol. The XMPP-Grid 298 Protocol makes use of the XMPP transport protocol and introduces an 299 application layer protocol leveraging XML and XMPP extensions to 300 define the protocol. 302 The components of XMPP-Grid are: 304 o XMPP-Grid Controller (Controller): The Controller manages the 305 control plane of XMPP-Grid operations. As such it authenticates 306 and authorizes platforms connecting to the data exchange grid and 307 controls whether or not they can publish, subscribe or query 308 Topics of security data. 310 o XMPP-Grid Connection Agent (Connection Agent): The Connection 311 Agent enables the adopting Node to communicate with the Controller 312 and other vendor platforms that have adopted XMPP-Grid. Through 313 this communication privileges of the connecting platform-- 314 authorization to connect, publish, subscribe, query--are 315 established. The Connection Agent is typically implemented as a 316 client library. 318 o XMPP-Grid Node (Node): A Node is a platform that has implemented 319 the Connection Agent so that it can connect to an XMPP-Grid 320 deployment to share and/or consume security data. 322 o Data Repository: This is the source of security data available on 323 the Grid and may be a network security platform, management 324 console, endpoint, etc. XMPP-Grid does not mandate a specific 325 information model, but instead remains open to transport 326 structured or unstructured data. Data may be supplied by the 327 security platform itself or by an external information repository. 329 o Topic: An XMPP-Grid Topic defines a type of security data that a 330 platform wants to share with other platform(s). 332 The operations carried out by XMPP-Grid to exchange security data 333 are: 335 o Grid Connect: This is a Controller operation that authenticates a 336 Node that has implemented the Connection Agent to establish a 337 connection with the XMPP-Grid. Once authenticated, authorization 338 policies on the Controller establish a Node's privileges on the 339 XMPP-Grid such as the right to undertake publish, subscribe or 340 query operations explained below. 342 o Publish Topic: Security information is made available when a XMPP- 343 Grid enabled platform "publishes" a "Topic". This operation is 344 authorized by the Controller and communicated to the connecting 345 platform via the Connection Agent. 347 o Topic Discovery: Nodes on a XMPP-Grid discover Topics of security 348 data relevant to them by searching the Topic directory available 349 within the XMPP-Grid deployment. The Controller maintains such a 350 Topic directory for every instance of XMPP-Grid. 352 o Subscribe to Topic: A Node seeking to consume security information 353 "subscribes" to a Topic that provides the security information it 354 seeks to serve its use-case. This operation has its authorization 355 checked by the Controller and communicated with the connecting 356 platform via the Connection Agent. 358 o Query: This operation enables a Node to request a specific set of 359 security data regarding a specific asset (such as a specific user 360 endpoint) or bulk output history from a Topic over a specific span 361 of time. Such queries can be carried out node-to-node or by 362 querying a central data repository. Query structure is adaptable 363 to match the information model in use. 365 XMPP-Grid is used to exchange security context data between systems 366 on a 1-to-1, 1-to-many, or many-to-many basis. Security data shared 367 between these systems may use pre-negotiated non-standard/native data 368 formats or may utilize an optional common information repository with 369 a standardized data format, as may be specified by SACM. XMPP-Grid 370 is data format agnostic and accommodates transport of whatever format 371 the end systems agree upon. 373 XMPP-Grid can operate in the following deployment architectures: 375 o Broker-Flow: An XMPP-Grid control plane brokers the authorization 376 and redirects the Topic subscriber to Topic publisher directly. 377 In this architecture, the Controller only manages the connection; 378 the security data flow is directly between Nodes using data 379 formats negotiated out-of-band. 381 o Centralized Data-Flow: An XMPP-Grid maintains the data within its 382 optional centralized database. In this architecture, the 383 Controller provides a common information structure for use in 384 formatting and storing security context data, such as IF-MAP, and 385 directly responds to Node publish and Subscribe requests. 387 o Proxy-Flow: An XMPP-Grid is acting as proxy, collecting the data 388 from the publisher(s) and presenting it to the subscriber 389 directly. This is used for ad-hoc queries. 391 Within the deployment architecture, XMPP-Grid may be used in any 392 combination of the following data exchange modes. The flexibility 393 afforded by the different modes enables security information to be 394 exchanged between systems in the method most suitable for serving a 395 given use-case. 397 o Continuous Topic update stream: This mode delivers in real-time 398 any data published to a Topic to the Nodes that are subscribed to 399 that Topic. 401 o Directed query: This mode enables Nodes to request a specific set 402 of security information regarding a specific asset, such as a 403 specific user endpoint. 405 o Bulk historic data query: This mode enables Nodes to request 406 transfer of past output from a Topic over a specific span of time. 408 1.4. Benefits of XMPP-Grid 410 Benefits of XMPP-Grid can be summarized on two fronts: 1) end-user 411 benefits, 2) benefits for adopting vendors. 413 Benefits for end-users deploying security services based on XMPP-Grid 414 security context information sharing capabilities are derived from 415 the results that come with standardization including: 417 o Consolidating relevant security event data from multiple systems 418 to the "right console at the right time". 420 o Cross-vendor interoperability out-of-the-box, when using a 421 standard data format. 423 o Coordinated security response across multiple products from 424 multiple vendors, ranging from endpoint security to AAA, NAC, IDS/ 425 IPS, Data Loss Prevention, firewalls to infrastructure such as 426 SIEM, CMDB, physical access control systems. 428 o Customer product choice and flexibility. No need to buy all 429 security products from one vendor. 431 Adopting XMPP-Grid security data sharing capabilities provides a 432 number of benefits for adopting vendors, especially when compared to 433 proprietary interfaces, such as: 435 o Integrate the XMPP-Grid Connection Agent once to interface with 436 many platforms, simultaneously by subscribing or publishing 437 relevant security data 439 o Security information shared is configurable (via Topics) based on 440 relevance to specific use-cases and platforms 442 o Only sharing relevant data enables both publishing and subscribing 443 platforms to scale their security data sharing by eliminating 444 excess, irrelevant data 446 o Integrated authorization and security ensures only appropriate 447 XMPP-Grid operations are executed by permitted platforms 449 o Ability to share security data in native or structured formats 450 enables data model flexibility for adopting vendors 452 o Flexibility, adaptability to evolve to address new use cases over 453 time. Utilize data-agnostic transport protocol or the extensible 454 schema that allows for easy support for vendor-specific data. 456 1.5. Example Workflow 457 ______________ 458 | XMPP-Grid | 459 Authorize /| Controller |\Authorize 460 / |____________| \ 461 ________/ ^ \_________ 462 "I have location" |Location| | | APP |"I have app info" 463 "I need app & ID.."|________|\ | /|________|"I need loc & dev" 464 \ | / 465 _\___|_____/_____ 466 |Continuous Flow| 467 <-----|---------------|------> 468 | Directed Query| 469 --/------|-----\- 470 / | \ 471 / | \ 472 __________/ | \__________ 473 "I have sec events"| SIEM | V | PAP |"I have ID & dev-type" 474 "I need ID & dev"|________| ______________ |________|"I need loc & MDM" 475 | Device Mgr | 476 |____________| 477 "I have MDM Info!" 478 "I need location..." 480 Figure 1: Typical XMPP-Grid Workflow 482 a. XMPP-Grid Controller establishes a grid for platforms wanting to 483 exchange security data. 485 b. A platform (Node) with a source of security data requests 486 connection to the Grid. 488 c. Controller authenticates and establishes authorized privileges 489 (e.g. privilege to publish and/or subscribe to security data 490 Topics) for the requesting Node. 492 d. Node may either publish a security data Topic, subscribe to a 493 security data Topic, query a Node or Topic, or any combination of 494 these operations. 496 e. Publishing Nodes unicast Topic updates to the Grid in real-time. 497 The Grid handles replication and distribution of the Topic to 498 subscribing Nodes. A Node may publish multiple Topics, thereby 499 allowing for customized relevance of the security data shared. 501 f. Subscribing Nodes receive continuous real-time stream of updates 502 to the Topic to which they are subscribed. 504 g. Any Node on the Grid may subscribe to any Topics published to the 505 Grid (as permitted by authorization policy), thereby allowing for 506 one-to-one, one-to-many and many-to-many meshed security data 507 sharing between Nodes. 509 2. Applicability of XMPP-Grid to SACM Use Cases 511 This section discusses the applicability of XMPP-Grid to the usage 512 scenarios defined in [I-D.ietf-sacm-use-cases]. 514 Within the SACM use-cases, the working group has outlined four use- 515 cases and seven usage-scenarios. XMPP-Grid is applicable to each one 516 of the use-cases and usage-scenarios by following one of the three 517 main logical flows of XMPP-Grid as outlined in section 1.1.1. The 518 three flows are summarized here: 520 o Broker-Flow: XMPP-Grid brokers the authorization and redirects the 521 Topic subscriber to Topic publisher directly. 523 o Centralized Data-Flow: XMPP-Grid is maintaining the data within 524 its optional centralized database. 526 o Proxy-Flow: XMPP-Grid is acting as proxy, collecting the data from 527 the publisher(s) and presenting it to the subscriber directly. 528 This is used for ad-hoc queries. 530 Each of the seven defined usage-scenarios is listed below, along with 531 a summary of how XMPP-Grid is applicable to each use-case. 533 It is important to note that XMPP-Grid is data model agnostic, and 534 may use any information model to structure data between systems. The 535 most common standardized security information model deployed 536 currently is IF-MAP, which XMPP-Grid interoperates with today. 538 2.1. Applicability of XMPP-Grid to SACM Usage Scenarios 540 2.1.1. SACM Definition and Publication of Automatable Configuration 541 Checklists 543 XMPP-Grid is fully applicable to the usage-scenario 2.2.1 as defined 544 within the SACM use-cases document. As a vendor creates a new guide, 545 they would publish an entry describing the existence of the checklist 546 to the applicable Topic within XMPP-Grid. For the purposes of this 547 explanation, the Topic name will be "Guide". 549 Grid Nodes who are subscribed to the Topic, will receive the 550 notification of the Topic update. In response or on-demand, the Node 551 will query XMPP-Grid in order to initiate the downloading of the new 552 guide(s). The Grid Controller authorizes the download and proceeds 553 to retrieve the guide(s) from the publisher, and transfers that 554 download to the subscriber. 556 Similarly, when an administrator publishes a new checklist, they 557 would publish an entry describing the existence of the checklist to 558 the applicable Topic within XMPP-Grid. For the purposes of this 559 explanation, the Topic name will be "Checklist". 561 Grid Nodes who are subscribed to the Topic, will receive the 562 notification of the Topic update. In response or on-demand, the 563 participating entity will query XMPP-Grid in order to initiate the 564 downloading of the new checklist(s). The Grid Controller authorizes 565 the download and proceeds to retrieve the checklist(s) from the 566 publisher, and transfers that download to the subscriber. This is an 567 example of XMPP-Grid in Proxy-Flow mode. 569 2.1.2. SACM Automated Checklist Verification 571 An Endpoint Management System (EMS) publishes a Topic to XMPP-Grid 572 defining itself as an owner of Endpoint Data. Other network services 573 that are interested in endpoint data may subscribe to the Topic on 574 Endpoint Data, which is authorized by the XMPP-Grid. 576 A Baseline Service is subscribed to the Endpoint Data Topic, and has 577 a need for that updated endpoint data. The Baseline Service 578 (subscriber) requests the data from the XMPP-Grid, which authorizes 579 the retrieval and informs the subscriber of the existence of data on 580 the EMS directly. In this instance, the data transfer has been 581 authorized and occurs directly between the subscriber and the EMS. 583 The subscriber has now created new checklists and published the 584 information to the checklist Topic in XMPP-Grid. A PDP is subscribed 585 to the Checklist Topic, and is notified of the new checklists. The 586 PDP requests the data from the XMPP-Grid, which in-turn authorizes 587 the download and brokers the direct communication between the 588 Baseline Service and the PDP Directly. 590 This usage scenario is an example of XMPP-Grid in the Broker-Flow. 591 It is also showing that single entities may act as both publisher and 592 subscriber with the XMPP-Grid simultaneously. 594 2.1.3. SACM Detection of Posture Deviations 596 A user disables the firewall on a managed endpoint, which in-turn 597 sends a notice to its managing Compliance Service. The Compliance 598 Service publishes and alert to the "Alert Topic" in XMPP-Grid. There 599 is an Assessment Service, which subscribes to the Alert Topic, and is 600 therefore notified of the alert. The Assessment service consumes 601 that alert directly from the XMPP-Grid and triggers an immediate 602 assessment of the endpoint. 604 This is an example of XMPP-Grid centralized-data flow. While XMPP- 605 Grid is information model agnostic, in this scenario IF-MAP could be 606 used as the centralized data repository with XMPP-Grid providing the 607 transport in/out of the IF-MAP database.. 609 2.1.4. SACM Endpoint Information Analysis and Reporting 611 There are endpoints that are uploading large quantities of data to a 612 Suspicious Server on Internet. The admin queries XMPP-Grid for the 613 posture of the endpoints. The XMPP-Grid responds with all the 614 publishers of that information along with the authorization to query 615 for the data. The admin application is now able to query the data 616 sources directly, which indicates that the applicable endpoints all 617 have certain applications installed. The admin is now able to pivot 618 the query and receive information on all other endpoints that have 619 the same application installed. 621 This usage scenario is an example of XMPP-Grid Broker-Flow. 623 2.1.5. SACM Asynchronous Compliance/Vulnerability Assessment at Ice 624 Station Zebra 626 A University Team at Ice Station Zebra registers their Equipment with 627 an Asset Management System. The university puts together a 628 collection request for all deployed assets, and sends the query to 629 the XMPP-Grid. The collection request is queued at the XMPP-Grid for 630 the next window of connectivity when the request is sent to the 631 deployed assets. The remote endpoints fulfill the request and queue 632 the results for the next return opportunity. The results are sent 633 back to the university, where they are compared against what is in 634 the Asset Management System already. 636 This is an example of XMPP-Grid centralized-data flow. While XMPP- 637 Grid is information model agnostic, in this scenario IF-MAP could be 638 used as the centralized data repository with XMPP-Grid providing the 639 transport in/out of the IF-MAP database. 641 2.1.6. SACM Identification and Retrieval of Guidance 643 There are multiple configuration services in the environment, each 644 populating a "guide" Topic in XMPP-Grid. The operator queries XMPP- 645 Grid in order to discover and consolidate a single list to be 646 compared. The XMPP-Grid replies with list of data stores, and 647 authorization to perform the queries directly to those data stores. 649 As the Admin/Operator defines search criteria, the operator is able 650 to query the data stores directly for that content, only returning to 651 the centralized XMPP-Grid when authorization is required. 653 This usage scenario is an example of XMPP-Grid in the Broker-Flow 655 2.1.7. SACM Guidance Change Detection 657 An Operator identifies content that they desire to assess, and 658 subscribes to that content Topic with XMPP-Grid. When a change to 659 that content occurs, the Operator is notified. Additionally, the 660 operator may be sent a query response. Any Data Collection and 661 evaluation Activities will also trigger an update to the operator 662 (subscriber). 664 This usage scenario is an example of XMPP-Grid centralized-data flow. 665 While XMPP-Grid is information model agnostic, in this scenario IF- 666 MAP could be used as the centralized data repository with XMPP-Grid 667 providing the transport in/out of the IF-MAP database. 669 3. XMPP-Grid Architecture 671 XMPP-Grid is a communication fabric that facilitates secure sharing 672 of information between network elements and networked applications 673 connected to the fabric both in real time and on demand. 675 XMPP-Grid uses XMPP servers that operate as a cluster with message 676 routing between them, for data plane communication. XMPP-Grid uses a 677 control plane element, the XMPP-Grid Controller, that is an external 678 component of XMPP for centralized policy-based control plane. 680 --------------- --------------- --------------- 681 | XMPP-Grid | | XMPP-Grid | | XMPP-Grid | 682 | Controller | | Controller | | Controller | 683 | | | | | | 684 --------------- --------------- --------------- 685 | | | 686 | | | 687 --------------- --------------- --------------- 688 | XMPP Server | | XMPP Server | | XMPP Server | 689 | |---------| |--------| | 690 | | | | | | 691 --------------- --------------- --------------- 693 Figure 2: XMPP Server and XMPP-Grid Cluster Architecture 694 The connected Nodes, with appropriate authorization privileges, can: 696 o Receive real-time events of the published messages from the 697 publisher through Topic subscriptions 699 o Make directed queries to other Nodes in the XMPP-Grid with 700 appropriate authorization from the Controller 702 o Negotiate out-of-band secure file transfer channel with the peer 704 This model enables flexible API usage depending on the Nodes' 705 contextual and time-sensitivity needs of security information. 707 3.1. XMPP Overview 709 XMPP is used as the foundation message routing protocol for 710 exchanging security data between systems across XMPP-Grid. XMPP is a 711 communications protocol for message-oriented middleware based on XML. 712 Designed to be extensible, the protocol uses de-centralized client- 713 server architecture where the clients connect to the servers securely 714 and the messages between the clients are routed through the XMPP 715 servers deployed within the cluster. XMPP has been used extensively 716 for publish-subscribe systems, file transfer, video, VoIP, Internet 717 of Things, Smart Grid Software Defined Networks (SDN) and other 718 collaboration and social networking applications. The following are 719 the 4 IETF specifications produced by XMPP working group: 721 o [RFC6120] Extensible Messaging and Presence Protocol (XMPP): Core 723 o [RFC6121] Extensible Messaging and Presence Protocol (XMPP): 724 Instant Messaging and Presence 726 o [RFC3922] Mapping the Extensible Messaging and Presence Protocol 727 (XMPP) to Common Presence and Instant Messaging (CPIM) 729 o [RFC3923] End-to-End Signing and Object Encryption for the 730 Extensible Messaging and Presence Protocol (XMPP) 732 XMPP offers several of the following salient features for building a 733 security data interexchange protocol: 735 o Open - standards-based, decentralized and federated architecture, 736 with no single point of failure 738 o Security - Supports domain segregations and federation. Offers 739 strong security via Simple Authentication and Security Layer 740 (SASL) [RFC4422] and Transport Layer Security (TLS) [RFC5246]. 742 o Real-time event management/exchange - using publish, subscribe 743 notifications 745 o Flexibility and Extensibility - XMPP is XML based and is easily 746 extensible to adapt to new use-cases. Custom functionality can be 747 built on top of it. 749 o Multiple information exchanges - XMPP offers multiple information 750 exchange mechanisms between the participating clients - 752 o 754 * Real-time event notifications through publish and subscribe. 756 * On-demand or directed queries between the clients communicated 757 through the XMPP server 759 * Facilitates out-of-band, direct communication between 760 participating clients 762 o Bi-directional - avoids firewall tunneling and avoids opening up a 763 new connection in each direction between client and server. 765 o Scalable - supports cluster mode deployment with fan-out and 766 message routing 768 o Peer-to-peer communications also enables scale - directed queries 769 and out-of-band file transfer support 771 o XMPP offers Node availability, Node service capability discovery, 772 and Node presence within the XMPP network. Nodes ability to 773 detect the availability, presence and capabilities of other 774 participating nodes eases turnkey deployment. 776 The XMPP extensions used in XMPP-Grid are now part (e.g. publish/ 777 subscribe) of the main XMPP specification [RFC6120] and the presence 778 in [RFC6121]. A full list of XMPP Extension Protocols (XEPs) 779 [RFC6120] can be found in http://xmpp.org/extensions/xep-0001.html . 781 3.2. XMPP-Grid Protocol Extensions to XMPP 783 XMPP-Grid defines an infrastructure protocol that hides the nuances 784 of the XMPP data plane protocol and makes the information sharing 785 models extensible with simple intuitive APIs. XMPP-Grid Nodes 786 connect to the Grid using the XMPP-Grid Protocol. The XMPP-Grid 787 Protocol makes use of the XMPP transport protocol and introduces an 788 application layer protocol leveraging XML and XMPP extensions to 789 define the protocol. The capability providers on the Grid extend the 790 XMPP-Grid Protocol infrastructure model and define capability 791 specific models and schemas, allowing a cleaner separation of 792 infrastructure and capabilities that can run on the infrastructure. 794 3.3. XMPP-Grid Controller Protocol Flow 796 At the heart of the XMPP-Grid network, the XMPP-Grid Controller 797 serves as the centralized policy-based control plane element managing 798 all Node authentications, authorizations, capabilities/Topics and 799 their subscription list. XMPP-Grid Controller manages all control 800 aspects of the Node communication (including management) with the 801 XMPP-Grid and other participating Nodes with mutual trust and 802 authorizations' enforcement. XMPP-Grid Controller is a component of 803 XMPP server and programs the data plane XMPP server with Node 804 accounts, account status, XMPP Topics that are dynamically created 805 and Topic subscriptions. This is analogous to File Transfer Protocol 806 (FTP) that has control and data plane communication phases. Once the 807 Node requests are authenticated and authorized in the control plane 808 phase by the Controller, the Controller removes itself from the data 809 flow. All data plane communication then occurs between the Nodes, 810 publishers and subscribers of XMPP Topics happen at the XMPP data 811 plane layer. 813 ---------------- ---------------- ---------------- 814 | Publi- | Node | | Grid | XMPP | | Node | Sub- | 815 | sher |client| | Ctrlr | Srvr | |client| scriber| 816 | | | | | | | | | 817 ----------------- ----------------- ----------------- 818 | Authen & allow Grid Ctrlr Comm | | 819 |<------------------------------>| | 820 | | | | 821 | |Publisher | | 822 | | Auth | | 823 | | Status | | 824 | |<---------| | 825 | | | | 826 | | | Authen & allow Grid Ctrlr | 827 | | | Communication | 828 | | |<------------------------->| 829 | | | | 830 | |Subscriber| | 831 | | Auth | | 832 | | Status & | | 833 | | Account | | 834 | |<---------| | 835 | | | | 836 | Author Publisher to | | | 837 | Topic Sequence | | | 838 --- |<------------------->| | | 839 C | | | | | 840 O | | | Add | | 841 N | | |Publisher | | 842 T | | | to Topic | | 843 R | | |--------->| | 844 O | | | | | 845 L | | | Author Subscriber to Topic Sequence | 846 --- | |<------------------------------------>| 847 | | | | 848 | | Add | | 849 | |Subscriber| | 850 | | to Topic | | 851 | |--------->| | 852 ---------------------------------------------------------------------- 853 | | | | 854 | Publish Message to Topic | | 855 --- |-------------------------------->| | 856 | | | | | 857 I | | Publish Success Published Message to Subscriber | 858 N | |<----------------------------------------------------------->| 859 F | | | | | 860 R | | | | Subscribe Success | 861 A | | | |<--------------------------| 862 | | | | | 863 --- | | Topic & Publisher Discovery Request | 864 | |<-------------------------------------| 865 | | | | 866 | | Topic & Publisher JID Response | 867 | |------------------------------------->| 868 | | | | 869 | | Out-of-Band Bulk Dnld Query Reqeust | 870 | |<-------------------------------------| 871 | | | | 872 | | Out-of-Band Bulk Dnld Query Author | 873 | |------------------------------------->| 874 | | | 875 | Out-of-Band Data Bulk Byte Stream | 876 |<----------------------------------------------------------->| 878 Figure 3: XMPP Controller Message Flow 880 Through a centralized authorization model, XMPP-Grid Controller 881 provides - 882 o Visibility into "who is connecting", "who is accessing what" 884 o Node account management with provisions to add, delete or disable 885 accounts, and with provisions to auto or manual approve Node 886 account approval requests during the Node registration phase 888 o Centralized, policy-based authorization, providing "who can do 889 what" for publish-subscribe, directed peer-to-peer queries or for 890 bulk out-of-band transfers between participating Nodes 892 o Topics and subscription list management with provision to enable 893 or disable Topics 895 o Dynamic creation of sub-Topics within the main Topic depending on 896 attributes of interest from the requesting Node 898 o Ability to perform message filters on the published messages 900 3.4. XMPP-Grid Node Connection Protocol Flow 902 Nodes connecting to XMPP-Grid go through the phases of 903 authentication, registration and authorization before they can 904 participate in information exchange on XMPP-Grid. 906 3.4.1. Authentication 908 The communication between the Node and the XMPP-Grid Controller is 909 cryptographically encrypted using TLS. XMPP-Grid uses X.509 910 certificate-based mutual authentication between the Nodes and 911 Controller. Internally, XMPP uses Simple Authentication and Security 912 Layer (SASL)[RFC4422] External mechanism to authenticate and 913 establish secure tunnel with the Nodes, allowing the XMPP-Grid 914 Controller to rely on this capability offered by XMPP. If the Node 915 certificate does not pass the validation process, the connection 916 establishment is terminated with the error messages defined by the 917 XMPP standard. On successful authentication, XMPP SASL component 918 extracts the Node certificate and Node username to the Controller for 919 registration. 921 3.4.2. Registration 923 Once a Node has been authenticated and a secure tunnel has been 924 successfully established, the Nodes will register their accounts with 925 the Controller and Nodes provide their username to the Controller as 926 part of the registration request. XMPP-Grid supports manual 927 registration (requires explicit approval of the Node account) and 928 mutual authentication trust-based auto-approval registration in order 929 to provide additional trust and usability options to the 930 administrator. The administrator may map the Nodes to the Node 931 groups to add additional level of validation and trust, and enforce 932 Node group based authorization. This allows the certificate- 933 username-group trust to get uniquely establishment for each Node and 934 duplicate registration requests using the same username will be 935 rejected. 937 During the registration process, the Controller restricts all Node 938 communication with the XMPP-Grid and only Node to Controller 939 communication is allowed. Once the Node is successfully registered, 940 the Controller lifts the restriction and allows the Nodes to 941 communicate on XMPP-Grid after it passes the authorization phase. It 942 should be noted that the registered and authorized Nodes could 943 publish, subscribe or query to multiple XMPP Topics between login and 944 logout to XMPP-Grid. Multiple Node applications running on a Node 945 could use one XMPP-Grid Node to connect to XMPP-Grid. The XMPP-Grid 946 Node should support Node applications' subscription to Topics and 947 should multiplex messages on its connection to XMPP-Grid. If a Node 948 application wants to be identified explicitly on XMPP-Grid, a new 949 XMPP-Grid Node connection to XMPP-Grid is required. 951 ----------------- --------------------------- 952 | | | Grid | XMPP | 953 | Node | | Controller| Server | 954 | | | | | 955 ----------------- --------------------------- 956 | | | 957 _____| | | 958 | | | | 959 Register | | | | 960 |---->| | | 961 | TLS Connect(username, cert) | | 962 |<------------------------------------------------------>| 963 | | | 964 | | Track | 965 | |(username,cert) | 966 | |<---------------| 967 |Register(username) | | 968 |-------------------------------------->| | 969 | |___ | 970 | | | Approve & | 971 | | | Authorize | 972 | |<--| Account | 973 | | | 974 | |Create User | 975 | |Account | 976 | |(username) | 977 | |--------------->| 978 | Registration Successful | | 979 |<--------------------------------------| | 980 | | | 981 | Login() | | 982 |-------------------------------------->| | 983 | | | 984 | Pub/Sub/Query | | 985 |<------------------------------------------------------>| 986 | | | 987 | | | 988 | Logout() | | 989 |-------------------------------------->| | 990 | | | 992 Figure 4: XMPP-Grid Node Registration 994 3.4.3. Authorization 996 The registered Nodes send subscription requests to the Controller. 997 The Controller, depending on the defined authorization privileges, 998 grants permissions to subscribe and/or publish to a Topic at the 999 registration time. The Controller updates the XMPP data plane server 1000 with the new subscriber information and its capability. Node 1001 identity extracted from the request, group to which the Node is 1002 assigned during account approval and Topic/capability to which the 1003 permission is sought could be some of the ways to authorize Nodes and 1004 their requests in XMPP-Grid. Similarly, the Controller authorizes 1005 directed peer-to-peer or out-of-band requests from a requesting peer. 1006 The destination peer has options to query back the Controller to 1007 retrieve and enforce granular authorizations such as read-only, 1008 write-only, read/write. 1010 In a Query Authorization flow, the capability provider responding to 1011 the query is responsible for enforcing the authorization decision. 1012 It retrieves "is authorized" from the XMPP-Grid Controller. Based on 1013 the result, the service either allows or disallows the flow from 1014 continuing. 1016 ----------------- ----------------- ----------------- 1017 | Subscriber | | XMPP-Grid | | Publisher | 1018 | | | | | | 1019 ----------------- ----------------- ----------------- 1020 | | | 1021 | | | 1022 | query request | 1023 |------------------------------------------------->| 1024 | | |____ 1025 | | | | extract 1026 | | | | identity 1027 | | |<--- 1028 | | | 1029 | | is authorized? | 1030 | | (identity, service) | 1031 | |<------------------------| 1032 | | | 1033 | query response | 1034 |<-------------------------------------------------| 1035 | | | 1037 Figure 5: Node Query Authorization Flow 1038 For Publish Authorization, prior to allowing a publish request by a 1039 user, the XMPP-Grid Controller calls the rule evaluation engine 1040 directly for "is authorized". Based this result, the Controller 1041 either allows or disallowed the flow from continuing. 1043 ----------------- ----------------- ----------------- 1044 | Publisher | | XMPP-Grid | | XMPP | 1045 | | | Controller | | Server | 1046 ----------------- ----------------- ----------------- 1047 | | | 1048 | publish | | 1049 |----------------------->|____ | 1050 | | | extract | 1051 | | | identity | 1052 | |<--- | 1053 | | | 1054 | |____ | 1055 | | | is authorized? | 1056 | | | (identity,publish) | 1057 | |<--- | 1058 | | | 1059 | | publish | 1060 | |------------------------>| 1061 | | | 1063 Figure 6: Node Publish Authorization Flow 1065 For Subscribe Authorization, prior to allowing a subscribe request by 1066 a user, the XMPP-Grid Controller calls the rule evaluation engine 1067 directly for "is authorized". Based this result, the Controller 1068 either allows or disallowed the flow from continuing. 1070 ----------------- ----------------- ----------------- 1071 | Subscriber | | XMPP-Grid | | XMPP | 1072 | | | Controller | | Server | 1073 ----------------- ----------------- ----------------- 1074 | | | 1075 | subscribe | | 1076 |----------------------->|____ | 1077 | | | extract | 1078 | | | identity | 1079 | |<--- | 1080 | | | 1081 | |____ | 1082 | | | is authorized? | 1083 | | | (identity,publish) | 1084 | |<--- | 1085 | | | 1086 | | subscribe | 1087 | |------------------------>| 1088 | | | 1090 Figure 7: Node Subscribe Authorization Flow 1092 Bulk Data Query differs from other data transfer modes. Unlike with 1093 other modes of communication that operate in-band with the XMPP-Grid, 1094 bulk downloads occur out-of-band (over a different protocol, outside 1095 of the connection that was established with the XMPP-Grid 1096 Controller). Previously discussed authorization mechanisms are 1097 therefore not appropriate in this context. 1099 ----------------- ----------------- ----------------- 1100 | Subscriber | | XMPP-Grid | | Publisher | 1101 | | | Controller | | | 1102 ----------------- ----------------- ----------------- 1103 | | | 1104 | request | 1105 |------------------------------------------------->| 1106 | | |____ extract 1107 | | | | cert 1108 | | | | chain 1109 | | |<--- 1110 | | is authorized | 1111 | | (cert chain, service) | 1112 | |<------------------------| 1113 | | | 1114 | response | 1115 |<-------------------------------------------------| 1116 | | | 1118 Figure 8: Node Bulk Data Query Flow 1120 Instead the bulk download service sends the certificate chain used by 1121 a Node in the TLS connection to the XMPP-Grid Controller for purposes 1122 of authenticating and authorizing the Node. Upon receiving a request 1123 with a certificate chain, the Controller checks the issuing 1124 certificate against the trust store, looks up the identity associated 1125 with the certificate, evaluates the rules, and returns "is 1126 authorized" to the service. Then the service can either allow or 1127 disallow the flow from continuing. 1129 3.5. XMPP-Grid Topics Protocol Flow 1131 For each capability, XMPP-Grid supports extensibility through XML 1132 schemas where the providers (publishers) of the capabilities define 1133 the schemas for the data exchanged. The capability provider shall 1134 also define the version, the available queries and notifications that 1135 it can support. The capability provider publishes the messages to 1136 one or more XMPP Topics, that it requests XMPP-Grid to create 1137 dynamically, depending on: 1139 a. If the capability provider has mutually exclusive schemas, 1140 different Topics will be created where the capability provider 1141 will be a publisher to each Topic with a separate schema. 1143 b. For a given Topic, if the subscribers wants to receive filtered 1144 attributes or attribute values in capability provider's published 1145 data, XMPP-Grid Controller creates sub Topics to the main Topic 1146 based on the message filters expressed. XMPP-Grid Controller 1147 enrolls the capability provider as the publisher and the 1148 requesting subscribers based on the message filter criteria they 1149 express. The capability provider will be the publisher to both 1150 the main Topic and the sub-Topics. 1152 c. In the case mentioned in (b) above, it is possible for the 1153 capability provider to just publish on the main Topic and have 1154 the XMPP-Grid Controller filter the published messages on the 1155 Controller-side and deliver attributes and attribute values of 1156 interest to the subscribers. Controller-side message filter 1157 application and the specify mechanisms such as XPATH that can be 1158 used for parsing the messages is beyond the scope of this 1159 specification. 1161 3.5.1. Topic Versioning 1163 XMPP-Grid supports versioning to support forward and backward 1164 compatible information models. The providers of capability include 1165 the version number in the messages they publish and the receiving 1166 Nodes can interpret the Topic version and process the attributes 1167 accordingly. The expectation is any new version of a capability must 1168 be of additive updates only. In other words, existing elements and 1169 attributes cannot be changed, only new elements or attributes can be 1170 added. This will enable nodes with older capability be able to 1171 process newer version. The extra new elements or attributes will be 1172 ignored. Instead of using the same Topic for all versions, it is 1173 possible in XMPP-Grid to programmatically create separate Topics for 1174 each version and allow them to be discovered and subscribed by the 1175 Nodes. 1177 In XMPP-Grid, versioning support applies equally to both publish/ 1178 subscribe, directed and out-of-band queries. 1180 3.5.2. Topic Discovery 1182 The Nodes connected to XMPP-Grid can query the Controller and get the 1183 list of all capabilities/Topics running on XMPP-Grid. The XML 1184 samples provided in XMPP-Grid Protocol section above provide 1185 illustrations of Capability Query and Capability Provider Query. 1187 3.5.3. Subtopics and Message Filters 1189 XMPP-Grid supports semantic message filtering for Topics. The 1190 content being published by a provider can be semantically grouped 1191 into categories based on domain, location of endpoints for example. 1192 The provider of a capability specifies whether it supports semantic 1193 filtering or not to the Controller at the subscribe time to the Topic 1194 under consideration. 1196 XMPP-Grid subscribers query the Controller and obtain the filtering 1197 options available for each capability, and express their message 1198 filtering criteria at subscription time. The Controller, for each 1199 unique filter criteria specified by the subscribers, creates a new 1200 sub Topic under the main capability Topic. All the subscribers with 1201 the same filtering criteria will be subscribed to the Subtopic. The 1202 set of filter criteria for a capability will be predefined by the 1203 capability provider and could be based on the well-defined attributes 1204 of the message. 1206 ----------------- --------------------------- -------------- 1207 | | | Grid | XMPP | | Capability | 1208 | Node | | Controller| Server | | Provider | 1209 | | | | | | | 1210 ----------------- --------------------------- -------------- 1211 | | | | 1212 |Subscribe with filter | | 1213 |------------------->|____ | | 1214 | | | translate & | | 1215 | | | validate | | 1216 | |<---- filter | | 1217 | |____ | | 1218 | | | Check if sub-topic | 1219 | | | for filter | | 1220 | |<--- exists | | 1221 | | | | 1222 | |Create subtopic if doesn't exist | 1223 | |--------------------->| | 1224 | | | | 1225 | |Add Pub & Sub to Sub-Topic | 1226 | |--------------------->| | 1227 | | | | 1228 | |Notify Publisher | | 1229 | |------------------------------------->| 1230 | Subscribe Success | | | 1231 |<-------------------| | | 1232 | | | | 1234 Figure 9: Subtopics and Information Filter Subscribe Operations Flow 1236 The publisher will be responsible for applying the filter on the 1237 message and publishing the message on the Topic and the Subtopic 1238 based on the filter criteria. Filtering logic will be on the 1239 publisher, as the publisher understands the message content. XMPP- 1240 Grid fabric is oblivious to the message content. 1242 To avoid proliferation of new Subtopics, the capability provider 1243 could express the configurable limit on the number of Subtopics that 1244 can be created for its capability at registration time. The XMPP- 1245 Grid Controller will perform periodic cleanup of Subtopics whenever 1246 their subscription list reduces to 0. 1248 In XMPP-Grid, message filters are provided to all APIs i.e. publish/ 1249 subscribe and directed query. 1251 ----------------- --------------------------- -------------- 1252 | Capability | | Grid | XMPP | | | 1253 | Provider | | Controller| Server | | Node | 1254 | | | | | | | 1255 ----------------- --------------------------- -------------- 1256 | | | | 1257 | Register as Publisher | | 1258 |------------------->| | | 1259 | |Add Publisher to main | | 1260 | |topic & all subtopics | | 1261 | |--------------------->| | 1262 |Return registration | | | 1263 |success & list of | | | 1264 |subtopics with | | | 1265 |filtering criteria | | | 1266 |<-------------------| | | 1267 | | | | 1268 |Publish message to | | | 1269 |main topic | | | 1270 |------------------->| | | 1271 Check |____ |Publish message to | | 1272 filtering| | |main topic | | 1273 criteria & | |--------------------->| | 1274 identity |<--- | | | 1275 | | | | 1276 |Publish message to | | | 1277 |subtopic that matched filter | | 1278 |------------------------------------------>| | 1279 | | | Notify | 1280 | | |-------------->| 1282 Figure 10: Subtopic Publish Operations Flow 1284 3.6. XMPP-Grid Protocol Details 1286 The XMPP-Grid Protocol provides provides an abstraction layer over 1287 and above XMPP messages with the intent to provide intuitive 1288 interfaces to the Nodes connecting to XMPP-Grid. Nodes connecting to 1289 XMPP-Grid use the following interfaces (provided as XML samples) 1290 offered by XMPP-Grid protocol to connect and participate in 1291 information exchange on XMPP-Grid: 1293 o Register the Node to XMPP-Grid: Node identified as 1294 "Node2@domain.com/mac" sends the following Registration request to 1295 XMPP-Grid controller. 1297 1299 1300 1301 1302 1303 1305 o Node login to XMPP-Grid: The following XML sample shows the Login 1306 request from Node "Node2@domain.com/mac" to XMPP-Grid controller and 1307 Login response returned by the XMPP-Grid controller to the Node. 1309 // Request 1310 1312 1313 1314 1315 1316 1317 1319 // Response 1320 1322 1323 1324 1325 1326 1327 1328 1329 1331 o Node logout from XMPP-Grid: The following XML sample shows the 1332 Logout request sent by Node "Node2@domain.com/mac" to XMPP-Grid 1333 controller. 1335 1337 1338 1339 1340 1341 1342 1344 o Capability Discovery Query: The following XML sample shows the 1345 Capability Discovery query request from Node "Node2@domain.com/mac" 1346 to XMPP-Grid controller. The XMPP-Grid controller returns the list 1347 of capabilities supported by XMPP-Grid and their versions as a 1348 response to the Node's request. 1350 // Request 1351 1353 1354 1356 1357 1359 // Response 1360 1362 1363 1365 1367 0 1368 TrustSecMetaDataCapability-1.0 1369 1.0 1370 1371 1373 0 1374 1375 EndpointProfileMetaDataCapability-1.0 1376 1.0 1377 1378 1380 0 1381 IdentityGroupCapability-1.0 1382 1.0 1383 1384 1386 0 1387 TDAnalysisServiceCapability-1.0 1388 1.0 1389 1390 1392 0 1393 NetworkCaptureCapability-1.0 1394 1.0 1395 1396 1398 0 1399 1400 EndpointProtectionServiceCapability-1.0 1401 1.0 1402 1403 1405 0 1406 1407 GridControllerAdminServiceCapability-1.0 1408 1.0 1409 1410 1412 0 1413 SessionDirectoryCapability-1.0 1414 1.0 1415 1416 1417 1418 1419 o Specific Capability Provider Query: The following XML sample shows 1420 the Capability Provider hostname query request from Node 1421 "Node2@domain.com/mac" to XMPP-Grid controller. XMPP-Grid controller 1422 returns the hostname of the specific Capability Provider as a 1423 response to the Node's request. 1425 // Request 1426 1428 1429 1430 com.domain.ise.session.SessionQuery 1432 1433 1434 1435 1437 // Response 1438 1441 1442 1443 1446 ise@syam-06.domain.com/syam-mac 1447 1448 1449 1450 o Register as a publisher to the Topic: The following XML sample 1451 shows the Register as a Publisher request from a Node 1452 "Node2@domain.com/mac" to XMPP-Grid controller. 1454 1456 1457 1459 1478 1479 1481 1493 1494 1517 1518 1520 1521 user1 1522 1523 1524 1525 1527 // Query Response 1528 1530 1531 1533 1534 user1 1535 1536 1537 User Identity Groups:Employee 1538 1539 Identity 1540 1541 1542 1543 1544 1545 1547 4. XMPP-Grid Compatibility with IF-MAP Information Model 1549 As mentioned throughout this document, XMPP-Grid is information model 1550 and data format agnostic, as it focuses on transport of security 1551 context data. There are, however, deployment scenarios where 1552 accessing data in a common format in a consistent information model 1553 will be required for serving SACM use-cases. The most prevalent 1554 standards-based model for such deployments is IF-MAP, thus an XMPP- 1555 Grid/IF-MAP compatibility discussion is salient for this document. 1557 The Trusted Network Connect Working Group (TNC-WG) has defined an 1558 open solution architecture [IF-MAP] that enables network operators to 1559 enforce policies regarding the security state of endpoints in order 1560 to determine whether to grant access to a requested network 1561 infrastructure. Part of the TNC architecture is IF-MAP, a standard 1562 interface between the Metadata Access Point and other elements of the 1563 TNC architecture. Readers who wish to understand in detail and 1564 implement IF-MAP are encouraged to review the following documents: 1566 o [IF-MAP]Trusted Computing Group, TNC Architecture for 1567 Interoperability, Revision 1.5, May 2012 1569 o [IF-MAP-SOAP]Trusted Computing Group, TNC IF-MAP Binding for SOAP, 1570 Revision 2.2, March 2014 1572 o [IF-MAP-NETSEC]Trusted Computing Group, TNC IF-MAP Metadata for 1573 Network Security, Revision 1.0, August 2010 1575 o [IF-MAP-ICS]Trusted Computing Group, TNC IF-MAP Metadata for ICS, 1576 Security, Revision 1.0, October 2012 1578 From a compatibility perspective, XMPP-Grid can substitute the SOAP- 1579 based IF-MAP standard interface between the MAP server and other 1580 elements in the network, thereby providing the information transport 1581 between IF-MAP clients. This substitution delivers greater 1582 scalability and timely data, as well as backwards compatibility with 1583 IF-MAP deployments. The IF-MAP data data (Topics and Subtopics can 1584 be created based on IF-MAP data models) and operation models 1585 (interfaces, message filters could be defined for the Topics and 1586 Subtopics based on the IF-MAP operations supported for the use-cases 1587 developed for use-cases such as network security can be overlaid on 1588 XMPP-Grid transport thereby achieving model consistency for both IF- 1589 MAP enabled and XMPP-Grid enabled network deployment scenarios. The 1590 MAP Server will be the participant in both the IF-MAP enabled network 1591 and the XMPP-Grid enabled network serving as aggregator and publisher 1592 of information. 1594 IF-MAP Enabled Devices 1595 ____________ ___________ _____________ 1596 |__________|_ | | IF-MAP | Flow | 1597 || _________|_ | |<-------->|Controllers| 1598 || | | IF-MAP | | |___________| 1599 -|_| PDP |<-------->| | 1600 |_________| | | _____________ 1601 | MAP | IF-MAP | | 1602 ____________ | Server |<-------->| Sensors | 1603 |__________|_ | | |___________| 1604 || _________|_ | | _____________ 1605 || | | IF-MAP | | IF-MAP | | 1606 -|_| PEP |<-------->| |<-------->| Others | 1607 |_________| |_________| |___________| 1608 ^ 1609 | 1610 | Grid 1611 XMPP-Grid Enabled Devices | 1612 ____________ _____V_____ _____________ 1613 |__________|_ | | Grid | Flow | 1614 || _________|_ | |<-------->|Controllers| 1615 || | | Grid | | |___________| 1616 -|_| PDP |<-------->| Grid | 1617 |_________| | Server | _____________ 1618 | Cluster | Grid | | 1619 ____________ | |<-------->| Sensors | 1620 |__________|_ | | |___________| 1621 || _________|_ |_________| _____________ 1622 || | | | | 1623 -|_| PEP | GRID | Others | 1624 |_________|<----------------------------->|___________| 1626 Figure 11: XMPP-Grid and IF-MAP Interoperability 1628 The MAP server will be a XMPP-Grid Node connected to the XMPP-Grid 1629 Controller. The MAP server will play the role of subscribers and/or 1630 publishers depending on the MAP graphs and the contextual metadata to 1631 be aggregated and/or published. 1633 4.1. MAP Server as XMPP-Grid Subscriber for Metadata Aggregation 1635 The MAP Server will be a subscriber when aggregating metadata from 1636 various XMPP-Grid-enabled PEPs and PDPs in the network. Topics will 1637 be created in XMPP-Grid depending on the metadata to be aggregated, 1638 how relational or disjoint the metadata types, metadata-identifier 1639 linkages in IF-MAP graph are and the publishers of the data such as 1640 the Access Requestors, PEPs and PDPs. As discussed in the Topics 1641 section earlier, XMPP-Grid provides the ability to the Capability 1642 provider to create main Topics and Subtopics. The MAP server will be 1643 a subscriber to all of the Topics created for such purposes of 1644 aggregation. It is the responsibility of the MAP server to use the 1645 subscribed metadata to build and manage the MAP graphs. 1647 XMPP-Grid architecture allows multiple MAP servers to be subscribers 1648 to the Topics and also other network elements such as Flow 1649 Controllers and Sensors to directly consume information from the 1650 sources. This enables a complete decentralized architecture for IF- 1651 MAP for metadata aggregation where the MAP Server need not always be 1652 the sole publisher of metadata for the MAP graph. With such approach 1653 it will be possible for time-sensitive subscribers to directly 1654 consume information from the sources and use the MAP server for query 1655 and search purposes only, enabling the MAP servers to scale 1656 significantly. This also allows aggregation of metadata based on 1657 domains where MAP server can aggregate and publish metadata based on 1658 domain, and subscribers could use message filters such as domain, 1659 location to receive only metadata of interest to them. 1661 Region 1 Region 2 1662 ___________ ___________ 1663 | | | | 1664 | MAP | | MAP | 1665 | Server | | Server | 1666 ____________ | | | | ___________ 1667 |__________|_ |_________| |_________| _|_________| 1668 || _________|_ ^ ^ _|_________|| 1669 || | | Grid | | Grid | ||- 1670 -|_| PDP |<-----------| |Grid Grid| |----------->| PDP |- 1671 |_________| | | | | |_________| 1672 ____________ __V__V_____ ______V__V__ ___________ 1673 |__________|_ | | | | _|_________| 1674 || _________|_ | | | | _|_________|| 1675 || | | Grid | | | | Grid | ||- 1676 -|_| PEP |<-------->| | | |<-------->| PEP |- 1677 |_________| | | | | |_________| 1678 _____________ | Grid | Grid | Grid | _____________ 1679 | Flow | Grid | Server |<---->| Server | Grid | Flow | 1680 |Controllers|<--------->| | | |<--------->|Controllers| 1681 |___________| | | | | |___________| 1682 _____________ | | | | _____________ 1683 | | Grid | | | | Grid | | 1684 | Sensors |<--------->| | | |<--------->| Sensors | 1685 |___________| |_________| |__________| |___________| 1687 Figure 12: XMPP-Grid Bridging Multiple IF-MAP Instances 1689 4.2. MAP Server as XMPP-Grid Publisher for Metadata Dissemination 1691 MAP Server could publish the MAP graph attribute changes to 1692 interested subscribers such as Flow Controllers, Sensors in the 1693 following ways 1695 a. MAP Server to publish all attribute changes of a MAP graph on a 1696 main Topic to which the interested network elements participate 1697 as subscribers. The subscribers will be able to get real-time 1698 notifications through Publish-Subscribe and make on-demand peer- 1699 to-peer directed or bulk queries depending on their authorization 1700 privileges. 1702 b. In addition, MAP server, at registration time with XMPP-Grid, 1703 could register the MAP graph's filtering criteria as a Publisher 1704 with XMPP-Grid. The filtering criteria of a MAP graph could be 1705 based on a combination of - 1707 A. metadata types 1709 B. metadata-identifier linkage attributes 1711 C. metadata class 1713 D. existing IF-MAP search criteria 1715 As discussed in the Topics section, XMPP-Grid Controller will create 1716 Subtopics and manage the Subtopics through the lifecycle based on the 1717 subscription list. The MAP Server and XMPP-Grid applies the message 1718 filters to publish-subscribe, directed or bulk queries made by the 1719 subscribers. 1721 5. IANA Considerations 1723 IANA Considerations to be determined 1725 6. Security Considerations 1727 A XMPP-Grid Controller serves as an controlling broker for XMPP-Grid 1728 Nodes such as Enforcement Points, Policy Servers, CMDBs, and Sensors, 1729 using a publish-subscribe-search model of information exchange and 1730 lookup. By increasing the ability of XMPP-Grid Nodes to learn about 1731 and respond to security-relevant events and data, XMPP-Grid can 1732 improve the timeliness and utility of the security system. However, 1733 this integrated security system can also be exploited by attackers if 1734 they can compromise it. Therefore, strong security protections for 1735 XMPP-Grid are essential. 1737 This section provides a security analysis of the XMPP-Grid transport 1738 protocol and the architectural elements that employ it, specifically 1739 with respect to their use of this protocol. Three subsections define 1740 the trust model (which elements are trusted to do what), the threat 1741 model (attacks that may be mounted on the system), and the 1742 countermeasures (ways to address or mitigate the threats previously 1743 identified). 1745 6.1. Trust Model 1747 The first step in analyzing the security of the XMPP-Grid transport 1748 protocol is to describe the trust model, listing what each 1749 architectural element is trusted to do. The items listed here are 1750 assumptions, but provisions are made in the Threat Model and 1751 Countermeasures sections for elements that fail to perform as they 1752 were trusted to do. 1754 6.1.1. Network 1756 The network used to carry XMPP-Grid messages is trusted to: 1758 o Perform best effort delivery of network traffic 1760 The network used to carry XMPP-Grid messages is not expected 1761 (trusted) to: 1763 o Provide confidentiality or integrity protection for messages sent 1764 over it 1766 o Provide timely or reliable service 1768 6.1.2. XMPP-Grid Nodes 1770 Authorized XMPP-Grid Nodes are trusted to: 1772 o Preserve the confidentiality of sensitive data retrieved via the 1773 XMPP-Grid Controller 1775 6.1.3. XMPP-Grid Controller 1777 The XMPP-Grid Controller is trusted to: 1779 o Broker requests for data and enforce authorization of access to 1780 this data throughout its lifecycle 1782 o Perform service requests in a timely and accurate manner 1784 o Create and maintain accurate operational attributes 1785 o Only reveal data to and accept service requests from authorized 1786 parties 1788 The XMPP-Grid Controller is not expected (trusted) to: 1790 o Verify the truth (correctness) of data 1792 6.1.4. Certification Authority 1794 The Certification Authority (CA) that issues certificates for the 1795 XMPP-Grid Controller and/or XMPP-Grid Nodes (or each CA, if there are 1796 several) is trusted to: 1798 o Protect the confidentiality of the CA's private key 1800 o Ensure that only proper certificates are issued and that all 1801 certificates are issued in accordance with the CA's policies 1803 o Revoke certificates previously issued when necessary 1805 o Regularly and securely distribute certificate revocation 1806 information 1808 o Promptly detect and report any violations of this trust so that 1809 they can be handled 1811 The CA is not expected (trusted) to: 1813 o Issue certificates that go beyond name constraints or other 1814 constraints imposed by a relying party or a cross-certificate 1816 6.2. Threat Model 1818 To secure the XMPP-Grid transport protocol and the architectural 1819 elements that implement it, this section identifies the attacks that 1820 can be mounted against the protocol and elements. 1822 6.2.1. Network Attacks 1824 A variety of attacks can be mounted using the network. For the 1825 purposes of this subsection the phrase "network traffic" should be 1826 taken to mean messages and/or parts of messages. Any of these 1827 attacks may be mounted by network elements, by parties who control 1828 network elements, and (in many cases) by parties who control network- 1829 attached devices. 1831 o Network traffic may be passively monitored to glean information 1832 from any unencrypted traffic 1834 o Even if all traffic is encrypted, valuable information can be 1835 gained by traffic analysis (volume, timing, source and destination 1836 addresses, etc.) 1838 o Network traffic may be modified in transit 1840 o Previously transmitted network traffic may be replayed 1842 o New network traffic may be added 1844 o Network traffic may be blocked, perhaps selectively 1846 o A "Man In The Middle" (MITM) attack may be mounted where an 1847 attacker interposes itself between two communicating parties and 1848 poses as the other end to either party or impersonates the other 1849 end to either or both parties 1851 o Resist attacks (including denial of service and other attacks from 1852 XMPP-Grid Nodes) 1854 o Undesired network traffic may be sent in an effort to overload an 1855 architectural component, thus mounting a denial of service attack 1857 6.2.2. XMPP-Grid Nodes 1859 An unauthorized XMPP-Grid Nodes (one which is not recognized by the 1860 XMPP-Grid Controller or is recognized but not authorized to perform 1861 any actions) cannot mount any attacks other than those listed in the 1862 Network Attacks section above. 1864 An authorized XMPP-Grid Node, on the other hand, can mount many 1865 attacks. These attacks might occur because the XMPP-Grid Node is 1866 controlled by a malicious, careless, or incompetent party (whether 1867 because its owner is malicious, careless, or incompetent or because 1868 the XMPP-Grid Node has been compromised and is now controlled by a 1869 party other than its owner). They might also occur because the XMPP- 1870 Grid Node is running malicious software; because the XMPP-Grid Node 1871 is running buggy software (which may fail in a state that floods the 1872 network with traffic); or because the XMPP-Grid Node has been 1873 configured improperly. From a security standpoint, it generally 1874 makes no difference why an attack is initiated. The same 1875 countermeasures can be employed in any case. 1877 Here is a list of attacks that may be mounted by an authorized XMPP- 1878 Grid Node: 1880 o Cause many false alarms or otherwise overload the XMPP-Grid 1881 Controller or other elements in the network security system 1882 (including human administrators) leading to a denial of service or 1883 disabling parts of the network security system 1885 o Omit important actions (such as posting incriminating data), 1886 resulting in incorrect access 1888 o Use confidential information obtained from the XMPP-Grid 1889 Controller to enable further attacks (such as using endpoint 1890 health check results to exploit vulnerable endpoints) 1892 o Advertise data crafted to exploit vulnerabilities in the XMPP-Grid 1893 Controller or in other XMPP-Grid Nodes, with a goal of 1894 compromising those systems 1896 o Issue a search request or set up a subscription that matches an 1897 enormous result, leading to resource exhaustion on the XMPP-Grid 1898 Controller, the publishing XMPP-Grid Node, and/or the network 1900 o Establish a communication channel using another XMPP-Grid Node's 1901 session-id 1903 Dependencies of or vulnerabilities of authorized XMPP-Grid Nodes may 1904 be exploited to effect these attacks. Another way to effect these 1905 attacks is to gain the ability to impersonate a XMPP-Grid Node 1906 (through theft of the XMPP-Grid Node's identity credentials or 1907 through other means). Even a clock skew between the XMPP-Grid Node 1908 and XMPP-Grid Controller can cause problems if the XMPP-Grid Node 1909 assumes that old XMPP-Grid Node data should be ignored. 1911 6.2.3. XMPP-Grid Controllers 1913 An unauthorized XMPP-Grid Controller (one which is not trusted by 1914 XMPP-Grid Nodes) cannot mount any attacks other than those listed in 1915 the Network Attacks section above. 1917 An authorized XMPP-Grid Controller can mount many attacks. Similar 1918 to the XMPP-Grid Node case described above, these attacks might occur 1919 because the XMPP-Grid Controller is controlled by a malicious, 1920 careless, or incompetent party (either a XMPP-Grid Controller 1921 administrator or an attacker who has seized control of the XMPP-Grid 1922 Controller). They might also occur because the XMPP-Grid Controller 1923 is running malicious software, because the XMPP-Grid Controller is 1924 running buggy software (which may fail in a state that corrupts data 1925 or floods the network with traffic), or because the XMPP-Grid 1926 Controller has been configured improperly. 1928 All of the attacks listed for XMPP-Grid Node above can be mounted by 1929 the XMPP-Grid Controller. Detection of these attacks will be more 1930 difficult since the XMPP-Grid Controller can create false operational 1931 attributes and/or logs that imply some other party created any bad 1932 data. 1934 Additional XMPP-Grid Controller attacks may include: 1936 o Expose different data to different XMPP-Grid Nodes to mislead 1937 investigators or cause inconsistent behavior 1939 o Mount an even more effective denial of service attack than a 1940 single XMPP-Grid Node could 1942 o Obtain and cache XMPP-Grid Node credentials so they can be used to 1943 impersonate XMPP-Grid Nodes even after a breach of the XMPP-Grid 1944 Controller is repaired 1946 o Obtain and cache XMPP-Grid Controller administrator credentials so 1947 they can be used to regain control of the XMPP-Grid Controller 1948 after the breach of the XMPP-Grid Controller is repaired 1950 Dependencies of or vulnerabilities of the XMPP-Grid Controller may be 1951 exploited to obtain control of the XMPP-Grid Controller and effect 1952 these attacks. 1954 6.2.4. Certification Authority 1956 A Certification Authority trusted to issue certificates for the XMPP- 1957 Grid Controller and/or XMPP-Grid Nodes can mount several attacks: 1959 o Issue certificates for unauthorized parties, enabling them to 1960 impersonate authorized parties such as the XMPP-Grid Controller or 1961 a XMPP-Grid Node. This can lead to all the threats that can be 1962 mounted by the certificate's subject. 1964 o Issue certificates without following all of the CA's policies. 1965 Because this can result in issuing certificates that may be used 1966 to impersonate authorized parties, this can lead to all the 1967 threats that can be mounted by the certificate's subject. 1969 o Fail to revoke previously issued certificates that need to be 1970 revoked. This can lead to undetected impersonation of the 1971 certificate's subject or failure to revoke authorization of the 1972 subject, and therefore can lead to all of the threats that can be 1973 mounted by that subject. 1975 o Fail to regularly and securely distribute certificate revocation 1976 information. This may cause a relying party to accept a revoked 1977 certificate, leading to undetected impersonation of the 1978 certificate's subject or failure to revoke authorization of the 1979 subject, and therefore can lead to all of the threats that can be 1980 mounted by that subject. It can also cause a relying party to 1981 refuse to proceed with a transaction because timely revocation 1982 information is not available, even though the transaction should 1983 be permitted to proceed. 1985 o Allow the CA's private key to be revealed to an unauthorized 1986 party. This can lead to all the threats above. Even worse, the 1987 actions taken with the private key will not be known to the CA. 1989 o Fail to promptly detect and report errors and violations of trust 1990 so that relying parties can be promptly notified. This can cause 1991 the threats listed earlier in this section to persist longer than 1992 necessary, leading to many knock-on effects. 1994 6.3. Countermeasures 1996 Below are countermeasures for specific attack scenarios to the XMPP- 1997 Grid infrastructure. 1999 6.3.1. Securing the XMPP-Grid Transport Protocol 2001 To address network attacks, the XMPP-Grid transport protocol 2002 described in this document requires that the XMPP-Grid messages MUST 2003 be carried over TLS (minimally TLS 1.2 [RFC5246]) as described in 2004 [RFC2818]. The XMPP-Grid Node MUST verify the XMPP-Grid Controller's 2005 certificate and determine whether the XMPP-Grid Controller is trusted 2006 by this XMPP-Grid Node before completing the TLS handshake. The 2007 XMPP-Grid Controller MUST authenticate the XMPP-Grid Node either 2008 using mutual certificate-based authentication in the TLS handshake or 2009 using Basic Authentication as described in IETF RFC 2617. XMPP-Grid 2010 Controller MUST use Simple Authentication and Security Layer (SASL), 2011 described in [RFC4422], to support the aforesaid authentication 2012 mechanisms. SASL offers authentication mechanism negotiations 2013 between the XMPP-Grid Controller and XMPP-Grid node during the 2014 connection establishment phase. XMPP-Grid Nodes and XMPP-Grid 2015 Controllers using mutual certificate-based authentication SHOULD each 2016 verify the revocation status of the other party. All XMPP-Grid 2017 Controllers and XMPP-Grid Nodes MUST implement both mutual 2018 certificate-based authentication and Basic Authentication. The 2019 selection of which XMPP-Grid Node authentication technique to use in 2020 any particular deployment is left to the administrator. 2022 An XMPP-Grid Controller MAY also support a local, configurable set of 2023 Basic Authentication userid-password pairs. If so, it is 2024 implementation dependent whether a XMPP-Grid Controller ends a 2025 session when an administrator changes the configured password. Since 2026 Basic Authentication has many security disadvantages (especially the 2027 transmission of reusable XMPP-Grid Node passwords to the XMPP-Grid 2028 Controller), it SHOULD only be used when absolutely necessary. Per 2029 the HTTP specification, when basic authentication is in use, a XMPP- 2030 Grid Controller MAY respond to any request that lacks credentials 2031 with an error code similar to HTTP code 401. A XMPP-Grid Node SHOULD 2032 avoid this code by submitting basic auth credentials with every 2033 request when basic authentication is in use. If it does not do so, a 2034 XMPP-Grid Node MUST respond to this code by resubmitting the same 2035 request with credentials (unless the XMPP-Grid Node is shutting 2036 down). 2038 As XMPP uses TLS as the transport and security mechanisms, it is 2039 understood that best practices such as those in 2040 [I-D.ietf-uta-tls-bcp] are followed. 2042 These protocol security measures provide protection against all the 2043 network attacks listed in the above document section except denial of 2044 service attacks. If protection against these denial of service 2045 attacks is desired, ingress filtering, rate limiting per source IP 2046 address, and other denial of service mitigation measures may be 2047 employed. In addition, a XMPP-Grid Controller MAY automatically 2048 disable a misbehaving XMPP-Grid Node. 2050 6.3.2. Securing XMPP-Grid Nodes 2052 XMPP-Grid Nodes may be deployed in locations that are susceptible to 2053 physical attacks. Physical security measures may be taken to avoid 2054 compromise of XMPP-Grid Nodes, but these may not always be practical 2055 or completely effective. An alternative measure is to configure the 2056 XMPP-Grid Controller to provide read-only access for such systems. 2057 The XMPP-Grid Controller SHOULD also include a full authorization 2058 model so that individual XMPP-Grid Nodes may be configured to have 2059 only the privileges that they need. The XMPP-Grid Controller MAY 2060 provide functional templates so that the administrator can configure 2061 a specific XMPP-Grid Node as a DHCP server and authorize only the 2062 operations and metadata types needed by a DHCP server to be permitted 2063 for that XMPP-Grid Node. These techniques can reduce the negative 2064 impacts of a compromised XMPP-Grid Node without diminishing the 2065 utility of the overall system. 2067 To handle attacks within the bounds of this authorization model, the 2068 XMPP-Grid Controller MAY also include rate limits and alerts for 2069 unusual XMPP-Grid Node behavior. XMPP-Grid Controllers SHOULD make 2070 it easy to revoke a XMPP-Grid Node's authorization when necessary. 2071 Another way to detect attacks from XMPP-Grid Nodes is to create fake 2072 entries in the available data (honeytokens) which normal XMPP-Grid 2073 Nodes will not attempt to access. The XMPP-Grid Controller SHOULD 2074 include auditable logs of XMPP-Grid Node activities. 2076 To avoid compromise of XMPP-Grid Node, XMPP-Grid Node SHOULD be 2077 hardened against attack and minimized to reduce their attack surface. 2078 They SHOULD go through a TNC handshake to verify the integrity of the 2079 XMPP-Grid Node, and SHOULD, if feasible, utilize a Trusted Platform 2080 Module (TPM) for identity and/or integrity measurements of the XMPP- 2081 Grid Node within a TNC handshake. They should be well managed to 2082 minimize vulnerabilities in the underlying platform and in systems 2083 upon which the XMPP-Grid Node depends. Personnel with administrative 2084 access should be carefully screened and monitored to detect problems 2085 as soon as possible. 2087 6.3.3. Securing XMPP-Grid Controllers 2089 Because of the serious consequences of XMPP-Grid Controller 2090 compromise, XMPP-Grid Controllers SHOULD be especially well hardened 2091 against attack and minimized to reduce their attack surface. They 2092 SHOULD go through a regular TNC handshake to verify the integrity of 2093 the XMPP-Grid Controller, and SHOULD utilize a Trusted Platform 2094 Module (TPM) for identity and/or integrity measurements of the XMPP- 2095 Grid Node within a TNC handshake. They should be well managed to 2096 minimize vulnerabilities in the underlying platform and in systems 2097 upon which the XMPP-Grid Controller depends. Network security 2098 measures such as firewalls or intrusion detection systems may be used 2099 to monitor and limit traffic to and from the XMPP-Grid Controller. 2100 Personnel with administrative access should be carefully screened and 2101 monitored to detect problems as soon as possible. Administrators 2102 should not use password-based authentication but should instead use 2103 non-reusable credentials and multi-factor authentication (where 2104 available). Physical security measures SHOULD be employed to prevent 2105 physical attacks on XMPP-Grid Controllers. 2107 To ease detection of XMPP-Grid Controller compromise should it occur, 2108 XMPP-Grid Controller behavior should be monitored to detect unusual 2109 behavior (such as a reboot, a large increase in traffic, or different 2110 views of an information repository for similar XMPP-Grid Nodes). 2111 XMPP-Grid Nodes should log and/or notify administrators when peculiar 2112 XMPP-Grid Controller behavior is detected. To aid forensic 2113 investigation, permanent read-only audit logs of security-relevant 2114 information (especially administrative actions) should be maintained. 2115 If XMPP-Grid Controller compromise is detected, a careful analysis 2116 should be performed of the impact of this compromise. Any reusable 2117 credentials that may have been compromised should be reissued. 2119 6.3.4. Limit on search result size 2121 While XMPP-Grid is designed for high scalability to 100,000s of 2122 Nodes, an XMPP-Grid Controller MAY establish a limit to the amount of 2123 data it is willing to return in search or subscription results. This 2124 mitigates the threat of a XMPP-Grid Node causing resource exhaustion 2125 by issuing a search or subscription that leads to an enormous result. 2127 6.3.5. Cryptographically random session-id and authentication checks 2128 for ARC 2130 A XMPP-Grid Controller SHOULD ensure that the XMPP-Grid Node 2131 establishing an ARC is the same XMPP-Grid Node as the XMPP-Grid Node 2132 that established the corresponding SSRC. The XMPP-Grid Controller 2133 SHOULD employ both of the following strategies: 2135 o session-ids SHOULD be cryptographically random 2137 o The HTTPS transport for the SSRC and the ARC SHOULD be 2138 authenticated using the same credentials. SSL session resumption 2139 MAY be used to establish the ARC based on the SSRC SSL session. 2141 6.3.6. Securing the Certification Authority 2143 As noted above, compromise of a Certification Authority (CA) trusted 2144 to issue certificates for the XMPP-Grid Controller and/or XMPP-Grid 2145 Nodes is a major security breach. Many guidelines for proper CA 2146 security have been developed: the CA/Browser Forum's Baseline 2147 Requirements, the AICPA/CICA Trust Service Principles, etc. The CA 2148 operator and relying parties should agree on an appropriately 2149 rigorous security practices to be used. 2151 Even with the most rigorous security practices, a CA may be 2152 compromised. If this compromise is detected quickly, relying parties 2153 can remove the CA from their list of trusted CAs, and other CAs can 2154 revoke any certificates issued to the CA. However, CA compromise may 2155 go undetected for some time, and there's always the possibility that 2156 a CA is being operated improperly or in a manner that is not in the 2157 interests of the relying parties. For this reason, relying parties 2158 may wish to "pin" a small number of particularly critical 2159 certificates (such as the certificate for the XMPP-Grid Controller). 2160 Once a certificate has been pinned, the relying party will not accept 2161 another certificate in its place unless the Administrator explicitly 2162 commands it to do so. This does not mean that the relying party will 2163 not check the revocation status of pinned certificates. However, the 2164 Administrator may still be consulted if a pinned certificate is 2165 revoked, since the CA and revocation process are not completely 2166 trusted. 2168 6.4. Summary 2170 XMPP-Grid's considerable value as a broker for security-sensitive 2171 data exchange distribution also makes the protocol and the network 2172 security elements that implement it a target for attack. Therefore, 2173 strong security has been included as a basic design principle within 2174 the XMPP-Grid design process. 2176 The XMPP-Grid transport protocol provides strong protection against a 2177 variety of different attacks. In the event that a XMPP-Grid Node or 2178 XMPP-Grid Controller is compromised, the effects of this compromise 2179 have been reduced and limited with the recommended role-based 2180 authorization model and other provisions, and best practices for 2181 managing and protecting XMPP-Grid systems have been described. Taken 2182 together, these measures should provide protection commensurate with 2183 the threat to XMPP-Grid systems, thus ensuring that they fulfill 2184 their promise as a network security clearing-house. 2186 7. Privacy Considerations 2188 XMPP-Grid Nodes may publish information about endpoint health, 2189 network access, events (which may include information about what 2190 services an endpoint is accessing), roles and capabilities, and the 2191 identity of the end user operating the endpoint. Any of this 2192 published information may be queried by other XMPP-Grid Nodes and 2193 could potentially be used to correlate network activity to a 2194 particular end user. 2196 Dynamic and static information brokered by a XMPP-Grid Controller, 2197 ostensibly for purposes of correlation by XMPP-Grid Nodes for 2198 intrusion detection, could be misused by a broader set of XMPP-Grid 2199 Nodes which hitherto have been performing specific roles with strict 2200 well-defined separation of duties. 2202 Care should be taken by deployers of XMPP-Grid to ensure that the 2203 information published by XMPP-Grid Nodes does not violate agreements 2204 with end users or local and regional laws and regulations. This can 2205 be accomplished either by configuring XMPP-Grid Nodes to not publish 2206 certain information or by restricting access to sensitive data to 2207 trusted XMPP-Grid Nodes. That is, the easiest means to ensure 2208 privacy or protect sensitive data, is to omit or not share it at all. 2210 Another consideration for deployers is to enable end-to-end 2211 encryption to ensure the data is protected from the data layer to 2212 data layer and thus protect it from the transport layer. 2214 8. Evolution of XMPP-Grid 2216 XMPP-Grid is the convergence of IF-MAP from the Trusted Computing 2217 Group and the Platform-Exchange Grid (pxGrid) from Cisco Systems. 2218 Both frameworks focus on enabling end users to implement multi-vendor 2219 systems that share security context information that enables 2220 coordinated defense-in-depth and security automation. 2222 An ecosystem of vendors has been shipping IF-MAP enabled products 2223 since 2008 to provide an architecture that supports standardized, 2224 dynamic security data interexchange among a wide variety of 2225 networking and security components. IF-MAP has been continually 2226 enhanced by the Trusted Computing Group, culminating in the most 2227 recent version, IF-MAP 2.2, published in March 2014. IF-MAP has 2228 focused on providing a standardized information model that can be 2229 utilized for data interoperability between vendors. 2231 Cisco pxGrid was introduced in 2013 and has since developed a broad- 2232 based security and networking vendor ecosystem. pxGrid was developed 2233 by extending standards-based XMPP message routing. The goal of 2234 pxGrid is to specifically address a lack of transport protocols 2235 available in the industry that deliver highly scalable, many-to-many 2236 platform security data interexchange in real-time. 2238 XMPP-Grid brings together the strengths of both IF-MAP and pxGrid. 2239 IF-MAP provides a mature and standardized information model. This 2240 information model is accessible by Cisco pxGrid to transport relevant 2241 data between systems. The combined XMPP-Grid delivers a highly 2242 scalable, real-time data exchange transport protocol with an 2243 interoperable information model based on the experience from real- 2244 world, production deployments. 2246 9. Acknowledgements 2248 The authors would like to acknowledge the contributions, authoring 2249 and/or editing of the following people: Henk Birkholz, Jessica 2250 Fitzgerald-McKay, Steve Hanna, Steve Venema. 2252 10. References 2254 10.1. Normative References 2256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2257 Requirement Levels", BCP 14, RFC 2119, March 1997. 2259 [RFC3922] Saint-Andre, P., "Mapping the Extensible Messaging and 2260 Presence Protocol (XMPP) to Common Presence and Instant 2261 Messaging (CPIM)", RFC 3922, October 2004. 2263 [RFC3923] Saint-Andre, P., "End-to-End Signing and Object Encryption 2264 for the Extensible Messaging and Presence Protocol 2265 (XMPP)", RFC 3923, October 2004. 2267 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 2268 Security Layer (SASL)", RFC 4422, June 2006. 2270 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 2271 Protocol (XMPP): Core", RFC 6120, March 2011. 2273 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 2274 Protocol (XMPP): Instant Messaging and Presence", RFC 2275 6121, March 2011. 2277 10.2. Informative References 2279 [I-D.ietf-sacm-terminology] 2280 Waltermire, D., Montville, A., Harrington, D., Cam-Winget, 2281 N., Lu, J., Ford, B., and M. Kaeo, "Terminology for 2282 Security Assessment", draft-ietf-sacm-terminology-06 (work 2283 in progress), February 2015. 2285 [I-D.ietf-sacm-use-cases] 2286 Waltermire, D. and D. Harrington, "Endpoint Security 2287 Posture Assessment - Enterprise Use Cases", draft-ietf- 2288 sacm-use-cases-09 (work in progress), March 2015. 2290 [I-D.ietf-uta-tls-bcp] 2291 Sheffer, Y., Holz, R., and P. Saint-Andre, 2292 "Recommendations for Secure Use of TLS and DTLS", draft- 2293 ietf-uta-tls-bcp-11 (work in progress), February 2015. 2295 [IF-MAP] Trusted Computing Group, "TNC Architecture for 2296 Interoperability, Revision 1.5", May 2012. 2298 [IF-MAP-ICS] 2299 Trusted Computing Group, "TNC IF-MAP Metadata for ICS, 2300 Security, Revision 1.0", October 2012. 2302 [IF-MAP-NETSEC] 2303 Trusted Computing Group, "TNC IF-MAP Metadata for Network 2304 Security, Revision 1.0", August 2010. 2306 [IF-MAP-SOAP] 2307 Trusted Computing Group, "TNC IF-MAP Binding for SOAP, 2308 Revision 2.1", May 2012. 2310 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2312 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 2313 Object Description Exchange Format", RFC 5070, December 2314 2007. 2316 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2317 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2319 Authors' Addresses 2321 Joseph Salowey 2322 Tableau Software 2323 837 North 34th Street, Suite 200 2324 Seattle , WA 98103 2326 Email: joe@salowey.net 2328 Lisa Lorenzin 2329 Pulse Secure 2330 2700 Zanker Rd., Suite 200 2331 San Jose, CA 95134 2332 USA 2334 Email: llorenzin@pulsesecure.net 2336 Cliff Kahn 2337 Pulse Secure 2338 2700 Zanker Rd., Suite 200 2339 San Jose, CA 95134 2340 USA 2342 Email: cliffordk@pulsesecure.net 2344 Scott Pope 2345 Cisco Systems 2346 5400 Meadows Road 2347 Suite 300 2348 Lake Oswego, OR 97035 2349 USA 2351 Email: scottp@cisco.com 2352 Syam Appala 2353 Cisco Systems 2354 80 West Tasman Drive 2355 San Jose, CA 95134 2356 USA 2358 Email: syam1@cisco.com 2360 Aaron Woland 2361 Cisco Systems 2362 1900 South Boulevard 2363 Charlotte, NC 28203 2364 USA 2366 Email: aawoland@cisco.com 2368 Nancy Cam-Winget (editor) 2369 Cisco Systems 2370 3550 Cisco WAY 2371 San Jose, CA 95134 2372 USA 2374 Email: ncamwing@cisco.com