RFC 8600
Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange
Pages: 28
Proposed Standard
Proposed Standard
Part 2 of 2 – Pages 14 to 28
8. Security Considerations
An XMPP-Grid Controller serves as a controlling broker for XMPP-Grid Platforms such as enforcement points, policy servers, Configuration Management Databases (CMDBs), and sensors, using a publish-subscribe- search model of information exchange and lookup. By increasing the ability of XMPP-Grid Platforms to learn about and respond to security incident reports and other security-relevant information, XMPP-Grid can improve the timeliness and utility of the security system. However, this integrated security system can also be exploited by attackers if they can compromise it. Therefore, strong security protections for XMPP-Grid are essential. As XMPP is the core of this document, the security considerations of [RFC6120] apply. In addition, as XMPP-Grid defines a specific instance, this section provides a security analysis of the XMPP-Grid data transfer protocol and the architectural elements that employ it, specifically with respect to their use of this protocol. Three subsections define the trust model (which elements are trusted to do what), the threat model (attacks that can be mounted on the system), and the countermeasures (ways to address or mitigate the threats previously identified).8.1. Trust Model
The first step in analyzing the security of the XMPP-Grid transport protocol is to describe the trust model and list what each architectural element is trusted to do. The items listed here are assumptions, but provisions are made in "Threat Model" (Section 8.2) and "Countermeasures" (Section 8.3) for elements that fail to perform as they were trusted to do.8.1.1. Network
The network used to carry XMPP-Grid messages (i.e., the underlying network transport layer over which XMPP runs) is trusted to: o Perform best-effort delivery of network traffic The network used to carry XMPP-Grid messages is not expected (trusted) to: o Provide confidentiality or integrity protection for messages sent over it o Provide timely or reliable service
8.1.2. XMPP-Grid Platforms
Authorized XMPP-Grid Platforms are trusted to: o Preserve the confidentiality of sensitive data retrieved via the XMPP-Grid Controller8.1.3. XMPP-Grid Controller
The XMPP-Grid Controller (including its associated Broker) is trusted to: o Broker requests for data and enforce authorization of access to this data throughout its lifecycle o Perform service requests in a timely and accurate manner o Create and maintain accurate operational attributes o Only reveal data to and accept service requests from authorized parties o Preserve the integrity (and confidentiality against unauthorized parties) of the data flowing through it. The XMPP-Grid Controller is not expected (trusted) to: o Verify the truth (correctness) of data8.1.4. Certification Authority
To allow XMPP-Grid Platforms to mutually authenticate with XMPP-Grid Controllers, it is expected that a Certification Authority (CA) is employed to issue certificates. Such a CA (or each CA, if there are several) is trusted to: o Ensure that only proper certificates are issued and that all certificates are issued in accordance with the CA's policies o Revoke certificates previously issued when necessary o Regularly and securely distribute certificate revocation information o Promptly detect and report any violations of this trust so that they can be handled
The CA is not expected (trusted) to:
o Issue certificates that go beyond the XMPP-Grid needs or other
constraints imposed by a relying party.
8.2. Threat Model
To secure the XMPP-Grid data transfer protocol and the architectural
elements that implement it, this section identifies the attacks that
can be mounted against the protocol and elements.
8.2.1. Network Attacks
A variety of attacks can be mounted using the network. For the
purposes of this subsection, the phrase "network traffic" can be
taken to mean messages and/or parts of messages. Any of these
attacks can be mounted by network elements, by parties who control
network elements, and (in many cases) by parties who control network-
attached devices.
o Network traffic can be passively monitored to glean information
from any unencrypted traffic
o Even if all traffic is encrypted, valuable information can be
gained by traffic analysis (volume, timing, source and destination
addresses, etc.)
o Network traffic can be modified in transit
o Previously transmitted network traffic can be replayed
o New network traffic can be added
o Network traffic can be blocked, perhaps selectively
o A man-in-the-middle (MITM) attack can be mounted where an attacker
interposes itself between two communicating parties and
impersonates the other end to either or both parties
o Undesired network traffic can be sent in an effort to overload an
architectural component, thus mounting a denial-of-service attack
8.2.2. XMPP-Grid Platforms
An unauthorized XMPP-Grid Platform (one that is not recognized by the
XMPP-Grid Controller or is recognized but not authorized to perform
any actions) cannot mount any attacks other than those listed in
"Network Attacks" (Section 8.2.1).
An authorized XMPP-Grid Platform, on the other hand, can mount many
attacks. These attacks might occur because the XMPP-Grid Platform is
controlled by a malicious, careless, or incompetent party (whether
because its owner is malicious, careless, or incompetent or because
the XMPP-Grid Platform has been compromised and is now controlled by
a party other than its owner). They might also occur because the
XMPP-Grid Platform is running malicious software, the XMPP-Grid
Platform is running buggy software (which can fail in a state that
floods the network with traffic), or the XMPP-Grid Platform has been
configured improperly. From a security standpoint, it generally
makes no difference why an attack is initiated. The same
countermeasures can be employed in any case.
Here is a list of attacks that can be mounted by an authorized XMPP-
Grid Platform:
o Cause many false alarms or otherwise overload the XMPP-Grid
Controller or other elements in the network security system
(including human administrators), leading to a denial of service
or parts of the network security system being disabled.
o Omit important actions (such as posting incriminating data),
resulting in incorrect access.
o Use confidential information obtained from the XMPP-Grid
Controller to enable further attacks (such as using endpoint
health check results to exploit vulnerable endpoints).
o Advertise data crafted to exploit vulnerabilities in the XMPP-Grid
Controller or in other XMPP-Grid Platforms with the goal of
compromising those systems.
o Issue a search request or set up a subscription that matches an
enormous result, leading to resource exhaustion on the XMPP-Grid
Controller, the publishing XMPP-Grid Platform, and/or the network.
o Establish a communication channel using another XMPP-Grid
Platform's session-id.
o Advertise false data that leads to incorrect (e.g., potentially
attacker-controlled or -induced) behavior of XMPP-Grid Platforms
by virtue of applying correct procedures to the falsified input.
Dependencies or vulnerabilities of authorized XMPP-Grid Platforms can
be exploited to effect these attacks. Another way to effect these
attacks is to gain the ability to impersonate an XMPP-Grid Platform
(through theft of the XMPP-Grid Platform's identity credentials or
through other means). Even a clock skew between the XMPP-Grid Platform and XMPP-Grid Controller can cause problems if the XMPP-Grid Platform assumes that old XMPP-Grid Platform data should be ignored.8.2.3. XMPP-Grid Controllers
An unauthorized XMPP-Grid Controller (one that is not trusted by XMPP-Grid Platforms) cannot mount any attacks other than those listed in "Network Attacks" (Section 8.2.1). An authorized XMPP-Grid Controller can mount many attacks. Similar to the XMPP-Grid Platform case described above, these attacks might occur because the XMPP-Grid Controller is controlled by a malicious, careless, or incompetent party (either an XMPP-Grid Controller administrator or an attacker who has seized control of the XMPP-Grid Controller). They might also occur because the XMPP-Grid Controller is running malicious software, the XMPP-Grid Controller is running buggy software (which can fail in a state that corrupts data or floods the network with traffic), or the XMPP-Grid Controller has been configured improperly. All of the attacks listed for XMPP-Grid Platform above can be mounted by the XMPP-Grid Controller. Detection of these attacks will be more difficult since the XMPP-Grid Controller can create false operational attributes and/or logs that imply some other party created any bad data. Additional XMPP-Grid Controller attacks can include: o Exposing different data to different XMPP-Grid Platforms to mislead investigators or cause inconsistent behavior. o Mounting an even more effective denial-of-service attack than a single XMPP-Grid Platform could; some mechanisms include inducing many platforms to perform the same operation in an amplification- style attack, completely refusing to pass any traffic at all, or sending floods of traffic to (certain) platforms or other targets. o Obtaining and caching XMPP-Grid Platform credentials so they can be used to impersonate XMPP-Grid Platforms even after a breach of the XMPP-Grid Controller is repaired. Some Simple Authentication and Security Layer (SASL) mechanisms (including the mandatory-to- implement SCRAM and EXTERNAL with TLS mutual certificate-based authentication) do not admit this class of attack, but others (such as PLAIN) are susceptible.
o Obtaining and caching XMPP-Grid Controller administrator
credentials so they can be used to regain control of the XMPP-Grid
Controller after the breach of the XMPP-Grid Controller is
repaired.
o Eavesdropping, injecting, or modifying the data being transferred
between Provider and Consumer.
Dependencies or vulnerabilities of the XMPP-Grid Controller can be
exploited to obtain control of the XMPP-Grid Controller and effect
these attacks.
8.2.4. Certification Authority
A Certification Authority trusted to issue certificates for the XMPP-
Grid Controller and/or XMPP-Grid Platforms can mount several attacks:
o Issue certificates for unauthorized parties, enabling them to
impersonate authorized parties such as the XMPP-Grid Controller or
an XMPP-Grid Platform. This can lead to all the threats that can
be mounted by the certificate's subject.
o Issue certificates without following all of the CA's policies.
Because this can result in issuing certificates that can be used
to impersonate authorized parties, this can lead to all the
threats that can be mounted by the certificate's subject.
o Fail to revoke previously issued certificates that need to be
revoked. This can lead to undetected impersonation of the
certificate's subject or failure to revoke authorization of the
subject and therefore can lead to all of the threats that can be
mounted by that subject.
o Fail to regularly and securely distribute certificate revocation
information. This can cause a relying party to accept a revoked
certificate, leading to undetected impersonation of the
certificate's subject or failure to revoke authorization of the
subject and therefore can lead to all of the threats that can be
mounted by that subject. It can also cause a relying party to
refuse to proceed with a transaction because timely revocation
information is not available, even though the transaction should
be permitted to proceed.
o Allow the CA's private key to be revealed to an unauthorized
party. This can lead to all the threats above. Even worse, the
actions taken with the private key will not be known to the CA.
o Fail to promptly detect and report errors and violations of trust
so that relying parties can be promptly notified. This can cause
the threats listed earlier in this section to persist longer than
necessary, leading to many knock-on effects.
8.3. Countermeasures
Below are countermeasures for specific attack scenarios to the XMPP-
Grid infrastructure.
8.3.1. Securing the XMPP-Grid Data Transfer Protocol
To address network attacks, the XMPP-Grid data transfer protocol
described in this document requires that the XMPP-Grid messages MUST
be carried over TLS (minimally TLS 1.2 and preferably TLS 1.3
[RFC8446]) as described in [RFC6120] and updated by [RFC7590]. The
XMPP-Grid Controller and XMPP-Grid Platforms SHOULD mutually
authenticate. The XMPP-Grid Platform MUST verify the XMPP-Grid
Controller's certificate and determine whether the XMPP-Grid
Controller is trusted by this XMPP-Grid Platform before completing
the TLS handshake. To ensure interoperability, implementations MUST
implement at least either the SASL EXTERNAL mechanism [RFC4422] or
the SASL SCRAM mechanism. When using the SASL SCRAM mechanism, the
SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256
variant, and SHA-256 variants [RFC7677] SHOULD be preferred over
SHA-1 variants [RFC5802]). XMPP-Grid Platforms and XMPP-Grid
Controllers using certificate-based authentication SHOULD each verify
the revocation status of the other party's certificate. The
selection of the XMPP-Grid Platform authentication technique to use
in any particular deployment is left to the administrator.
These protocol security measures provide protection against all the
network attacks listed in Section 8.2 except denial-of-service
attacks. If protection against these denial-of-service attacks is
desired, ingress filtering, rate limiting per source IP address, and
other denial-of-service mitigation measures can be employed. In
addition, an XMPP-Grid Controller MAY automatically disable a
misbehaving XMPP-Grid Platform.
8.3.2. Securing XMPP-Grid Platforms
XMPP-Grid Platforms can be deployed in locations that are susceptible
to physical attacks. Physical security measures can be taken to
avoid compromise of XMPP-Grid Platforms, but these are not always
practical or completely effective. An alternative measure is to
configure the XMPP-Grid Controller to provide read-only access for
such systems. The XMPP-Grid Controller SHOULD also include a full
authorization model so that individual XMPP-Grid Platforms can be
configured to have only the privileges that they need. The XMPP-Grid Controller MAY provide functional templates so that the administrator can configure a specific XMPP-Grid Platform as a DHCP [RFC2131] server and authorize only the operations and metadata types needed by a DHCP server to be permitted for that XMPP-Grid Platform. These techniques can reduce the negative impacts of a compromised XMPP-Grid Platform without diminishing the utility of the overall system. To handle attacks within the bounds of this authorization model, the XMPP-Grid Controller MAY also include rate limits and alerts for unusual XMPP-Grid Platform behavior. XMPP-Grid Controllers SHOULD make it easy to revoke an XMPP-Grid Platform's authorization when necessary. The XMPP-Grid Controller SHOULD include auditable logs of XMPP-Grid Platform activities. To avoid compromise of XMPP-Grid Platforms, they SHOULD be hardened against attack and minimized to reduce their attack surface. They should be well managed to minimize vulnerabilities in the underlying platform and in systems upon which the XMPP-Grid Platform depends. Personnel with administrative access should be carefully screened and monitored to detect problems as soon as possible.8.3.3. Securing XMPP-Grid Controllers
Because of the serious consequences of XMPP-Grid Controller compromise, XMPP-Grid Controllers need to be especially well hardened against attack and minimized to reduce their attack surface. They need to be well managed to minimize vulnerabilities in the underlying platform and in systems upon which the XMPP-Grid Controller depends. Network security measures such as firewalls or intrusion detection systems can be used to monitor and limit traffic to and from the XMPP-Grid Controller. Personnel with administrative access ought to be carefully screened and monitored to detect problems as soon as possible. Administrators SHOULD NOT use password-based authentication but SHOULD instead use non-reusable credentials and multi-factor authentication (where available). Physical security measures ought to be employed to prevent physical attacks on XMPP- Grid Controllers. To ease detection of XMPP-Grid Controller compromise should it occur, XMPP-Grid Controller behavior should be monitored to detect unusual behavior (such as a reboot, a large increase in traffic, or different views of an information repository for similar XMPP-Grid Platforms). It is a matter of local policy whether XMPP-Grid Platforms log and/or notify administrators when peculiar XMPP-Grid Controller behavior is detected and whether read-only audit logs of security-relevant information (especially administrative actions) are maintained; however, such behavior is encouraged to aid in forensic analysis.
Furthermore, if compromise of an XMPP-Grid Controller is detected, a careful analysis should be performed, and any reusable credentials that could have been compromised should be reissued. To address the potential for the XMPP-Grid Controller to eavesdrop, modify or inject data, it would be desirable to deploy end-to-end encryption between the Provider and the Consumer(s). Unfortunately, because there is no standardized method for encryption of one-to-many messages within XMPP, techniques for enforcing end-to-end encryption are out of scope for this specification.8.3.4. Broker Access Models for Topics
The XMPP publish-subscribe specification [XEP-0060] defines five access models for subscribing to Topics at a Broker: open, presence, roster, authorize, and whitelist. The first model allows uncontrolled access, and the next two models are appropriate only in instant-messaging applications. Therefore, a Broker SHOULD support only the authorize model (under which the Topic owner needs to approve all subscription requests and only subscribers can retrieve data items) and the whitelist model (under which only preconfigured Platforms can subscribe or retrieve data items). In order to ease the deployment burden, subscription approvals and whitelist management can be automated (e.g., the Topic "owner" can be a policy server). The choice between "authorize" and "whitelist" as the default access model is a matter for local service policy.8.3.5. Limit on Search Result Size
While XMPP-Grid is designed for high scalability to hundreds of thousands of Platforms, an XMPP-Grid Controller MAY establish a limit to the amount of data it is willing to return in search or subscription results. Platforms could use [XEP-0059] to restrict the size of the result sets the Controller returns in search or subscription results or topics' service discovery. This mitigates the threat of an XMPP-Grid Platform causing resource exhaustion by issuing a search or subscription that leads to an enormous result.8.3.6. Securing the Certification Authority
As noted above, compromise of a Certification Authority (CA) trusted to issue certificates for the XMPP-Grid Controller and/or XMPP-Grid Platforms is a major security breach. Many guidelines for proper CA security have been developed: the CA/Browser Forum's Baseline Requirements, the American Institute of Certified Public Accountants (AICPA) / Canadian Institute of Chartered Accountants (CICA) Trust
Service Principles, the IETF's Certificate Transparency [RFC6962], etc. The CA operator and relying parties should agree on appropriately rigorous security practices to be used. Even with the most rigorous security practices, a CA can be compromised. If this compromise is detected quickly, relying parties can remove the CA from their list of trusted CAs, and other CAs can revoke any certificates issued to the CA. However, CA compromise may go undetected for some time, and there's always the possibility that a CA is being operated improperly or in a manner that is not in the interests of the relying parties. For this reason, relying parties may wish to "pin" a small number of particularly critical certificates (such as the certificate for the XMPP-Grid Controller). Once a certificate has been pinned, the relying party will not accept another certificate in its place unless the Administrator explicitly commands it to do so. This does not mean that the relying party will not check the revocation status of pinned certificates. However, the Administrator can still be consulted if a pinned certificate is revoked, since the CA and revocation process are not completely trusted. By "pinning" one or a small set of certificates, the relying party has identified the effective XMPP-Grid Controller(s) authorized for connection.8.3.7. End-to-End Encryption of Messages
Because it is expected that there will be a relatively large number of Consumers for every Topic, for the purposes of content discovery and scaling, this document specifies a "one-to-many" communications pattern using the XMPP Publish-Subscribe extension. Unfortunately, there is no standardized technology for end-to-end encryption of one- to-many messages in XMPP. This implies that messages can be subject to eavesdropping, data injection, and data modification attacks within a Broker or Controller. If it is necessary to mitigate against such attacks, implementers would need to select a messaging pattern other than [XEP-0060], most likely the basic "instant messaging" pattern specified in [RFC6121] with a suitable XMPP extension for end-to-end encryption. The description of such an approach is out of scope for this document.8.4. Summary
XMPP-Grid's considerable value as a broker for security-sensitive data exchange distribution also makes the protocol and the network security elements that implement it a target for attack. Therefore, strong security has been included as a basic design principle within the XMPP-Grid design process.
The XMPP-Grid data transfer protocol provides strong protection against a variety of different attacks. In the event that an XMPP- Grid Platform or XMPP-Grid Controller is compromised, the effects of this compromise are reduced and limited with the recommended role- based authorization model and other provisions, and best practices for managing and protecting XMPP-Grid systems have been described. Taken together, these measures should provide protection commensurate with the threat to XMPP-Grid systems, thus ensuring that they fulfill their promise as a network security clearinghouse.9. Privacy Considerations
XMPP-Grid Platforms can publish information about endpoint health, network access, events (which can include information about which services an endpoint is accessing), roles and capabilities, and the identity of the end user operating the endpoint. Any of this published information can be queried by other XMPP-Grid Platforms and could potentially be used to correlate network activity to a particular end user. Dynamic and static information brokered by an XMPP-Grid Controller, ostensibly for the purposes of correlation by XMPP-Grid Platforms for intrusion detection, could be misused by a broader set of XMPP-Grid Platforms that hitherto have been performing specific roles with a strict, well-defined separation of duties. Care needs to be taken by deployers of XMPP-Grid to ensure that the information published by XMPP-Grid Platforms does not violate agreements with end users or local and regional laws and regulations. This can be accomplished either by configuring XMPP-Grid Platforms to not publish certain information or by restricting access to sensitive data to trusted XMPP-Grid Platforms. That is, the easiest means to ensure privacy or protect sensitive data is to omit or not share it at all. Similarly, care must be taken by deployers and XMPP-Grid Controller implementations as they implement the appropriate auditing tools. In particular, any information, such as logs, must be sensitive to the type of information stored to ensure that the information does not violate privacy and agreements with end users or local and regional laws and regulations. Another consideration for deployers is to enable end-to-end encryption to ensure the data is protected while in transit between data layers and thus protected from the transport layer. The means to achieve end-to-end encryption is beyond the scope of this document.
10. Operations and Management Considerations
In order to facilitate the management of Providers and the onboarding of Consumers, it is helpful to generate the following ahead of time: o Agreement between the operators of Provider services and the implementers of Consumer software regarding identifiers for common Topics (e.g., these could be registered with the XMPP Software Foundation's registry of well-known nodes for service discovery and publish-subscribe, located at <https://xmpp.org/registrar/ nodes.html>). o Security certificates (including appropriate certificate chains) for Controllers, including identification of any Providers associated with the Controllers (which might be located at subdomains). o Consistent and secure access control policies for publishing and subscribing to Topics. These matters are out of scope for this document but ought to be addressed by the XMPP-Grid community.11. References
11.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, <https://www.rfc-editor.org/info/rfc2026>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006, <https://www.rfc-editor.org/info/rfc4422>. [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, DOI 10.17487/RFC5802, July 2010, <https://www.rfc-editor.org/info/rfc5802>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, <https://www.rfc-editor.org/info/rfc6120>. [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, DOI 10.17487/RFC6121, March 2011, <https://www.rfc-editor.org/info/rfc6121>. [RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June 2015, <https://www.rfc-editor.org/info/rfc7590>. [RFC7677] Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms", RFC 7677, DOI 10.17487/RFC7677, November 2015, <https://www.rfc-editor.org/info/rfc7677>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [XEP-0004] Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and P. Saint-Andre, "Data Forms", XSF XEP 0004, August 2007, <https://xmpp.org/extensions/xep-0004.html>. [XEP-0030] Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- Andre, "Service Discovery", XSF XEP 0030, October 2017, <https://xmpp.org/extensions/xep-0030.html>. [XEP-0059] Paterson, I., Saint-Andre, P., Mercier, V., and J. Seguineau, "Result Set Management", XSF XEP 0059, September 2006, <https://xmpp.org/extensions/xep-0059.html>. [XEP-0060] Millard, P., Saint-Andre, P., and R. Meijer, "Publish- Subscribe", XSF XEP 0060, January 2019, <https://xmpp.org/extensions/xep-0060.html>. [XEP-0203] Saint-Andre, P., "Delayed Delivery", XSF XEP 0203, September 2009, <https://xmpp.org/extensions/xep-0203.html>.
11.2. Informative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>. [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, <https://www.rfc-editor.org/info/rfc6962>. [RFC7970] Danyliw, R., "The Incident Object Description Exchange Format Version 2", RFC 7970, DOI 10.17487/RFC7970, November 2016, <https://www.rfc-editor.org/info/rfc7970>. [RFC8274] Kampanakis, P. and M. Suzuki, "Incident Object Description Exchange Format Usage Guidance", RFC 8274, DOI 10.17487/RFC8274, November 2017, <https://www.rfc-editor.org/info/rfc8274>. [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>. [XEP-0160] Saint-Andre, P., "Best Practices for Handling Offline Messages", XSF XEP 0160, October 2016, <https://xmpp.org/extensions/xep-0160.html>.Acknowledgements
The authors would like to acknowledge the contributions, authoring and/or editing of the following people: Joseph Salowey, Lisa Lorenzin, Clifford Kahn, Henk Birkholz, Jessica Fitzgerald-McKay, Steve Hanna, and Steve Venema. In addition, we want to thank Takeshi Takahashi, Panos Kampanakis, Adam Montville, Chris Inacio, and Dave Cridland for reviewing and providing valuable comments.
Authors' Addresses
Nancy Cam-Winget (editor) Cisco Systems 3550 Cisco Way San Jose, CA 95134 United States of America Email: ncamwing@cisco.com Syam Appala Cisco Systems 3550 Cisco Way San Jose, CA 95134 United States of America Email: syam1@cisco.com Scott Pope Cisco Systems 5400 Meadows Road Suite 300 Lake Oswego, OR 97035 United States of America Email: scottp@cisco.com Peter Saint-Andre Mozilla Email: stpeter@mozilla.com