idnits 2.17.1 draft-ietf-mile-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 93 instances of too long lines in the document, the longest one being 277 characters in excess of 72. ** The abstract seems to contain references ([RFC6120]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 28, 2017) is 2584 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0060' -- 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: 2 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MILE N. Cam-Winget, Ed. 3 Internet-Draft S. Appala 4 Intended status: Standards Track S. Pope 5 Expires: September 29, 2017 Cisco Systems 6 March 28, 2017 8 XMPP Protocol Extensions for Use with IODEF 9 draft-ietf-mile-xmpp-grid-02 11 Abstract 13 This document describes the extensions made to Extensible Messaging 14 and Presence Protocol (XMPP) [RFC6120]that enables the use of XMPP as 15 a transport protocol for collecting and distributing any security 16 telemetry information between and among network platforms, endpoints, 17 and most any network connected device. Specifically, this document 18 will focus on how these extensions can be used to transport the 19 Incident Object Description Exchange Format (IODEF) information. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 29, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Glossary of Terms . . . . . . . . . . . . . . . . . . . . 3 57 1.2. What is XMPP-Grid? . . . . . . . . . . . . . . . . . . . 5 58 1.3. Overview of XMPP-Grid . . . . . . . . . . . . . . . . . . 6 59 1.4. Benefits of XMPP-Grid . . . . . . . . . . . . . . . . . . 9 60 1.5. Example Workflow . . . . . . . . . . . . . . . . . . . . 10 61 2. XMPP-Grid Architecture . . . . . . . . . . . . . . . . . . . 11 62 2.1. XMPP Overview . . . . . . . . . . . . . . . . . . . . . . 12 63 2.2. XMPP-Grid Protocol Extensions to XMPP . . . . . . . . . . 13 64 2.3. XMPP-Grid Controller Protocol Flow . . . . . . . . . . . 13 65 2.4. XMPP-Grid Node Connection Protocol Flow . . . . . . . . . 16 66 2.4.1. Authentication . . . . . . . . . . . . . . . . . . . 16 67 2.4.2. Registration . . . . . . . . . . . . . . . . . . . . 16 68 2.4.3. Authorization . . . . . . . . . . . . . . . . . . . . 19 69 2.5. XMPP-Grid Topics Protocol Flow . . . . . . . . . . . . . 22 70 2.5.1. Topic Versioning . . . . . . . . . . . . . . . . . . 23 71 2.5.2. Topic Discovery . . . . . . . . . . . . . . . . . . . 23 72 2.5.3. Subtopics and Message Filters . . . . . . . . . . . . 23 73 2.6. XMPP-Grid Protocol Details . . . . . . . . . . . . . . . 26 74 3. XMPP-Grid Compatibility with IODEF . . . . . . . . . . . . . 33 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 34 77 5.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 34 78 5.1.1. Network . . . . . . . . . . . . . . . . . . . . . . . 35 79 5.1.2. XMPP-Grid Nodes . . . . . . . . . . . . . . . . . . . 35 80 5.1.3. XMPP-Grid Controller . . . . . . . . . . . . . . . . 35 81 5.1.4. Certification Authority . . . . . . . . . . . . . . . 35 82 5.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 36 83 5.2.1. Network Attacks . . . . . . . . . . . . . . . . . . . 36 84 5.2.2. XMPP-Grid Nodes . . . . . . . . . . . . . . . . . . . 37 85 5.2.3. XMPP-Grid Controllers . . . . . . . . . . . . . . . . 38 86 5.2.4. Certification Authority . . . . . . . . . . . . . . . 39 87 5.3. Countermeasures . . . . . . . . . . . . . . . . . . . . . 40 88 5.3.1. Securing the XMPP-Grid Transport Protocol . . . . . . 40 89 5.3.2. Securing XMPP-Grid Nodes . . . . . . . . . . . . . . 41 90 5.3.3. Securing XMPP-Grid Controllers . . . . . . . . . . . 42 91 5.3.4. Limit on search result size . . . . . . . . . . . . . 42 92 5.3.5. Cryptographically random session-id and 93 authentication checks for ARC . . . . . . . . . . . . 43 94 5.3.6. Securing the Certification Authority . . . . . . . . 43 95 5.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 43 96 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 44 97 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 98 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 99 8.1. Normative References . . . . . . . . . . . . . . . . . . 45 100 8.2. Informative References . . . . . . . . . . . . . . . . . 45 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 103 1. Introduction 105 XMPP-Grid is a set of standards-based XMPP [RFC6120] messages with 106 extensions. It is intended for use as a secure transport and 107 communications protocol ecosystem for devices and organizations to 108 interconnect, forming an information grid for the exchange of 109 formatted data (e.g. XML, JSON, etc). This document describes the 110 extensions made to XMPP [RFC6120]that enables use of XMPP as a 111 transport protocol for securely collecting and distributing security 112 telemetry information between and among network platforms, endpoints, 113 and most any network connected device. 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 1.1. Glossary of Terms 121 AAA 123 Authentication, Authorization and Accounting. 125 CA 127 Certification Authority. 129 Capability Provider 131 Providers who are capable of sharing information on XMPP-Grid. 133 CMDB 135 Configuration Management Database. 137 IDS 139 Intrusion Detection System. 141 IPS 143 Intrusion Prevention System. 145 JID 147 Jabber Identifier, native address of an XMPP entity. 149 MDM 151 Mobile Device Management. 153 NAC 155 Network Admission Control. 157 PDP 159 Policy Decision Point. 161 PEP 163 Policy Enforcement Point. 165 Presence 167 XMPP-Grid node availability and online status on XMPP-Grid. 169 Publisher 171 A capability provider sharing contet information to other devices 172 participating on XMPP-Grid. 174 SIEM 176 Security Information and Event Management. 178 Subscriber 180 A device participating in XMPP-Grid and subscribing or consuming 181 information published by Publishers on XMPP-Grid. 183 Sub-Topics 185 Topic created by XMPP-Grid Controller under a capability 186 provider's topic based on message filter criteria expressed by 187 subscribers. 189 Topics 190 Contextual information channel created on XMPP-Grid where a 191 published message by the Publisher will be propagated by XMPP in 192 real-time to a set a subscribed devices. 194 VoIP 196 Voice over IP. 198 XMPP-Grid 200 Set of standards-based XMPP messages with extensions, intended for 201 use as a transport and communications protocol framework between 202 devices forming an information grid for sharing information. 204 XMPP-Grid Controller 206 Centralized component of XMPP-Grid responsible for managing all 207 control plane operations. 209 XMPP-Grid Connection Agent 211 XMPP-Grid client library that a XMPP-Grid node implements to 212 connect and exchange information with other vendor devices on 213 XMPP-Grid. 215 XMPP-Grid Node 217 Platform or device that implements XMPP-Grid Connection Agent to 218 connect to XMPP-Grid and share or consume security data. 220 1.2. What is XMPP-Grid? 222 XMPP-Grid is a set of standards-based XMPP messages with extensions. 223 It is intended for use as a transport and communications protocol 224 framework for devices that interconnect with each other, forming a 225 secure information grid. 227 XMPP-Grid enables secure, bi-directional multi-vendor exchange of 228 contextual information between IT infrastructure platforms such as 229 security monitoring and detection systems, network policy platforms, 230 asset and configuration management, identity and access management 231 platforms. XMPP-Grid can serve to securely exchange any contextual 232 information. XMPP-Grid is built on top of XMPP [RFC6120], [RFC6121] 233 which is an open IETF standard messaging routing protocol used in 234 commercial platforms such as Google Voice, Jabber IM, Microsoft 235 Messenger, AOL IM and a variety of IoT and XML message routing 236 services. XMPP is also being considered as a means to transport 237 IODEF [RFC5070]. XMPP-Grid is designed for orchestration of data 238 sharing between security platforms on a many-to-many basis for 239 millions of end systems. 241 XMPP-Grid provides a security data sharing framework that enables 242 multiple vendors to integrate to XMPP-Grid once, then both share and 243 consume data bi-directionally with many IT infrastructure platforms 244 and applications from a single consistent framework akin to a 245 network-wide information bus. This reduces the need to develop to 246 explicit, multiple platform-specific interfaces, thereby increasing 247 the breadth of platforms that can interface and share security data. 248 XMPP-Grid is also configurable thereby enabling partners to share 249 only security data they want to share and consume only information 250 relevant to their platform or use-case and to customize information 251 shared without revising the interfaces. XMPP-Grid is data-agnostic 252 enabling it to operate with virtually any data type such as IODEF 253 [RFC5070]. 255 1.3. Overview of XMPP-Grid 257 XMPP-Grid employs publish/subscribe/query operations brokered by a 258 controller, which enforces access control in the system. This 259 architecture controls what platforms can connect to the "grid" to 260 share ("publish") and/or consume ("subscribe" or "query") contextual 261 information ("Topics") (described in Section 3.3 and 3.5) such as 262 security data needed to support MILE. The control of 263 publish/subscribe/query operations is architecturally distinct from 264 the actual sharing of the contextual information. Control functions 265 are split into a logical control plane, whereas information exchange 266 is considered a logical data plane. This separation enables 267 scalability and customizability. 269 XMPP-Grid defines an infrastructure protocol that hides the nuances 270 of the XMPP data plane protocol and makes the information sharing 271 models extensible with simple intuitive interfaces. XMPP-Grid Nodes 272 connect to the Grid using the XMPP-Grid Protocol. The XMPP-Grid 273 Protocol makes use of the XMPP transport protocol and introduces an 274 application layer protocol leveraging XML and XMPP extensions to 275 define the protocol. 277 The components of XMPP-Grid are: 279 o XMPP-Grid Controller (Controller): The Controller manages the 280 control plane of XMPP-Grid operations. As such it authenticates 281 and authorizes platforms connecting to the data exchange grid and 282 controls whether or not they can publish, subscribe or query 283 Topics of security data. 285 o XMPP-Grid Connection Agent (Connection Agent): The Connection 286 Agent enables the adopting Node to communicate with the Controller 287 and other vendor platforms that have adopted XMPP-Grid. Through 288 this communication privileges of the connecting platform-- 289 authorization to connect, publish, subscribe, query--are 290 established. The Connection Agent is typically implemented as a 291 client library. 293 o XMPP-Grid Node (Node): A Node is a platform that has implemented 294 the Connection Agent so that it can connect to an XMPP-Grid 295 deployment to share and/or consume security data. 297 o Data Repository: This is the source of security data available on 298 the Grid and may be a network security platform, management 299 console, endpoint, etc. XMPP-Grid does not mandate a specific 300 information model, but instead remains open to transport 301 structured or unstructured data. Data may be supplied by the 302 security platform itself or by an external information repository. 304 o Topic: An XMPP-Grid Topic defines a type of security data that a 305 platform wants to share with other platform(s). 307 The operations carried out by XMPP-Grid to exchange security data 308 are: 310 o Grid Connect: This is a Controller operation that authenticates a 311 Node that has implemented the Connection Agent to establish a 312 connection with the XMPP-Grid. Once authenticated, authorization 313 policies on the Controller establish a Node's privileges on the 314 XMPP-Grid such as the right to undertake publish, subscribe or 315 query operations explained below. 317 o Publish Topic: Security information is made available when a XMPP- 318 Grid enabled platform "publishes" a "Topic". This operation is 319 authorized by the Controller and communicated to the connecting 320 platform via the Connection Agent. 322 o Topic Discovery: Nodes on a XMPP-Grid discover Topics of security 323 data relevant to them by searching the Topic directory available 324 within the XMPP-Grid deployment. The Controller maintains such a 325 Topic directory for every instance of XMPP-Grid. 327 o Subscribe to Topic: A Node seeking to consume security information 328 "subscribes" to a Topic that provides the security information it 329 seeks to serve its use-case. This operation has its authorization 330 checked by the Controller and communicated with the connecting 331 platform via the Connection Agent. 333 o Query: This operation enables a Node to request a specific set of 334 security data regarding a specific asset (such as a specific user 335 endpoint) or bulk output history from a Topic over a specific span 336 of time. Such queries can be carried out node-to-node or by 337 querying a central data repository. Query structure is adaptable 338 to match the information model in use. 340 XMPP-Grid is used to exchange security context data between systems 341 on a 1-to-1, 1-to-many, or many-to-many basis. Security data shared 342 between these systems may use pre-negotiated non-standard/native data 343 formats or may utilize an optional common information repository with 344 a standardized data format, such as IODEF. XMPP-Grid is data format 345 agnostic and accommodates transport of whatever format the end 346 systems agree upon. 348 XMPP-Grid can operate in the following deployment architectures: 350 o Broker-Flow: An XMPP-Grid control plane brokers the authorization 351 and redirects the Topic subscriber to Topic publisher directly. 352 In this architecture, the Controller only manages the connection; 353 the security data flow is directly between Nodes using data 354 formats negotiated out-of-band. 356 o Centralized Data-Flow: An XMPP-Grid maintains the data within its 357 optional centralized database. In this architecture, the 358 Controller provides a common information structure for use in 359 formatting and storing security context data, such as IODEF, and 360 directly responds to Node publish and Subscribe requests. 362 o Proxy-Flow: An XMPP-Grid is acting as proxy, collecting the data 363 from the publisher(s) and presenting it to the subscriber 364 directly. This is used for ad-hoc queries. 366 Within the deployment architecture, XMPP-Grid may be used in any 367 combination of the following data exchange modes. The flexibility 368 afforded by the different modes enables security information to be 369 exchanged between systems in the method most suitable for serving a 370 given use-case. 372 o Continuous Topic update stream: This mode delivers in real-time 373 any data published to a Topic to the Nodes that are subscribed to 374 that Topic. 376 o Directed query: This mode enables Nodes to request a specific set 377 of security information regarding a specific asset, such as a 378 specific user endpoint. 380 o Bulk historic data query: This mode enables Nodes to request 381 transfer of past output from a Topic over a specific span of time. 383 1.4. Benefits of XMPP-Grid 385 Benefits of XMPP-Grid can be summarized on two fronts: 1) end-user 386 benefits, 2) benefits for adopting vendors. 388 Benefits for end-users deploying security services based on XMPP-Grid 389 security context information sharing capabilities are derived from 390 the results that come with standardization including: 392 o Consolidating relevant security event data from multiple systems 393 to the "right console at the right time". 395 o Cross-vendor interoperability out-of-the-box, when using a 396 standard data format. 398 o Coordinated security response across multiple products from 399 multiple vendors, ranging from endpoint security to AAA, NAC, IDS/ 400 IPS, Data Loss Prevention, firewalls to infrastructure such as 401 SIEM, CMDB, physical access control systems. 403 o Customer product choice and flexibility. No need to buy all 404 security products from one vendor. 406 Adopting XMPP-Grid security data sharing capabilities provides a 407 number of benefits for adopting vendors, especially when compared to 408 proprietary interfaces, such as: 410 o Integrate the XMPP-Grid Connection Agent once to interface with 411 many platforms, simultaneously by subscribing or publishing 412 relevant security data 414 o Security information shared is configurable (via Topics) based on 415 relevance to specific use-cases and platforms 417 o Only sharing relevant data enables both publishing and subscribing 418 platforms to scale their security data sharing by eliminating 419 excess, irrelevant data 421 o Integrated authorization and security ensures only appropriate 422 XMPP-Grid operations are executed by permitted platforms 424 o Ability to share security data in native or structured formats 425 enables data model flexibility for adopting vendors 427 o Flexibility, adaptability to evolve to address new use cases over 428 time. Utilize data-agnostic transport protocol or the extensible 429 schema that allows for easy support for vendor-specific data. 431 1.5. Example Workflow 433 ______________ 434 | XMPP-Grid | 435 Authorize /| Controller |\Authorize 436 / |____________| \ 437 ________/ ^ \_________ 438 "I have location" |Location| | | APP |"I have app info" 439 "I need app & ID.."|________|\ | /|________|"I need loc & dev" 440 \ | / 441 _\___|_____/_____ 442 |Continuous Flow| 443 <-----|---------------|------> 444 | Directed Query| 445 --/------|-----\- 446 / | \ 447 / | \ 448 __________/ | \__________ 449 "I have sec events"| SIEM | V | PAP |"I have ID & dev-type" 450 "I need ID & dev"|________| ______________ |________|"I need loc & MDM" 451 | Device Mgr | 452 |____________| 453 "I have MDM Info!" 454 "I need location..." 456 Figure 1: Typical XMPP-Grid Workflow 458 a. XMPP-Grid Controller establishes a grid for platforms wanting to 459 exchange security data. 461 b. A platform (Node) with a source of security data requests 462 connection to the Grid. 464 c. Controller authenticates and establishes authorized privileges 465 (e.g. privilege to publish and/or subscribe to security data 466 Topics) for the requesting Node. 468 d. Node may either publish a security data Topic, subscribe to a 469 security data Topic, query a Node or Topic, or any combination of 470 these operations. 472 e. Publishing Nodes unicast Topic updates to the Grid in real-time. 473 The Grid handles replication and distribution of the Topic to 474 subscribing Nodes. A Node may publish multiple Topics, thereby 475 allowing for customized relevance of the security data shared. 477 f. Subscribing Nodes receive continuous real-time stream of updates 478 to the Topic to which they are subscribed. 480 g. Any Node on the Grid may subscribe to any Topics published to the 481 Grid (as permitted by authorization policy), thereby allowing for 482 one-to-one, one-to-many and many-to-many meshed security data 483 sharing between Nodes. 485 2. XMPP-Grid Architecture 487 XMPP-Grid is a communication fabric that facilitates secure sharing 488 of information between network elements and networked applications 489 connected to the fabric both in real time and on demand. 491 XMPP-Grid uses XMPP servers that operate as a cluster with message 492 routing between them, for data plane communication. XMPP-Grid uses a 493 control plane element, the XMPP-Grid Controller, that is an external 494 component of XMPP for centralized policy-based control plane. 496 --------------- --------------- --------------- 497 | XMPP-Grid | | XMPP-Grid | | XMPP-Grid | 498 | Controller | | Controller | | Controller | 499 | | | | | | 500 --------------- --------------- --------------- 501 | | | 502 | | | 503 --------------- --------------- --------------- 504 | XMPP Server | | XMPP Server | | XMPP Server | 505 | |---------| |--------| | 506 | | | | | | 507 --------------- --------------- --------------- 509 Figure 2: XMPP Server and XMPP-Grid Cluster Architecture 511 The connected Nodes, with appropriate authorization privileges, can: 513 o Receive real-time events of the published messages from the 514 publisher through Topic subscriptions 516 o Make directed queries to other Nodes in the XMPP-Grid with 517 appropriate authorization from the Controller 519 o Negotiate out-of-band secure file transfer channel with the peer 520 This model enables flexible API usage depending on the Nodes' 521 contextual and time-sensitivity needs of security information. 523 2.1. XMPP Overview 525 XMPP is used as the foundation message routing protocol for 526 exchanging security data between systems across XMPP-Grid. XMPP is a 527 communications protocol for message-oriented middleware based on XML. 528 Designed to be extensible, the protocol uses de-centralized client- 529 server architecture where the clients connect to the servers securely 530 and the messages between the clients are routed through the XMPP 531 servers deployed within the cluster. XMPP has been used extensively 532 for publish-subscribe systems, file transfer, video, VoIP, Internet 533 of Things, Smart Grid Software Defined Networks (SDN) and other 534 collaboration and social networking applications. The following are 535 the 4 IETF specifications produced by XMPP working group: 537 o [RFC6120] Extensible Messaging and Presence Protocol (XMPP): Core 539 o [RFC6121] Extensible Messaging and Presence Protocol (XMPP): 540 Instant Messaging and Presence 542 o [RFC3922] Mapping the Extensible Messaging and Presence Protocol 543 (XMPP) to Common Presence and Instant Messaging (CPIM) 545 o [RFC3923] End-to-End Signing and Object Encryption for the 546 Extensible Messaging and Presence Protocol (XMPP) 548 XMPP offers several of the following salient features for building a 549 security data interexchange protocol: 551 o Open - standards-based, decentralized and federated architecture, 552 with no single point of failure 554 o Security - Supports domain segregations and federation. Offers 555 strong security via Simple Authentication and Security Layer 556 (SASL) [RFC4422] and Transport Layer Security (TLS) [RFC5246]. 558 o Real-time event management/exchange - using publish, subscribe 559 notifications 561 o Flexibility and Extensibility - XMPP is XML based and is easily 562 extensible to adapt to new use-cases. Custom functionality can be 563 built on top of it. 565 o Multiple information exchanges - XMPP offers multiple information 566 exchange mechanisms between the participating clients - 568 o 570 * Real-time event notifications through publish and subscribe. 572 * On-demand or directed queries between the clients communicated 573 through the XMPP server 575 * Facilitates out-of-band, direct communication between 576 participating clients 578 o Bi-directional - avoids firewall tunneling and avoids opening up a 579 new connection in each direction between client and server. 581 o Scalable - supports cluster mode deployment with fan-out and 582 message routing 584 o Peer-to-peer communications also enables scale - directed queries 585 and out-of-band file transfer support 587 o XMPP offers Node availability, Node service capability discovery, 588 and Node presence within the XMPP network. Nodes ability to 589 detect the availability, presence and capabilities of other 590 participating nodes eases turnkey deployment. 592 The XMPP extensions used in XMPP-Grid are now part (e.g. publish/ 593 subscribe) of the main XMPP specification [RFC6120] and the presence 594 in [RFC6121]. A full list of XMPP Extension Protocols (XEPs) 595 [RFC6120] can be found in http://xmpp.org/extensions/xep-0001.html . 597 2.2. XMPP-Grid Protocol Extensions to XMPP 599 XMPP-Grid defines an infrastructure protocol that hides the nuances 600 of the XMPP data plane protocol and makes the information sharing 601 models extensible with simple intuitive APIs. XMPP-Grid Nodes 602 connect to the Grid using the XMPP-Grid Protocol. The XMPP-Grid 603 Protocol makes use of the XMPP transport protocol and introduces an 604 application layer protocol leveraging XML and XMPP extensions to 605 define the protocol. The capability providers on the Grid extend the 606 XMPP-Grid Protocol infrastructure model and define capability 607 specific models and schemas, allowing a cleaner separation of 608 infrastructure and capabilities that can run on the infrastructure. 610 2.3. XMPP-Grid Controller Protocol Flow 612 At the heart of the XMPP-Grid network, the XMPP-Grid Controller 613 serves as the centralized policy-based control plane element managing 614 all Node authentications, authorizations, capabilities/Topics and 615 their subscription list. XMPP-Grid Controller manages all control 616 aspects of the Node communication (including management) with the 617 XMPP-Grid and other participating Nodes with mutual trust and 618 authorizations' enforcement. XMPP-Grid Controller is a component of 619 XMPP server and programs the data plane XMPP server with Node 620 accounts, account status, XMPP Topics that are dynamically created 621 and Topic subscriptions. To allow for dynamic discovery and 622 extensibility of publish/subscribe mechanisms, the Controller 623 supports an extended discovery mechanism. As the default publish/ 624 subscribe mechanism, [XEP-0060] is defined. Examples for the 625 discovery are described in Section 2.5.2 and Section 2.6. Once the 626 Node requests are authenticated and authorized in the control plane 627 phase by the Controller, the Controller removes itself from the data 628 flow. All data plane communication then occurs between the Nodes, 629 publishers and subscribers of XMPP Topics happen at the XMPP data 630 plane layer. 632 ---------------- ---------------- ---------------- 633 | Publi- | Node | | Grid | XMPP | | Node | Sub- | 634 | sher |client| | Ctrlr | Srvr | |client| scriber| 635 | | | | | | | | | 636 ----------------- ----------------- ----------------- 637 | Authen & allow Grid Ctrlr Comm | | 638 |<------------------------------>| | 639 | | | | 640 | |Publisher | | 641 | | Auth | | 642 | | Status | | 643 | |<---------| | 644 | | | | 645 | | | Authen & allow Grid Ctrlr | 646 | | | Communication | 647 | | |<------------------------->| 648 | | | | 649 | |Subscriber| | 650 | | Auth | | 651 | | Status & | | 652 | | Account | | 653 | |<---------| | 654 | | | | 655 | Author Publisher to | | | 656 | Topic Sequence | | | 657 --- |<------------------->| | | 658 C | | | | | 659 O | | | Add | | 660 N | | |Publisher | | 661 T | | | to Topic | | 662 R | | |--------->| | 663 O | | | | | 664 L | | | Author Subscriber to Topic Sequence | 665 --- | |<------------------------------------>| 666 | | | | 667 | | Add | | 668 | |Subscriber| | 669 | | to Topic | | 670 | |--------->| | 671 ---------------------------------------------------------------------- 672 | | | | 673 | Publish Message to Topic | | 674 --- |-------------------------------->| | 675 | | | | | 676 I | | Publish Success Published Message to Subscriber | 677 N | |<----------------------------------------------------------->| 678 F | | | | | 679 R | | | | Subscribe Success | 680 A | | | |<--------------------------| 681 | | | | | 682 --- | | Topic & Publisher Discovery Request | 683 | |<-------------------------------------| 684 | | | | 685 | | Topic & Publisher JID Response | 686 | |------------------------------------->| 687 | | | | 688 | | Out-of-Band Bulk Dnld Query Reqeust | 689 | |<-------------------------------------| 690 | | | | 691 | | Out-of-Band Bulk Dnld Query Author | 692 | |------------------------------------->| 693 | | | 694 | Out-of-Band Data Bulk Byte Stream | 695 |<----------------------------------------------------------->| 697 Figure 3: XMPP Controller Message Flow 699 Through a centralized authorization model, XMPP-Grid Controller 700 provides - 702 o Visibility into "who is connecting", "who is accessing what" 704 o Node account management with provisions to add, delete or disable 705 accounts, and with provisions to auto or manual approve Node 706 account approval requests during the Node registration phase 708 o Centralized, policy-based authorization, providing "who can do 709 what" for publish-subscribe, directed peer-to-peer queries or for 710 bulk out-of-band transfers between participating Nodes 712 o Topics and subscription list management with provision to enable 713 or disable Topics 715 o Dynamic creation of sub-Topics within the main Topic depending on 716 attributes of interest from the requesting Node 718 o Ability to perform message filters on the published messages 720 2.4. XMPP-Grid Node Connection Protocol Flow 722 Nodes connecting to XMPP-Grid go through the phases of 723 authentication, registration and authorization before they can 724 participate in information exchange on XMPP-Grid. 726 2.4.1. Authentication 728 The communication between the Node and the XMPP-Grid Controller is 729 cryptographically encrypted using TLS. XMPP-Grid uses X.509 730 certificate-based mutual authentication between the Nodes and 731 Controller. Internally, XMPP uses Simple Authentication and Security 732 Layer (SASL)[RFC4422] External mechanism to authenticate and 733 establish secure tunnel with the Nodes, allowing the XMPP-Grid 734 Controller to rely on this capability offered by XMPP. If the Node 735 certificate does not pass the validation process, the connection 736 establishment is terminated with the error messages defined by the 737 XMPP standard. On successful authentication, XMPP SASL component 738 extracts the Node certificate and Node username to the Controller for 739 registration. 741 2.4.2. Registration 743 Once a Node has been authenticated and a secure tunnel has been 744 successfully established, the Nodes will register their accounts with 745 the Controller and Nodes provide their username to the Controller as 746 part of the registration request. XMPP-Grid supports manual 747 registration (requires explicit approval of the Node account) and 748 mutual authentication trust-based auto-approval registration in order 749 to provide additional trust and usability options to the 750 administrator. The administrator may map the Nodes to the Node 751 groups to add additional level of validation and trust, and enforce 752 Node group based authorization. This allows the certificate- 753 username-group trust to get uniquely establishment for each Node and 754 duplicate registration requests using the same username will be 755 rejected. 757 During the registration process, the Controller restricts all Node 758 communication with the XMPP-Grid and only Node to Controller 759 communication is allowed. Once the Node is successfully registered, 760 the Controller lifts the restriction and allows the Nodes to 761 communicate on XMPP-Grid after it passes the authorization phase. It 762 should be noted that the registered and authorized Nodes could 763 publish, subscribe or query to multiple XMPP Topics between login and 764 logout to XMPP-Grid. Multiple Node applications running on a Node 765 could use one XMPP-Grid Node to connect to XMPP-Grid. The XMPP-Grid 766 Node should support Node applications' subscription to Topics and 767 should multiplex messages on its connection to XMPP-Grid. If a Node 768 application wants to be identified explicitly on XMPP-Grid, a new 769 XMPP-Grid Node connection to XMPP-Grid is required. 771 ----------------- --------------------------- 772 | | | Grid | XMPP | 773 | Node | | Controller| Server | 774 | | | | | 775 ----------------- --------------------------- 776 | | | 777 _____| | | 778 | | | | 779 Register | | | | 780 |---->| | | 781 | TLS Connect(username, cert) | | 782 |<------------------------------------------------------>| 783 | | | 784 | | Track | 785 | |(username,cert) | 786 | |<---------------| 787 |Register(username) | | 788 |-------------------------------------->| | 789 | |___ | 790 | | | Approve & | 791 | | | Authorize | 792 | |<--| Account | 793 | | | 794 | |Create User | 795 | |Account | 796 | |(username) | 797 | |--------------->| 798 | Registration Successful | | 799 |<--------------------------------------| | 800 | | | 801 | Login() | | 802 |-------------------------------------->| | 803 | | | 804 | Pub/Sub/Query | | 805 |<------------------------------------------------------>| 806 | | | 807 | | | 808 | Logout() | | 809 |-------------------------------------->| | 810 | | | 812 Figure 4: XMPP-Grid Node Registration 814 2.4.3. Authorization 816 The registered Nodes send subscription requests to the Controller. 817 The Controller, depending on the defined authorization privileges, 818 grants permissions to subscribe and/or publish to a Topic at the 819 registration time. The Controller updates the XMPP data plane server 820 with the new subscriber information and its capability. Node 821 identity extracted from the request, group to which the Node is 822 assigned during account approval and Topic/capability to which the 823 permission is sought could be some of the ways to authorize Nodes and 824 their requests in XMPP-Grid. Similarly, the Controller authorizes 825 directed peer-to-peer or out-of-band requests from a requesting peer. 826 The destination peer has options to query back the Controller to 827 retrieve and enforce granular authorizations such as read-only, 828 write-only, read/write. 830 In a Query Authorization flow, the capability provider responding to 831 the query is responsible for enforcing the authorization decision. 832 It retrieves "is authorized" from the XMPP-Grid Controller. Based on 833 the result, the service either allows or disallows the flow from 834 continuing. 836 ----------------- ----------------- ----------------- 837 | Subscriber | | XMPP-Grid | | Publisher | 838 | | | | | | 839 ----------------- ----------------- ----------------- 840 | | | 841 | | | 842 | query request | 843 |------------------------------------------------->| 844 | | |____ 845 | | | | extract 846 | | | | identity 847 | | |<--- 848 | | | 849 | | is authorized? | 850 | | (identity, service) | 851 | |<------------------------| 852 | | | 853 | query response | 854 |<-------------------------------------------------| 855 | | | 857 Figure 5: Node Query Authorization Flow 858 For Publish Authorization, prior to allowing a publish request by a 859 user, the XMPP-Grid Controller calls the rule evaluation engine 860 directly for "is authorized". Based this result, the Controller 861 either allows or disallowed the flow from continuing. 863 ----------------- ----------------- ----------------- 864 | Publisher | | XMPP-Grid | | XMPP | 865 | | | Controller | | Server | 866 ----------------- ----------------- ----------------- 867 | | | 868 | publish | | 869 |----------------------->|____ | 870 | | | extract | 871 | | | identity | 872 | |<--- | 873 | | | 874 | |____ | 875 | | | is authorized? | 876 | | | (identity,publish) | 877 | |<--- | 878 | | | 879 | | publish | 880 | |------------------------>| 881 | | | 883 Figure 6: Node Publish Authorization Flow 885 For Subscribe Authorization, prior to allowing a subscribe request by 886 a user, the XMPP-Grid Controller calls the rule evaluation engine 887 directly for "is authorized". Based this result, the Controller 888 either allows or disallowed the flow from continuing. 890 ----------------- ----------------- ----------------- 891 | Subscriber | | XMPP-Grid | | XMPP | 892 | | | Controller | | Server | 893 ----------------- ----------------- ----------------- 894 | | | 895 | subscribe | | 896 |----------------------->|____ | 897 | | | extract | 898 | | | identity | 899 | |<--- | 900 | | | 901 | |____ | 902 | | | is authorized? | 903 | | | (identity,publish) | 904 | |<--- | 905 | | | 906 | | subscribe | 907 | |------------------------>| 908 | | | 910 Figure 7: Node Subscribe Authorization Flow 912 Bulk Data Query differs from other data transfer modes. Unlike with 913 other modes of communication that operate in-band with the XMPP-Grid, 914 bulk downloads occur out-of-band (over a different protocol, outside 915 of the connection that was established with the XMPP-Grid 916 Controller). Previously discussed authorization mechanisms are 917 therefore not appropriate in this context. 919 ----------------- ----------------- ----------------- 920 | Subscriber | | XMPP-Grid | | Publisher | 921 | | | Controller | | | 922 ----------------- ----------------- ----------------- 923 | | | 924 | request | 925 |------------------------------------------------->| 926 | | |____ extract 927 | | | | cert 928 | | | | chain 929 | | |<--- 930 | | is authorized | 931 | | (cert chain, service) | 932 | |<------------------------| 933 | | | 934 | response | 935 |<-------------------------------------------------| 936 | | | 938 Figure 8: Node Bulk Data Query Flow 940 Instead the bulk download service sends the certificate chain used by 941 a Node in the TLS connection to the XMPP-Grid Controller for purposes 942 of authenticating and authorizing the Node. Upon receiving a request 943 with a certificate chain, the Controller checks the issuing 944 certificate against the trust store, looks up the identity associated 945 with the certificate, evaluates the rules, and returns "is 946 authorized" to the service. Then the service can either allow or 947 disallow the flow from continuing. 949 2.5. XMPP-Grid Topics Protocol Flow 951 For each capability, XMPP-Grid supports extensibility through XML 952 schemas where the providers (publishers) of the capabilities define 953 the schemas for the data exchanged. The capability provider shall 954 also define the version, the available queries and notifications that 955 it can support. The capability provider publishes the messages to 956 one or more XMPP Topics, that it requests XMPP-Grid to create 957 dynamically, depending on: 959 a. If the capability provider has mutually exclusive schemas, 960 different Topics will be created where the capability provider 961 will be a publisher to each Topic with a separate schema. 963 b. For a given Topic, if the subscribers wants to receive filtered 964 attributes or attribute values in capability provider's published 965 data, XMPP-Grid Controller creates sub Topics to the main Topic 966 based on the message filters expressed. XMPP-Grid Controller 967 enrolls the capability provider as the publisher and the 968 requesting subscribers based on the message filter criteria they 969 express. The capability provider will be the publisher to both 970 the main Topic and the sub-Topics. 972 c. In the case mentioned in (b) above, it is possible for the 973 capability provider to just publish on the main Topic and have 974 the XMPP-Grid Controller filter the published messages on the 975 Controller-side and deliver attributes and attribute values of 976 interest to the subscribers. Controller-side message filter 977 application and the specify mechanisms such as XPATH that can be 978 used for parsing the messages is beyond the scope of this 979 specification. 981 2.5.1. Topic Versioning 983 XMPP-Grid supports versioning to support forward and backward 984 compatible information models. The providers of capability include 985 the version number in the messages they publish and the receiving 986 Nodes can interpret the Topic version and process the attributes 987 accordingly. The expectation is any new version of a capability must 988 be of additive updates only. In other words, existing elements and 989 attributes cannot be changed, only new elements or attributes can be 990 added. This will enable nodes with older capability be able to 991 process newer version. The extra new elements or attributes will be 992 ignored. Instead of using the same Topic for all versions, it is 993 possible in XMPP-Grid to programmatically create separate Topics for 994 each version and allow them to be discovered and subscribed by the 995 Nodes. 997 In XMPP-Grid, versioning support applies equally to both publish/ 998 subscribe, directed and out-of-band queries. 1000 2.5.2. Topic Discovery 1002 The Nodes connected to XMPP-Grid can query the Controller and get the 1003 list of all capabilities/Topics running on XMPP-Grid. As the 1004 Controller can support multiple publish/subscribe mechanisms, XMPP- 1005 Grid defines its own discovery mechanism. Section 2.6 provides 1006 illustrations of Capability Query and Capability Provider Query. 1008 2.5.3. Subtopics and Message Filters 1010 XMPP-Grid supports semantic message filtering for Topics. The 1011 content being published by a provider can be semantically grouped 1012 into categories based on domain, location of endpoints for example. 1013 The provider of a capability specifies whether it supports semantic 1014 filtering or not to the Controller at the subscribe time to the Topic 1015 under consideration. 1017 XMPP-Grid subscribers query the Controller and obtain the filtering 1018 options available for each capability, and express their message 1019 filtering criteria at subscription time. The Controller, for each 1020 unique filter criteria specified by the subscribers, creates a new 1021 sub Topic under the main capability Topic. All the subscribers with 1022 the same filtering criteria will be subscribed to the Subtopic. The 1023 set of filter criteria for a capability will be predefined by the 1024 capability provider and could be based on the well-defined attributes 1025 of the message. 1027 ----------------- --------------------------- -------------- 1028 | | | Grid | XMPP | | Capability | 1029 | Node | | Controller| Server | | Provider | 1030 | | | | | | | 1031 ----------------- --------------------------- -------------- 1032 | | | | 1033 |Subscribe with filter | | 1034 |------------------->|____ | | 1035 | | | translate & | | 1036 | | | validate | | 1037 | |<---- filter | | 1038 | |____ | | 1039 | | | Check if sub-topic | 1040 | | | for filter | | 1041 | |<--- exists | | 1042 | | | | 1043 | |Create subtopic if doesn't exist | 1044 | |--------------------->| | 1045 | | | | 1046 | |Add Pub & Sub to Sub-Topic | 1047 | |--------------------->| | 1048 | | | | 1049 | |Notify Publisher | | 1050 | |------------------------------------->| 1051 | Subscribe Success | | | 1052 |<-------------------| | | 1053 | | | | 1055 Figure 9: Subtopics and Information Filter Subscribe Operations Flow 1057 The publisher will be responsible for applying the filter on the 1058 message and publishing the message on the Topic and the Subtopic 1059 based on the filter criteria. Filtering logic will be on the 1060 publisher, as the publisher understands the message content. XMPP- 1061 Grid fabric is oblivious to the message content. 1063 To avoid proliferation of new Subtopics, the capability provider 1064 could express the configurable limit on the number of Subtopics that 1065 can be created for its capability at registration time. The XMPP- 1066 Grid Controller will perform periodic cleanup of Subtopics whenever 1067 their subscription list reduces to 0. 1069 In XMPP-Grid, message filters are provided to all APIs i.e. publish/ 1070 subscribe and directed query. 1072 ----------------- --------------------------- -------------- 1073 | Capability | | Grid | XMPP | | | 1074 | Provider | | Controller| Server | | Node | 1075 | | | | | | | 1076 ----------------- --------------------------- -------------- 1077 | | | | 1078 | Register as Publisher | | 1079 |------------------->| | | 1080 | |Add Publisher to main | | 1081 | |topic & all subtopics | | 1082 | |--------------------->| | 1083 |Return registration | | | 1084 |success & list of | | | 1085 |subtopics with | | | 1086 |filtering criteria | | | 1087 |<-------------------| | | 1088 | | | | 1089 |Publish message to | | | 1090 |main topic | | | 1091 |------------------->| | | 1092 Check |____ |Publish message to | | 1093 filtering| | |main topic | | 1094 criteria & | |--------------------->| | 1095 identity |<--- | | | 1096 | | | | 1097 |Publish message to | | | 1098 |subtopic that matched filter | | 1099 |------------------------------------------>| | 1100 | | | Notify | 1101 | | |-------------->| 1103 Figure 10: Subtopic Publish Operations Flow 1105 2.6. XMPP-Grid Protocol Details 1107 The XMPP-Grid Protocol provides an abstraction layer over and above 1108 XMPP messages with the intent to provide intuitive interfaces to the 1109 Nodes connecting to XMPP-Grid. Nodes connecting to XMPP-Grid use the 1110 following interfaces (provided as XML samples) offered by XMPP-Grid 1111 protocol to connect and participate in information exchange on XMPP- 1112 Grid: 1114 o Register the Node to XMPP-Grid: Node identified as 1115 "Node2@domain.com/mac" sends the following Registration request to 1116 XMPP-Grid controller. 1118 1120 1121 1122 1123 1124 1126 o Node login to XMPP-Grid: The following XML sample shows the Login 1127 request from Node "Node2@domain.com/mac" to XMPP-Grid controller and 1128 Login response returned by the XMPP-Grid controller to the Node. 1130 // Request 1131 1133 1134 1135 1136 1137 1138 1140 // Response 1141 1143 1144 1145 1146 1147 1148 1149 1150 1152 o Node logout from XMPP-Grid: The following XML sample shows the 1153 Logout request sent by Node "Node2@domain.com/mac" to XMPP-Grid 1154 controller. 1156 1158 1159 1160 1161 1162 1163 1165 o Capability Discovery Query: The following XML sample shows the 1166 Capability Discovery query request from Node "Node2@domain.com/mac" 1167 to XMPP-Grid controller. The XMPP-Grid controller returns the list 1168 of capabilities supported by XMPP-Grid and their versions as a 1169 response to the Node's request. 1171 // Request 1172 1174 1175 1177 1178 1180 // Response 1181 1183 1184 1186 1188 0 1189 TrustSecMetaDataCapability-1.0 1190 1.0 1191 1192 1194 0 1195 1196 EndpointProfileMetaDataCapability-1.0 1197 1.0 1198 1199 1201 0 1202 IdentityGroupCapability-1.0 1203 1.0 1204 1205 1207 0 1208 TDAnalysisServiceCapability-1.0 1209 1.0 1210 1211 1213 0 1214 NetworkCaptureCapability-1.0 1215 1.0 1216 1217 1219 0 1220 1221 EndpointProtectionServiceCapability-1.0 1222 1.0 1223 1224 1226 0 1227 1228 GridControllerAdminServiceCapability-1.0 1229 1.0 1230 1231 1233 0 1234 SessionDirectoryCapability-1.0 1235 1.0 1236 1237 1238 1239 1240 o Specific Capability Provider Query: The following XML sample shows 1241 the Capability Provider hostname query request from Node 1242 "Node2@domain.com/mac" to XMPP-Grid controller. XMPP-Grid controller 1243 returns the hostname of the specific Capability Provider as a 1244 response to the Node's request. 1246 // Request 1247 1249 1250 1251 com.domain.ise.session.SessionQuery 1253 1254 1255 1256 1258 // Response 1259 1262 1263 1264 1267 ise@syam-06.domain.com/syam-mac 1268 1269 1270 1271 o Register as a publisher to the Topic: The following XML sample 1272 shows the Register as a Publisher request from a Node 1273 "Node2@domain.com/mac" to XMPP-Grid controller. 1275 1277 1278 1280 1299 1300 1302 1314 1315 1337 1338 1339 101 1340 2016-10-13T14:53:44.154-07:00 1341 UGVybWl0QWNjZXNz 1342 Started 1343 1344 Acct-Session-Id 1345 101 1346 1347 1348 1349 1.1.1.1 1350 1351 00:11:22:33:44:55 1352 1353 172.21.170.242 1354 1355 1356 user1 1357 1358 1359 0 1360 0 1361 0 1362 None 1363 none 1364 1365 1366 1368 1369 1370 1371 1372 1374 // Publish message from XMPP PubSub to the Subscriber 1375 1376 1377 1378 1379 1380 1381 1382 1383 101 1384 2014-03-13T22:46:17.292-07:00 1385 Authenticated 1386 1387 Acct-Session-Id 1388 1389 1390 1391 10.0.0.2 1392 1393 00:11:22:33:44:55 1394 1395 1396 10.21.127.1 1397 1398 1399 1400 1401 user1 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 o Peer-to-Peer Directed Query: The following XML sample shows a peer- 1413 to-peer directed query request made by Node "Node2@domain.com/mac" to 1414 other XMPP-Grid participating Node "grid_Controller.jabber", seeking 1415 identity group information for a specific user "user1". 1416 "grid_Controller.jabber" returns the list of identity groups "user1" 1417 belongs as a response to the request. 1419 // Query Request 1420 1422 1423 1425 1426 user1 1427 1428 1429 1430 1432 // Query Response 1433 1435 1436 1438 1439 user1 1440 1441 1442 User Identity Groups:Employee 1443 1444 Identity 1445 1446 1447 1448 1449 1450 1452 3. XMPP-Grid Compatibility with IODEF 1454 The Incident Object Description and Exchange Format (IODEF) [RFC5070] 1455 defines a common data format and common exchange procedures for 1456 sharing incidents and related data between CSIRTs. RFC5070 provides 1457 the information and data model for IODEF specified with XML schema. 1459 XEP-0268 (http://xmpp.org/extensions/xep-0268.html), Incident 1460 Handling, defines ways for XMPP server deployments to share incident 1461 reports with each other using the IODEF format and handle attacks on 1462 the servers in real-time. 1464 Providers of incident reports, across administrative domains, could 1465 participate as publishers to an XMPP topic (for example: IODEF). 1466 Trust is achieved through authentication, authorization and account 1467 approval as defined in Section 2.4. The providers could expose IODEF 1468 incident attributes such as Authority as message filter criteria for 1469 the topic in order for subscribing systems to subscribe to incident 1470 reports from administrative domains of interest. The providers could 1471 further expose other IODEF attributes such as Assessment, Method, 1472 Attacker etc as message filter criteria for subscribers to 1473 selectively choose events of interest that are published from 1474 administrative domain(s). Privacy and regulatory requirements of 1475 information shared across administrative domains is beyond the scope 1476 of this document. 1478 4. IANA Considerations 1480 IANA Considerations to be determined 1482 5. Security Considerations 1484 A XMPP-Grid Controller serves as an controlling broker for XMPP-Grid 1485 Nodes such as Enforcement Points, Policy Servers, CMDBs, and Sensors, 1486 using a publish-subscribe-search model of information exchange and 1487 lookup. By increasing the ability of XMPP-Grid Nodes to learn about 1488 and respond to security-relevant events and data, XMPP-Grid can 1489 improve the timeliness and utility of the security system. However, 1490 this integrated security system can also be exploited by attackers if 1491 they can compromise it. Therefore, strong security protections for 1492 XMPP-Grid are essential. 1494 This section provides a security analysis of the XMPP-Grid transport 1495 protocol and the architectural elements that employ it, specifically 1496 with respect to their use of this protocol. Three subsections define 1497 the trust model (which elements are trusted to do what), the threat 1498 model (attacks that may be mounted on the system), and the 1499 countermeasures (ways to address or mitigate the threats previously 1500 identified). 1502 5.1. Trust Model 1504 The first step in analyzing the security of the XMPP-Grid transport 1505 protocol is to describe the trust model, listing what each 1506 architectural element is trusted to do. The items listed here are 1507 assumptions, but provisions are made in the Threat Model and 1508 Countermeasures sections for elements that fail to perform as they 1509 were trusted to do. 1511 5.1.1. Network 1513 The network used to carry XMPP-Grid messages is trusted to: 1515 o Perform best effort delivery of network traffic 1517 The network used to carry XMPP-Grid messages is not expected 1518 (trusted) to: 1520 o Provide confidentiality or integrity protection for messages sent 1521 over it 1523 o Provide timely or reliable service 1525 5.1.2. XMPP-Grid Nodes 1527 Authorized XMPP-Grid Nodes are trusted to: 1529 o Preserve the confidentiality of sensitive data retrieved via the 1530 XMPP-Grid Controller 1532 5.1.3. XMPP-Grid Controller 1534 The XMPP-Grid Controller is trusted to: 1536 o Broker requests for data and enforce authorization of access to 1537 this data throughout its lifecycle 1539 o Perform service requests in a timely and accurate manner 1541 o Create and maintain accurate operational attributes 1543 o Only reveal data to and accept service requests from authorized 1544 parties 1546 The XMPP-Grid Controller is not expected (trusted) to: 1548 o Verify the truth (correctness) of data 1550 5.1.4. Certification Authority 1552 The Certification Authority (CA) that issues certificates for the 1553 XMPP-Grid Controller and/or XMPP-Grid Nodes (or each CA, if there are 1554 several) is trusted to: 1556 o Protect the confidentiality of the CA's private key 1558 o Ensure that only proper certificates are issued and that all 1559 certificates are issued in accordance with the CA's policies 1561 o Revoke certificates previously issued when necessary 1563 o Regularly and securely distribute certificate revocation 1564 information 1566 o Promptly detect and report any violations of this trust so that 1567 they can be handled 1569 The CA is not expected (trusted) to: 1571 o Issue certificates that go beyond name constraints or other 1572 constraints imposed by a relying party or a cross-certificate 1574 5.2. Threat Model 1576 To secure the XMPP-Grid transport protocol and the architectural 1577 elements that implement it, this section identifies the attacks that 1578 can be mounted against the protocol and elements. 1580 5.2.1. Network Attacks 1582 A variety of attacks can be mounted using the network. For the 1583 purposes of this subsection the phrase "network traffic" should be 1584 taken to mean messages and/or parts of messages. Any of these 1585 attacks may be mounted by network elements, by parties who control 1586 network elements, and (in many cases) by parties who control network- 1587 attached devices. 1589 o Network traffic may be passively monitored to glean information 1590 from any unencrypted traffic 1592 o Even if all traffic is encrypted, valuable information can be 1593 gained by traffic analysis (volume, timing, source and destination 1594 addresses, etc.) 1596 o Network traffic may be modified in transit 1598 o Previously transmitted network traffic may be replayed 1600 o New network traffic may be added 1602 o Network traffic may be blocked, perhaps selectively 1603 o A "Man In The Middle" (MITM) attack may be mounted where an 1604 attacker interposes itself between two communicating parties and 1605 poses as the other end to either party or impersonates the other 1606 end to either or both parties 1608 o Resist attacks (including denial of service and other attacks from 1609 XMPP-Grid Nodes) 1611 o Undesired network traffic may be sent in an effort to overload an 1612 architectural component, thus mounting a denial of service attack 1614 5.2.2. XMPP-Grid Nodes 1616 An unauthorized XMPP-Grid Nodes (one which is not recognized by the 1617 XMPP-Grid Controller or is recognized but not authorized to perform 1618 any actions) cannot mount any attacks other than those listed in the 1619 Network Attacks section above. 1621 An authorized XMPP-Grid Node, on the other hand, can mount many 1622 attacks. These attacks might occur because the XMPP-Grid Node is 1623 controlled by a malicious, careless, or incompetent party (whether 1624 because its owner is malicious, careless, or incompetent or because 1625 the XMPP-Grid Node has been compromised and is now controlled by a 1626 party other than its owner). They might also occur because the XMPP- 1627 Grid Node is running malicious software; because the XMPP-Grid Node 1628 is running buggy software (which may fail in a state that floods the 1629 network with traffic); or because the XMPP-Grid Node has been 1630 configured improperly. From a security standpoint, it generally 1631 makes no difference why an attack is initiated. The same 1632 countermeasures can be employed in any case. 1634 Here is a list of attacks that may be mounted by an authorized XMPP- 1635 Grid Node: 1637 o Cause many false alarms or otherwise overload the XMPP-Grid 1638 Controller or other elements in the network security system 1639 (including human administrators) leading to a denial of service or 1640 disabling parts of the network security system 1642 o Omit important actions (such as posting incriminating data), 1643 resulting in incorrect access 1645 o Use confidential information obtained from the XMPP-Grid 1646 Controller to enable further attacks (such as using endpoint 1647 health check results to exploit vulnerable endpoints) 1649 o Advertise data crafted to exploit vulnerabilities in the XMPP-Grid 1650 Controller or in other XMPP-Grid Nodes, with a goal of 1651 compromising those systems 1653 o Issue a search request or set up a subscription that matches an 1654 enormous result, leading to resource exhaustion on the XMPP-Grid 1655 Controller, the publishing XMPP-Grid Node, and/or the network 1657 o Establish a communication channel using another XMPP-Grid Node's 1658 session-id 1660 Dependencies of or vulnerabilities of authorized XMPP-Grid Nodes may 1661 be exploited to effect these attacks. Another way to effect these 1662 attacks is to gain the ability to impersonate a XMPP-Grid Node 1663 (through theft of the XMPP-Grid Node's identity credentials or 1664 through other means). Even a clock skew between the XMPP-Grid Node 1665 and XMPP-Grid Controller can cause problems if the XMPP-Grid Node 1666 assumes that old XMPP-Grid Node data should be ignored. 1668 5.2.3. XMPP-Grid Controllers 1670 An unauthorized XMPP-Grid Controller (one which is not trusted by 1671 XMPP-Grid Nodes) cannot mount any attacks other than those listed in 1672 the Network Attacks section above. 1674 An authorized XMPP-Grid Controller can mount many attacks. Similar 1675 to the XMPP-Grid Node case described above, these attacks might occur 1676 because the XMPP-Grid Controller is controlled by a malicious, 1677 careless, or incompetent party (either a XMPP-Grid Controller 1678 administrator or an attacker who has seized control of the XMPP-Grid 1679 Controller). They might also occur because the XMPP-Grid Controller 1680 is running malicious software, because the XMPP-Grid Controller is 1681 running buggy software (which may fail in a state that corrupts data 1682 or floods the network with traffic), or because the XMPP-Grid 1683 Controller has been configured improperly. 1685 All of the attacks listed for XMPP-Grid Node above can be mounted by 1686 the XMPP-Grid Controller. Detection of these attacks will be more 1687 difficult since the XMPP-Grid Controller can create false operational 1688 attributes and/or logs that imply some other party created any bad 1689 data. 1691 Additional XMPP-Grid Controller attacks may include: 1693 o Expose different data to different XMPP-Grid Nodes to mislead 1694 investigators or cause inconsistent behavior 1696 o Mount an even more effective denial of service attack than a 1697 single XMPP-Grid Node could 1699 o Obtain and cache XMPP-Grid Node credentials so they can be used to 1700 impersonate XMPP-Grid Nodes even after a breach of the XMPP-Grid 1701 Controller is repaired 1703 o Obtain and cache XMPP-Grid Controller administrator credentials so 1704 they can be used to regain control of the XMPP-Grid Controller 1705 after the breach of the XMPP-Grid Controller is repaired 1707 Dependencies of or vulnerabilities of the XMPP-Grid Controller may be 1708 exploited to obtain control of the XMPP-Grid Controller and effect 1709 these attacks. 1711 5.2.4. Certification Authority 1713 A Certification Authority trusted to issue certificates for the XMPP- 1714 Grid Controller and/or XMPP-Grid Nodes can mount several attacks: 1716 o Issue certificates for unauthorized parties, enabling them to 1717 impersonate authorized parties such as the XMPP-Grid Controller or 1718 a XMPP-Grid Node. This can lead to all the threats that can be 1719 mounted by the certificate's subject. 1721 o Issue certificates without following all of the CA's policies. 1722 Because this can result in issuing certificates that may be used 1723 to impersonate authorized parties, this can lead to all the 1724 threats that can be mounted by the certificate's subject. 1726 o Fail to revoke previously issued certificates that need to be 1727 revoked. This can lead to undetected impersonation of the 1728 certificate's subject or failure to revoke authorization of the 1729 subject, and therefore can lead to all of the threats that can be 1730 mounted by that subject. 1732 o Fail to regularly and securely distribute certificate revocation 1733 information. This may cause a relying party to accept a revoked 1734 certificate, leading to undetected impersonation of the 1735 certificate's subject or failure to revoke authorization of the 1736 subject, and therefore can lead to all of the threats that can be 1737 mounted by that subject. It can also cause a relying party to 1738 refuse to proceed with a transaction because timely revocation 1739 information is not available, even though the transaction should 1740 be permitted to proceed. 1742 o Allow the CA's private key to be revealed to an unauthorized 1743 party. This can lead to all the threats above. Even worse, the 1744 actions taken with the private key will not be known to the CA. 1746 o Fail to promptly detect and report errors and violations of trust 1747 so that relying parties can be promptly notified. This can cause 1748 the threats listed earlier in this section to persist longer than 1749 necessary, leading to many knock-on effects. 1751 5.3. Countermeasures 1753 Below are countermeasures for specific attack scenarios to the XMPP- 1754 Grid infrastructure. 1756 5.3.1. Securing the XMPP-Grid Transport Protocol 1758 To address network attacks, the XMPP-Grid transport protocol 1759 described in this document requires that the XMPP-Grid messages MUST 1760 be carried over TLS (minimally TLS 1.2 [RFC5246]) as described in 1761 [RFC2818]. The XMPP-Grid Node MUST verify the XMPP-Grid Controller's 1762 certificate and determine whether the XMPP-Grid Controller is trusted 1763 by this XMPP-Grid Node before completing the TLS handshake. The 1764 XMPP-Grid Controller MUST authenticate the XMPP-Grid Node either 1765 using mutual certificate-based authentication in the TLS handshake or 1766 using Basic Authentication as described in IETF RFC 2617. XMPP-Grid 1767 Controller MUST use Simple Authentication and Security Layer (SASL), 1768 described in [RFC4422], to support the aforesaid authentication 1769 mechanisms. SASL offers authentication mechanism negotiations 1770 between the XMPP-Grid Controller and XMPP-Grid node during the 1771 connection establishment phase. XMPP-Grid Nodes and XMPP-Grid 1772 Controllers using mutual certificate-based authentication SHOULD each 1773 verify the revocation status of the other party. All XMPP-Grid 1774 Controllers and XMPP-Grid Nodes MUST implement both mutual 1775 certificate-based authentication and Basic Authentication. The 1776 selection of which XMPP-Grid Node authentication technique to use in 1777 any particular deployment is left to the administrator. 1779 An XMPP-Grid Controller MAY also support a local, configurable set of 1780 Basic Authentication userid-password pairs. If so, it is 1781 implementation dependent whether a XMPP-Grid Controller ends a 1782 session when an administrator changes the configured password. Since 1783 Basic Authentication has many security disadvantages (especially the 1784 transmission of reusable XMPP-Grid Node passwords to the XMPP-Grid 1785 Controller), it SHOULD only be used when absolutely necessary. Per 1786 the HTTP specification, when basic authentication is in use, a XMPP- 1787 Grid Controller MAY respond to any request that lacks credentials 1788 with an error code similar to HTTP code 401. A XMPP-Grid Node SHOULD 1789 avoid this code by submitting basic auth credentials with every 1790 request when basic authentication is in use. If it does not do so, a 1791 XMPP-Grid Node MUST respond to this code by resubmitting the same 1792 request with credentials (unless the XMPP-Grid Node is shutting 1793 down). 1795 As XMPP uses TLS as the transport and security mechanisms, it is 1796 understood that best practices such as those in 1797 [I-D.ietf-uta-tls-bcp] are followed. 1799 These protocol security measures provide protection against all the 1800 network attacks listed in the above document section except denial of 1801 service attacks. If protection against these denial of service 1802 attacks is desired, ingress filtering, rate limiting per source IP 1803 address, and other denial of service mitigation measures may be 1804 employed. In addition, a XMPP-Grid Controller MAY automatically 1805 disable a misbehaving XMPP-Grid Node. 1807 5.3.2. Securing XMPP-Grid Nodes 1809 XMPP-Grid Nodes may be deployed in locations that are susceptible to 1810 physical attacks. Physical security measures may be taken to avoid 1811 compromise of XMPP-Grid Nodes, but these may not always be practical 1812 or completely effective. An alternative measure is to configure the 1813 XMPP-Grid Controller to provide read-only access for such systems. 1814 The XMPP-Grid Controller SHOULD also include a full authorization 1815 model so that individual XMPP-Grid Nodes may be configured to have 1816 only the privileges that they need. The XMPP-Grid Controller MAY 1817 provide functional templates so that the administrator can configure 1818 a specific XMPP-Grid Node as a DHCP server and authorize only the 1819 operations and metadata types needed by a DHCP server to be permitted 1820 for that XMPP-Grid Node. These techniques can reduce the negative 1821 impacts of a compromised XMPP-Grid Node without diminishing the 1822 utility of the overall system. 1824 To handle attacks within the bounds of this authorization model, the 1825 XMPP-Grid Controller MAY also include rate limits and alerts for 1826 unusual XMPP-Grid Node behavior. XMPP-Grid Controllers SHOULD make 1827 it easy to revoke a XMPP-Grid Node's authorization when necessary. 1828 Another way to detect attacks from XMPP-Grid Nodes is to create fake 1829 entries in the available data (honeytokens) which normal XMPP-Grid 1830 Nodes will not attempt to access. The XMPP-Grid Controller SHOULD 1831 include auditable logs of XMPP-Grid Node activities. 1833 To avoid compromise of XMPP-Grid Node, XMPP-Grid Node SHOULD be 1834 hardened against attack and minimized to reduce their attack surface. 1835 They SHOULD go through a TNC handshake to verify the integrity of the 1836 XMPP-Grid Node, and SHOULD, if feasible, utilize a Trusted Platform 1837 Module (TPM) for identity and/or integrity measurements of the XMPP- 1838 Grid Node within a TNC handshake. They should be well managed to 1839 minimize vulnerabilities in the underlying platform and in systems 1840 upon which the XMPP-Grid Node depends. Personnel with administrative 1841 access should be carefully screened and monitored to detect problems 1842 as soon as possible. 1844 5.3.3. Securing XMPP-Grid Controllers 1846 Because of the serious consequences of XMPP-Grid Controller 1847 compromise, XMPP-Grid Controllers SHOULD be especially well hardened 1848 against attack and minimized to reduce their attack surface. They 1849 SHOULD go through a regular TNC handshake to verify the integrity of 1850 the XMPP-Grid Controller, and SHOULD utilize a Trusted Platform 1851 Module (TPM) for identity and/or integrity measurements of the XMPP- 1852 Grid Node within a TNC handshake. They should be well managed to 1853 minimize vulnerabilities in the underlying platform and in systems 1854 upon which the XMPP-Grid Controller depends. Network security 1855 measures such as firewalls or intrusion detection systems may be used 1856 to monitor and limit traffic to and from the XMPP-Grid Controller. 1857 Personnel with administrative access should be carefully screened and 1858 monitored to detect problems as soon as possible. Administrators 1859 should not use password-based authentication but should instead use 1860 non-reusable credentials and multi-factor authentication (where 1861 available). Physical security measures SHOULD be employed to prevent 1862 physical attacks on XMPP-Grid Controllers. 1864 To ease detection of XMPP-Grid Controller compromise should it occur, 1865 XMPP-Grid Controller behavior should be monitored to detect unusual 1866 behavior (such as a reboot, a large increase in traffic, or different 1867 views of an information repository for similar XMPP-Grid Nodes). 1868 XMPP-Grid Nodes should log and/or notify administrators when peculiar 1869 XMPP-Grid Controller behavior is detected. To aid forensic 1870 investigation, permanent read-only audit logs of security-relevant 1871 information (especially administrative actions) should be maintained. 1872 If XMPP-Grid Controller compromise is detected, a careful analysis 1873 should be performed of the impact of this compromise. Any reusable 1874 credentials that may have been compromised should be reissued. 1876 5.3.4. Limit on search result size 1878 While XMPP-Grid is designed for high scalability to 100,000s of 1879 Nodes, an XMPP-Grid Controller MAY establish a limit to the amount of 1880 data it is willing to return in search or subscription results. This 1881 mitigates the threat of a XMPP-Grid Node causing resource exhaustion 1882 by issuing a search or subscription that leads to an enormous result. 1884 5.3.5. Cryptographically random session-id and authentication checks 1885 for ARC 1887 A XMPP-Grid Controller SHOULD ensure that the XMPP-Grid Node 1888 establishing an ARC is the same XMPP-Grid Node as the XMPP-Grid Node 1889 that established the corresponding SSRC. The XMPP-Grid Controller 1890 SHOULD employ both of the following strategies: 1892 o session-ids SHOULD be cryptographically random 1894 o The HTTPS transport for the SSRC and the ARC SHOULD be 1895 authenticated using the same credentials. SSL session resumption 1896 MAY be used to establish the ARC based on the SSRC SSL session. 1898 5.3.6. Securing the Certification Authority 1900 As noted above, compromise of a Certification Authority (CA) trusted 1901 to issue certificates for the XMPP-Grid Controller and/or XMPP-Grid 1902 Nodes is a major security breach. Many guidelines for proper CA 1903 security have been developed: the CA/Browser Forum's Baseline 1904 Requirements, the AICPA/CICA Trust Service Principles, etc. The CA 1905 operator and relying parties should agree on an appropriately 1906 rigorous security practices to be used. 1908 Even with the most rigorous security practices, a CA may be 1909 compromised. If this compromise is detected quickly, relying parties 1910 can remove the CA from their list of trusted CAs, and other CAs can 1911 revoke any certificates issued to the CA. However, CA compromise may 1912 go undetected for some time, and there's always the possibility that 1913 a CA is being operated improperly or in a manner that is not in the 1914 interests of the relying parties. For this reason, relying parties 1915 may wish to "pin" a small number of particularly critical 1916 certificates (such as the certificate for the XMPP-Grid Controller). 1917 Once a certificate has been pinned, the relying party will not accept 1918 another certificate in its place unless the Administrator explicitly 1919 commands it to do so. This does not mean that the relying party will 1920 not check the revocation status of pinned certificates. However, the 1921 Administrator may still be consulted if a pinned certificate is 1922 revoked, since the CA and revocation process are not completely 1923 trusted. 1925 5.4. Summary 1927 XMPP-Grid's considerable value as a broker for security-sensitive 1928 data exchange distribution also makes the protocol and the network 1929 security elements that implement it a target for attack. Therefore, 1930 strong security has been included as a basic design principle within 1931 the XMPP-Grid design process. 1933 The XMPP-Grid transport protocol provides strong protection against a 1934 variety of different attacks. In the event that a XMPP-Grid Node or 1935 XMPP-Grid Controller is compromised, the effects of this compromise 1936 have been reduced and limited with the recommended role-based 1937 authorization model and other provisions, and best practices for 1938 managing and protecting XMPP-Grid systems have been described. Taken 1939 together, these measures should provide protection commensurate with 1940 the threat to XMPP-Grid systems, thus ensuring that they fulfill 1941 their promise as a network security clearing-house. 1943 6. Privacy Considerations 1945 XMPP-Grid Nodes may publish information about endpoint health, 1946 network access, events (which may include information about what 1947 services an endpoint is accessing), roles and capabilities, and the 1948 identity of the end user operating the endpoint. Any of this 1949 published information may be queried by other XMPP-Grid Nodes and 1950 could potentially be used to correlate network activity to a 1951 particular end user. 1953 Dynamic and static information brokered by a XMPP-Grid Controller, 1954 ostensibly for purposes of correlation by XMPP-Grid Nodes for 1955 intrusion detection, could be misused by a broader set of XMPP-Grid 1956 Nodes which hitherto have been performing specific roles with strict 1957 well-defined separation of duties. 1959 Care should be taken by deployers of XMPP-Grid to ensure that the 1960 information published by XMPP-Grid Nodes does not violate agreements 1961 with end users or local and regional laws and regulations. This can 1962 be accomplished either by configuring XMPP-Grid Nodes to not publish 1963 certain information or by restricting access to sensitive data to 1964 trusted XMPP-Grid Nodes. That is, the easiest means to ensure 1965 privacy or protect sensitive data, is to omit or not share it at all. 1967 Another consideration for deployers is to enable end-to-end 1968 encryption to ensure the data is protected from the data layer to 1969 data layer and thus protect it from the transport layer. 1971 7. Acknowledgements 1973 The authors would like to acknowledge the contributions, authoring 1974 and/or editing of the following people: Joseph Salowey, Lisa 1975 Lorenzin, Clifford Kahn, Henk Birkholz, Jessica Fitzgerald-McKay, 1976 Steve Hanna, and Steve Venema. 1978 8. References 1980 8.1. Normative References 1982 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1983 Requirement Levels", BCP 14, RFC 2119, 1984 DOI 10.17487/RFC2119, March 1997, 1985 . 1987 [RFC3922] Saint-Andre, P., "Mapping the Extensible Messaging and 1988 Presence Protocol (XMPP) to Common Presence and Instant 1989 Messaging (CPIM)", RFC 3922, DOI 10.17487/RFC3922, October 1990 2004, . 1992 [RFC3923] Saint-Andre, P., "End-to-End Signing and Object Encryption 1993 for the Extensible Messaging and Presence Protocol 1994 (XMPP)", RFC 3923, DOI 10.17487/RFC3923, October 2004, 1995 . 1997 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 1998 Authentication and Security Layer (SASL)", RFC 4422, 1999 DOI 10.17487/RFC4422, June 2006, 2000 . 2002 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 2003 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 2004 March 2011, . 2006 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 2007 Protocol (XMPP): Instant Messaging and Presence", 2008 RFC 6121, DOI 10.17487/RFC6121, March 2011, 2009 . 2011 [XEP-0060] 2012 Millard, P. and P. Saint-Andre, "Publish-Subscribe", 2013 XSF XEP 0060, July 2010. 2015 8.2. Informative References 2017 [I-D.ietf-uta-tls-bcp] 2018 Sheffer, Y., Holz, R., and P. Saint-Andre, 2019 "Recommendations for Secure Use of TLS and DTLS", draft- 2020 ietf-uta-tls-bcp-11 (work in progress), February 2015. 2022 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2023 DOI 10.17487/RFC2818, May 2000, 2024 . 2026 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 2027 Object Description Exchange Format", RFC 5070, 2028 DOI 10.17487/RFC5070, December 2007, 2029 . 2031 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2032 (TLS) Protocol Version 1.2", RFC 5246, 2033 DOI 10.17487/RFC5246, August 2008, 2034 . 2036 Authors' Addresses 2038 Nancy Cam-Winget (editor) 2039 Cisco Systems 2040 3550 Cisco Way 2041 San Jose, CA 95134 2042 USA 2044 Email: ncamwing@cisco.com 2046 Syam Appala 2047 Cisco Systems 2048 3550 Cisco Way 2049 San Jose, CA 95134 2050 USA 2052 Email: syam1@cisco.com 2054 Scott Pope 2055 Cisco Systems 2056 5400 Meadows Road 2057 Suite 300 2058 Lake Oswego, OR 97035 2059 USA 2061 Email: scottp@cisco.com