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
1277
1278
1280
1299
1300
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