idnits 2.17.1 draft-ietf-mile-xmpp-grid-05.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 (February 8, 2018) is 2269 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) == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-14 ** Downref: Normative reference to an Informational draft: draft-ietf-sacm-terminology (ref. 'I-D.ietf-sacm-terminology') -- 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-0060' -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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: August 12, 2018 Cisco Systems 6 P. Saint-Andre 7 Mozilla 8 February 8, 2018 10 Using XMPP for Security Information Exchange 11 draft-ietf-mile-xmpp-grid-05 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 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 August 12, 2018. 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 (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 . . . . . . . . . . . . . . . . . . . . . . . . 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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 71 11.2. Informative References . . . . . . . . . . . . . . . . . 22 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 74 1. Introduction 76 This document describes "XMPP-Grid": a method for using the 77 Extensible Messaging and Presence Protocol (XMPP) [RFC6120] to 78 collect and distribute security-relevant information among network 79 platforms, endpoints, and any other network-connected device. Among 80 other things, XMPP provides a publish-subscribe service [XEP-0060] 81 that acts as a broker, enabling control-plane functions by which 82 entities can discover available information to be published or 83 consumed. Although such information can take the form of any 84 structured data (XML, JSON, etc.), this document illustrates the 85 principles of XMPP-Grid with examples that use the Incident Object 86 Description Exchange Format (IODEF) [RFC7970]. 88 2. Terminology 90 This document uses XMPP terminology defined in [RFC6120] and 91 [XEP-0060] as well as Security Automation and Continuous Monitoring 92 (SACM) terminology defined in [I-D.ietf-sacm-terminology]. Because 93 the intended audience for this document is those who implement and 94 deploy security reporting systems, in general the SACM terms are used 95 (however, mappings are provided for the benefit of XMPP developers 96 and operators). 98 Broker: In SACM, a specific type of controller containing control 99 plane functions; as used here, the term refers to an XMPP publish- 100 subscribe service. 102 Broker Flow: In SACM, a method by which security-related information 103 is published and consumed in a mediated fashion through a Broker. 104 In this flow, the Broker handles authorization of Consumers and 105 Providers to Topics, receives messages from Providers, and 106 delivers published messages to Consumers. 108 Consumer: In SACM, an entity that contains functions to receive 109 information from other components; as used here, the term refers 110 to an XMPP publish-subscribe Subscriber. 112 Controller: In SACM, a "component containing control plane functions 113 that manage and facilitate information sharing or execute on 114 security functions"; as used here, the term refers to an XMPP 115 server, which provides core message delivery [RFC6120] used by 116 publish-subscribe entities. 118 Node: The XMPP term for a Topic. 120 Platform: Any entity that connects to the XMPP-Grid in order to 121 publish or consume security-related data. 123 Provider: In SACM, an entity that contains functions to provide 124 information to other components; as used here, the term refers to 125 an XMPP publish-subscribe Publisher. 127 Publisher: The XMPP term for a Provider. 129 Publish-Subscribe Service: The XMPP term for the kind Broker 130 discussed here. 132 Subscriber: The XMPP term for a Consumer. 134 Topic: A contextual information channel created on a Broker at which 135 messages generated by a Provider are propagated in real time to 136 one or more Consumers. Each Topic is limited to a specific type 137 and format of security data (e.g., IODEF) and provides an XMPP 138 interface by which the data can be obtained. 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 3. Architecture 146 The following figure illustrates the architecture of XMPP-Grid. 148 +--------------------------------------+ 149 | +--------------------------------------+ 150 | | +--------------------------------------+ 151 | | | | 152 +-| | Platforms | 153 +-| | 154 +--------------------------------------+ 155 / \ / \ / \ 156 / C \ / \ / \ 157 - o - - d - - - 158 ||n||A | a |B | |C 159 ||t|| | t | | | 160 - r - - a - | | 161 \ o / \ / | | 162 \ l / \ / | | 163 /|---------------------|\ | | 164 /|----/ \--------| d |--|\ 165 / / Controller \ ctrl | a | \ 166 \ \ & Broker / plane | t | / 167 \|----\ /--------| a |--|/ 168 \|---------------------|/ | | 169 / \ / \ | | 170 / C \ / \ | | 171 - o - - d - | | 172 ||n||A | a |B | |C 173 ||t|| | t | | | 174 - r - - a - - - 175 \ o / \ / \ / 176 \ l / \ / \ / 177 +------------------------------------+ 178 | |-+ 179 | Platforms | | 180 | | |-+ 181 +------------------------------------+ | | 182 +------------------------------------+ | 183 +------------------------------------+ 185 Figure 1: XMPP-Grid Architecture 187 Platforms connect to the Controller (XMPP server) to authenticate and 188 then establish appropriate authorizations and relationships (e.g., 189 Provider or Consumer) at the Broker. The control plane messaging is 190 established through XMPP and shown as "A" (control plane interface) 191 in Figure 1. Authorized nodes can then share data either thru the 192 Broker (shown as "B" in Figure 1) or in some cases directly (shown as 193 "C" in Figure 1). This document focuses primarily on the Broker Flow 194 for information sharing ("direct flow" interactions can be used for 195 specialized purposes such as bulk data transfer, but methods for 196 doing so are outside the scope of this document). 198 4. Workflow 200 A typical XMPP-Grid workflow is as follows: 202 a. A Platform with a source of security data requests connection to 203 the XMPP-Grid via a Controller (XMPP server). 205 b. The Controller authenticates the Platform. 207 c. The Platform establishes authorized privileges (e.g. privilege to 208 publish and/or subscribe to security data Topics) with a Broker. 210 d. The Platform can publish security-related data to a Topic, 211 subscribe to a Topic, query a Topic, or any combination of these 212 operations. 214 e. A Provider unicasts its Topic updates to the Grid in real time 215 through a Broker. The Broker handles replication and 216 distribution of the Topic to Consumers. A Provider can publish 217 the same or different data to multiple Topics. 219 f. Any Platform on the Grid can subscribe to any Topics published to 220 the Grid (as permitted by authorization policy), and as Consumers 221 will then receive a continual, real-time stream of updates from 222 the Topics to which it is subscribed. 224 The general workflow is summarized in the figure below: 226 +--------------+ +------------+ +---------------+ 227 | IODEF Client | | Controller | | IODEF Service | 228 | (Consumer) | | & Broker | | (Provider) | 229 +--------------+ +------------+ +---------------+ 230 | | | 231 | Establish XMPP | | 232 | Client Session | | 233 | (RFC 6120) | | 234 |--------------------->| | 235 | | Establish XMPP | 236 | | Client Session | 237 | | (RFC 6120) | 238 | |<------------------------| 239 | | Request Topic Creation | 240 | | (XEP-0060) | 241 | |<------------------------| 242 | | Topic Creation Success | 243 | | (XEP-0060) | 244 | |------------------------>| 245 | Request Topic List | | 246 | (XEP-0030) | | 247 |--------------------->| | 248 | Return Topic List | | 249 | (XEP-0030) | | 250 |<---------------------| | 251 | | | 252 | Query Each Topic | | 253 | (XEP-0030) | | 254 |--------------------->| | 255 | Return Topic Data | | 256 | Including Topic Type | | 257 | (XEP-0030) | | 258 |<---------------------| | 259 | | | 260 | Subscribe to IODEF | | 261 | Topic (XEP-0060) | | 262 |--------------------->| | 263 | Subscription Success | | 264 | (XEP-0060) | | 265 |<---------------------| | 266 | | Publish IODEF Incident | 267 | | (XEP-0060) | 268 | Receive IODEF |<------------------------| 269 | Incident (XEP-0060) | | 270 |<---------------------| | 271 | | | 273 Figure 2: IODEF Example Workflow 275 The following sections provide protocol examples for the service 276 discovery and publish-subscribe parts of the workflow. 278 5. Service Discovery 280 Using the XMPP service discovery extension [XEP-0030], a Controller 281 enables Platforms to discover what information can be consumed 282 through the Broker, and at which Topics. As an example, the 283 Controller at 'security-grid.example' might provide a Broker at 284 'broker.security-grid.example' hosting a number of Topics. A 285 Platform at 'xmpp-grid-client@mile-host.example' would query the 286 Broker about its available Topics by sending an XMPP "disco#items" 287 request to the Broker: 289 293 294 296 The Broker responds with the Topics it hosts: 298 302 303 306 309 310 312 In order to determine the exact nature of each Topic (i.e., in order 313 to find topics that publish incidents in the IODEF format), a 314 Platform would send an XMPP "disco#info" request to each Topic: 316 322 323 The Broker responds with the "disco#info" description, which SHOULD 324 include an XMPP Data Form [XEP-0004] including a 'pubsub#type' field 325 that specifies the supported namespace (in this example, the IODEF 326 namespace defined in [RFC7970]): 328 332 334 335 336 337 338 http://jabber.org/protocol/pubsub#meta-data 339 340 341 urn:ietf:params:xml:ns:iodef-2.0 342 343 344 345 347 6. Publish-Subscribe 349 Using the XMPP publish-subscribe extension [XEP-0030], a Consumer 350 subscribes to a Topic and a Provider publishes information to that 351 Topic, which the Broker then distributes to all subscribed Consumers. 353 First, a Provider would create a Topic as follows: 355 359 360 361 362 364 Note: The foregoing example is the minimal protocol needed to create 365 a Topic with the default node configuration on the XMPP publish- 366 subscribe service specified in the 'to' address of the creation 367 request stanza. Depending on security requirements, the Provider 368 might need to request a non-default configuration for the node; see 369 [XEP-0060] for detailed examples. 371 Unless an error occurs (see [XEP-0060] for various error flows), the 372 Broker responds with success: 374 379 Second, a Consumer would subscribe as follows: 381 385 386 388 389 391 Unless an error occurs (see [XEP-0060] for various error flows), the 392 Broker responds with success: 394 398 399 403 404 406 Third, a Provider would publish an incident as follows: 408 412 413 414 415 421 422 492382 423 2015-07-18T09:00:00-05:00 424 425 426 contact@csirt.example.com 427 428 429 430 431 432 433 434 436 (The payload in the foregoing example is from [RFC7970]; payloads for 437 additional use cases can be found in [RFC8274].) 439 The Broker would then deliver that incident report to all Consumers 440 who are subscribe to the Topic: 442 446 447 448 449 455 456 492382 457 2015-07-18T09:00:00-05:00 458 459 460 contact@csirt.example.com 461 462 463 464 465 466 467 468 470 7. IANA Considerations 472 This document has no actions for IANA. 474 8. Security Considerations 476 An XMPP-Grid Controller serves as an controlling broker for XMPP-Grid 477 Platforms such as Enforcement Points, Policy Servers, CMDBs, and 478 Sensors, using a publish-subscribe-search model of information 479 exchange and lookup. By increasing the ability of XMPP-Grid 480 Platforms to learn about and respond to security-relevant events and 481 data, XMPP-Grid can improve the timeliness and utility of the 482 security system. However, this integrated security system can also 483 be exploited by attackers if they can compromise it. Therefore, 484 strong security protections for XMPP-Grid are essential. 486 This section provides a security analysis of the XMPP-Grid data 487 transfer protocol and the architectural elements that employ it, 488 specifically with respect to their use of this protocol. Three 489 subsections define the trust model (which elements are trusted to do 490 what), the threat model (attacks that can be mounted on the system), 491 and the countermeasures (ways to address or mitigate the threats 492 previously identified). 494 8.1. Trust Model 496 The first step in analyzing the security of the XMPP-Grid transport 497 protocol is to describe the trust model, listing what each 498 architectural element is trusted to do. The items listed here are 499 assumptions, but provisions are made in the Threat Model and 500 Countermeasures sections for elements that fail to perform as they 501 were trusted to do. 503 8.1.1. Network 505 The network used to carry XMPP-Grid messages (i.e., the underlying 506 network transport layer over which XMPP runs) is trusted to: 508 o Perform best effort delivery of network traffic 510 The network used to carry XMPP-Grid messages is not expected 511 (trusted) to: 513 o Provide confidentiality or integrity protection for messages sent 514 over it 516 o Provide timely or reliable service 518 8.1.2. XMPP-Grid Platforms 520 Authorized XMPP-Grid Platforms are trusted to: 522 o Preserve the confidentiality of sensitive data retrieved via the 523 XMPP-Grid Controller 525 8.1.3. XMPP-Grid Controller 527 The XMPP-Grid Controller (including its associated Broker) is trusted 528 to: 530 o Broker requests for data and enforce authorization of access to 531 this data throughout its lifecycle 533 o Perform service requests in a timely and accurate manner 535 o Create and maintain accurate operational attributes 536 o Only reveal data to and accept service requests from authorized 537 parties 539 The XMPP-Grid Controller is not expected (trusted) to: 541 o Verify the truth (correctness) of data 543 8.1.4. Certification Authority 545 The Certification Authority (CA) that issues certificates for the 546 XMPP-Grid Controller and/or XMPP-Grid Platforms (or each CA, if there 547 are several) is trusted to: 549 o Ensure that only proper certificates are issued and that all 550 certificates are issued in accordance with the CA's policies 552 o Revoke certificates previously issued when necessary 554 o Regularly and securely distribute certificate revocation 555 information 557 o Promptly detect and report any violations of this trust so that 558 they can be handled 560 The CA is not expected (trusted) to: 562 o Issue certificates that go beyond the XMPP-Grid needs or other 563 constraints imposed by a relying party. 565 8.2. Threat Model 567 To secure the XMPP-Grid data transfer protocol and the architectural 568 elements that implement it, this section identifies the attacks that 569 can be mounted against the protocol and elements. 571 8.2.1. Network Attacks 573 A variety of attacks can be mounted using the network. For the 574 purposes of this subsection the phrase "network traffic" can be taken 575 to mean messages and/or parts of messages. Any of these attacks can 576 be mounted by network elements, by parties who control network 577 elements, and (in many cases) by parties who control network-attached 578 devices. 580 o Network traffic can be passively monitored to glean information 581 from any unencrypted traffic 583 o Even if all traffic is encrypted, valuable information can be 584 gained by traffic analysis (volume, timing, source and destination 585 addresses, etc.) 587 o Network traffic can be modified in transit 589 o Previously transmitted network traffic can be replayed 591 o New network traffic can be added 593 o Network traffic can be blocked, perhaps selectively 595 o A "Man In The Middle" (MITM) attack can be mounted where an 596 attacker interposes itself between two communicating parties and 597 poses as the other end to either party or impersonates the other 598 end to either or both parties 600 o Resist attacks (including denial of service and other attacks from 601 XMPP-Grid Platforms) 603 o Undesired network traffic can be sent in an effort to overload an 604 architectural component, thus mounting a denial of service attack 606 8.2.2. XMPP-Grid Platforms 608 An unauthorized XMPP-Grid Platform (one which is not recognized by 609 the XMPP-Grid Controller or is recognized but not authorized to 610 perform any actions) cannot mount any attacks other than those listed 611 in the Network Attacks section above. 613 An authorized XMPP-Grid Platform, on the other hand, can mount many 614 attacks. These attacks might occur because the XMPP-Grid Platform is 615 controlled by a malicious, careless, or incompetent party (whether 616 because its owner is malicious, careless, or incompetent or because 617 the XMPP-Grid Platform has been compromised and is now controlled by 618 a party other than its owner). They might also occur because the 619 XMPP-Grid Platform is running malicious software; because the XMPP- 620 Grid Platform is running buggy software (which can fail in a state 621 that floods the network with traffic); or because the XMPP-Grid 622 Platform has been configured improperly. From a security standpoint, 623 it generally makes no difference why an attack is initiated. The 624 same countermeasures can be employed in any case. 626 Here is a list of attacks that can be mounted by an authorized XMPP- 627 Grid Platform: 629 o Cause many false alarms or otherwise overload the XMPP-Grid 630 Controller or other elements in the network security system 631 (including human administrators) leading to a denial of service or 632 disabling parts of the network security system 634 o Omit important actions (such as posting incriminating data), 635 resulting in incorrect access 637 o Use confidential information obtained from the XMPP-Grid 638 Controller to enable further attacks (such as using endpoint 639 health check results to exploit vulnerable endpoints) 641 o Advertise data crafted to exploit vulnerabilities in the XMPP-Grid 642 Controller or in other XMPP-Grid Platforms, with a goal of 643 compromising those systems 645 o Issue a search request or set up a subscription that matches an 646 enormous result, leading to resource exhaustion on the XMPP-Grid 647 Controller, the publishing XMPP-Grid Platform, and/or the network 649 o Establish a communication channel using another XMPP-Grid 650 Platform's session-id 652 Dependencies of or vulnerabilities of authorized XMPP-Grid Platforms 653 can be exploited to effect these attacks. Another way to effect 654 these attacks is to gain the ability to impersonate an XMPP-Grid 655 Platform (through theft of the XMPP-Grid Platform's identity 656 credentials or through other means). Even a clock skew between the 657 XMPP-Grid Platform and XMPP-Grid Controller can cause problems if the 658 XMPP-Grid Platform assumes that old XMPP-Grid Platform data deserves 659 to be ignored. 661 8.2.3. XMPP-Grid Controllers 663 An unauthorized XMPP-Grid Controller (one which is not trusted by 664 XMPP-Grid Platforms) cannot mount any attacks other than those listed 665 in the Network Attacks section above. 667 An authorized XMPP-Grid Controller can mount many attacks. Similar 668 to the XMPP-Grid Platform case described above, these attacks might 669 occur because the XMPP-Grid Controller is controlled by a malicious, 670 careless, or incompetent party (either an XMPP-Grid Controller 671 administrator or an attacker who has seized control of the XMPP-Grid 672 Controller). They might also occur because the XMPP-Grid Controller 673 is running malicious software, because the XMPP-Grid Controller is 674 running buggy software (which can fail in a state that corrupts data 675 or floods the network with traffic), or because the XMPP-Grid 676 Controller has been configured improperly. 678 All of the attacks listed for XMPP-Grid Platform above can be mounted 679 by the XMPP-Grid Controller. Detection of these attacks will be more 680 difficult since the XMPP-Grid Controller can create false operational 681 attributes and/or logs that imply some other party created any bad 682 data. 684 Additional XMPP-Grid Controller attacks can include: 686 o Expose different data to different XMPP-Grid Platforms to mislead 687 investigators or cause inconsistent behavior 689 o Mount an even more effective denial of service attack than a 690 single XMPP-Grid Platform could 692 o Obtain and cache XMPP-Grid Platform credentials so they can be 693 used to impersonate XMPP-Grid Platforms even after a breach of the 694 XMPP-Grid Controller is repaired 696 o Obtain and cache XMPP-Grid Controller administrator credentials so 697 they can be used to regain control of the XMPP-Grid Controller 698 after the breach of the XMPP-Grid Controller is repaired 700 Dependencies of or vulnerabilities of the XMPP-Grid Controller can be 701 exploited to obtain control of the XMPP-Grid Controller and effect 702 these attacks. 704 8.2.4. Certification Authority 706 A Certification Authority trusted to issue certificates for the XMPP- 707 Grid Controller and/or XMPP-Grid Platforms can mount several attacks: 709 o Issue certificates for unauthorized parties, enabling them to 710 impersonate authorized parties such as the XMPP-Grid Controller or 711 an XMPP-Grid Platform. This can lead to all the threats that can 712 be mounted by the certificate's subject. 714 o Issue certificates without following all of the CA's policies. 715 Because this can result in issuing certificates that can be used 716 to impersonate authorized parties, this can lead to all the 717 threats that can be mounted by the certificate's subject. 719 o Fail to revoke previously issued certificates that need to be 720 revoked. This can lead to undetected impersonation of the 721 certificate's subject or failure to revoke authorization of the 722 subject, and therefore can lead to all of the threats that can be 723 mounted by that subject. 725 o Fail to regularly and securely distribute certificate revocation 726 information. This can cause a relying party to accept a revoked 727 certificate, leading to undetected impersonation of the 728 certificate's subject or failure to revoke authorization of the 729 subject, and therefore can lead to all of the threats that can be 730 mounted by that subject. It can also cause a relying party to 731 refuse to proceed with a transaction because timely revocation 732 information is not available, even though the transaction should 733 be permitted to proceed. 735 o Allow the CA's private key to be revealed to an unauthorized 736 party. This can lead to all the threats above. Even worse, the 737 actions taken with the private key will not be known to the CA. 739 o Fail to promptly detect and report errors and violations of trust 740 so that relying parties can be promptly notified. This can cause 741 the threats listed earlier in this section to persist longer than 742 necessary, leading to many knock-on effects. 744 8.3. Countermeasures 746 Below are countermeasures for specific attack scenarios to the XMPP- 747 Grid infrastructure. 749 8.3.1. Securing the XMPP-Grid Data Transfer Protocol 751 To address network attacks, the XMPP-Grid data transfer protocol 752 described in this document requires that the XMPP-Grid messages MUST 753 be carried over TLS (minimally TLS 1.2 [RFC5246]) as described in 754 [RFC6120] and updated by [RFC7590]. The XMPP-Grid Platform MUST 755 verify the XMPP-Grid Controller's certificate and determine whether 756 the XMPP-Grid Controller is trusted by this XMPP-Grid Platform before 757 completing the TLS handshake. The XMPP-Grid Controller MUST 758 authenticate the XMPP-Grid Platform either using the SASL EXTERNAL 759 mechanism or using the SASL SCRAM mechanism (with the SCRAM-SHA- 760 256-PLUS variant being preferred over the SCRAM-SHA-256 variant and 761 SHA-256 variants [RFC7677] being preferred over SHA-1 varients 762 [RFC5802]). XMPP-Grid Platforms and XMPP-Grid Controllers using 763 mutual certificate-based authentication SHOULD each verify the 764 revocation status of the other party's certificate. All XMPP-Grid 765 Controllers and XMPP-Grid Platforms MUST implement both SASL EXTERNAL 766 and SASL SCRAM. The selection of which XMPP-Grid Platform 767 authentication technique to use in any particular deployment is left 768 to the administrator. 770 These protocol security measures provide protection against all the 771 network attacks listed in the above document section except denial of 772 service attacks. If protection against these denial of service 773 attacks is desired, ingress filtering, rate limiting per source IP 774 address, and other denial of service mitigation measures can be 775 employed. In addition, an XMPP-Grid Controller MAY automatically 776 disable a misbehaving XMPP-Grid Platform. 778 8.3.2. Securing XMPP-Grid Platforms 780 XMPP-Grid Platforms can be deployed in locations that are susceptible 781 to physical attacks. Physical security measures can be taken to 782 avoid compromise of XMPP-Grid Platforms, but these are not always 783 practical or completely effective. An alternative measure is to 784 configure the XMPP-Grid Controller to provide read-only access for 785 such systems. The XMPP-Grid Controller SHOULD also include a full 786 authorization model so that individual XMPP-Grid Platforms can be 787 configured to have only the privileges that they need. The XMPP-Grid 788 Controller MAY provide functional templates so that the administrator 789 can configure a specific XMPP-Grid Platform as a DHCP server and 790 authorize only the operations and metadata types needed by a DHCP 791 server to be permitted for that XMPP-Grid Platform. These techniques 792 can reduce the negative impacts of a compromised XMPP-Grid Platform 793 without diminishing the utility of the overall system. 795 To handle attacks within the bounds of this authorization model, the 796 XMPP-Grid Controller MAY also include rate limits and alerts for 797 unusual XMPP-Grid Platform behavior. XMPP-Grid Controllers SHOULD 798 make it easy to revoke an XMPP-Grid Platform's authorization when 799 necessary. Another way to detect attacks from XMPP-Grid Platforms is 800 to create fake entries in the available data (honeytokens) which 801 normal XMPP-Grid Platforms will not attempt to access. The XMPP-Grid 802 Controller SHOULD include auditable logs of XMPP-Grid Platform 803 activities. 805 To avoid compromise of XMPP-Grid Platform, XMPP-Grid Platform SHOULD 806 be hardened against attack and minimized to reduce their attack 807 surface. They should be well managed to minimize vulnerabilities in 808 the underlying platform and in systems upon which the XMPP-Grid 809 Platform depends. Personnel with administrative access should be 810 carefully screened and monitored to detect problems as soon as 811 possible. 813 8.3.3. Securing XMPP-Grid Controllers 815 Because of the serious consequences of XMPP-Grid Controller 816 compromise, XMPP-Grid Controllers need to be especially well hardened 817 against attack and minimized to reduce their attack surface. They 818 need to be well managed to minimize vulnerabilities in the underlying 819 platform and in systems upon which the XMPP-Grid Controller depends. 820 Network security measures such as firewalls or intrusion detection 821 systems can be used to monitor and limit traffic to and from the 822 XMPP-Grid Controller. Personnel with administrative access ought to 823 be carefully screened and monitored to detect problems as soon as 824 possible. Administrators SHOULD NOT use password-based 825 authentication but should instead use non-reusable credentials and 826 multi-factor authentication (where available). Physical security 827 measures ought to be employed to prevent physical attacks on XMPP- 828 Grid Controllers. 830 To ease detection of XMPP-Grid Controller compromise should it occur, 831 XMPP-Grid Controller behavior should be monitored to detect unusual 832 behavior (such as a reboot, a large increase in traffic, or different 833 views of an information repository for similar XMPP-Grid Platforms). 834 XMPP-Grid Platforms should log and/or notify administrators when 835 peculiar XMPP-Grid Controller behavior is detected. To aid forensic 836 investigation, permanent read-only audit logs of security-relevant 837 information (especially administrative actions) should be maintained. 838 If XMPP-Grid Controller compromise is detected, a careful analysis 839 should be performed of the impact of this compromise. Any reusable 840 credentials that can have been compromised should be reissued. 842 8.3.4. Broker Access Models for Topics 844 The XMPP publish-subscribe specification [XEP-0060] defines five 845 access models for subscribing to Topics at a Broker: open, presence, 846 roster, authorize, and whitelist. The first model allows 847 uncontrolled access and the next two models are appropriate only in 848 instant-messaging applications. Therefore, a Broker SHOULD support 849 only the authorize model (under which the Topic owner needs to 850 approve all subscription requests and only subscribers can retrieve 851 data items) and the whitelist model (under which only preconfigured 852 Platforms can subscribe or retrieve data items). In order to ease 853 the deployment burden, subscription approvals and whitelist 854 management can be automated (e.g, the Topic "owner" can be a policy 855 server). The choice between "authorize" and "whitelist" as the 856 default access model is a matter for local service policy. 858 8.3.5. Limit on Search Result Size 860 While XMPP-Grid is designed for high scalability to 100,000s of 861 Platforms, an XMPP-Grid Controller MAY establish a limit to the 862 amount of data it is willing to return in search or subscription 863 results. This mitigates the threat of an XMPP-Grid Platform causing 864 resource exhaustion by issuing a search or subscription that leads to 865 an enormous result. 867 8.3.6. Securing the Certification Authority 869 As noted above, compromise of a Certification Authority (CA) trusted 870 to issue certificates for the XMPP-Grid Controller and/or XMPP-Grid 871 Platforms is a major security breach. Many guidelines for proper CA 872 security have been developed: the CA/Browser Forum's Baseline 873 Requirements, the AICPA/CICA Trust Service Principles, etc. The CA 874 operator and relying parties should agree on an appropriately 875 rigorous security practices to be used. 877 Even with the most rigorous security practices, a CA can be 878 compromised. If this compromise is detected quickly, relying parties 879 can remove the CA from their list of trusted CAs, and other CAs can 880 revoke any certificates issued to the CA. However, CA compromise may 881 go undetected for some time, and there's always the possibility that 882 a CA is being operated improperly or in a manner that is not in the 883 interests of the relying parties. For this reason, relying parties 884 may wish to "pin" a small number of particularly critical 885 certificates (such as the certificate for the XMPP-Grid Controller). 886 Once a certificate has been pinned, the relying party will not accept 887 another certificate in its place unless the Administrator explicitly 888 commands it to do so. This does not mean that the relying party will 889 not check the revocation status of pinned certificates. However, the 890 Administrator can still be consulted if a pinned certificate is 891 revoked, since the CA and revocation process are not completely 892 trusted. 894 8.4. Summary 896 XMPP-Grid's considerable value as a broker for security-sensitive 897 data exchange distribution also makes the protocol and the network 898 security elements that implement it a target for attack. Therefore, 899 strong security has been included as a basic design principle within 900 the XMPP-Grid design process. 902 The XMPP-Grid data transfer protocol provides strong protection 903 against a variety of different attacks. In the event that an XMPP- 904 Grid Platform or XMPP-Grid Controller is compromised, the effects of 905 this compromise have been reduced and limited with the recommended 906 role-based authorization model and other provisions, and best 907 practices for managing and protecting XMPP-Grid systems have been 908 described. Taken together, these measures should provide protection 909 commensurate with the threat to XMPP-Grid systems, thus ensuring that 910 they fulfill their promise as a network security clearing-house. 912 9. Privacy Considerations 914 XMPP-Grid Platforms can publish information about endpoint health, 915 network access, events (which can include information about what 916 services an endpoint is accessing), roles and capabilities, and the 917 identity of the end user operating the endpoint. Any of this 918 published information can be queried by other XMPP-Grid Platforms and 919 could potentially be used to correlate network activity to a 920 particular end user. 922 Dynamic and static information brokered by an XMPP-Grid Controller, 923 ostensibly for purposes of correlation by XMPP-Grid Platforms for 924 intrusion detection, could be misused by a broader set of XMPP-Grid 925 Platforms which hitherto have been performing specific roles with 926 strict well-defined separation of duties. 928 Care needs to be taken by deployers of XMPP-Grid to ensure that the 929 information published by XMPP-Grid Platforms does not violate 930 agreements with end users or local and regional laws and regulations. 931 This can be accomplished either by configuring XMPP-Grid Platforms to 932 not publish certain information or by restricting access to sensitive 933 data to trusted XMPP-Grid Platforms. That is, the easiest means to 934 ensure privacy or protect sensitive data, is to omit or not share it 935 at all. 937 Another consideration for deployers is to enable end-to-end 938 encryption to ensure the data is protected from the data layer to 939 data layer and thus protect it from the transport layer. 941 10. Acknowledgements 943 The authors would like to acknowledge the contributions, authoring 944 and/or editing of the following people: Joseph Salowey, Lisa 945 Lorenzin, Clifford Kahn, Henk Birkholz, Jessica Fitzgerald-McKay, 946 Steve Hanna, and Steve Venema. In addition, we want to thank Takeshi 947 Takahashi, Panos Kampanakis, Adam Montville, Chris Inacio, and Dave 948 Cridland for reviewing and providing valuable comments. 950 11. References 952 11.1. Normative References 954 [I-D.ietf-sacm-terminology] 955 Birkholz, H., Lu, J., Strassner, J., and N. Cam-Winget, 956 "Secure Automation and Continuous Monitoring (SACM) 957 Terminology", draft-ietf-sacm-terminology-14 (work in 958 progress), December 2017. 960 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 961 Requirement Levels", BCP 14, RFC 2119, 962 DOI 10.17487/RFC2119, March 1997, . 965 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 966 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 967 March 2011, . 969 [RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer 970 Security (TLS) in the Extensible Messaging and Presence 971 Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June 972 2015, . 974 [RFC7677] Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple 975 Authentication and Security Layer (SASL) Mechanisms", 976 RFC 7677, DOI 10.17487/RFC7677, November 2015, 977 . 979 [XEP-0004] 980 Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and 981 P. Saint-Andre, "Data Forms", XSF XEP 0004, August 2007. 983 [XEP-0030] 984 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 985 Andre, "Service Discovery", XSF XEP 0030, July 2010. 987 [XEP-0060] 988 Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 989 Subscribe", XSF XEP 0060, December 2017. 991 11.2. Informative References 993 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 994 (TLS) Protocol Version 1.2", RFC 5246, 995 DOI 10.17487/RFC5246, August 2008, . 998 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 999 "Salted Challenge Response Authentication Mechanism 1000 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, 1001 DOI 10.17487/RFC5802, July 2010, . 1004 [RFC7970] Danyliw, R., "The Incident Object Description Exchange 1005 Format Version 2", RFC 7970, DOI 10.17487/RFC7970, 1006 November 2016, . 1008 [RFC8274] Kampanakis, P. and M. Suzuki, "Incident Object Description 1009 Exchange Format Usage Guidance", RFC 8274, 1010 DOI 10.17487/RFC8274, November 2017, . 1013 Authors' Addresses 1015 Nancy Cam-Winget (editor) 1016 Cisco Systems 1017 3550 Cisco Way 1018 San Jose, CA 95134 1019 USA 1021 Email: ncamwing@cisco.com 1023 Syam Appala 1024 Cisco Systems 1025 3550 Cisco Way 1026 San Jose, CA 95134 1027 USA 1029 Email: syam1@cisco.com 1031 Scott Pope 1032 Cisco Systems 1033 5400 Meadows Road 1034 Suite 300 1035 Lake Oswego, OR 97035 1036 USA 1038 Email: scottp@cisco.com 1040 Peter Saint-Andre 1041 Mozilla 1043 Email: stpeter@mozilla.com