idnits 2.17.1 draft-ietf-mile-xmpp-grid-10.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 is 1 instance of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1874 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-0004' -- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0030' -- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0059' -- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0060' -- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0203' -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 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 12, 2019 Cisco Systems 6 P. Saint-Andre 7 Mozilla 8 March 11, 2019 10 Using XMPP for Security Information Exchange 11 draft-ietf-mile-xmpp-grid-10 13 Abstract 15 This document describes how to use the Extensible Messaging and 16 Presence Protocol (XMPP) to collect and distribute security incident 17 reports and other security-relevant information between network- 18 connected devices, primarily for the purpose of communication among 19 Computer Security Incident Response Teams and associated entities. 20 To illustrate the principles involved, this document describes such a 21 usage for the Incident Object Description Exchange Format (IODEF). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 12, 2019. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Service Discovery . . . . . . . . . . . . . . . . . . . . . . 7 62 6. Publish-Subscribe . . . . . . . . . . . . . . . . . . . . . . 9 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 8.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 13 66 8.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 14 67 8.3. Countermeasures . . . . . . . . . . . . . . . . . . . . . 18 68 8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 21 69 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 70 10. Operations and Management Considerations . . . . . . . . . . 23 71 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 72 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 73 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 74 12.2. Informative References . . . . . . . . . . . . . . . . . 25 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 77 1. Introduction 79 This document defines an architecture, i.e., "XMPP-Grid", as a method 80 for using the Extensible Messaging and Presence Protocol (XMPP) 81 [RFC6120] to collect and distribute security incident reports and 82 other security-relevant information among network platforms, 83 endpoints, and any other network-connected device, primarily for the 84 purpose of communication among Computer Security Incident Response 85 Teams and associated entities. In effect, this document specifies an 86 Applicability Statement ([RFC2026], Section 3.2) that defines how to 87 use XMPP for the exchange of security notifications on a controlled- 88 access network among authorized entities. 90 Among other things, XMPP provides a publish-subscribe service 91 [XEP-0060] that acts as a broker, enabling control-plane functions by 92 which entities can discover available information to be published or 93 consumed. Although such information can take the form of any 94 structured data (XML, JSON, etc.), this document illustrates the 95 principles of XMPP-Grid with examples that use the Incident Object 96 Description Exchange Format (IODEF) [RFC7970]. That is, while other 97 security information formats can be shared using XMPP, this document 98 uses IODEF as one such example format that can be published and 99 consumed using XMPP. 101 2. Terminology 103 This document uses XMPP terminology defined in [RFC6120] and 104 [XEP-0060]. Because the intended audience for this document is those 105 who implement and deploy security reporting systems, mappings are 106 provided for the benefit of XMPP developers and operators. 108 Broker: A specific type of controller containing control plane 109 functions; as used here, the term refers to an XMPP publish- 110 subscribe service. 112 Broker Flow: A method by which security incident reports and other 113 security-relevant information is published and consumed in a 114 mediated fashion through a Broker. In this flow, the Broker 115 handles authorization of Consumers and Providers to Topics, 116 receives messages from Providers, and delivers published messages 117 to Consumers. 119 Consumer: An entity that contains functions to receive information 120 from other components; as used here, the term refers to an XMPP 121 publish-subscribe Subscriber. 123 Controller: A "component containing control plane functions that 124 manage and facilitate information sharing or execute on security 125 functions"; as used here, the term refers to an XMPP server, which 126 provides core message delivery [RFC6120] used by publish-subscribe 127 entities. 129 Node: The XMPP term for a Topic. 131 Platform: Any entity that connects to the XMPP-Grid in order to 132 publish or consume security-relevant information. 134 Provider: An entity that contains functions to provide information 135 to other components; as used here, the term refers to an XMPP 136 publish-subscribe Publisher. 138 Topic: A contextual information channel created on a Broker at which 139 messages generated by a Provider are propagated in real time to 140 one or more Consumers. Each Topic is limited to a specific type 141 and format of security data (e.g. IODEF namespace) and provides 142 an XMPP interface by which the data can be obtained. 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in BCP 147 14 [RFC2119] [RFC8174] when, and only when, they appear in all 148 capitals, as shown here. 150 3. Architecture 152 The following figure illustrates the architecture of XMPP-Grid. 154 +--------------------------------------+ 155 | +--------------------------------------+ 156 | | +--------------------------------------+ 157 | | | | 158 +-| | Platforms | 159 +-| | 160 +--------------------------------------+ 161 / \ / \ / \ 162 / C \ / \ / \ 163 - o - - d - - - 164 ||n||A | a |B | |C 165 ||t|| | t | | | 166 - r - - a - | | 167 \ o / \ / | | 168 \ l / \ / | | 169 /|---------------------|\ | | 170 /|----/ \--------| d |--|\ 171 / / Controller \ ctrl | a | \ 172 \ \ & Broker / plane | t | / 173 \|----\ /--------| a |--|/ 174 \|---------------------|/ | | 175 / \ / \ | | 176 / C \ / \ | | 177 - o - - d - | | 178 ||n||A | a |B | |C 179 ||t|| | t | | | 180 - r - - a - - - 181 \ o / \ / \ / 182 \ l / \ / \ / 183 +------------------------------------+ 184 | |-+ 185 | Platforms | | 186 | | |-+ 187 +------------------------------------+ | | 188 +------------------------------------+ | 189 +------------------------------------+ 191 Figure 1: XMPP-Grid Architecture 193 Platforms connect to the Controller (XMPP server) to authenticate and 194 then establish appropriate authorizations to be a Provider or 195 Consumer of topics of interest at the Broker. The control plane 196 messaging is established through XMPP and shown as "A" (control plane 197 interface) in Figure 1. Authorized Platforms can then share data 198 either through the Broker (shown as "B" in Figure 1) or in some cases 199 directly (shown as "C" in Figure 1). This document focuses primarily 200 on the Broker Flow for information sharing ("direct flow" 201 interactions can be used for specialized purposes such as bulk data 202 transfer, but methods for doing so are outside the scope of this 203 document). 205 4. Workflow 207 Implementations of XMPP-Grid workflow adhere to the following 208 workflow: 210 a. A Platform with a source of security data requests connection to 211 the XMPP-Grid via a Controller. 213 b. The Controller authenticates the Platform. 215 c. The Platform establishes authorized privileges (e.g. privilege to 216 publish and/or subscribe to one or more Topics) with a Broker. 218 d. The Platform can publish security incident reports and other 219 security-relevant information to a Topic, subscribe to a Topic, 220 query a Topic, or any combination of these operations. 222 e. A Provider unicasts its Topic updates to the Grid in real time 223 through a Broker. The Broker handles replication and 224 distribution of the Topic to Consumers. A Provider can publish 225 the same or different data to multiple Topics. 227 f. Any Platform on the Grid can subscribe to any Topics published to 228 the Grid (as permitted by authorization policy), and (as 229 Consumers) will then receive a continual, real-time stream of 230 updates from the Topics to which it is subscribed. 232 The general workflow is summarized in the figure below: 234 +--------------+ +------------+ +---------------+ 235 | IODEF Client | | Controller | | IODEF Service | 236 | (Consumer) | | & Broker | | (Provider) | 237 +--------------+ +------------+ +---------------+ 238 | | | 239 | Establish XMPP | | 240 | Client Session | | 241 | (RFC 6120) | | 242 |--------------------->| | 243 | | Establish XMPP | 244 | | Client Session | 245 | | (RFC 6120) | 246 | |<------------------------| 247 | | Request Topic Creation | 248 | | (XEP-0060) | 249 | |<------------------------| 250 | | Topic Creation Success | 251 | | (XEP-0060) | 252 | |------------------------>| 253 | Request Topic List | | 254 | (XEP-0030) | | 255 |--------------------->| | 256 | Return Topic List | | 257 | (XEP-0030) | | 258 |<---------------------| | 259 | | | 260 | Query Each Topic | | 261 | (XEP-0030) | | 262 |--------------------->| | 263 | Return Topic Data | | 264 | Including Topic Type | | 265 | (XEP-0030) | | 266 |<---------------------| | 267 | | | 268 | Subscribe to IODEF | | 269 | Topic (XEP-0060) | | 270 |--------------------->| | 271 | Subscription Success | | 272 | (XEP-0060) | | 273 |<---------------------| | 274 | | Publish IODEF Incident | 275 | | (XEP-0060) | 276 | Receive IODEF |<------------------------| 277 | Incident (XEP-0060) | | 278 |<---------------------| | 279 | | | 281 Figure 2: IODEF Example Workflow 283 XMPP-Grid implementations MUST adhere to the mandatory-to-implement 284 and mandatory-to-negotiate features as defined in [RFC6120]. 285 Similarly, implementations MUST implement [XEP-0060] to facilitate 286 the asynchronous sharing for information. Implementations SHOULD 287 implement Service Discovery as defined in [XEP-0030] to facilitate 288 the means to dynamically discover the available information and 289 namespaces (Topics) to be published or consumed. Implementations 290 should take caution if their deployments allow for a large number of 291 topics. The Result Set Management as defined in [XEP-0059], SHOULD 292 be used to allow the requesting entity to explicitly request Service 293 Discovery result sets to be returned in pages or limited size, if the 294 discovery results are larger in size. Note that the control plane 295 may optionally also implement [XEP-0203] to facilitate delayed 296 delivery of messages to the connected consumer as described in 297 [XEP-0060]. Since information may be timely and sensitive, 298 capability providers should communicate to the controller whether its 299 messages can be cached for delayed delivery during configuration; 300 such function is out of scope for this document. 302 The following sections provide protocol examples for the service 303 discovery and publish-subscribe parts of the workflow. 305 5. Service Discovery 307 Using the XMPP service discovery extension [XEP-0030], a Controller 308 enables Platforms to discover what information can be consumed 309 through the Broker, and at which Topics. Platforms could use 310 [XEP-0059] to restrict the size of the result sets the Controller 311 returns in Service Discovery response. As an example, the Controller 312 at 'security-grid.example' might provide a Broker at 313 'broker.security-grid.example' hosting a number of Topics. A 314 Platform at 'xmpp-grid-client@mile-host.example' would query the 315 Broker about its available Topics by sending an XMPP "disco#items" 316 request to the Broker: 318 322 323 325 The Broker responds with the Topics it hosts: 327 331 332 335 338 339 341 In order to determine the exact nature of each Topic (i.e., in order 342 to find topics that publish incidents in the IODEF format), a 343 Platform would send an XMPP "disco#info" request to each Topic: 345 351 353 The Broker responds with the "disco#info" description, which MUST 354 include an XMPP Data Form [XEP-0004] including a 'pubsub#type' field 355 that specifies the supported namespace (in this example, the IODEF 356 namespace defined in [RFC7970]): 358 362 364 365 366 367 368 http://jabber.org/protocol/pubsub#meta-data 369 370 371 urn:ietf:params:xml:ns:iodef-2.0 372 373 374 375 377 The Platform discovers the topics by obtaining the Broker's response 378 and obtaining the namespaces returned in the "pubsub#type" field (in 379 the foregoing example, IODEF 2.0). 381 6. Publish-Subscribe 383 Using the XMPP publish-subscribe extension [XEP-0060], a Consumer 384 subscribes to a Topic and a Provider publishes information to that 385 Topic, which the Broker then distributes to all subscribed Consumers. 387 First, a Provider would create a Topic as follows: 389 393 394 395 396 398 Note: The foregoing example is the minimal protocol needed to create 399 a Topic with the default node configuration on the XMPP publish- 400 subscribe service specified in the 'to' address of the creation 401 request stanza. Depending on security requirements, the Provider 402 might need to request a non-default configuration for the node; see 403 [XEP-0060] for detailed examples. To also help with the Topic 404 configuration, the Provider may also optionally include 405 configurations parameters such as: 407 408 409 410 http://jabber.org/protocol/pubsub#node_config 411 412 authorize 413 1 414 never 415 416 418 The above configuration indicates the Topic is configured to enable 419 the XMPP-Controller to manage the subscriptions, be in persistent 420 mode and disables the Broker from cacheing the last item published. 421 Please refer to [XEP-0060] a more detailed description of these 422 configuration and other available configuration options. 424 Unless an error occurs (see [XEP-0060] for various error flows), the 425 Broker responds with success: 427 432 Second, a Consumer would subscribe as follows: 434 438 439 441 442 444 Unless an error occurs (see [XEP-0060] for various error flows), the 445 Broker responds with success: 447 451 452 456 457 459 Third, a Provider would publish an incident to the broker using the 460 MILEHost topic as follows: 462 466 467 468 469 475 476 492382 477 2015-07-18T09:00:00-05:00 478 479 480 contact@csirt.example.com 481 482 483 484 485 486 487 488 490 (The payload in the foregoing example is from [RFC7970]; payloads for 491 additional use cases can be found in [RFC8274].) 493 The Broker would then deliver that incident report to all Consumers 494 who are subscribed to the Topic: 496 500 501 502 503 509 510 492382 511 2015-07-18T09:00:00-05:00 512 513 514 contact@csirt.example.com 515 516 517 518 519 520 521 522 524 7. IANA Considerations 526 This document has no actions for IANA. 528 8. Security Considerations 530 An XMPP-Grid Controller serves as an controlling broker for XMPP-Grid 531 Platforms such as Enforcement Points, Policy Servers, CMDBs, and 532 Sensors, using a publish-subscribe-search model of information 533 exchange and lookup. By increasing the ability of XMPP-Grid 534 Platforms to learn about and respond to security incident reports and 535 other security-relevant information, XMPP-Grid can improve the 536 timeliness and utility of the security system. However, this 537 integrated security system can also be exploited by attackers if they 538 can compromise it. Therefore, strong security protections for XMPP- 539 Grid are essential. 541 As XMPP is the core of this document, the security considerations of 542 [RFC6120] applies. In addition, as XMPP-Grid defines a specific 543 instance, this section provides a security analysis of the XMPP-Grid 544 data transfer protocol and the architectural elements that employ it, 545 specifically with respect to their use of this protocol. Three 546 subsections define the trust model (which elements are trusted to do 547 what), the threat model (attacks that can be mounted on the system), 548 and the countermeasures (ways to address or mitigate the threats 549 previously identified). 551 8.1. Trust Model 553 The first step in analyzing the security of the XMPP-Grid transport 554 protocol is to describe the trust model, listing what each 555 architectural element is trusted to do. The items listed here are 556 assumptions, but provisions are made in the Threat Model and 557 Countermeasures sections for elements that fail to perform as they 558 were trusted to do. 560 8.1.1. Network 562 The network used to carry XMPP-Grid messages (i.e., the underlying 563 network transport layer over which XMPP runs) is trusted to: 565 o Perform best effort delivery of network traffic 567 The network used to carry XMPP-Grid messages is not expected 568 (trusted) to: 570 o Provide confidentiality or integrity protection for messages sent 571 over it 573 o Provide timely or reliable service 575 8.1.2. XMPP-Grid Platforms 577 Authorized XMPP-Grid Platforms are trusted to: 579 o Preserve the confidentiality of sensitive data retrieved via the 580 XMPP-Grid Controller 582 8.1.3. XMPP-Grid Controller 584 The XMPP-Grid Controller (including its associated Broker) is trusted 585 to: 587 o Broker requests for data and enforce authorization of access to 588 this data throughout its lifecycle 590 o Perform service requests in a timely and accurate manner 591 o Create and maintain accurate operational attributes 593 o Only reveal data to and accept service requests from authorized 594 parties 596 The XMPP-Grid Controller is not expected (trusted) to: 598 o Verify the truth (correctness) of data 600 8.1.4. Certification Authority 602 To allow XMPP-Grid Platforms to mutually authenticate with XMPP-Grid 603 Controllers, it is expected that a Certification Authority (CA) is 604 employed to issue certificates. Such a CA (or each CA, if there are 605 several) is trusted to: 607 o Ensure that only proper certificates are issued and that all 608 certificates are issued in accordance with the CA's policies 610 o Revoke certificates previously issued when necessary 612 o Regularly and securely distribute certificate revocation 613 information 615 o Promptly detect and report any violations of this trust so that 616 they can be handled 618 The CA is not expected (trusted) to: 620 o Issue certificates that go beyond the XMPP-Grid needs or other 621 constraints imposed by a relying party. 623 8.2. Threat Model 625 To secure the XMPP-Grid data transfer protocol and the architectural 626 elements that implement it, this section identifies the attacks that 627 can be mounted against the protocol and elements. 629 8.2.1. Network Attacks 631 A variety of attacks can be mounted using the network. For the 632 purposes of this subsection the phrase "network traffic" can be taken 633 to mean messages and/or parts of messages. Any of these attacks can 634 be mounted by network elements, by parties who control network 635 elements, and (in many cases) by parties who control network-attached 636 devices. 638 o Network traffic can be passively monitored to glean information 639 from any unencrypted traffic 641 o Even if all traffic is encrypted, valuable information can be 642 gained by traffic analysis (volume, timing, source and destination 643 addresses, etc.) 645 o Network traffic can be modified in transit 647 o Previously transmitted network traffic can be replayed 649 o New network traffic can be added 651 o Network traffic can be blocked, perhaps selectively 653 o A "Man In The Middle" (MITM) attack can be mounted where an 654 attacker interposes itself between two communicating parties and 655 poses as the other end to either party or impersonates the other 656 end to either or both parties 658 o Undesired network traffic can be sent in an effort to overload an 659 architectural component, thus mounting a denial of service attack 661 8.2.2. XMPP-Grid Platforms 663 An unauthorized XMPP-Grid Platform (one which is not recognized by 664 the XMPP-Grid Controller or is recognized but not authorized to 665 perform any actions) cannot mount any attacks other than those listed 666 in the Network Attacks section above. 668 An authorized XMPP-Grid Platform, on the other hand, can mount many 669 attacks. These attacks might occur because the XMPP-Grid Platform is 670 controlled by a malicious, careless, or incompetent party (whether 671 because its owner is malicious, careless, or incompetent or because 672 the XMPP-Grid Platform has been compromised and is now controlled by 673 a party other than its owner). They might also occur because the 674 XMPP-Grid Platform is running malicious software; because the XMPP- 675 Grid Platform is running buggy software (which can fail in a state 676 that floods the network with traffic); or because the XMPP-Grid 677 Platform has been configured improperly. From a security standpoint, 678 it generally makes no difference why an attack is initiated. The 679 same countermeasures can be employed in any case. 681 Here is a list of attacks that can be mounted by an authorized XMPP- 682 Grid Platform: 684 o Cause many false alarms or otherwise overload the XMPP-Grid 685 Controller or other elements in the network security system 686 (including human administrators) leading to a denial of service or 687 disabling parts of the network security system 689 o Omit important actions (such as posting incriminating data), 690 resulting in incorrect access 692 o Use confidential information obtained from the XMPP-Grid 693 Controller to enable further attacks (such as using endpoint 694 health check results to exploit vulnerable endpoints) 696 o Advertise data crafted to exploit vulnerabilities in the XMPP-Grid 697 Controller or in other XMPP-Grid Platforms, with a goal of 698 compromising those systems 700 o Issue a search request or set up a subscription that matches an 701 enormous result, leading to resource exhaustion on the XMPP-Grid 702 Controller, the publishing XMPP-Grid Platform, and/or the network 704 o Establish a communication channel using another XMPP-Grid 705 Platform's session-id 707 Dependencies of or vulnerabilities of authorized XMPP-Grid Platforms 708 can be exploited to effect these attacks. Another way to effect 709 these attacks is to gain the ability to impersonate an XMPP-Grid 710 Platform (through theft of the XMPP-Grid Platform's identity 711 credentials or through other means). Even a clock skew between the 712 XMPP-Grid Platform and XMPP-Grid Controller can cause problems if the 713 XMPP-Grid Platform assumes that old XMPP-Grid Platform data should be 714 ignored. 716 8.2.3. XMPP-Grid Controllers 718 An unauthorized XMPP-Grid Controller (one which is not trusted by 719 XMPP-Grid Platforms) cannot mount any attacks other than those listed 720 in the Network Attacks section above. 722 An authorized XMPP-Grid Controller can mount many attacks. Similar 723 to the XMPP-Grid Platform case described above, these attacks might 724 occur because the XMPP-Grid Controller is controlled by a malicious, 725 careless, or incompetent party (either an XMPP-Grid Controller 726 administrator or an attacker who has seized control of the XMPP-Grid 727 Controller). They might also occur because the XMPP-Grid Controller 728 is running malicious software, because the XMPP-Grid Controller is 729 running buggy software (which can fail in a state that corrupts data 730 or floods the network with traffic), or because the XMPP-Grid 731 Controller has been configured improperly. 733 All of the attacks listed for XMPP-Grid Platform above can be mounted 734 by the XMPP-Grid Controller. Detection of these attacks will be more 735 difficult since the XMPP-Grid Controller can create false operational 736 attributes and/or logs that imply some other party created any bad 737 data. 739 Additional XMPP-Grid Controller attacks can include: 741 o Expose different data to different XMPP-Grid Platforms to mislead 742 investigators or cause inconsistent behavior 744 o Mount an even more effective denial of service attack than a 745 single XMPP-Grid Platform could 747 o Obtain and cache XMPP-Grid Platform credentials so they can be 748 used to impersonate XMPP-Grid Platforms even after a breach of the 749 XMPP-Grid Controller is repaired 751 o Obtain and cache XMPP-Grid Controller administrator credentials so 752 they can be used to regain control of the XMPP-Grid Controller 753 after the breach of the XMPP-Grid Controller is repaired 755 o Eavesdrop, inject or modify the data being transferred between 756 provider and consumer 758 Dependencies of or vulnerabilities of the XMPP-Grid Controller can be 759 exploited to obtain control of the XMPP-Grid Controller and effect 760 these attacks. 762 8.2.4. Certification Authority 764 A Certification Authority trusted to issue certificates for the XMPP- 765 Grid Controller and/or XMPP-Grid Platforms can mount several attacks: 767 o Issue certificates for unauthorized parties, enabling them to 768 impersonate authorized parties such as the XMPP-Grid Controller or 769 an XMPP-Grid Platform. This can lead to all the threats that can 770 be mounted by the certificate's subject. 772 o Issue certificates without following all of the CA's policies. 773 Because this can result in issuing certificates that can be used 774 to impersonate authorized parties, this can lead to all the 775 threats that can be mounted by the certificate's subject. 777 o Fail to revoke previously issued certificates that need to be 778 revoked. This can lead to undetected impersonation of the 779 certificate's subject or failure to revoke authorization of the 780 subject, and therefore can lead to all of the threats that can be 781 mounted by that subject. 783 o Fail to regularly and securely distribute certificate revocation 784 information. This can cause a relying party to accept a revoked 785 certificate, leading to undetected impersonation of the 786 certificate's subject or failure to revoke authorization of the 787 subject, and therefore can lead to all of the threats that can be 788 mounted by that subject. It can also cause a relying party to 789 refuse to proceed with a transaction because timely revocation 790 information is not available, even though the transaction should 791 be permitted to proceed. 793 o Allow the CA's private key to be revealed to an unauthorized 794 party. This can lead to all the threats above. Even worse, the 795 actions taken with the private key will not be known to the CA. 797 o Fail to promptly detect and report errors and violations of trust 798 so that relying parties can be promptly notified. This can cause 799 the threats listed earlier in this section to persist longer than 800 necessary, leading to many knock-on effects. 802 8.3. Countermeasures 804 Below are countermeasures for specific attack scenarios to the XMPP- 805 Grid infrastructure. 807 8.3.1. Securing the XMPP-Grid Data Transfer Protocol 809 To address network attacks, the XMPP-Grid data transfer protocol 810 described in this document requires that the XMPP-Grid messages MUST 811 be carried over TLS (minimally TLS 1.2 [RFC8446]) as described in 812 [RFC6120] and updated by [RFC7590]. The XMPP-Grid Controller and 813 XMPP-Grid Platforms SHOULD mutually authenticate. The XMPP-Grid 814 Platform MUST verify the XMPP-Grid Controller's certificate and 815 determine whether the XMPP-Grid Controller is trusted by this XMPP- 816 Grid Platform before completing the TLS handshake. To ensure 817 interoperability, implementations MUST implement at least one of 818 either the SASL EXTERNAL mechanism [RFC4422] or the SASL SCRAM 819 mechanism. When using the SASL SCRAM mechanism, the SCRAM-SHA- 820 256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant; 821 and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 822 variants [RFC5802]). XMPP-Grid Platforms and XMPP-Grid Controllers 823 using certificate-based authentication SHOULD each verify the 824 revocation status of the other party's certificate. The selection of 825 which XMPP-Grid Platform authentication technique to use in any 826 particular deployment is left to the administrator. 828 These protocol security measures provide protection against all the 829 network attacks listed in the above document section except denial of 830 service attacks. If protection against these denial of service 831 attacks is desired, ingress filtering, rate limiting per source IP 832 address, and other denial of service mitigation measures can be 833 employed. In addition, an XMPP-Grid Controller MAY automatically 834 disable a misbehaving XMPP-Grid Platform. 836 8.3.2. Securing XMPP-Grid Platforms 838 XMPP-Grid Platforms can be deployed in locations that are susceptible 839 to physical attacks. Physical security measures can be taken to 840 avoid compromise of XMPP-Grid Platforms, but these are not always 841 practical or completely effective. An alternative measure is to 842 configure the XMPP-Grid Controller to provide read-only access for 843 such systems. The XMPP-Grid Controller SHOULD also include a full 844 authorization model so that individual XMPP-Grid Platforms can be 845 configured to have only the privileges that they need. The XMPP-Grid 846 Controller MAY provide functional templates so that the administrator 847 can configure a specific XMPP-Grid Platform as a DHCP [RFC2131] 848 server and authorize only the operations and metadata types needed by 849 a DHCP server to be permitted for that XMPP-Grid Platform. These 850 techniques can reduce the negative impacts of a compromised XMPP-Grid 851 Platform without diminishing the utility of the overall system. 853 To handle attacks within the bounds of this authorization model, the 854 XMPP-Grid Controller MAY also include rate limits and alerts for 855 unusual XMPP-Grid Platform behavior. XMPP-Grid Controllers SHOULD 856 make it easy to revoke an XMPP-Grid Platform's authorization when 857 necessary. The XMPP-Grid Controller SHOULD include auditable logs of 858 XMPP-Grid Platform activities. 860 To avoid compromise of XMPP-Grid Platform, XMPP-Grid Platform SHOULD 861 be hardened against attack and minimized to reduce their attack 862 surface. They should be well managed to minimize vulnerabilities in 863 the underlying platform and in systems upon which the XMPP-Grid 864 Platform depends. Personnel with administrative access should be 865 carefully screened and monitored to detect problems as soon as 866 possible. 868 8.3.3. Securing XMPP-Grid Controllers 870 Because of the serious consequences of XMPP-Grid Controller 871 compromise, XMPP-Grid Controllers need to be especially well hardened 872 against attack and minimized to reduce their attack surface. They 873 need to be well managed to minimize vulnerabilities in the underlying 874 platform and in systems upon which the XMPP-Grid Controller depends. 875 Network security measures such as firewalls or intrusion detection 876 systems can be used to monitor and limit traffic to and from the 877 XMPP-Grid Controller. Personnel with administrative access ought to 878 be carefully screened and monitored to detect problems as soon as 879 possible. Administrators SHOULD NOT use password-based 880 authentication but SHOULD instead use non-reusable credentials and 881 multi-factor authentication (where available). Physical security 882 measures ought to be employed to prevent physical attacks on XMPP- 883 Grid Controllers. 885 To ease detection of XMPP-Grid Controller compromise should it occur, 886 XMPP-Grid Controller behavior should be monitored to detect unusual 887 behavior (such as a reboot, a large increase in traffic, or different 888 views of an information repository for similar XMPP-Grid Platforms). 889 It is a matter of local policy whether XMPP-Grid Platforms log and/or 890 notify administrators when peculiar XMPP-Grid Controller behavior is 891 detected, and whether read-only audit logs of security-relevant 892 information (especially administrative actions) are maintained; 893 however, such behavior is encouraged to aid in forensic analysis. 894 Furthermore, if compromise of an XMPP-Grid Controller is detected, a 895 careful analysis should be performed and any reusable credentials 896 that can have been compromised should be reissued. 898 To address the potential for the XMPP-Grid controller to eavesdrop, 899 modify or inject data, it would be desirable to deploy end-to-end 900 encryption between the provider and the consumer(s). Unfortunately, 901 because there is no standardized method for encryption of one-to-many 902 messages within XMPP, techniques for enforcing end-to-end encryption 903 are out of scope for this specification. 905 8.3.4. Broker Access Models for Topics 907 The XMPP publish-subscribe specification [XEP-0060] defines five 908 access models for subscribing to Topics at a Broker: open, presence, 909 roster, authorize, and whitelist. The first model allows 910 uncontrolled access and the next two models are appropriate only in 911 instant-messaging applications. Therefore, a Broker SHOULD support 912 only the authorize model (under which the Topic owner needs to 913 approve all subscription requests and only subscribers can retrieve 914 data items) and the whitelist model (under which only preconfigured 915 Platforms can subscribe or retrieve data items). In order to ease 916 the deployment burden, subscription approvals and whitelist 917 management can be automated (e.g, the Topic "owner" can be a policy 918 server). The choice between "authorize" and "whitelist" as the 919 default access model is a matter for local service policy. 921 8.3.5. Limit on Search Result Size 923 While XMPP-Grid is designed for high scalability to 100,000s of 924 Platforms, an XMPP-Grid Controller MAY establish a limit to the 925 amount of data it is willing to return in search or subscription 926 results. Platforms could use [XEP-0059] to restrict the size of the 927 result sets the Controller returns in search or subscription results 928 or topics' service discovery. This mitigates the threat of an XMPP- 929 Grid Platform causing resource exhaustion by issuing a search or 930 subscription that leads to an enormous result. 932 8.3.6. Securing the Certification Authority 934 As noted above, compromise of a Certification Authority (CA) trusted 935 to issue certificates for the XMPP-Grid Controller and/or XMPP-Grid 936 Platforms is a major security breach. Many guidelines for proper CA 937 security have been developed: the CA/Browser Forum's Baseline 938 Requirements, the AICPA/CICA Trust Service Principles, the IETF's 939 Certificate Transparency [RFC6962] etc. The CA operator and relying 940 parties should agree on an appropriately rigorous security practices 941 to be used. 943 Even with the most rigorous security practices, a CA can be 944 compromised. If this compromise is detected quickly, relying parties 945 can remove the CA from their list of trusted CAs, and other CAs can 946 revoke any certificates issued to the CA. However, CA compromise may 947 go undetected for some time, and there's always the possibility that 948 a CA is being operated improperly or in a manner that is not in the 949 interests of the relying parties. For this reason, relying parties 950 may wish to "pin" a small number of particularly critical 951 certificates (such as the certificate for the XMPP-Grid Controller). 952 Once a certificate has been pinned, the relying party will not accept 953 another certificate in its place unless the Administrator explicitly 954 commands it to do so. This does not mean that the relying party will 955 not check the revocation status of pinned certificates. However, the 956 Administrator can still be consulted if a pinned certificate is 957 revoked, since the CA and revocation process are not completely 958 trusted. By "pinning" one or a small set of certificates, the 959 relying party has the effective XMPP-Grid Controller(s) authorized to 960 connect to. 962 8.4. Summary 964 XMPP-Grid's considerable value as a broker for security-sensitive 965 data exchange distribution also makes the protocol and the network 966 security elements that implement it a target for attack. Therefore, 967 strong security has been included as a basic design principle within 968 the XMPP-Grid design process. 970 The XMPP-Grid data transfer protocol provides strong protection 971 against a variety of different attacks. In the event that an XMPP- 972 Grid Platform or XMPP-Grid Controller is compromised, the effects of 973 this compromise have been reduced and limited with the recommended 974 role-based authorization model and other provisions, and best 975 practices for managing and protecting XMPP-Grid systems have been 976 described. Taken together, these measures should provide protection 977 commensurate with the threat to XMPP-Grid systems, thus ensuring that 978 they fulfill their promise as a network security clearing-house. 980 9. Privacy Considerations 982 XMPP-Grid Platforms can publish information about endpoint health, 983 network access, events (which can include information about what 984 services an endpoint is accessing), roles and capabilities, and the 985 identity of the end user operating the endpoint. Any of this 986 published information can be queried by other XMPP-Grid Platforms and 987 could potentially be used to correlate network activity to a 988 particular end user. 990 Dynamic and static information brokered by an XMPP-Grid Controller, 991 ostensibly for purposes of correlation by XMPP-Grid Platforms for 992 intrusion detection, could be misused by a broader set of XMPP-Grid 993 Platforms which hitherto have been performing specific roles with 994 strict well-defined separation of duties. 996 Care needs to be taken by deployers of XMPP-Grid to ensure that the 997 information published by XMPP-Grid Platforms does not violate 998 agreements with end users or local and regional laws and regulations. 999 This can be accomplished either by configuring XMPP-Grid Platforms to 1000 not publish certain information or by restricting access to sensitive 1001 data to trusted XMPP-Grid Platforms. That is, the easiest means to 1002 ensure privacy or protect sensitive data, is to omit or not share it 1003 at all. 1005 Similarly, care must be taken by deployers and XMPP-Grid Controller 1006 implementations as they implement the appropriate auditing tools. In 1007 particular, any information, such as logs must be sensitive to the 1008 type of information stored to ensure that the information does not 1009 violate privacy and agreements with end users or local and regional 1010 laws and regulations. 1012 Another consideration for deployers is to enable end-to-end 1013 encryption to ensure the data is protected from the data layer to 1014 data layer and thus protect it from the transport layer. The means 1015 to achieve end-to-end encrpytion is beyond the scope of this 1016 document. 1018 10. Operations and Management Considerations 1020 In order to facilitate the management of Providers and the onboarding 1021 of Consumers, it is helpful to generate the following ahead of time: 1023 o Agreement between the operators of Provider services and the 1024 implementers of Consumer software regarding identifiers for common 1025 Topics (e.g., these could be registered with the XMPP Software 1026 Foundation's registry of well-known nodes for service discovery 1027 and publish-subscribe located at ). 1030 o Security certificates (including appropriate certificate chains) 1031 for Controllers, including identification of any Providers 1032 associated with the Controllers (which might be located at 1033 subdomains). 1035 o Consistent and secure access control policies for publishing and 1036 subscribing to Topics. 1038 These matters are out of scope for this document but ought to be 1039 addressed by the XMPP-Grid community. 1041 11. Acknowledgements 1043 The authors would like to acknowledge the contributions, authoring 1044 and/or editing of the following people: Joseph Salowey, Lisa 1045 Lorenzin, Clifford Kahn, Henk Birkholz, Jessica Fitzgerald-McKay, 1046 Steve Hanna, and Steve Venema. In addition, we want to thank Takeshi 1047 Takahashi, Panos Kampanakis, Adam Montville, Chris Inacio, and Dave 1048 Cridland for reviewing and providing valuable comments. 1050 12. References 1052 12.1. Normative References 1054 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1055 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 1056 . 1058 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1059 Requirement Levels", BCP 14, RFC 2119, 1060 DOI 10.17487/RFC2119, March 1997, 1061 . 1063 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 1064 Authentication and Security Layer (SASL)", RFC 4422, 1065 DOI 10.17487/RFC4422, June 2006, 1066 . 1068 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 1069 "Salted Challenge Response Authentication Mechanism 1070 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, 1071 DOI 10.17487/RFC5802, July 2010, 1072 . 1074 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1075 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1076 March 2011, . 1078 [RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer 1079 Security (TLS) in the Extensible Messaging and Presence 1080 Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June 1081 2015, . 1083 [RFC7677] Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple 1084 Authentication and Security Layer (SASL) Mechanisms", 1085 RFC 7677, DOI 10.17487/RFC7677, November 2015, 1086 . 1088 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1089 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1090 May 2017, . 1092 [XEP-0004] 1093 Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and 1094 P. Saint-Andre, "Data Forms", XSF XEP 0004, August 2007. 1096 [XEP-0030] 1097 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 1098 Andre, "Service Discovery", XSF XEP 0030, July 2010. 1100 [XEP-0059] 1101 Paterson, I., Saint-Andre, P., Mercier, V., and J. 1102 Seguineau, "Result Set Management", XSF XEP 0059, 1103 September 2006. 1105 [XEP-0060] 1106 Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 1107 Subscribe", XSF XEP 0060, December 2017. 1109 [XEP-0203] 1110 Saint-Andre, P., "Delayed Delivery", XSF XEP 0203, 1111 December 2009. 1113 12.2. Informative References 1115 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1116 RFC 2131, DOI 10.17487/RFC2131, March 1997, 1117 . 1119 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 1120 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 1121 . 1123 [RFC7970] Danyliw, R., "The Incident Object Description Exchange 1124 Format Version 2", RFC 7970, DOI 10.17487/RFC7970, 1125 November 2016, . 1127 [RFC8274] Kampanakis, P. and M. Suzuki, "Incident Object Description 1128 Exchange Format Usage Guidance", RFC 8274, 1129 DOI 10.17487/RFC8274, November 2017, 1130 . 1132 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1133 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1134 . 1136 Authors' Addresses 1138 Nancy Cam-Winget (editor) 1139 Cisco Systems 1140 3550 Cisco Way 1141 San Jose, CA 95134 1142 USA 1144 Email: ncamwing@cisco.com 1146 Syam Appala 1147 Cisco Systems 1148 3550 Cisco Way 1149 San Jose, CA 95134 1150 USA 1152 Email: syam1@cisco.com 1153 Scott Pope 1154 Cisco Systems 1155 5400 Meadows Road 1156 Suite 300 1157 Lake Oswego, OR 97035 1158 USA 1160 Email: scottp@cisco.com 1162 Peter Saint-Andre 1163 Mozilla 1165 Email: stpeter@mozilla.com