idnits 2.17.1 draft-ietf-mile-xmpp-grid-08.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 4, 2018) is 1999 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: May 8, 2019 Cisco Systems 6 P. Saint-Andre 7 Mozilla 8 November 4, 2018 10 Using XMPP for Security Information Exchange 11 draft-ietf-mile-xmpp-grid-08 13 Abstract 15 This document describes how to use the Extensible Messaging and 16 Presence Protocol (XMPP) to collect and distribute security-relevant 17 information between network-connected devices. To illustrate the 18 principles involved, this document describes such a usage for the 19 Incident Object Description Exchange Format (IODEF). 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 https://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 May 8, 2019. 38 Copyright Notice 40 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5. Service Discovery . . . . . . . . . . . . . . . . . . . . . . 7 60 6. Publish-Subscribe . . . . . . . . . . . . . . . . . . . . . . 8 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 63 8.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 12 64 8.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 13 65 8.3. Countermeasures . . . . . . . . . . . . . . . . . . . . . 17 66 8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 20 67 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 68 10. Operations and Management Considerations . . . . . . . . . . 21 69 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 70 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 71 12.1. Normative References . . . . . . . . . . . . . . . . . . 22 72 12.2. Informative References . . . . . . . . . . . . . . . . . 22 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 75 1. Introduction 77 This document describes "XMPP-Grid": a method for using the 78 Extensible Messaging and Presence Protocol (XMPP) [RFC6120] to 79 collect and distribute security-relevant information among network 80 platforms, endpoints, and any other network-connected device. Among 81 other things, XMPP provides a publish-subscribe service [XEP-0060] 82 that acts as a broker, enabling control-plane functions by which 83 entities can discover available information to be published or 84 consumed. Although such information can take the form of any 85 structured data (XML, JSON, etc.), this document illustrates the 86 principles of XMPP-Grid with examples that use the Incident Object 87 Description Exchange Format (IODEF) [RFC7970]. That is, while other 88 security information formats can be shared using XMPP, this document 89 uses IODEF as one such example format that can be published and 90 consumed using XMPP. 92 2. Terminology 94 This document uses XMPP terminology defined in [RFC6120] and 95 [XEP-0060]. Because the intended audience for this document is those 96 who implement and deploy security reporting systems, mappings are 97 provided for the benefit of XMPP developers and operators. 99 Broker: A specific type of controller containing control plane 100 functions; as used here, the term refers to an XMPP publish- 101 subscribe service. 103 Broker Flow: A method by which security-related information is 104 published and consumed in a mediated fashion through a Broker. In 105 this flow, the Broker handles authorization of Consumers and 106 Providers to Topics, receives messages from Providers, and 107 delivers published messages to Consumers. 109 Consumer: An entity that contains functions to receive information 110 from other components; as used here, the term refers to an XMPP 111 publish-subscribe Subscriber. 113 Controller: A "component containing control plane functions that 114 manage and facilitate information sharing or execute on security 115 functions"; as used here, the term refers to an XMPP server, which 116 provides core message delivery [RFC6120] used by publish-subscribe 117 entities. 119 Node: The XMPP term for a Topic. 121 Platform: Any entity that connects to the XMPP-Grid in order to 122 publish or consume security-related data. 124 Provider: An entity that contains functions to provide information 125 to other components; as used here, the term refers to an XMPP 126 publish-subscribe Publisher. 128 Topic: A contextual information channel created on a Broker at which 129 messages generated by a Provider are propagated in real time to 130 one or more Consumers. Each Topic is limited to a specific type 131 and format of security data (e.g. IODEF namespace) and provides 132 an XMPP interface by which the data can be obtained. 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in BCP 137 14 [RFC2119] [RFC8174] when, and only when, they appear in all 138 capitals, as shown here. 140 3. Architecture 142 The following figure illustrates the architecture of XMPP-Grid. 144 +--------------------------------------+ 145 | +--------------------------------------+ 146 | | +--------------------------------------+ 147 | | | | 148 +-| | Platforms | 149 +-| | 150 +--------------------------------------+ 151 / \ / \ / \ 152 / C \ / \ / \ 153 - o - - d - - - 154 ||n||A | a |B | |C 155 ||t|| | t | | | 156 - r - - a - | | 157 \ o / \ / | | 158 \ l / \ / | | 159 /|---------------------|\ | | 160 /|----/ \--------| d |--|\ 161 / / Controller \ ctrl | a | \ 162 \ \ & Broker / plane | t | / 163 \|----\ /--------| a |--|/ 164 \|---------------------|/ | | 165 / \ / \ | | 166 / C \ / \ | | 167 - o - - d - | | 168 ||n||A | a |B | |C 169 ||t|| | t | | | 170 - r - - a - - - 171 \ o / \ / \ / 172 \ l / \ / \ / 173 +------------------------------------+ 174 | |-+ 175 | Platforms | | 176 | | |-+ 177 +------------------------------------+ | | 178 +------------------------------------+ | 179 +------------------------------------+ 181 Figure 1: XMPP-Grid Architecture 183 Platforms connect to the Controller (XMPP server) to authenticate and 184 then establish appropriate authorizations to be a Provider or 185 Consumer of interested Topics at the Broker. The control plane 186 messaging is established through XMPP and shown as "A" (control plane 187 interface) in Figure 1. Authorized nodes can then share data either 188 through the Broker (shown as "B" in Figure 1) or in some cases 189 directly (shown as "C" in Figure 1). This document focuses primarily 190 on the Broker Flow for information sharing ("direct flow" 191 interactions can be used for specialized purposes such as bulk data 192 transfer, but methods for doing so are outside the scope of this 193 document). 195 4. Workflow 197 A typical XMPP-Grid workflow is as follows: 199 a. A Platform with a source of security data requests connection to 200 the XMPP-Grid via a Controller. 202 b. The Controller authenticates the Platform. 204 c. The Platform establishes authorized privileges (e.g. privilege to 205 publish and/or subscribe to one or more Topics) with a Broker. 207 d. The Platform can publish security-related data to a Topic, 208 subscribe to a Topic, query a Topic, or any combination of these 209 operations. 211 e. A Provider unicasts its Topic updates to the Grid in real time 212 through a Broker. The Broker handles replication and 213 distribution of the Topic to Consumers. A Provider can publish 214 the same or different data to multiple Topics. 216 f. Any Platform on the Grid can subscribe to any Topics published to 217 the Grid (as permitted by authorization policy), and (as 218 Consumers) will then receive a continual, real-time stream of 219 updates from the Topics to which it is subscribed. 221 The general workflow is summarized in the figure below: 223 +--------------+ +------------+ +---------------+ 224 | IODEF Client | | Controller | | IODEF Service | 225 | (Consumer) | | & Broker | | (Provider) | 226 +--------------+ +------------+ +---------------+ 227 | | | 228 | Establish XMPP | | 229 | Client Session | | 230 | (RFC 6120) | | 231 |--------------------->| | 232 | | Establish XMPP | 233 | | Client Session | 234 | | (RFC 6120) | 235 | |<------------------------| 236 | | Request Topic Creation | 237 | | (XEP-0060) | 238 | |<------------------------| 239 | | Topic Creation Success | 240 | | (XEP-0060) | 241 | |------------------------>| 242 | Request Topic List | | 243 | (XEP-0030) | | 244 |--------------------->| | 245 | Return Topic List | | 246 | (XEP-0030) | | 247 |<---------------------| | 248 | | | 249 | Query Each Topic | | 250 | (XEP-0030) | | 251 |--------------------->| | 252 | Return Topic Data | | 253 | Including Topic Type | | 254 | (XEP-0030) | | 255 |<---------------------| | 256 | | | 257 | Subscribe to IODEF | | 258 | Topic (XEP-0060) | | 259 |--------------------->| | 260 | Subscription Success | | 261 | (XEP-0060) | | 262 |<---------------------| | 263 | | Publish IODEF Incident | 264 | | (XEP-0060) | 265 | Receive IODEF |<------------------------| 266 | Incident (XEP-0060) | | 267 |<---------------------| | 268 | | | 270 Figure 2: IODEF Example Workflow 272 XMPP-Grid implementations MUST adhere to the mandatory-to-implement 273 and mandatory-to-negotiate features as defined in [RFC6120]. 274 Similarly, implementations MUST implement [XEP-0060] to facilitate 275 the asynchronous sharing for information. The Service Discovery per 276 [XEP-0030] SHOULD be implemented to facilitate the means to 277 dynamically discover the available information and namespaces 278 (Topics) to be published or consumed. 280 The following sections provide protocol examples for the service 281 discovery and publish-subscribe parts of the workflow. 283 5. Service Discovery 285 Using the XMPP service discovery extension [XEP-0030], a Controller 286 enables Platforms to discover what information can be consumed 287 through the Broker, and at which Topics. As an example, the 288 Controller at 'security-grid.example' might provide a Broker at 289 'broker.security-grid.example' hosting a number of Topics. A 290 Platform at 'xmpp-grid-client@mile-host.example' would query the 291 Broker about its available Topics by sending an XMPP "disco#items" 292 request to the Broker: 294 298 299 301 The Broker responds with the Topics it hosts: 303 307 308 311 314 315 317 In order to determine the exact nature of each Topic (i.e., in order 318 to find topics that publish incidents in the IODEF format), a 319 Platform would send an XMPP "disco#info" request to each Topic: 321 327 329 The Broker responds with the "disco#info" description, which SHOULD 330 include an XMPP Data Form [XEP-0004] including a 'pubsub#type' field 331 that specifies the supported namespace (in this example, the IODEF 332 namespace defined in [RFC7970]): 334 338 340 341 342 343 344 http://jabber.org/protocol/pubsub#meta-data 345 346 347 urn:ietf:params:xml:ns:iodef-2.0 348 349 350 351 353 6. Publish-Subscribe 355 Using the XMPP publish-subscribe extension [XEP-0030], a Consumer 356 subscribes to a Topic and a Provider publishes information to that 357 Topic, which the Broker then distributes to all subscribed Consumers. 359 First, a Provider would create a Topic as follows: 361 365 366 367 368 369 Note: The foregoing example is the minimal protocol needed to create 370 a Topic with the default node configuration on the XMPP publish- 371 subscribe service specified in the 'to' address of the creation 372 request stanza. Depending on security requirements, the Provider 373 might need to request a non-default configuration for the node; see 374 [XEP-0060] for detailed examples. 376 Unless an error occurs (see [XEP-0060] for various error flows), the 377 Broker responds with success: 379 384 Second, a Consumer would subscribe as follows: 386 390 391 393 394 396 Unless an error occurs (see [XEP-0060] for various error flows), the 397 Broker responds with success: 399 403 404 408 409 411 Third, a Provider would publish an incident as follows: 413 417 418 419 420 426 427 492382 428 2015-07-18T09:00:00-05:00 429 430 431 contact@csirt.example.com 432 433 434 435 436 437 438 439 441 (The payload in the foregoing example is from [RFC7970]; payloads for 442 additional use cases can be found in [RFC8274].) 444 The Broker would then deliver that incident report to all Consumers 445 who are subscribe to the Topic: 447 451 452 453 454 460 461 492382 462 2015-07-18T09:00:00-05:00 463 464 465 contact@csirt.example.com 466 467 468 469 470 471 472 473 475 7. IANA Considerations 477 This document has no actions for IANA. 479 8. Security Considerations 481 An XMPP-Grid Controller serves as an controlling broker for XMPP-Grid 482 Platforms such as Enforcement Points, Policy Servers, CMDBs, and 483 Sensors, using a publish-subscribe-search model of information 484 exchange and lookup. By increasing the ability of XMPP-Grid 485 Platforms to learn about and respond to security-relevant events and 486 data, XMPP-Grid can improve the timeliness and utility of the 487 security system. However, this integrated security system can also 488 be exploited by attackers if they can compromise it. Therefore, 489 strong security protections for XMPP-Grid are essential. 491 This section provides a security analysis of the XMPP-Grid data 492 transfer protocol and the architectural elements that employ it, 493 specifically with respect to their use of this protocol. Three 494 subsections define the trust model (which elements are trusted to do 495 what), the threat model (attacks that can be mounted on the system), 496 and the countermeasures (ways to address or mitigate the threats 497 previously identified). 499 8.1. Trust Model 501 The first step in analyzing the security of the XMPP-Grid transport 502 protocol is to describe the trust model, listing what each 503 architectural element is trusted to do. The items listed here are 504 assumptions, but provisions are made in the Threat Model and 505 Countermeasures sections for elements that fail to perform as they 506 were trusted to do. 508 8.1.1. Network 510 The network used to carry XMPP-Grid messages (i.e., the underlying 511 network transport layer over which XMPP runs) is trusted to: 513 o Perform best effort delivery of network traffic 515 The network used to carry XMPP-Grid messages is not expected 516 (trusted) to: 518 o Provide confidentiality or integrity protection for messages sent 519 over it 521 o Provide timely or reliable service 523 8.1.2. XMPP-Grid Platforms 525 Authorized XMPP-Grid Platforms are trusted to: 527 o Preserve the confidentiality of sensitive data retrieved via the 528 XMPP-Grid Controller 530 8.1.3. XMPP-Grid Controller 532 The XMPP-Grid Controller (including its associated Broker) is trusted 533 to: 535 o Broker requests for data and enforce authorization of access to 536 this data throughout its lifecycle 538 o Perform service requests in a timely and accurate manner 540 o Create and maintain accurate operational attributes 541 o Only reveal data to and accept service requests from authorized 542 parties 544 The XMPP-Grid Controller is not expected (trusted) to: 546 o Verify the truth (correctness) of data 548 8.1.4. Certification Authority 550 The Certification Authority (CA) that issues certificates for the 551 XMPP-Grid Controller and/or XMPP-Grid Platforms (or each CA, if there 552 are several) is trusted to: 554 o Ensure that only proper certificates are issued and that all 555 certificates are issued in accordance with the CA's policies 557 o Revoke certificates previously issued when necessary 559 o Regularly and securely distribute certificate revocation 560 information 562 o Promptly detect and report any violations of this trust so that 563 they can be handled 565 The CA is not expected (trusted) to: 567 o Issue certificates that go beyond the XMPP-Grid needs or other 568 constraints imposed by a relying party. 570 8.2. Threat Model 572 To secure the XMPP-Grid data transfer protocol and the architectural 573 elements that implement it, this section identifies the attacks that 574 can be mounted against the protocol and elements. 576 8.2.1. Network Attacks 578 A variety of attacks can be mounted using the network. For the 579 purposes of this subsection the phrase "network traffic" can be taken 580 to mean messages and/or parts of messages. Any of these attacks can 581 be mounted by network elements, by parties who control network 582 elements, and (in many cases) by parties who control network-attached 583 devices. 585 o Network traffic can be passively monitored to glean information 586 from any unencrypted traffic 588 o Even if all traffic is encrypted, valuable information can be 589 gained by traffic analysis (volume, timing, source and destination 590 addresses, etc.) 592 o Network traffic can be modified in transit 594 o Previously transmitted network traffic can be replayed 596 o New network traffic can be added 598 o Network traffic can be blocked, perhaps selectively 600 o A "Man In The Middle" (MITM) attack can be mounted where an 601 attacker interposes itself between two communicating parties and 602 poses as the other end to either party or impersonates the other 603 end to either or both parties 605 o Resist attacks (including denial of service and other attacks from 606 XMPP-Grid Platforms) 608 o Undesired network traffic can be sent in an effort to overload an 609 architectural component, thus mounting a denial of service attack 611 8.2.2. XMPP-Grid Platforms 613 An unauthorized XMPP-Grid Platform (one which is not recognized by 614 the XMPP-Grid Controller or is recognized but not authorized to 615 perform any actions) cannot mount any attacks other than those listed 616 in the Network Attacks section above. 618 An authorized XMPP-Grid Platform, on the other hand, can mount many 619 attacks. These attacks might occur because the XMPP-Grid Platform is 620 controlled by a malicious, careless, or incompetent party (whether 621 because its owner is malicious, careless, or incompetent or because 622 the XMPP-Grid Platform has been compromised and is now controlled by 623 a party other than its owner). They might also occur because the 624 XMPP-Grid Platform is running malicious software; because the XMPP- 625 Grid Platform is running buggy software (which can fail in a state 626 that floods the network with traffic); or because the XMPP-Grid 627 Platform has been configured improperly. From a security standpoint, 628 it generally makes no difference why an attack is initiated. The 629 same countermeasures can be employed in any case. 631 Here is a list of attacks that can be mounted by an authorized XMPP- 632 Grid Platform: 634 o Cause many false alarms or otherwise overload the XMPP-Grid 635 Controller or other elements in the network security system 636 (including human administrators) leading to a denial of service or 637 disabling parts of the network security system 639 o Omit important actions (such as posting incriminating data), 640 resulting in incorrect access 642 o Use confidential information obtained from the XMPP-Grid 643 Controller to enable further attacks (such as using endpoint 644 health check results to exploit vulnerable endpoints) 646 o Advertise data crafted to exploit vulnerabilities in the XMPP-Grid 647 Controller or in other XMPP-Grid Platforms, with a goal of 648 compromising those systems 650 o Issue a search request or set up a subscription that matches an 651 enormous result, leading to resource exhaustion on the XMPP-Grid 652 Controller, the publishing XMPP-Grid Platform, and/or the network 654 o Establish a communication channel using another XMPP-Grid 655 Platform's session-id 657 Dependencies of or vulnerabilities of authorized XMPP-Grid Platforms 658 can be exploited to effect these attacks. Another way to effect 659 these attacks is to gain the ability to impersonate an XMPP-Grid 660 Platform (through theft of the XMPP-Grid Platform's identity 661 credentials or through other means). Even a clock skew between the 662 XMPP-Grid Platform and XMPP-Grid Controller can cause problems if the 663 XMPP-Grid Platform assumes that old XMPP-Grid Platform data deserves 664 to be ignored. 666 8.2.3. XMPP-Grid Controllers 668 An unauthorized XMPP-Grid Controller (one which is not trusted by 669 XMPP-Grid Platforms) cannot mount any attacks other than those listed 670 in the Network Attacks section above. 672 An authorized XMPP-Grid Controller can mount many attacks. Similar 673 to the XMPP-Grid Platform case described above, these attacks might 674 occur because the XMPP-Grid Controller is controlled by a malicious, 675 careless, or incompetent party (either an XMPP-Grid Controller 676 administrator or an attacker who has seized control of the XMPP-Grid 677 Controller). They might also occur because the XMPP-Grid Controller 678 is running malicious software, because the XMPP-Grid Controller is 679 running buggy software (which can fail in a state that corrupts data 680 or floods the network with traffic), or because the XMPP-Grid 681 Controller has been configured improperly. 683 All of the attacks listed for XMPP-Grid Platform above can be mounted 684 by the XMPP-Grid Controller. Detection of these attacks will be more 685 difficult since the XMPP-Grid Controller can create false operational 686 attributes and/or logs that imply some other party created any bad 687 data. 689 Additional XMPP-Grid Controller attacks can include: 691 o Expose different data to different XMPP-Grid Platforms to mislead 692 investigators or cause inconsistent behavior 694 o Mount an even more effective denial of service attack than a 695 single XMPP-Grid Platform could 697 o Obtain and cache XMPP-Grid Platform credentials so they can be 698 used to impersonate XMPP-Grid Platforms even after a breach of the 699 XMPP-Grid Controller is repaired 701 o Obtain and cache XMPP-Grid Controller administrator credentials so 702 they can be used to regain control of the XMPP-Grid Controller 703 after the breach of the XMPP-Grid Controller is repaired 705 Dependencies of or vulnerabilities of the XMPP-Grid Controller can be 706 exploited to obtain control of the XMPP-Grid Controller and effect 707 these attacks. 709 8.2.4. Certification Authority 711 A Certification Authority trusted to issue certificates for the XMPP- 712 Grid Controller and/or XMPP-Grid Platforms can mount several attacks: 714 o Issue certificates for unauthorized parties, enabling them to 715 impersonate authorized parties such as the XMPP-Grid Controller or 716 an XMPP-Grid Platform. This can lead to all the threats that can 717 be mounted by the certificate's subject. 719 o Issue certificates without following all of the CA's policies. 720 Because this can result in issuing certificates that can be used 721 to impersonate authorized parties, this can lead to all the 722 threats that can be mounted by the certificate's subject. 724 o Fail to revoke previously issued certificates that need to be 725 revoked. This can lead to undetected impersonation of the 726 certificate's subject or failure to revoke authorization of the 727 subject, and therefore can lead to all of the threats that can be 728 mounted by that subject. 730 o Fail to regularly and securely distribute certificate revocation 731 information. This can cause a relying party to accept a revoked 732 certificate, leading to undetected impersonation of the 733 certificate's subject or failure to revoke authorization of the 734 subject, and therefore can lead to all of the threats that can be 735 mounted by that subject. It can also cause a relying party to 736 refuse to proceed with a transaction because timely revocation 737 information is not available, even though the transaction should 738 be permitted to proceed. 740 o Allow the CA's private key to be revealed to an unauthorized 741 party. This can lead to all the threats above. Even worse, the 742 actions taken with the private key will not be known to the CA. 744 o Fail to promptly detect and report errors and violations of trust 745 so that relying parties can be promptly notified. This can cause 746 the threats listed earlier in this section to persist longer than 747 necessary, leading to many knock-on effects. 749 8.3. Countermeasures 751 Below are countermeasures for specific attack scenarios to the XMPP- 752 Grid infrastructure. 754 8.3.1. Securing the XMPP-Grid Data Transfer Protocol 756 To address network attacks, the XMPP-Grid data transfer protocol 757 described in this document requires that the XMPP-Grid messages MUST 758 be carried over TLS (minimally TLS 1.2 [RFC8446]) as described in 759 [RFC6120] and updated by [RFC7590]. The XMPP-Grid Platform MUST 760 verify the XMPP-Grid Controller's certificate and determine whether 761 the XMPP-Grid Controller is trusted by this XMPP-Grid Platform before 762 completing the TLS handshake. The XMPP-Grid Controller MUST 763 authenticate the XMPP-Grid Platform either using the SASL EXTERNAL 764 mechanism or using the SASL SCRAM mechanism (with the SCRAM-SHA- 765 256-PLUS variant being preferred over the SCRAM-SHA-256 variant and 766 SHA-256 variants [RFC7677] being preferred over SHA-1 varients 767 [RFC5802]). XMPP-Grid Platforms and XMPP-Grid Controllers using 768 mutual certificate-based authentication SHOULD each verify the 769 revocation status of the other party's certificate. All XMPP-Grid 770 Controllers and XMPP-Grid Platforms MUST implement both SASL EXTERNAL 771 and SASL SCRAM. The selection of which XMPP-Grid Platform 772 authentication technique to use in any particular deployment is left 773 to the administrator. 775 These protocol security measures provide protection against all the 776 network attacks listed in the above document section except denial of 777 service attacks. If protection against these denial of service 778 attacks is desired, ingress filtering, rate limiting per source IP 779 address, and other denial of service mitigation measures can be 780 employed. In addition, an XMPP-Grid Controller MAY automatically 781 disable a misbehaving XMPP-Grid Platform. 783 8.3.2. Securing XMPP-Grid Platforms 785 XMPP-Grid Platforms can be deployed in locations that are susceptible 786 to physical attacks. Physical security measures can be taken to 787 avoid compromise of XMPP-Grid Platforms, but these are not always 788 practical or completely effective. An alternative measure is to 789 configure the XMPP-Grid Controller to provide read-only access for 790 such systems. The XMPP-Grid Controller SHOULD also include a full 791 authorization model so that individual XMPP-Grid Platforms can be 792 configured to have only the privileges that they need. The XMPP-Grid 793 Controller MAY provide functional templates so that the administrator 794 can configure a specific XMPP-Grid Platform as a DHCP server and 795 authorize only the operations and metadata types needed by a DHCP 796 server to be permitted for that XMPP-Grid Platform. These techniques 797 can reduce the negative impacts of a compromised XMPP-Grid Platform 798 without diminishing the utility of the overall system. 800 To handle attacks within the bounds of this authorization model, the 801 XMPP-Grid Controller MAY also include rate limits and alerts for 802 unusual XMPP-Grid Platform behavior. XMPP-Grid Controllers SHOULD 803 make it easy to revoke an XMPP-Grid Platform's authorization when 804 necessary. Another way to detect attacks from XMPP-Grid Platforms is 805 to create fake entries in the available data (honeytokens) which 806 normal XMPP-Grid Platforms will not attempt to access. The XMPP-Grid 807 Controller SHOULD include auditable logs of XMPP-Grid Platform 808 activities. 810 To avoid compromise of XMPP-Grid Platform, XMPP-Grid Platform SHOULD 811 be hardened against attack and minimized to reduce their attack 812 surface. They should be well managed to minimize vulnerabilities in 813 the underlying platform and in systems upon which the XMPP-Grid 814 Platform depends. Personnel with administrative access should be 815 carefully screened and monitored to detect problems as soon as 816 possible. 818 8.3.3. Securing XMPP-Grid Controllers 820 Because of the serious consequences of XMPP-Grid Controller 821 compromise, XMPP-Grid Controllers need to be especially well hardened 822 against attack and minimized to reduce their attack surface. They 823 need to be well managed to minimize vulnerabilities in the underlying 824 platform and in systems upon which the XMPP-Grid Controller depends. 825 Network security measures such as firewalls or intrusion detection 826 systems can be used to monitor and limit traffic to and from the 827 XMPP-Grid Controller. Personnel with administrative access ought to 828 be carefully screened and monitored to detect problems as soon as 829 possible. Administrators SHOULD NOT use password-based 830 authentication but should instead use non-reusable credentials and 831 multi-factor authentication (where available). Physical security 832 measures ought to be employed to prevent physical attacks on XMPP- 833 Grid Controllers. 835 To ease detection of XMPP-Grid Controller compromise should it occur, 836 XMPP-Grid Controller behavior should be monitored to detect unusual 837 behavior (such as a reboot, a large increase in traffic, or different 838 views of an information repository for similar XMPP-Grid Platforms). 839 XMPP-Grid Platforms should log and/or notify administrators when 840 peculiar XMPP-Grid Controller behavior is detected. To aid forensic 841 investigation, permanent read-only audit logs of security-relevant 842 information (especially administrative actions) should be maintained. 843 If XMPP-Grid Controller compromise is detected, a careful analysis 844 should be performed of the impact of this compromise. Any reusable 845 credentials that can have been compromised should be reissued. 847 8.3.4. Broker Access Models for Topics 849 The XMPP publish-subscribe specification [XEP-0060] defines five 850 access models for subscribing to Topics at a Broker: open, presence, 851 roster, authorize, and whitelist. The first model allows 852 uncontrolled access and the next two models are appropriate only in 853 instant-messaging applications. Therefore, a Broker SHOULD support 854 only the authorize model (under which the Topic owner needs to 855 approve all subscription requests and only subscribers can retrieve 856 data items) and the whitelist model (under which only preconfigured 857 Platforms can subscribe or retrieve data items). In order to ease 858 the deployment burden, subscription approvals and whitelist 859 management can be automated (e.g, the Topic "owner" can be a policy 860 server). The choice between "authorize" and "whitelist" as the 861 default access model is a matter for local service policy. 863 8.3.5. Limit on Search Result Size 865 While XMPP-Grid is designed for high scalability to 100,000s of 866 Platforms, an XMPP-Grid Controller MAY establish a limit to the 867 amount of data it is willing to return in search or subscription 868 results. This mitigates the threat of an XMPP-Grid Platform causing 869 resource exhaustion by issuing a search or subscription that leads to 870 an enormous result. 872 8.3.6. Securing the Certification Authority 874 As noted above, compromise of a Certification Authority (CA) trusted 875 to issue certificates for the XMPP-Grid Controller and/or XMPP-Grid 876 Platforms is a major security breach. Many guidelines for proper CA 877 security have been developed: the CA/Browser Forum's Baseline 878 Requirements, the AICPA/CICA Trust Service Principles, etc. The CA 879 operator and relying parties should agree on an appropriately 880 rigorous security practices to be used. 882 Even with the most rigorous security practices, a CA can be 883 compromised. If this compromise is detected quickly, relying parties 884 can remove the CA from their list of trusted CAs, and other CAs can 885 revoke any certificates issued to the CA. However, CA compromise may 886 go undetected for some time, and there's always the possibility that 887 a CA is being operated improperly or in a manner that is not in the 888 interests of the relying parties. For this reason, relying parties 889 may wish to "pin" a small number of particularly critical 890 certificates (such as the certificate for the XMPP-Grid Controller). 891 Once a certificate has been pinned, the relying party will not accept 892 another certificate in its place unless the Administrator explicitly 893 commands it to do so. This does not mean that the relying party will 894 not check the revocation status of pinned certificates. However, the 895 Administrator can still be consulted if a pinned certificate is 896 revoked, since the CA and revocation process are not completely 897 trusted. 899 8.4. Summary 901 XMPP-Grid's considerable value as a broker for security-sensitive 902 data exchange distribution also makes the protocol and the network 903 security elements that implement it a target for attack. Therefore, 904 strong security has been included as a basic design principle within 905 the XMPP-Grid design process. 907 The XMPP-Grid data transfer protocol provides strong protection 908 against a variety of different attacks. In the event that an XMPP- 909 Grid Platform or XMPP-Grid Controller is compromised, the effects of 910 this compromise have been reduced and limited with the recommended 911 role-based authorization model and other provisions, and best 912 practices for managing and protecting XMPP-Grid systems have been 913 described. Taken together, these measures should provide protection 914 commensurate with the threat to XMPP-Grid systems, thus ensuring that 915 they fulfill their promise as a network security clearing-house. 917 9. Privacy Considerations 919 XMPP-Grid Platforms can publish information about endpoint health, 920 network access, events (which can include information about what 921 services an endpoint is accessing), roles and capabilities, and the 922 identity of the end user operating the endpoint. Any of this 923 published information can be queried by other XMPP-Grid Platforms and 924 could potentially be used to correlate network activity to a 925 particular end user. 927 Dynamic and static information brokered by an XMPP-Grid Controller, 928 ostensibly for purposes of correlation by XMPP-Grid Platforms for 929 intrusion detection, could be misused by a broader set of XMPP-Grid 930 Platforms which hitherto have been performing specific roles with 931 strict well-defined separation of duties. 933 Care needs to be taken by deployers of XMPP-Grid to ensure that the 934 information published by XMPP-Grid Platforms does not violate 935 agreements with end users or local and regional laws and regulations. 936 This can be accomplished either by configuring XMPP-Grid Platforms to 937 not publish certain information or by restricting access to sensitive 938 data to trusted XMPP-Grid Platforms. That is, the easiest means to 939 ensure privacy or protect sensitive data, is to omit or not share it 940 at all. 942 Another consideration for deployers is to enable end-to-end 943 encryption to ensure the data is protected from the data layer to 944 data layer and thus protect it from the transport layer. 946 10. Operations and Management Considerations 948 In order to facilitate the management of Providers and the onboarding 949 of Consumers, it is helpful to generate the following ahead of time: 951 o Agreement between the operators of Provider services and the 952 implementers of Consumer software regarding identifiers for common 953 Topics (e.g., these could be registered with the XMPP Software 954 Foundation's registry of well-known nodes for service discovery 955 and publish-subscribe located at ). 958 o Security certificates (including appropriate certificate chains) 959 for Controllers, including identification of any Providers 960 associated with the Controllers (which might be located at 961 subdomains). 963 o Consistent and secure access control policies for publishing and 964 subscribing to Topics. 966 These matters are out of scope for this document but ought to be 967 addressed by the XMPP-Grid community. 969 11. Acknowledgements 971 The authors would like to acknowledge the contributions, authoring 972 and/or editing of the following people: Joseph Salowey, Lisa 973 Lorenzin, Clifford Kahn, Henk Birkholz, Jessica Fitzgerald-McKay, 974 Steve Hanna, and Steve Venema. In addition, we want to thank Takeshi 975 Takahashi, Panos Kampanakis, Adam Montville, Chris Inacio, and Dave 976 Cridland for reviewing and providing valuable comments. 978 12. References 980 12.1. Normative References 982 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 983 Requirement Levels", BCP 14, RFC 2119, 984 DOI 10.17487/RFC2119, March 1997, 985 . 987 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 988 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 989 March 2011, . 991 [RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer 992 Security (TLS) in the Extensible Messaging and Presence 993 Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June 994 2015, . 996 [RFC7677] Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple 997 Authentication and Security Layer (SASL) Mechanisms", 998 RFC 7677, DOI 10.17487/RFC7677, November 2015, 999 . 1001 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1002 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1003 May 2017, . 1005 12.2. Informative References 1007 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 1008 "Salted Challenge Response Authentication Mechanism 1009 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, 1010 DOI 10.17487/RFC5802, July 2010, 1011 . 1013 [RFC7970] Danyliw, R., "The Incident Object Description Exchange 1014 Format Version 2", RFC 7970, DOI 10.17487/RFC7970, 1015 November 2016, . 1017 [RFC8274] Kampanakis, P. and M. Suzuki, "Incident Object Description 1018 Exchange Format Usage Guidance", RFC 8274, 1019 DOI 10.17487/RFC8274, November 2017, 1020 . 1022 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1023 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1024 . 1026 [XEP-0004] 1027 Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and 1028 P. Saint-Andre, "Data Forms", XSF XEP 0004, August 2007. 1030 [XEP-0030] 1031 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 1032 Andre, "Service Discovery", XSF XEP 0030, July 2010. 1034 [XEP-0060] 1035 Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 1036 Subscribe", XSF XEP 0060, December 2017. 1038 Authors' Addresses 1040 Nancy Cam-Winget (editor) 1041 Cisco Systems 1042 3550 Cisco Way 1043 San Jose, CA 95134 1044 USA 1046 Email: ncamwing@cisco.com 1048 Syam Appala 1049 Cisco Systems 1050 3550 Cisco Way 1051 San Jose, CA 95134 1052 USA 1054 Email: syam1@cisco.com 1055 Scott Pope 1056 Cisco Systems 1057 5400 Meadows Road 1058 Suite 300 1059 Lake Oswego, OR 97035 1060 USA 1062 Email: scottp@cisco.com 1064 Peter Saint-Andre 1065 Mozilla 1067 Email: stpeter@mozilla.com