idnits 2.17.1 draft-ietf-xmpp-3920bis-22.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 8790 has weird spacing: '...equence xmlns...' == Line 8791 has weird spacing: '...s:group ref=...' -- The document date (December 20, 2010) is 4876 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2560 (ref. 'OCSP') (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 3447 (ref. 'PKIX-ALGO') (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) == Outdated reference: A later version (-14) exists of draft-saintandre-tls-server-id-check-12 -- Possible downref: Non-RFC (?) normative reference: ref. 'UCS2' -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' -- Possible downref: Non-RFC (?) normative reference: ref. 'X509' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' ** Obsolete normative reference: RFC 3023 (ref. 'XML-MEDIA') (Obsoleted by RFC 7303) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML-NAMES' == Outdated reference: A later version (-09) exists of draft-ietf-xmpp-address-08 == Outdated reference: A later version (-20) exists of draft-ietf-xmpp-3921bis-17 -- Obsolete informational reference (is this intentional?): RFC 2831 (ref. 'DIGEST-MD5') (Obsoleted by RFC 6331) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. 'IANA-GUIDE') (Obsoleted by RFC 8126) == Outdated reference: A later version (-10) exists of draft-ietf-tsvwg-iana-ports-09 -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) -- Obsolete informational reference (is this intentional?): RFC 3921 (Obsoleted by RFC 6121) -- Obsolete informational reference (is this intentional?): RFC 4013 (ref. 'SASLPREP') (Obsoleted by RFC 7613) -- Obsolete informational reference (is this intentional?): RFC 5077 (ref. 'TLS-RESUME') (Obsoleted by RFC 8446) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XMPP P. Saint-Andre 3 Internet-Draft Cisco 4 Obsoletes: 3920 (if approved) December 20, 2010 5 Intended status: Standards Track 6 Expires: June 23, 2011 8 Extensible Messaging and Presence Protocol (XMPP): Core 9 draft-ietf-xmpp-3920bis-22 11 Abstract 13 The Extensible Messaging and Presence Protocol (XMPP) is an 14 application profile of the Extensible Markup Language (XML) that 15 enables the near-real-time exchange of structured yet extensible data 16 between any two or more network entities. This document defines 17 XMPP's core protocol methods: setup and teardown of XML streams, 18 channel encryption, authentication, error handling, and communication 19 primitives for messaging, network availability ("presence"), and 20 request-response interactions. This document obsoletes RFC 3920. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 23, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9 57 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 58 1.2. History . . . . . . . . . . . . . . . . . . . . . . . . 9 59 1.3. Functional Summary . . . . . . . . . . . . . . . . . . . 9 60 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . 11 61 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 13 62 2.1. Global Addresses . . . . . . . . . . . . . . . . . . . . 13 63 2.2. Presence . . . . . . . . . . . . . . . . . . . . . . . . 14 64 2.3. Persistent Streams . . . . . . . . . . . . . . . . . . . 14 65 2.4. Structured Data . . . . . . . . . . . . . . . . . . . . 14 66 2.5. Distributed Network of Clients and Servers . . . . . . . 15 67 3. TCP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 16 68 3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 16 69 3.2. Resolution of Fully Qualified Domain Names . . . . . . . 17 70 3.2.1. Preferred Process: SRV Lookup . . . . . . . . . . . 17 71 3.2.2. Fallback Processes . . . . . . . . . . . . . . . . . 18 72 3.2.3. When Not to Use SRV . . . . . . . . . . . . . . . . 18 73 3.2.4. Use of SRV Records with Add-On Services . . . . . . 18 74 3.3. Reconnection . . . . . . . . . . . . . . . . . . . . . . 19 75 3.4. Reliability . . . . . . . . . . . . . . . . . . . . . . 19 76 4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . . 20 77 4.1. Stream Fundamentals . . . . . . . . . . . . . . . . . . 20 78 4.2. Opening a Stream . . . . . . . . . . . . . . . . . . . . 23 79 4.3. Stream Negotiation . . . . . . . . . . . . . . . . . . . 24 80 4.3.1. Basic Concepts . . . . . . . . . . . . . . . . . . . 24 81 4.3.2. Stream Features Format . . . . . . . . . . . . . . . 24 82 4.3.3. Restarts . . . . . . . . . . . . . . . . . . . . . . 27 83 4.3.4. Resending Features . . . . . . . . . . . . . . . . . 27 84 4.3.5. Completion of Stream Negotiation . . . . . . . . . . 27 85 4.3.6. Determination of Addresses . . . . . . . . . . . . . 28 86 4.3.7. Flow Chart . . . . . . . . . . . . . . . . . . . . . 29 87 4.4. Closing a Stream . . . . . . . . . . . . . . . . . . . . 31 88 4.5. Directionality . . . . . . . . . . . . . . . . . . . . . 31 89 4.6. Handling of Silent Peers . . . . . . . . . . . . . . . . 33 90 4.6.1. Dead Connection . . . . . . . . . . . . . . . . . . 34 91 4.6.2. Broken Stream . . . . . . . . . . . . . . . . . . . 34 92 4.6.3. Idle Peer . . . . . . . . . . . . . . . . . . . . . 34 93 4.6.4. Use of Checking Methods . . . . . . . . . . . . . . 35 94 4.7. Stream Attributes . . . . . . . . . . . . . . . . . . . 35 95 4.7.1. from . . . . . . . . . . . . . . . . . . . . . . . . 35 96 4.7.2. to . . . . . . . . . . . . . . . . . . . . . . . . . 37 97 4.7.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 38 98 4.7.4. xml:lang . . . . . . . . . . . . . . . . . . . . . . 39 99 4.7.5. version . . . . . . . . . . . . . . . . . . . . . . 41 100 4.7.6. Summary of Stream Attributes . . . . . . . . . . . . 42 101 4.8. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 42 102 4.8.1. Stream Namespace . . . . . . . . . . . . . . . . . . 42 103 4.8.2. Content Namespace . . . . . . . . . . . . . . . . . 43 104 4.8.3. XMPP Content Namespaces . . . . . . . . . . . . . . 44 105 4.8.4. Other Namespaces . . . . . . . . . . . . . . . . . . 45 106 4.8.5. Namespace Declarations and Prefixes . . . . . . . . 46 107 4.9. Stream Errors . . . . . . . . . . . . . . . . . . . . . 48 108 4.9.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 48 109 4.9.1.1. Stream Errors Are Unrecoverable . . . . . . . . . 48 110 4.9.1.2. Stream Errors Can Occur During Setup . . . . . . 48 111 4.9.1.3. Stream Errors When the Host is Unspecified or 112 Unknown . . . . . . . . . . . . . . . . . . . . . 49 113 4.9.1.4. Where Stream Errors Are Sent . . . . . . . . . . 50 114 4.9.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 50 115 4.9.3. Defined Stream Error Conditions . . . . . . . . . . 52 116 4.9.3.1. bad-format . . . . . . . . . . . . . . . . . . . 52 117 4.9.3.2. bad-namespace-prefix . . . . . . . . . . . . . . 52 118 4.9.3.3. conflict . . . . . . . . . . . . . . . . . . . . 53 119 4.9.3.4. connection-timeout . . . . . . . . . . . . . . . 54 120 4.9.3.5. host-gone . . . . . . . . . . . . . . . . . . . . 55 121 4.9.3.6. host-unknown . . . . . . . . . . . . . . . . . . 55 122 4.9.3.7. improper-addressing . . . . . . . . . . . . . . . 56 123 4.9.3.8. internal-server-error . . . . . . . . . . . . . . 56 124 4.9.3.9. invalid-from . . . . . . . . . . . . . . . . . . 57 125 4.9.3.10. invalid-namespace . . . . . . . . . . . . . . . . 57 126 4.9.3.11. invalid-xml . . . . . . . . . . . . . . . . . . . 58 127 4.9.3.12. not-authorized . . . . . . . . . . . . . . . . . 59 128 4.9.3.13. not-well-formed . . . . . . . . . . . . . . . . . 59 129 4.9.3.14. policy-violation . . . . . . . . . . . . . . . . 60 130 4.9.3.15. remote-connection-failed . . . . . . . . . . . . 60 131 4.9.3.16. reset . . . . . . . . . . . . . . . . . . . . . . 61 132 4.9.3.17. resource-constraint . . . . . . . . . . . . . . . 61 133 4.9.3.18. restricted-xml . . . . . . . . . . . . . . . . . 62 134 4.9.3.19. see-other-host . . . . . . . . . . . . . . . . . 62 135 4.9.3.20. system-shutdown . . . . . . . . . . . . . . . . . 64 136 4.9.3.21. undefined-condition . . . . . . . . . . . . . . . 64 137 4.9.3.22. unsupported-encoding . . . . . . . . . . . . . . 64 138 4.9.3.23. unsupported-feature . . . . . . . . . . . . . . . 65 139 4.9.3.24. unsupported-stanza-type . . . . . . . . . . . . . 66 140 4.9.3.25. unsupported-version . . . . . . . . . . . . . . . 66 141 4.9.4. Application-Specific Conditions . . . . . . . . . . 67 142 4.10. Simplified Stream Examples . . . . . . . . . . . . . . . 68 143 5. STARTTLS Negotiation . . . . . . . . . . . . . . . . . . . . 70 144 5.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 70 145 5.2. Support . . . . . . . . . . . . . . . . . . . . . . . . 71 146 5.3. Stream Negotiation Rules . . . . . . . . . . . . . . . . 71 147 5.3.1. Mandatory-to-Negotiate . . . . . . . . . . . . . . . 71 148 5.3.2. Restart . . . . . . . . . . . . . . . . . . . . . . 71 149 5.3.3. Data Formatting . . . . . . . . . . . . . . . . . . 71 150 5.3.4. Order of TLS and SASL Negotiations . . . . . . . . . 71 151 5.3.5. TLS Renegotiation . . . . . . . . . . . . . . . . . 72 152 5.3.6. TLS Extensions . . . . . . . . . . . . . . . . . . . 73 153 5.4. Process . . . . . . . . . . . . . . . . . . . . . . . . 73 154 5.4.1. Exchange of Stream Headers and Stream Features . . . 73 155 5.4.2. Initiation of STARTTLS Negotiation . . . . . . . . . 74 156 5.4.2.1. STARTTLS Command . . . . . . . . . . . . . . . . 74 157 5.4.2.2. Failure Case . . . . . . . . . . . . . . . . . . 74 158 5.4.2.3. Proceed Case . . . . . . . . . . . . . . . . . . 75 159 5.4.3. TLS Negotiation . . . . . . . . . . . . . . . . . . 75 160 5.4.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . 75 161 5.4.3.2. TLS Failure . . . . . . . . . . . . . . . . . . . 76 162 5.4.3.3. TLS Success . . . . . . . . . . . . . . . . . . . 77 163 6. SASL Negotiation . . . . . . . . . . . . . . . . . . . . . . 78 164 6.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 78 165 6.2. Support . . . . . . . . . . . . . . . . . . . . . . . . 78 166 6.3. Stream Negotiation Rules . . . . . . . . . . . . . . . . 78 167 6.3.1. Mandatory-to-Negotiate . . . . . . . . . . . . . . . 79 168 6.3.2. Restart . . . . . . . . . . . . . . . . . . . . . . 79 169 6.3.3. Mechanism Preferences . . . . . . . . . . . . . . . 79 170 6.3.4. Mechanism Offers . . . . . . . . . . . . . . . . . . 79 171 6.3.5. Data Formatting . . . . . . . . . . . . . . . . . . 80 172 6.3.6. Security Layers . . . . . . . . . . . . . . . . . . 81 173 6.3.7. Simple User Name . . . . . . . . . . . . . . . . . . 81 174 6.3.8. Authorization Identity . . . . . . . . . . . . . . . 81 175 6.3.9. Realms . . . . . . . . . . . . . . . . . . . . . . . 82 176 6.3.10. Round Trips . . . . . . . . . . . . . . . . . . . . 82 177 6.4. Process . . . . . . . . . . . . . . . . . . . . . . . . 83 178 6.4.1. Exchange of Stream Headers and Stream Features . . . 83 179 6.4.2. Initiation . . . . . . . . . . . . . . . . . . . . . 84 180 6.4.3. Challenge-Response Sequence . . . . . . . . . . . . 85 181 6.4.4. Abort . . . . . . . . . . . . . . . . . . . . . . . 85 182 6.4.5. SASL Failure . . . . . . . . . . . . . . . . . . . . 86 183 6.4.6. SASL Success . . . . . . . . . . . . . . . . . . . . 87 184 6.5. SASL Errors . . . . . . . . . . . . . . . . . . . . . . 88 185 6.5.1. aborted . . . . . . . . . . . . . . . . . . . . . . 89 186 6.5.2. account-disabled . . . . . . . . . . . . . . . . . . 89 187 6.5.3. credentials-expired . . . . . . . . . . . . . . . . 89 188 6.5.4. encryption-required . . . . . . . . . . . . . . . . 89 189 6.5.5. incorrect-encoding . . . . . . . . . . . . . . . . . 90 190 6.5.6. invalid-authzid . . . . . . . . . . . . . . . . . . 90 191 6.5.7. invalid-mechanism . . . . . . . . . . . . . . . . . 90 192 6.5.8. malformed-request . . . . . . . . . . . . . . . . . 91 193 6.5.9. mechanism-too-weak . . . . . . . . . . . . . . . . . 91 194 6.5.10. not-authorized . . . . . . . . . . . . . . . . . . . 91 195 6.5.11. temporary-auth-failure . . . . . . . . . . . . . . . 92 196 6.6. SASL Definition . . . . . . . . . . . . . . . . . . . . 92 197 7. Resource Binding . . . . . . . . . . . . . . . . . . . . . . 93 198 7.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 93 199 7.2. Support . . . . . . . . . . . . . . . . . . . . . . . . 94 200 7.3. Stream Negotiation Rules . . . . . . . . . . . . . . . . 94 201 7.3.1. Mandatory-to-Negotiate . . . . . . . . . . . . . . . 94 202 7.3.2. Restart . . . . . . . . . . . . . . . . . . . . . . 94 203 7.4. Advertising Support . . . . . . . . . . . . . . . . . . 94 204 7.5. Generation of Resource Identifiers . . . . . . . . . . . 95 205 7.6. Server-Generated Resource Identifier . . . . . . . . . . 95 206 7.6.1. Success Case . . . . . . . . . . . . . . . . . . . . 95 207 7.6.2. Error Cases . . . . . . . . . . . . . . . . . . . . 96 208 7.6.2.1. Resource Constraint . . . . . . . . . . . . . . . 96 209 7.6.2.2. Not Allowed . . . . . . . . . . . . . . . . . . . 96 210 7.7. Client-Submitted Resource Identifier . . . . . . . . . . 97 211 7.7.1. Success Case . . . . . . . . . . . . . . . . . . . . 97 212 7.7.2. Error Cases . . . . . . . . . . . . . . . . . . . . 98 213 7.7.2.1. Bad Request . . . . . . . . . . . . . . . . . . . 98 214 7.7.2.2. Conflict . . . . . . . . . . . . . . . . . . . . 98 215 7.7.3. Retries . . . . . . . . . . . . . . . . . . . . . . 100 216 8. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 100 217 8.1. Common Attributes . . . . . . . . . . . . . . . . . . . 100 218 8.1.1. to . . . . . . . . . . . . . . . . . . . . . . . . . 101 219 8.1.1.1. Client-to-Server Streams . . . . . . . . . . . . 101 220 8.1.1.2. Server-to-Server Streams . . . . . . . . . . . . 102 221 8.1.2. from . . . . . . . . . . . . . . . . . . . . . . . . 102 222 8.1.2.1. Client-to-Server Streams . . . . . . . . . . . . 102 223 8.1.2.2. Server-to-Server Streams . . . . . . . . . . . . 103 224 8.1.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 104 225 8.1.4. type . . . . . . . . . . . . . . . . . . . . . . . . 104 226 8.1.5. xml:lang . . . . . . . . . . . . . . . . . . . . . . 104 227 8.2. Basic Semantics . . . . . . . . . . . . . . . . . . . . 105 228 8.2.1. Message Semantics . . . . . . . . . . . . . . . . . 105 229 8.2.2. Presence Semantics . . . . . . . . . . . . . . . . . 106 230 8.2.3. IQ Semantics . . . . . . . . . . . . . . . . . . . . 106 231 8.3. Stanza Errors . . . . . . . . . . . . . . . . . . . . . 108 232 8.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 109 233 8.3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 110 234 8.3.3. Defined Conditions . . . . . . . . . . . . . . . . . 111 235 8.3.3.1. bad-request . . . . . . . . . . . . . . . . . . . 111 236 8.3.3.2. conflict . . . . . . . . . . . . . . . . . . . . 112 237 8.3.3.3. feature-not-implemented . . . . . . . . . . . . . 112 238 8.3.3.4. forbidden . . . . . . . . . . . . . . . . . . . . 113 239 8.3.3.5. gone . . . . . . . . . . . . . . . . . . . . . . 114 240 8.3.3.6. internal-server-error . . . . . . . . . . . . . . 114 241 8.3.3.7. item-not-found . . . . . . . . . . . . . . . . . 115 242 8.3.3.8. jid-malformed . . . . . . . . . . . . . . . . . . 115 243 8.3.3.9. not-acceptable . . . . . . . . . . . . . . . . . 116 244 8.3.3.10. not-allowed . . . . . . . . . . . . . . . . . . . 117 245 8.3.3.11. not-authorized . . . . . . . . . . . . . . . . . 117 246 8.3.3.12. policy-violation . . . . . . . . . . . . . . . . 118 247 8.3.3.13. recipient-unavailable . . . . . . . . . . . . . . 118 248 8.3.3.14. redirect . . . . . . . . . . . . . . . . . . . . 119 249 8.3.3.15. registration-required . . . . . . . . . . . . . . 120 250 8.3.3.16. remote-server-not-found . . . . . . . . . . . . . 121 251 8.3.3.17. remote-server-timeout . . . . . . . . . . . . . . 122 252 8.3.3.18. resource-constraint . . . . . . . . . . . . . . . 122 253 8.3.3.19. service-unavailable . . . . . . . . . . . . . . . 123 254 8.3.3.20. subscription-required . . . . . . . . . . . . . . 124 255 8.3.3.21. undefined-condition . . . . . . . . . . . . . . . 124 256 8.3.3.22. unexpected-request . . . . . . . . . . . . . . . 125 257 8.3.4. Application-Specific Conditions . . . . . . . . . . 126 258 8.4. Extended Content . . . . . . . . . . . . . . . . . . . . 127 259 9. Detailed Examples . . . . . . . . . . . . . . . . . . . . . . 130 260 9.1. Client-to-Server Examples . . . . . . . . . . . . . . . 130 261 9.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 130 262 9.1.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 132 263 9.1.3. Resource Binding . . . . . . . . . . . . . . . . . . 134 264 9.1.4. Stanza Exchange . . . . . . . . . . . . . . . . . . 135 265 9.1.5. Close . . . . . . . . . . . . . . . . . . . . . . . 136 266 9.2. Server-to-Server Examples . . . . . . . . . . . . . . . 136 267 9.2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 136 268 9.2.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 138 269 9.2.3. Stanza Exchange . . . . . . . . . . . . . . . . . . 139 270 9.2.4. Close . . . . . . . . . . . . . . . . . . . . . . . 139 271 10. Server Rules for Processing XML Stanzas . . . . . . . . . . . 140 272 10.1. In-Order Processing . . . . . . . . . . . . . . . . . . 140 273 10.2. General Considerations . . . . . . . . . . . . . . . . . 141 274 10.3. No 'to' Address . . . . . . . . . . . . . . . . . . . . 143 275 10.3.1. Message . . . . . . . . . . . . . . . . . . . . . . 143 276 10.3.2. Presence . . . . . . . . . . . . . . . . . . . . . . 143 277 10.3.3. IQ . . . . . . . . . . . . . . . . . . . . . . . . . 143 278 10.4. Remote Domain . . . . . . . . . . . . . . . . . . . . . 144 279 10.4.1. Existing Stream . . . . . . . . . . . . . . . . . . 144 280 10.4.2. No Existing Stream . . . . . . . . . . . . . . . . . 144 281 10.4.3. Error Handling . . . . . . . . . . . . . . . . . . . 144 282 10.5. Local Domain . . . . . . . . . . . . . . . . . . . . . . 145 283 10.5.1. domainpart . . . . . . . . . . . . . . . . . . . . . 145 284 10.5.2. domainpart/resourcepart . . . . . . . . . . . . . . 145 285 10.5.3. localpart@domainpart . . . . . . . . . . . . . . . . 145 286 10.5.3.1. No Such User . . . . . . . . . . . . . . . . . . 145 287 10.5.3.2. User Exists . . . . . . . . . . . . . . . . . . . 146 289 10.5.4. localpart@domainpart/resourcepart . . . . . . . . . 146 290 11. XML Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 147 291 11.1. XML Restrictions . . . . . . . . . . . . . . . . . . . . 147 292 11.2. XML Namespace Names and Prefixes . . . . . . . . . . . . 147 293 11.3. Well-Formedness . . . . . . . . . . . . . . . . . . . . 148 294 11.4. Validation . . . . . . . . . . . . . . . . . . . . . . . 148 295 11.5. Inclusion of XML Declaration . . . . . . . . . . . . . . 149 296 11.6. Character Encoding . . . . . . . . . . . . . . . . . . . 149 297 11.7. Whitespace . . . . . . . . . . . . . . . . . . . . . . . 149 298 11.8. XML Versions . . . . . . . . . . . . . . . . . . . . . . 150 299 12. Internationalization Considerations . . . . . . . . . . . . . 150 300 13. Security Considerations . . . . . . . . . . . . . . . . . . . 150 301 13.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 150 302 13.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 151 303 13.3. Order of Layers . . . . . . . . . . . . . . . . . . . . 152 304 13.4. Confidentiality and Integrity . . . . . . . . . . . . . 152 305 13.5. Peer Entity Authentication . . . . . . . . . . . . . . . 153 306 13.6. Strong Security . . . . . . . . . . . . . . . . . . . . 153 307 13.7. Certificates . . . . . . . . . . . . . . . . . . . . . . 153 308 13.7.1. Certificate Generation . . . . . . . . . . . . . . . 154 309 13.7.1.1. General Considerations . . . . . . . . . . . . . 154 310 13.7.1.2. Server Certificates . . . . . . . . . . . . . . . 155 311 13.7.1.3. Client Certificates . . . . . . . . . . . . . . . 157 312 13.7.1.4. XmppAddr Identifier Type . . . . . . . . . . . . 157 313 13.7.2. Certificate Validation . . . . . . . . . . . . . . . 158 314 13.7.2.1. Server Certificates . . . . . . . . . . . . . . . 159 315 13.7.2.2. Client Certificates . . . . . . . . . . . . . . . 160 316 13.7.2.3. Checking of Certificates in Long-Lived Streams . 161 317 13.7.2.4. Use of Certificates in XMPP Extensions . . . . . 162 318 13.8. Mandatory-to-Implement TLS and SASL Technologies . . . . 162 319 13.8.1. For Authentication Only . . . . . . . . . . . . . . 162 320 13.8.2. For Confidentiality Only . . . . . . . . . . . . . . 162 321 13.8.3. For Confidentiality and Authentication With 322 Passwords . . . . . . . . . . . . . . . . . . . . . 163 323 13.8.4. For Confidentiality and Authentication Without 324 Passwords . . . . . . . . . . . . . . . . . . . . . 164 325 13.9. Technology Reuse . . . . . . . . . . . . . . . . . . . . 164 326 13.9.1. Use of Base 64 in SASL . . . . . . . . . . . . . . . 164 327 13.9.2. Use of DNS . . . . . . . . . . . . . . . . . . . . . 164 328 13.9.3. Use of Hash Functions . . . . . . . . . . . . . . . 165 329 13.9.4. Use of SASL . . . . . . . . . . . . . . . . . . . . 165 330 13.9.5. Use of TLS . . . . . . . . . . . . . . . . . . . . . 166 331 13.9.6. Use of UTF-8 . . . . . . . . . . . . . . . . . . . . 167 332 13.9.7. Use of XML . . . . . . . . . . . . . . . . . . . . . 167 333 13.10. Information Leaks . . . . . . . . . . . . . . . . . . . 167 334 13.10.1. IP Addresses . . . . . . . . . . . . . . . . . . . . 167 335 13.10.2. Presence Information . . . . . . . . . . . . . . . . 167 336 13.11. Directory Harvesting . . . . . . . . . . . . . . . . . . 168 337 13.12. Denial of Service . . . . . . . . . . . . . . . . . . . 168 338 13.13. Firewalls . . . . . . . . . . . . . . . . . . . . . . . 170 339 13.14. Interdomain Federation . . . . . . . . . . . . . . . . . 170 340 13.15. Non-Repudiation . . . . . . . . . . . . . . . . . . . . 170 341 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 171 342 14.1. XML Namespace Name for TLS Data . . . . . . . . . . . . 171 343 14.2. XML Namespace Name for SASL Data . . . . . . . . . . . . 171 344 14.3. XML Namespace Name for Stream Errors . . . . . . . . . . 171 345 14.4. XML Namespace Name for Resource Binding . . . . . . . . 172 346 14.5. XML Namespace Name for Stanza Errors . . . . . . . . . . 172 347 14.6. GSSAPI Service Name . . . . . . . . . . . . . . . . . . 172 348 14.7. Port Numbers and Service Names . . . . . . . . . . . . . 172 349 15. Conformance Requirements . . . . . . . . . . . . . . . . . . 173 350 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 182 351 16.1. Normative References . . . . . . . . . . . . . . . . . . 182 352 16.2. Informative References . . . . . . . . . . . . . . . . . 185 353 Appendix A. XML Schemas . . . . . . . . . . . . . . . . . . . . 191 354 A.1. Stream Namespace . . . . . . . . . . . . . . . . . . . . 192 355 A.2. Stream Error Namespace . . . . . . . . . . . . . . . . . 193 356 A.3. STARTTLS Namespace . . . . . . . . . . . . . . . . . . . 196 357 A.4. SASL Namespace . . . . . . . . . . . . . . . . . . . . . 196 358 A.5. Client Namespace . . . . . . . . . . . . . . . . . . . . 198 359 A.6. Server Namespace . . . . . . . . . . . . . . . . . . . . 202 360 A.7. Resource Binding Namespace . . . . . . . . . . . . . . . 208 361 A.8. Stanza Error Namespace . . . . . . . . . . . . . . . . . 208 362 Appendix B. Contact Addresses . . . . . . . . . . . . . . . . . 210 363 Appendix C. Account Provisioning . . . . . . . . . . . . . . . . 210 364 Appendix D. Differences from RFC 3920 . . . . . . . . . . . . . 210 365 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 212 366 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 212 368 1. Introduction 370 1.1. Overview 372 The Extensible Messaging and Presence Protocol (XMPP) is an 373 application profile of the Extensible Markup Language [XML] that 374 enables the near-real-time exchange of structured yet extensible data 375 between any two or more network entities. This document defines 376 XMPP's core protocol methods: setup and teardown of XML streams, 377 channel encryption, authentication, error handling, and communication 378 primitives for messaging, network availability ("presence"), and 379 request-response interactions. 381 1.2. History 383 The basic syntax and semantics of XMPP were developed originally 384 within the Jabber open-source community, mainly in 1999. In late 385 2002, the XMPP Working Group was chartered with developing an 386 adaptation of the base Jabber protocol that would be suitable as an 387 IETF instant messaging (IM) and presence technology in accordance 388 with [IMP-REQS]. In October 2004, [RFC3920] and [RFC3921] were 389 published, representing the most complete definition of XMPP at that 390 time. 392 Since 2004 the Internet community has gained extensive implementation 393 and deployment experience with XMPP, including formal 394 interoperability testing carried out under the auspices of the XMPP 395 Standards Foundation (XSF). This document incorporates comprehensive 396 feedback from software developers and XMPP service providers, 397 including a number of backward-compatible modifications summarized 398 under Appendix D. As a result, this document reflects the rough 399 consensus of the Internet community regarding the core features of 400 XMPP 1.0, thus obsoleting RFC 3920. 402 1.3. Functional Summary 404 This non-normative section provides a developer-friendly, functional 405 summary of XMPP; refer to the sections that follow for a normative 406 definition of XMPP. 408 The purpose of XMPP is to enable the exchange of relatively small 409 pieces of structured data (called "XML stanzas") over a network 410 between any two (or more) entities. XMPP is typically implemented 411 using a distributed client-server architecture, wherein a client 412 needs to connect to a server in order to gain access to the network 413 and thus be allowed to exchange XML stanzas with other entities 414 (which can be associated with other servers). The process whereby a 415 client connects to a server, exchanges XML stanzas, and ends the 416 connection is: 418 1. Determine the IP address and port at which to connect, typically 419 based on resolution of a fully-qualified domain name 420 (Section 3.2) 421 2. Open a Transmission Control Protocol [TCP] connection 422 3. Open an XML stream over TCP (Section 4.2) 423 4. Preferably negotiate Transport Layer Security [TLS] for channel 424 encryption (Section 5) 425 5. Authenticate using a Simple Authentication and Security Layer 426 [SASL] mechanism (Section 6) 427 6. Bind a resource to the stream (Section 7) 428 7. Exchange an unbounded number of XML stanzas with other entities 429 on the network (Section 8) 430 8. Close the XML stream (Section 4.4) 431 9. Close the TCP connection 433 Within XMPP, one server can optionally connect to another server to 434 enable inter-domain or inter-server communication. For this to 435 happen, the two servers need to negotiate a connection between 436 themselves and then exchange XML stanzas; the process for doing so 437 is: 439 1. Determine the IP address and port at which to connect, typically 440 based on resolution of a fully-qualified domain name 441 (Section 3.2) 442 2. Open a TCP connection 443 3. Open an XML stream (Section 4.2) 444 4. Preferably negotiate TLS for channel encryption (Section 5) 445 5. Authenticate using a Simple Authentication and Security Layer 446 [SASL] mechanism (Section 6) * 447 6. Exchange an unbounded number of XML stanzas both directly for the 448 servers and indirectly on behalf of entities associated with each 449 server, such as connected clients (Section 8) 450 7. Close the XML stream (Section 4.4) 451 8. Close the TCP connection 453 * Interoperability Note: At the time of writing, most deployed 454 servers still use the Server Dialback protocol [XEP-0220] to 455 provide weak identity verification instead of using SASL with PKIX 456 certificates to provide strong authentication, especially in cases 457 where SASL negotiation would not result in strong authentication 458 anyway (e.g., because TLS negotiation was not mandated by the peer 459 server, or because the PKIX certificate presented by the peer 460 server during TLS negotiation is self-signed and has not been 461 previously accepted); for details, see [XEP-0220]. The solutions 462 specified in this document offer a significantly stronger level of 463 security (see also Section 13.6). 465 This document specifies how clients connect to servers and specifies 466 the basic semantics of XML stanzas. However, this document does not 467 define the "payloads" of the XML stanzas that might be exchanged once 468 a connection is successfully established; instead, those payloads are 469 defined by various XMPP extensions. For example, [XMPP-IM] defines 470 extensions for basic instant messaging and presence functionality. 471 In addition, various specifications produced in the XSF's XEP series 472 [XEP-0001] define extensions for a wide range of applications. 474 1.4. Terminology 476 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 477 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 478 "OPTIONAL" in this document are to be interpreted as described in RFC 479 2119 [KEYWORDS]. 481 Certain security-related terms are to be understood in the sense 482 defined in [SEC-TERMS]; such terms include, but are not limited to, 483 "assurance", "attack", "authentication", "authorization", 484 "certificate", "certification authority", "certification path", 485 "confidentiality", "credential", "downgrade", "encryption", "hash 486 value", "identity", "integrity", "signature", "self-signed 487 certificate", "sign", "spoof", "tamper", "trust", "trust anchor", 488 "validate", and "verify". 490 Certain terms related to certificates, domains, and application 491 service identity are to be understood in the sense defined in 492 [TLS-CERTS]; these include, but are not limited to, "PKIX 493 certificate", "source domain", "derived domain", and the identifier 494 types "CN-ID", "DNS-ID", and "SRV-ID". 496 Other security-related terms are to be understood in the sense 497 defined in the referenced specifications (for example, "denial of 498 service" as described in [DOS] or "end entity certificate" as 499 described in [PKIX]). 501 The term "whitespace" is used to refer to any character or characters 502 matching the "S" production from [XML], i.e., one or more instances 503 of the SP, HTAB, CR, or LF rules defined in [ABNF]. 505 The terms "localpart", "domainpart", and "resourcepart" are defined 506 in [XMPP-ADDR]. 508 The term "bare JID" refers to an XMPP address of the form 509 (for an account at a server) or of the form 510 (for a server). 512 The term "full JID" refers to an XMPP address of the form 513 (for a particular authorized 514 client or device associated with an account) or of the form 515 (for a particular resource or script 516 associated with a server). 518 The term "XML stream" (also "stream") is defined under Section 4.1. 520 The term "XML stanza" (also "stanza") is defined under Section 4.1. 521 There are three kinds of stanzas: message, presence, and IQ (short 522 for "Info/Query"). These communication primitives are defined under 523 Section 8.2.1, Section 8.2.2, and Section 8.2.3, respectively. 525 The term "originating entity" refers to the entity that first 526 generates a stanza that is sent over an XMPP network (e.g., a 527 connected client, an add-on service, or a server). The term 528 "generated stanza" refers to the stanza so generated. 530 The term "input stream" designates an XML stream over which a server 531 receives data from a connected client or remote server, and the term 532 "output stream" designates an XML stream over which a server sends 533 data to a connected client or remote server. The following terms 534 designate some of the actions that a server can perform when 535 processing data received over an input stream: 537 route: pass the data to a remote server for direct processing by 538 the remote server or eventual delivery to a client associated 539 with the remote server 541 deliver: pass the data to a connected client 543 ignore: discard the data without acting upon it or returning an 544 error to the sender 546 When the term "ignore" is used with regard to client processing of 547 data it receives, the phrase "without acting upon it" explicitly 548 includes not presenting the data to a human user. 550 Following the "XML Notation" used in [IRI] to represent characters 551 that cannot be rendered in ASCII-only documents, some examples in 552 this document use the form "&#x...." as a notational device to 553 represent [UNICODE] characters (e.g., the string "ř" stands 554 for the Unicode character LATIN SMALL LETTER R WITH CARON); this form 555 is definitely not to be sent over the wire in XMPP systems. 557 Consistent with the convention used in [URI] to represent Uniform 558 Resource Indentifiers, XMPP addresses in running text are enclosed 559 between '<' and '>' (although natively they are not URIs). 561 In examples, lines have been wrapped for improved readability, 562 "[...]" means elision, and the following prepended strings are used 563 (these prepended strings are not to be sent over the wire): 565 o C: = a client 566 o E: = any XMPP entity 567 o I: = an initiating entity 568 o P: = a peer server 569 o R: = a receiving entity 570 o S: = a server 571 o S1: = server1 572 o S2: = server2 574 Readers need to be aware that the examples are not exhaustive and 575 that, in examples for some protocol flows, the alternate steps shown 576 would not necessarily be triggered by the exact data sent in the 577 previous step; in all cases the protocol definitions specified in 578 this document or in normatively referenced documents rule over any 579 examples provided here. All examples are fictional and the 580 information exchanged (e.g., usernames and passwords) does not 581 represent any existing users or servers. 583 2. Architecture 585 XMPP provides a technology for the asynchronous, end-to-end exchange 586 of structured data by means of direct, persistent XML streams among a 587 distributed network of globally-addressable, presence-aware clients 588 and servers. Because this architectural style involves ubiquitous 589 knowledge of network availability and a conceptually unlimited number 590 of concurrent information transactions in the context of a given 591 client-to-server or server-to-server session, we label it 592 "Availability for Concurrent Transactions" (ACT) to distinguish it 593 from the "Representational State Transfer" [REST] architectural style 594 familiar from the World Wide Web. Although the architecture of XMPP 595 is similar in important ways to that of email (see [EMAIL-ARCH]), it 596 introduces several modifications to facilitate communication in close 597 to real time. The salient features of this ACTive architectural 598 style are as follows. 600 2.1. Global Addresses 602 As with email, XMPP uses globally-unique addresses (based on the 603 Domain Name System) in order to route and deliver messages over the 604 network. All XMPP entities are addressable on the network, most 605 particularly clients and servers but also various additional services 606 that can be accessed by clients and servers. In general, server 607 addresses are of the form (e.g., ), 608 accounts hosted at a server are of the form 609 (e.g., , called a "bare JID"), and a 610 particular connected device or resource that is currently authorized 611 for interaction on behalf of an account is of the form 612 (e.g., 613 , called a "full JID"). For 614 historical reasons, XMPP addresses are often called Jabber IDs or 615 JIDs. Because the formal specification of the XMPP address format 616 depends on internationalization technologies that are in flux at the 617 time of writing, the format is defined in [XMPP-ADDR] instead of this 618 document. The terms "localpart", "domainpart", and "resourcepart" 619 are defined more formally in [XMPP-ADDR]. 621 2.2. Presence 623 XMPP includes the ability for an entity to advertise its network 624 availability or "presence" to other entities. In XMPP, this 625 availability for communication is signalled end-to-end by means of a 626 dedicated communication primitive: the stanza. Although 627 knowledge of network availability is not strictly necessary for the 628 exchange of XMPP messages, it facilitates real-time interaction 629 because the originator of a message can know before initiating 630 communication that the intended recipient is online and available. 631 End-to-end presence is defined in [XMPP-IM]. 633 2.3. Persistent Streams 635 Availability for communication is also built into each point-to-point 636 "hop" through the use of persistent XML streams over long-lived TCP 637 connections. These "always-on" client-to-server and server-to-server 638 streams enable each party to push data to the other party at any time 639 for immediate routing or delivery. XML streams are defined under 640 Section 4. 642 2.4. Structured Data 644 The basic protocol data unit in XMPP is not an XML stream (which 645 simply provides the transport for point-to-point communication) but 646 an XML "stanza", which is essentially a fragment of XML that is sent 647 over a stream. The root element of a stanza includes routing 648 attributes (such as "from" and "to" addresses) and the child elements 649 of the stanza contain a payload for delivery to the intended 650 recipient. XML stanzas are defined under Section 8. 652 2.5. Distributed Network of Clients and Servers 654 In practice, XMPP consists of a network of clients and servers that 655 inter-communicate (however, communication between any two given 656 deployed servers is strictly discretionary and a matter of local 657 service policy). Thus, for example, the user 658 associated with the server might be able to exchange 659 messages, presence, and other structured data with the user 660 associated with the server . This 661 pattern is familiar from messaging protocols that make use of global 662 addresses, such as the email network (see [SMTP] and [EMAIL-ARCH]). 663 As a result, end-to-end communication in XMPP is logically peer-to- 664 peer but physically client-to-server-to-server-to-client, as 665 illustrated in the following diagram. 667 example.net <--------------> im.example.com 668 ^ ^ 669 | | 670 v v 671 romeo@example.net juliet@im.example.com 673 Figure 1: Distributed Client-Server Architecture 675 Informational Note: Architectures that employ XML streams 676 (Section 4) and XML stanzas (Section 8) but that establish peer- 677 to-peer connections directly between clients using technologies 678 based on [LINKLOCAL] have been deployed, but such architectures 679 are not defined in this specification and are best described as 680 "XMPP-like"; for details, see [XEP-0174]. In addition, XML 681 streams can be established end-to-end over any reliable transport, 682 including extensions to XMPP itself; however, such methods are out 683 of scope for this specification. 685 The following paragraphs describe the responsibilities of clients and 686 servers on the network. 688 A client is an entity that establishes an XML stream with a server by 689 authenticating using the credentials of a registered account (via 690 SASL negotiation (Section 6)) and that then completes resource 691 binding (Section 7) in order to enable delivery of XML stanzas 692 between the server and the client over the negotiated stream. The 693 client then uses XMPP to communicate with its server, other clients, 694 and any other entities on the network, where the server is 695 responsible for delivering stanzas to other connected clients at the 696 same server or routing them to remote servers. Multiple clients can 697 connect simultaneously to a server on behalf of the same registered 698 account, where each client is differentiated by the resourcepart of 699 an XMPP address (e.g., vs. 700 ), as defined under [XMPP-ADDR] and 701 Section 7. 703 A server is an entity whose primary responsibilities are to: 705 o Manage XML streams (Section 4) with connected clients and deliver 706 XML stanzas (Section 8) to those clients over the negotiated 707 streams; this includes responsibility for ensuring that a client 708 authenticates with the server before being granted access to the 709 XMPP network. 711 o Subject to local service policies on server-to-server 712 communication, manage XML streams (Section 4) with remote servers 713 and route XML stanzas (Section 8) to those servers over the 714 negotiated streams. 716 Depending on the application, the secondary responsibilities of an 717 XMPP server can include: 719 o Storing data that is used by clients (e.g., contact lists for 720 users of XMPP-based instant messaging and presence applications as 721 defined in [XMPP-IM]); in this case, the relevant XML stanza is 722 handled directly by the server itself on behalf of the client and 723 is not routed to a remote server or delivered to a connected 724 client. 726 o Hosting add-on services that also use XMPP as the basis for 727 communication but that provide additional functionality beyond 728 that defined in this document or in [XMPP-IM]; examples include 729 multi-user conferencing services as specified in [XEP-0045] and 730 publish-subscribe services as specified in [XEP-0060]. 732 3. TCP Binding 734 3.1. Scope 736 As XMPP is defined in this specification, an initiating entity 737 (client or server) MUST open a Transmission Control Protocol [TCP] 738 connection to the receiving entity (server) before it negotiates XML 739 streams with the receiving entity. The parties then maintain that 740 TCP connection for as long as the XML streams are in use. The rules 741 specified in the following sections apply to the TCP binding. 743 Informational Note: There is no necessary coupling of XML streams 744 to TCP, and other transports are possible. For example, two 745 entities could connect to each other by means of [HTTP] as 746 specified in [XEP-0124] and [XEP-0206]. However, this 747 specification defines only a binding of XMPP to TCP. 749 3.2. Resolution of Fully Qualified Domain Names 751 Because XML streams are sent over TCP, the initiating entity needs to 752 determine the IPv4 or IPv6 address (and port) of the receiving entity 753 before it can attempt to open an XML stream. Typically this is done 754 by resolving the receiving entity's fully-qualified domain name or 755 "FDQN" (see [DNS-CONCEPTS]). 757 3.2.1. Preferred Process: SRV Lookup 759 The preferred process for FQDN resolution is to use [DNS-SRV] records 760 as follows: 762 1. The initiating entity constructs a DNS SRV query whose inputs 763 are: 764 * a Service of "xmpp-client" (for client-to-server connections) 765 or "xmpp-server" (for server-to-server connections) 766 * a Proto of "tcp" 767 * a Name corresponding to the "origin domain" [TLS-CERTS] of the 768 XMPP service to which the initiating entity wishes to connect 769 (e.g., "example.net" or "im.example.com") 771 2. The result is a query such as "_xmpp-client._tcp.example.net." or 772 "_xmpp-server._tcp.im.example.com.". 774 3. If a response is received, it will contain one or more 775 combinations of a port and FDQN, each of which is weighted and 776 prioritized as described in [DNS-SRV]. 778 (However, if the result of the SRV lookup is a single resource 779 record with a Target of ".", i.e. the root domain, then the 780 initiating entity MUST abort SRV processing at this point because 781 according to [DNS-SRV] such a Target "means that the service is 782 decidedly not available at this domain".) 784 4. The initiating entity chooses at least one of the returned FQDNs 785 to resolve (following the rules in [DNS-SRV]), which it does by 786 performing DNS "A" or "AAAA" lookups on the FDQN; this will 787 result in an IPv4 or IPv6 address. 789 5. The initiating entity uses the IP address(es) from the 790 successfully resolved FDQN (with the corresponding port number 791 returned by the SRV lookup) as the connection address for the 792 receiving entity. 794 6. If the initiating entity fails to connect using that IP address 795 but the "A" or "AAAA" lookups returned more than one IP address, 796 then the initiating entity uses the next resolved IP address for 797 that FDQN as the connection address. 799 7. If the initiating entity fails to connect using all resolved IP 800 addresses for a given FDQN, then it repeats the process of 801 resolution and connection for the next FQDN returned by the SRV 802 lookup based on the priority and weight as defined in [DNS-SRV]. 804 8. If the initiating entity receives a response to its SRV query but 805 it is not able to establish an XMPP connection using the data 806 received in the response, it SHOULD NOT attempt the fallback 807 process described in the next section (this helps to prevent a 808 state mismatch between inbound and outbound connections). 810 9. If the initiating entity does not receive a response to its SRV 811 query, it SHOULD attempt the fallback process described in the 812 next section. 814 3.2.2. Fallback Processes 816 The fallback process SHOULD be a normal "A" or "AAAA" address record 817 resolution to determine the IPv4 or IPv6 address of the origin 818 domain, where the port used is the "xmpp-client" port of 5222 for 819 client-to-server connections or the "xmpp-server" port of 5269 for 820 server-to-server connections (these are the default ports as 821 registered with the IANA as described under Section 14.7). 823 If connections via TCP are unsuccessful, the initiating entity might 824 attempt to find and use alternative connection methods such as the 825 HTTP binding (see [XEP-0124] and [XEP-0206]), which might be 826 discovered using [DNS-TXT] records as described in [XEP-0156]. 828 3.2.3. When Not to Use SRV 830 If the initiating entity has been explicitly configured to associate 831 a particular FQDN (and potentially port) with the origin domain of 832 the receiving entity (say, to "hardcode" an association from an 833 origin domain of example.net to a configured FQDN of 834 apps.example.com), the initiating entity is encouraged to use the 835 configured name instead of performing the preferred SRV resolution 836 process on the origin domain. 838 3.2.4. Use of SRV Records with Add-On Services 840 Many XMPP servers are implemented in such a way that they can host 841 add-on services (beyond those defined in this specification and 843 [XMPP-IM]) at DNS domain names that typically are "subdomains" of the 844 main XMPP service (e.g., conference.example.net for a [XEP-0045] 845 service associated with the example.net XMPP service) or "subdomains" 846 of the first-level domain of the underlying service (e.g., 847 muc.example.com for a [XEP-0045] service associated with the 848 im.example.com XMPP service). If an entity associated with a remote 849 XMPP server wishes to communicate with such an add-on service, it 850 would generate an appropriate XML stanza and the remote server would 851 attempt to resolve the add-on service's DNS domain name via an SRV 852 lookup on resource records such as "_xmpp- 853 server._tcp.conference.example.net." or "_xmpp- 854 server._tcp.muc.example.com.". Therefore if the administrators of an 855 XMPP service wish to enable entities associated with remote servers 856 to access such add-on services, they need to advertise the 857 appropriate "_xmpp-server" SRV records in addition to the "_xmpp- 858 server" record for their main XMPP service. In case SRV records are 859 not available, the fallback methods described under Section 3.2.2 can 860 be used to resolve the DNS domain names of add-on services. 862 3.3. Reconnection 864 It can happen that an XMPP server goes offline unexpectedly while 865 servicing TCP connections from connected clients and remote servers. 866 Because the number of such connections can be quite large, the 867 reconnection algorithm employed by entities that seek to reconnect 868 can have a significant impact on software performance and network 869 congestion. If an entity chooses to reconnect, it: 871 o SHOULD set the number of seconds that expire before reconnecting 872 to an unpredictable number between 0 and 60 (this helps to ensure 873 that not all entities attempt to reconnect at exactly the same 874 number of seconds after being disconnected). 876 o SHOULD back off increasingly on the time between subsequent 877 reconnection attempts (e.g., in accordance with "truncated binary 878 exponential backoff" as described in [ETHERNET]) if the first 879 reconnection attempt does not succeed. 881 It is RECOMMENDED to make use of TLS session resumption [TLS-RESUME] 882 when reconnecting. A future version of this document, or a separate 883 specification, might provide more detailed guidelines regarding 884 methods for speeding the reconnection process. 886 3.4. Reliability 888 The use of long-lived TCP connections in XMPP implies that the 889 sending of XML stanzas over XML streams can be unreliable, since the 890 parties to a long-lived TCP connection might not discover a 891 connectivity disruption in a timely manner. At the XMPP application 892 layer, long connectivity disruptions can result in undelivered 893 stanzas. Although the core XMPP technology defined in this 894 specification does not contain features to overcome this lack of 895 reliability, there exist XMPP extensions for doing so (e.g., 896 [XEP-0198]). 898 4. XML Streams 900 4.1. Stream Fundamentals 902 Two fundamental concepts make possible the rapid, asynchronous 903 exchange of relatively small payloads of structured information 904 between XMPP entities: XML streams and XML stanzas. These terms are 905 defined as follows. 907 Definition of XML Stream: An XML stream is a container for the 908 exchange of XML elements between any two entities over a network. 909 The start of an XML stream is denoted unambiguously by an opening 910 "stream header" (i.e., an XML tag with appropriate 911 attributes and namespace declarations), while the end of the XML 912 stream is denoted unambiguously by a closing XML tag. 913 During the life of the stream, the entity that initiated it can 914 send an unbounded number of XML elements over the stream, either 915 elements used to negotiate the stream (e.g., to complete TLS 916 negotiation (Section 5) or SASL negotiation (Section 6)) or XML 917 stanzas. The "initial stream" is negotiated from the initiating 918 entity (typically a client or server) to the receiving entity 919 (typically a server), and can be seen as corresponding to the 920 initiating entity's "connection to" or "session with" the 921 receiving entity. The initial stream enables unidirectional 922 communication from the initiating entity to the receiving entity; 923 in order to enable exchange of stanzas from the receiving entity 924 to the initiating entity, the receiving entity MUST negotiate a 925 stream in the opposite direction (the "response stream"). 927 Definition of XML Stanza: An XML stanza is the basic unit of meaning 928 in XMPP. A stanza is a first-level element (at depth=1 of the 929 stream) whose element name is "message", "presence", or "iq" and 930 whose qualifying namespace is 'jabber:client' or 'jabber:server'. 931 By contrast, a first-level element qualified by any other 932 namespace is not an XML stanza (stream errors, stream features, 933 TLS-related elements, SASL-related elements, etc.), nor is a 934 , , or element that is qualified by the 935 'jabber:client' or 'jabber:server' namespace but that occurs at a 936 depth other than one (e.g., a element contained within 937 an extension element (Section 8.4) for reporting purposes), nor is 938 a , , or element that is qualified by a 939 namespace other than 'jabber:client' or 'jabber:server'. An XML 940 stanza typically contains one or more child elements (with 941 accompanying attributes, elements, and XML character data) as 942 necessary in order to convey the desired information, which MAY be 943 qualified by any XML namespace (see [XML-NAMES] as well as 944 Section 8.4 in this specification). 946 There are three kinds of stanzas: message, presence, and IQ (short 947 for "Info/Query"). These stanza types provide three different 948 communication primitives: a "push" mechanism for generalized 949 messaging, a specialized "publish-subscribe" mechanism for 950 broadcasting information about network availability, and a "request- 951 response" mechanism for more structured exchanges of data (similar to 952 [HTTP]). Further explanations are provided under Section 8.2.1, 953 Section 8.2.2, and Section 8.2.3, respectively. 955 Consider the example of a client's connection to a server. The 956 client initiates an XML stream by sending a stream header to the 957 server, preferably preceded by an XML declaration specifying the XML 958 version and the character encoding supported (see Section 11.5 and 959 Section 11.6). Subject to local policies and service provisioning, 960 the server then replies with a second XML stream back to the client, 961 again preferably preceded by an XML declaration. Once the client has 962 completed SASL negotiation (Section 6) and resource binding 963 (Section 7), the client can send an unbounded number of XML stanzas 964 over the stream. When the client desires to close the stream, it 965 simply sends a closing tag to the server as further 966 described under Section 4.4. 968 In essence, then, one XML stream functions as an envelope for the XML 969 stanzas sent during a session and another XML stream functions as an 970 envelope for the XML stanzas received during a session. We can 971 represent this in a simplistic fashion as follows. 973 +--------------------+--------------------+ 974 | INITIAL STREAM | RESPONSE STREAM | 975 +--------------------+--------------------+ 976 | | | 977 |--------------------|--------------------| 978 | | | 979 |--------------------|--------------------| 980 | | | 981 | | | 982 | | | 983 |--------------------|--------------------| 984 | | | 985 | | | 986 | | | 987 |--------------------|--------------------| 988 | | | 990 | | | 991 | | | 992 |--------------------|--------------------| 993 | | | 995 | | | 996 | | | 997 |--------------------|--------------------| 998 | [ ... ] | | 999 |--------------------|--------------------| 1000 | | [ ... ] | 1001 |--------------------|--------------------| 1002 | | | 1003 |--------------------|--------------------| 1004 | | | 1005 +--------------------+--------------------+ 1007 Figure 2: A Simplistic View of Two Streams 1009 Those who are accustomed to thinking of XML in a document-centric 1010 manner might find the following analogies useful: 1012 o The two XML streams are like two "documents" (matching the 1013 "document" production from [XML]) that are built up through the 1014 accumulation of XML stanzas. 1016 o The root element is like the "document entity" for each 1017 "document" (as described in Section 4.8 of [XML]). 1019 o The XML stanzas sent over the streams are like "fragments" of the 1020 "documents" (as described in [XML-FRAG]). 1022 However, these descriptions are merely analogies, because XMPP does 1023 not deal in documents and fragments but in streams and stanzas. 1025 The remainder of this section defines the following aspects of XML 1026 streams (along with related topics): 1028 o How to open a stream (Section 4.2) 1029 o The stream negotation process (Section 4.3) 1030 o How to close a stream (Section 4.4) 1031 o The directionality of XML streams (Section 4.5) 1032 o How to handle peers that are silent (Section 4.6) 1033 o The XML attributes of a stream (Section 4.7) 1034 o The XML namespaces of a stream (Section 4.8) 1035 o Error handling related to XML streams (Section 4.9) 1037 4.2. Opening a Stream 1039 After connecting to the appropriate IP address and port of the 1040 receiving entity, the initiating entity opens a stream by sending a 1041 stream header (the "initial stream header") to the receiving entity. 1043 I: 1044 1052 The receiving entity then replies by sending a stream header of its 1053 own (the "response stream header") to the initiating entity. 1055 R: 1056 1065 The entities can then proceed with the remainder of the stream 1066 negotiation process. 1068 4.3. Stream Negotiation 1070 4.3.1. Basic Concepts 1072 Because the receiving entity for a stream acts as a gatekeeper to the 1073 domains it services, it imposes certain conditions for connecting as 1074 a client or as a peer server. At a minimum, the initiating entity 1075 needs to authenticate with the receiving entity before it is allowed 1076 to send stanzas to the receiving entity (for client-to-server streams 1077 this means using SASL as described under Section 6). However, the 1078 receiving entity can consider conditions other than authentication to 1079 be mandatory-to-negotiate, such as encryption using TLS as described 1080 under Section 5. The receiving entity informs the initiating entity 1081 about such conditions by communicating "stream features": the set of 1082 particular protocol interactions that the initiating entity needs to 1083 complete before the receiving entity will accept XML stanzas from the 1084 initiating entity, as well as any protocol interactions that are 1085 voluntary-to-negotiate but that might improve the handling of an XML 1086 stream (e.g., establishment of application-layer compression as 1087 described in [XEP-0138]). 1089 The existence of conditions for connecting implies that streams need 1090 to be negotiated. The order of layers (TCP, then TLS, then SASL, 1091 then XMPP as described under Section 13.3) implies that stream 1092 negotiation is a multi-stage process. Further structure is imposed 1093 by two factors: (1) a given stream feature might be offered only to 1094 certain entities or only after certain other features have been 1095 negotiated (e.g., resource binding is offered only after SASL 1096 authentication), and (2) stream features can be either mandatory-to- 1097 negotiate or voluntary-to-negotiate. Finally, for security reasons 1098 the parties to a stream need to discard knowledge that they gained 1099 during the negotiation process after successfully completing the 1100 protocol interactions defined for certain features (e.g., TLS in all 1101 cases and SASL in the case when a security layer might be 1102 established, as defined in the specification for the relevant SASL 1103 mechanism); this is done by flushing the old stream context and 1104 exchanging new stream headers over the existing TCP connection. 1106 4.3.2. Stream Features Format 1108 If the initiating entity includes in the initial stream header the 1109 'version' attribute set to a value of at least "1.0" (see 1110 Section 4.7.5), after sending the response stream header the 1111 receiving entity MUST send a child element (typically 1112 prefixed by the stream namespace prefix as described under 1113 Section 4.8.5) to the initiating entity in order to announce any 1114 conditions for continuation of the stream negotiation process. Each 1115 condition takes the form of a child element of the 1116 element, qualified by a namespace that is different from the stream 1117 namespace and the content namespace. The element can 1118 contain one child, contain multiple children, or be empty. 1120 Implementation Note: The order of child elements contained in any 1121 given element is not significant. 1123 If a particular stream feature is or can be mandatory-to-negotiate, 1124 the definition of that feature needs to do one of the following: 1126 1. Declare that the feature is always mandatory-to-negotiate (e.g., 1127 this is true of resource binding for XMPP clients); or 1129 2. Specify a way for the receiving entity to flag the feature as 1130 mandatory-to-negotiate for this interaction (e.g., for STARTTLS, 1131 this is done by including an empty element in the 1132 advertisement for that stream feature, but that is not a generic 1133 format for all stream features); it is RECOMMENDED that stream 1134 feature definitions for new mandatory-to-negotiate features do so 1135 by including an empty element as is done for 1136 STARTTLS. 1138 Informational Note: Because there is no generic format for 1139 indicating that a feature is mandatory-to-negotiate, it is 1140 possible that a feature which is not understood by the initiating 1141 entity might be considered mandatory-to-negotiate by the receiving 1142 entity, resulting in failure of the stream negotiation process. 1143 Although such an outcome would be undesirable, the working group 1144 deemed it rare enough that a generic format was not needed. 1146 For security reasons, certain stream features necessitate the 1147 initiating entity to send a new initial stream header upon successful 1148 negotiation of the feature (e.g., TLS in all cases and SASL in the 1149 case when a security layer might be established). If this is true of 1150 a given stream feature, the definition of that feature needs to 1151 specify that a stream restart is expected after negotiation of the 1152 feature. 1154 A element that contains at least one mandatory-to- 1155 negotiate feature indicates that the stream negotiation is not 1156 complete and that the initiating entity MUST negotiate further 1157 features. 1159 R: 1160 1161 1162 1163 1165 A element MAY contain more than one mandatory-to- 1166 negotiate feature. This means that the initiating entity can choose 1167 among the mandatory-to-negotiate features at this stage of the stream 1168 negotiation process. As an example, perhaps a future technology will 1169 perform roughly the same function as TLS, so the receiving entity 1170 might advertise support for both TLS and the future technology at the 1171 same stage of the stream negotiation process. However, this applies 1172 only at a given stage of the stream negotiation process and does not 1173 apply to features that are mandatory-to-negotiate at different stages 1174 (e.g., the receiving entity would not advertise both STARTTLS and 1175 SASL as mandatory-to-negotiate, or both SASL and resource binding as 1176 mandatory-to-negotiate, because TLS would need to be negotiated 1177 before SASL and because SASL would need to be negotiated before 1178 resource binding). 1180 A element that contains both mandatory-to-negotiate and 1181 voluntary-to-negotiate features indicates that the negotiation is not 1182 complete but that the initiating entity MAY complete the voluntary- 1183 to-negotiate feature(s) before it attempts to negotiate the 1184 mandatory-to-negotiate feature(s). 1186 R: 1187 1188 1189 zlib 1190 lzw 1191 1192 1194 A element that contains only voluntary-to-negotiate 1195 features indicates that the stream negotiation is complete and that 1196 the initiating entity is cleared to send XML stanzas, but that the 1197 initiating entity MAY negotiate further features if desired. 1199 R: 1200 1201 zlib 1202 lzw 1203 1204 1206 An empty element indicates that the stream negotiation is 1207 complete and that the initiating entity is cleared to send XML 1208 stanzas. 1210 R: 1212 4.3.3. Restarts 1214 On successful negotiation of a feature that necessitates a stream 1215 restart, both parties MUST consider the previous stream to be 1216 replaced but MUST NOT send a closing tag and MUST NOT 1217 terminate the underlying TCP connection; instead, the parties MUST 1218 reuse the existing connection, which might be in a new state (e.g., 1219 encrypted as a result of TLS negotiation). The initiating entity 1220 then MUST send a new initial stream header, which SHOULD be preceded 1221 by an XML declaration as described under Section 11.5. When the 1222 receiving entity receives the new initial stream header, it MUST 1223 generate a new stream ID (instead of re-using the old stream ID) 1224 before sending a new response stream header (which SHOULD be preceded 1225 by an XML declaration as described under Section 11.5). 1227 4.3.4. Resending Features 1229 The receiving entity MUST send an updated list of stream features to 1230 the initiating entity after a stream restart. The list of updated 1231 features MAY be empty if there are no further features to be 1232 advertised or MAY include any combination of features. 1234 4.3.5. Completion of Stream Negotiation 1236 The receiving entity indicates completion of the stream negotiation 1237 process by sending to the initiating entity either an empty 1238 element or a element that contains only 1239 voluntary-to-negotiate features. After doing so, the receiving 1240 entity MAY send an empty element (e.g., after negotiation 1241 of such voluntary-to-negotiate features) but MUST NOT send additional 1242 stream features to the initiating entity (if the receiving entity has 1243 new features to offer, preferably limited to mandatory-to-negotiate 1244 or security-critical features, it can simply close the stream with a 1245 stream error (Section 4.9.3.16) and then advertise the new 1246 features when the initiating entity reconnects, preferably closing 1247 existing streams in a staggered way so that not all of the initiating 1248 entities reconnect at once). Once stream negotiation is complete, 1249 the initiating entity is cleared to send XML stanzas over the stream 1250 for as long as the stream is maintained by both parties. 1252 Informational Note: Resource binding as specified under Section 7 1253 is an historical exception to the foregoing rule, since it is 1254 mandatory-to-negotiate for clients but uses XML stanzas for 1255 negotiation purposes. 1257 The initiating entity MUST NOT attempt to send XML stanzas 1258 (Section 8) to entities other than itself (i.e., the client's 1259 connected resource or any other authenticated resource of the 1260 client's account) or the server to which it is connected until stream 1261 negotiation has been completed. Even if the initiating entity does 1262 attempt to do so, the receiving entity MUST NOT accept such stanzas 1263 and MUST close the stream with a stream error 1264 (Section 4.9.3.12). This rule applies to XML stanzas only (i.e., 1265 , , and elements qualified by the content 1266 namespace) and not to XML elements used for stream negotiation (e.g., 1267 elements used to complete TLS negotiation (Section 5) or SASL 1268 negotiation (Section 6)). 1270 4.3.6. Determination of Addresses 1272 After the parties to an XML stream have completed the appropriate 1273 aspects of stream negotiation, the receiving entity for a stream MUST 1274 determine the initiating entity's JID. 1276 For client-to-server communication, both SASL negotiation (Section 6) 1277 and resource binding (Section 7) MUST be completed before the server 1278 can determine the client's address. The client's bare JID 1279 () MUST be the authorization identity (as 1280 defined by [SASL]), either (1) as directly communicated by the client 1281 during SASL negotiation (Section 6) or (2) as derived by the server 1282 from the authentication identity if no authorization identity was 1283 specified during SASL negotiation. The resourcepart of the full JID 1284 () MUST be the resource negotiated 1285 by the client and server during resource binding (Section 7). A 1286 client MUST NOT attempt to guess at its JID but instead MUST consider 1287 its JID to be whatever the server returns to it during resource 1288 binding. The server MUST ensure that the resulting JID (including 1289 localpart, domainpart, resourcepart, and separator characters) 1290 conforms to the canonical format for XMPP addresses defined in 1291 [XMPP-ADDR]; to meet this restriction, the server MAY replace the JID 1292 sent by the client with the canonicalized JID as determined by the 1293 server and communicate that JID to the client during resource 1294 binding. 1296 For server-to-server communication, the initiating server's bare JID 1297 () MUST be the authorization identity (as defined by 1298 [SASL]), either (1) as directly communicated by the initiating server 1299 during SASL negotiation (Section 6) or (2) as derived by the 1300 receiving server from the authentication identity if no authorization 1301 identity was specified during SASL negotiation; in the absence of 1302 SASL negotiation, the receiving server MAY consider the authorization 1303 identity to be an identity negotiated within the relevant 1304 verification protocol (e.g., the 'from' attribute of the 1305 element in Server Dialback [XEP-0220]). 1307 Security Warning: Because it is possible for a third party to 1308 tamper with information that is sent over the stream before a 1309 security layer such as TLS is successfully negotiated, it is 1310 advisable for the receiving server to treat any such unprotected 1311 information with caution; this applies especially to the 'from' 1312 and 'to' addresses on the first initial stream header sent by the 1313 initiating entity. 1315 4.3.7. Flow Chart 1317 We summarize the foregoing rules in the following non-normative flow 1318 chart for the stream negotiation process, presented from the 1319 perspective of the initiating entity. 1321 +---------------------+ 1322 | open TCP connection | 1323 +---------------------+ 1324 | 1325 v 1326 +---------------+ 1327 | send initial |<-------------------------+ 1328 | stream header | ^ 1329 +---------------+ | 1330 | | 1331 v | 1332 +------------------+ | 1333 | receive response | | 1334 | stream header | | 1335 +------------------+ | 1336 | | 1337 v | 1338 +----------------+ | 1339 | receive stream | | 1340 +------------------>| features | | 1341 ^ {OPTIONAL} +----------------+ | 1342 | | | 1343 | v | 1344 | +<-----------------+ | 1345 | | | 1346 | {empty?} ----> {all voluntary?} ----> {some mandatory?} | 1347 | | no | no | | 1348 | | yes | yes | yes | 1349 | | v v | 1350 | | +---------------+ +----------------+ | 1351 | | | MAY negotiate | | MUST negotiate | | 1352 | | | any or none | | one feature | | 1353 | | +---------------+ +----------------+ | 1354 | v | | | 1355 | +---------+ v | | 1356 | | DONE |<----- {negotiate?} | | 1357 | +---------+ no | | | 1358 | yes | | | 1359 | v v | 1360 | +--------->+<---------+ | 1361 | | | 1362 | v | 1363 +<-------------------------- {restart mandatory?} ------------>+ 1364 no yes 1366 Figure 3: Stream Negotiation Flow Chart 1368 4.4. Closing a Stream 1370 An XML stream from one entity to another can be closed at any time, 1371 either because a specific stream error (Section 4.9) has occurred or 1372 in the absence of an error (e.g., when a client simply ends its 1373 session). 1375 A stream is closed by sending a closing tag. 1377 E: 1379 If the parties are using either two streams over a single TCP 1380 connection or two streams over two TCP connections, the entity that 1381 sends the closing stream tag MUST behave as follows: 1383 1. Wait for the other party to also close its outbound stream before 1384 terminating the underlying TCP connection(s); this gives the 1385 other party an opportunity to finish transmitting any outbound 1386 data to the closing entity before the TCP connection(s) is 1387 terminated. 1389 2. Refrain from sending any further data over its outbound stream to 1390 the other entity, but continue to process data received from the 1391 other entity (and, if necessary, process such data). 1393 3. Consider both streams to be void if the other party does not send 1394 its closing stream tag within a reasonable amount of time (where 1395 the definition of "reasonable" is a matter of implementation or 1396 deployment). 1398 4. After receiving a reciprocal closing stream tag from the other 1399 party or waiting a reasonable amount of time with no response, 1400 terminate the underlying TCP connection(s). 1402 Security Warning: In accordance with Section 7.2.1 of [TLS], to 1403 help prevent a truncation attack the party that is closing the 1404 stream MUST send a TLS close_notify alert and MUST receive a 1405 responding close_notify alert from the other party before 1406 terminating the underlying TCP connection(s). 1408 If the parties are using multiple streams over multiple TCP 1409 connections, there is no defined pairing of streams and therefore the 1410 behavior is a matter for implementation. 1412 4.5. Directionality 1414 An XML stream is always unidirectional, by which is meant that XML 1415 stanzas can be sent in only one direction over the stream (either 1416 from the initiating entity to the receiving entity or from the 1417 receiving entity to the initiating entity). 1419 Depending on the type of session that has been negotiated and the 1420 nature of the entities involved, the entities might use: 1422 o Two streams over a single TCP connection, where the security 1423 context negotiated for the first stream is applied to the second 1424 stream. This is typical for client-to-server sessions, and a 1425 server MUST allow a client to use the same TCP connection for both 1426 streams. 1428 o Two streams over two TCP connections, where each stream is 1429 separately secured. In this approach, one TCP connection is used 1430 for the stream in which stanzas are sent from the initiating 1431 entity to the receiving entity, and the other TCP connection is 1432 used for the stream in which stanzas are sent from the receiving 1433 entity to the initiating entity. This is typical for server-to- 1434 server sessions. 1436 o Multiple streams over two or more TCP connections, where each 1437 stream is separately secured. This approach is sometimes used for 1438 server-to-server communication between two large XMPP service 1439 providers; however, this can make it difficult to maintain 1440 coherence of data received over multiple streams in situations 1441 described under Section 10.1, which is why a server MAY close the 1442 stream with a stream error (Section 4.9.3.3) if a 1443 remote server attempts to negotiate more than one stream (as 1444 described under Section 4.9.3.3). 1446 This concept of directionality applies only to stanzas and explicitly 1447 does not apply to first-level children of the stream root that are 1448 used to bootstrap or manage the stream (e.g., first-level elements 1449 used for TLS negotiation, SASL negotiation, Server Dialback 1450 [XEP-0220], and Stream Management [XEP-0198]). 1452 The foregoing considerations imply that while completing STARTTLS 1453 negotiation (Section 5) and SASL negotiation (Section 6) two servers 1454 would use one TCP connection, but after the stream negotiation 1455 process is done that original TCP connection would be used only for 1456 the initiating server to send XML stanzas to the receiving server. 1457 In order for the receiving server to send XML stanzas to the 1458 initiating server, the receiving server would need to reverse the 1459 roles and negotiate an XML stream from the receiving server to the 1460 initiating server over a separate TCP connection. This separate TCP 1461 connection is then secured using a new round of TLS and/or SASL 1462 negotiation. 1464 Implementation Note: For historical reasons, a server-to-server 1465 session always uses two TCP connections. While that approach 1466 remains the standard behavior described in this document, 1467 extensions such as [XEP-0288] enable servers to negotiate the use 1468 of a single TCP connection for bidirectional stanza exchange. 1470 Informational Note: Although XMPP developers sometimes apply the 1471 terms "unidirectional" and "bidirectional" to the underlying TCP 1472 connection (e.g., calling the TCP connection for a client-to- 1473 server session "bidirectional" and the TCP connection for a 1474 server-to-server session "unidirectional"), strictly speaking a 1475 stream is always unidirectional (because the initiating entity and 1476 receiving entity always have a minimum of two streams, one in each 1477 direction) and a TCP connection is always bidirectional (because 1478 TCP traffic can be sent in both directions). Directionality 1479 applies to the application-layer traffic sent over the TCP 1480 connection, not to the transport-layer traffic sent over the TCP 1481 connection itself. 1483 4.6. Handling of Silent Peers 1485 When an entity that is a party to a stream has not received any XMPP 1486 traffic from its stream peer for some period of time, the peer might 1487 appear to be silent. There are several reasons why this might 1488 happen: 1490 1. The underlying TCP connection is dead. 1492 2. The XML stream is broken despite the fact that the underlying TCP 1493 connection is alive. 1495 3. The peer is idle and simply has not sent any XMPP traffic over 1496 its XML stream to the entity. 1498 These three conditions are best handled separately, as described in 1499 the following sections. 1501 Implementation Note: For the purpose of handling silent peers, we 1502 treat a two unidirectional TCP connections as conceptually 1503 equivalent to a single bidirectional TCP connection (see 1504 Section 4.5); however, implementers need to be aware that, in the 1505 case of two unidirectional TCP connections, responses to traffic 1506 at the XMPP application layer will come back from the peer on the 1507 second TCP connection. In addition, the use of multiple streams 1508 in each direction (which is a somewhat frequent deployment choice 1509 for server-to-server connectivity among large XMPP service 1510 providers) further complicates application-level checking of XMPP 1511 streams and their underlying TCP connections, because there is no 1512 necessary correlation between any given initial stream and any 1513 given response stream. 1515 4.6.1. Dead Connection 1517 If the underlying TCP connection is dead, stream-level checks (e.g., 1518 [XEP-0199] and [XEP-0198]) are ineffective. Therefore it is 1519 unnecessary to close the stream with or without an error, and it is 1520 appropriate instead to simply terminate the TCP connection. 1522 One common method for checking the TCP connection is to send a space 1523 character (U+0020) between XML stanzas, which is allowed for XML 1524 streams as described under Section 11.7; the sending of such a space 1525 character is properly called a "whitespace keepalive" (the term 1526 "whitespace ping" is often used, despite the fact that it is not a 1527 ping since no "pong" is possible). However, this is not allowed 1528 during TLS negotiation or SASL negotiation, as described under 1529 Section 5.3.3 and Section 6.3.5. 1531 4.6.2. Broken Stream 1533 Even if the underlying TCP connection is alive, the peer might never 1534 respond to XMPP traffic that the entity sends, whether normal stanzas 1535 or specialized stream-checking traffic such as the application-level 1536 pings defined in [XEP-0199] or the more comprehensive Stream 1537 Management protocol defined in [XEP-0198]. In this case, it is 1538 appropriate for the entity to close a broken stream with a 1539 stream error (Section 4.9.3.4). 1541 4.6.3. Idle Peer 1543 Even if the underlying TCP connection is alive and the stream is not 1544 broken, the peer might have sent no stanzas for a certain period of 1545 time. In this case, the peer itself MAY close the stream (as 1546 described under Section 4.4) rather than leaving an unused stream 1547 open. If the idle peer does not close the stream, the other party 1548 MAY either close the stream using the handshake described under 1549 Section 4.4 or close the stream with a stream error (e.g., (Section 4.9.3.17) if the entity has reached a limit on 1551 the number of open TCP connections or 1552 (Section 4.9.3.14) if the connection has exceeded a local timeout 1553 policy). However, consistent with the order of layers (specified 1554 under Section 13.3), the other party is advised to verify that the 1555 underlying TCP connection is alive and the stream is unbroken (as 1556 described above) before concluding that the peer is idle. 1557 Furthermore, it is preferable to be liberal in accepting idle peers, 1558 since experience has shown that doing so improves the reliability of 1559 communication over XMPP networks and that it is typically more 1560 efficient to maintain a stream between two servers than to 1561 aggressively timeout such a stream. 1563 4.6.4. Use of Checking Methods 1565 Implementers are advised to support whichever stream-checking and 1566 connection-checking methods they deem appropriate, but to carefully 1567 weigh the network impact of such methods against the benefits of 1568 discovering broken streams and dead TCP connections in a timely 1569 manner. The length of time between the use of any particular check 1570 is very much a matter of local service policy and depends strongly on 1571 the network environment and usage scenarios of a given deployment and 1572 connection type; at the time of writing, it is RECOMMENDED that any 1573 such check be performed not more than once every 5 minutes and that, 1574 ideally, such checks will be initiated by clients rather than 1575 servers. Those who implement XMPP software and deploy XMPP services 1576 are encouraged to seek additional advice regarding appropriate timing 1577 of stream-checking and connection-checking methods, particularly when 1578 power-constrained devices are being used (e.g., in mobile 1579 environments). 1581 4.7. Stream Attributes 1583 The attributes of the root element are defined in the 1584 following sections. 1586 Security Warning: Until and unless the confidentiality and 1587 integrity of the stream are protected via TLS as described under 1588 Section 5 or an equivalent security layer (such as the SASL GSSAPI 1589 mechanism), the attributes provided in a stream header could be 1590 tampered with by an attacker. 1592 Implementation Note: The attributes of the root element 1593 are not prepended by a namespace prefix because, as explained in 1594 [XML-NAMES], "[d]efault namespace declarations do not apply 1595 directly to attribute names; the interpretation of unprefixed 1596 attributes is determined by the element on which they appear." 1598 4.7.1. from 1600 The 'from' attribute specifies an XMPP identity of the entity sending 1601 the stream element. 1603 For initial stream headers in client-to-server communication, the 1604 'from' attribute is the XMPP identity of the principal controlling 1605 the client, i.e., a JID of the form . The 1606 client might not know the XMPP identity, e.g., because the XMPP 1607 identity is assigned at a level other than the XMPP application layer 1608 (as in the General Security Service Application Program Interface 1609 [GSS-API]) or is derived by the server from information provided by 1610 the client (as in some deployments of end-user certificates with the 1611 SASL EXTERNAL mechanism). Furthermore, if the client considers the 1612 XMPP identity to be private information then it is advised not to 1613 include a 'from' attribute before the confidentiality and integrity 1614 of the stream are protected via TLS or an equivalent security layer. 1615 However, if the client knows the XMPP identity then it SHOULD include 1616 the 'from' attribute after the confidentiality and integrity of the 1617 stream are protected via TLS or an equivalent security layer. 1619 I: 1620 1628 For initial stream headers in server-to-server communication, the 1629 'from' attribute is one of the configured FQDNs of the server, i.e., 1630 a JID of the form . The initiating server might have 1631 more than one XMPP identity, e.g., in the case of a server that 1632 provides virtual hosting, so it will need to choose an identity that 1633 is associated with this output stream (e.g., based on the 'to' 1634 attribute of the stanza that triggered the stream negotiation 1635 attempt). Because a server is a "public entity" on the XMPP network, 1636 it MUST include the 'from' attribute after the confidentiality and 1637 integrity of the stream are protected via TLS or an equivalent 1638 security layer. 1640 I: 1641 1649 For response stream headers in both client-to-server and server-to- 1650 server communication, the receiving entity MUST include the 'from' 1651 attribute and MUST set its value to one of the receiving entity's 1652 FQDNs (which MAY be an FQDN other than that specified in the 'to' 1653 attribute of the initial stream header, as described under 1654 Section 4.9.1.3 and Section 4.9.3.6). 1656 R: 1657 1666 Whether or not the 'from' attribute is included, each entity MUST 1667 verify the identity of the other entity before exchanging XML stanzas 1668 with it, as described under Section 13.5. 1670 Interoperability Note: It is possible that implementations based 1671 on [RFC3920] will not include the 'from' address on any stream 1672 headers (even ones whose confidentiality and integrity are 1673 protected); an entity SHOULD be liberal in accepting such stream 1674 headers. 1676 4.7.2. to 1678 For initial stream headers in both client-to-server and server-to- 1679 server communication, the initiating entity MUST include the 'to' 1680 attribute and MUST set its value to a domainpart that the initiating 1681 entity knows or expects the receiving entity to service. (The same 1682 information can be provided in other ways, such as a Server Name 1683 Indication during TLS negotiation as described in [TLS-EXT].) 1685 I: 1686 1694 For response stream headers in client-to-server communication, if the 1695 client included a 'from' attribute in the initial stream header then 1696 the server MUST include a 'to' attribute in the response stream 1697 header and MUST set its value to the bare JID specified in the 'from' 1698 attribute of the initial stream header. If the client did not 1699 include a 'from' attribute in the initial stream header then the 1700 server MUST NOT include a 'to' attribute in the response stream 1701 header. 1703 R: 1704 1713 For response stream headers in server-to-server communication, the 1714 receiving entity MUST include a 'to' attribute in the response stream 1715 header and MUST set its value to the domainpart specified in the 1716 'from' attribute of the initial stream header. 1718 R: 1719 1728 Whether or not the 'to' attribute is included, each entity MUST 1729 verify the identity of the other entity before exchanging XML stanzas 1730 with it, as described under Section 13.5. 1732 Interoperability Note: It is possible that implementations based 1733 on [RFC3920] will not include the 'to' address on stream headers; 1734 an entity SHOULD be liberal in accepting such stream headers. 1736 4.7.3. id 1738 The 'id' attribute specifies a unique identifier for the stream, 1739 called a "stream ID". The stream ID MUST be generated by the 1740 receiving entity when it sends a response stream header and MUST BE 1741 unique within the receiving application (normally a server). 1743 Security Warning: The stream ID MUST be both unpredictable and 1744 non-repeating because it can be security-critical when re-used by 1745 an authentication mechanisms, as is the case for Server Dialback 1746 [XEP-0220] and the "XMPP 0.9" authentication mechanism used before 1747 RFC 3920 defined the use of SASL in XMPP; for recommendations 1748 regarding randomness for security purposes, see [RANDOM]. 1750 For initial stream headers, the initiating entity MUST NOT include 1751 the 'id' attribute; however, if the 'id' attribute is included, the 1752 receiving entity MUST ignore it. 1754 For response stream headers, the receiving entity MUST include the 1755 'id' attribute. 1757 R: 1758 1767 Interoperability Note: In RFC 3920, the text regarding inclusion 1768 of the 'id' attribute was ambiguous, leading some implementations 1769 to leave the attribute off the response stream header. 1771 4.7.4. xml:lang 1773 The 'xml:lang' attribute specifies an entity's preferred or default 1774 language for any human-readable XML character data to be sent over 1775 the stream (an XML stanza can also possess an 'xml:lang' attribute, 1776 as discussed under Section 8.1.5). The syntax of this attribute is 1777 defined in Section 2.12 of [XML]; in particular, the value of the 1778 'xml:lang' attribute MUST conform to the NMTOKEN datatype (as defined 1779 in Section 2.3 of [XML]) and MUST conform to the language identifier 1780 format defined in [LANGTAGS]. 1782 For initial stream headers, the initiating entity SHOULD include the 1783 'xml:lang' attribute. 1785 I: 1786 1794 For response stream headers, the receiving entity MUST include the 1795 'xml:lang' attribute. The following rules apply: 1797 o If the initiating entity included an 'xml:lang' attribute in its 1798 initial stream header and the receiving entity supports that 1799 language in the human-readable XML character data that it 1800 generates and sends to the initiating entity (e.g., in the 1801 element for stream and stanza errors), the value of the 'xml:lang' 1802 attribute MUST be the identifier for the initiating entity's 1803 preferred language (e.g., "de-CH"). 1805 o If the receiving entity supports a language that matches the 1806 initiating entity's preferred language according to the "lookup 1807 scheme" specified in Section 3.4 of [LANGMATCH] (e.g., "de" 1808 instead of "de-CH"), then the value of the 'xml:lang' attribute 1809 SHOULD be the identifier for the matching language. 1811 o If the receiving entity does not support the initiating entity's 1812 preferred language or a matching language according to the lookup 1813 scheme (or if the initiating entity did not include the 'xml:lang' 1814 attribute in its initial stream header), then the value of the 1815 'xml:lang' attribute MUST be the identifier for the default 1816 language of the receiving entity (e.g., "en"). 1818 R: 1819 1828 If the initiating entity included the 'xml:lang' attribute in its 1829 initial stream header, the receiving entity SHOULD remember that 1830 value as the default xml:lang for all stanzas sent by the initiating 1831 entity over the current stream. As described under Section 8.1.5, 1832 the initiating entity MAY include the 'xml:lang' attribute in any XML 1833 stanzas it sends over the stream. If the initiating entity does not 1834 include the 'xml:lang' attribute in any such stanza, the receiving 1835 entity SHOULD add the 'xml:lang' attribute to the stanza when routing 1836 it to a remote server or delivering it to a connected client, where 1837 the value of the attribute MUST be the identifier for the language 1838 preferred by the initiating entity (even if the receiving entity does 1839 not support that language for human-readable XML character data it 1840 generates and sends to the initiating entity, such as in stream or 1841 stanza errors). If the initiating entity includes the 'xml:lang' 1842 attribute in any such stanza, the receiving entity MUST NOT modify or 1843 delete it when routing it to a remote server or delivering it to a 1844 connected client. 1846 4.7.5. version 1848 The inclusion of the version attribute set to a value of at least 1849 "1.0" signals support for the stream-related protocols defined in 1850 this specification, including TLS negotiation (Section 5), SASL 1851 negotiation (Section 6), stream features (Section 4.3.2), and stream 1852 errors (Section 4.9). 1854 The version of XMPP specified in this specification is "1.0"; in 1855 particular, XMPP 1.0 encapsulates the stream-related protocols as 1856 well as the basic semantics of the three defined XML stanza types 1857 (, , and as described under Section 8.2.1, 1858 Section 8.2.2, and Section 8.2.3, respectively). 1860 The numbering scheme for XMPP versions is ".". The 1861 major and minor numbers MUST be treated as separate integers and each 1862 number MAY be incremented higher than a single digit. Thus, "XMPP 1863 2.4" would be a lower version than "XMPP 2.13", which in turn would 1864 be lower than "XMPP 12.3". Leading zeros (e.g., "XMPP 6.01") MUST be 1865 ignored by recipients and MUST NOT be sent. 1867 The major version number will be incremented only if the stream and 1868 stanza formats or obligatory actions have changed so dramatically 1869 that an older version entity would not be able to interoperate with a 1870 newer version entity if it simply ignored the elements and attributes 1871 it did not understand and took the actions defined in the older 1872 specification. 1874 The minor version number will be incremented only if significant new 1875 capabilities have been added to the core protocol (e.g., a newly 1876 defined value of the 'type' attribute for message, presence, or IQ 1877 stanzas). The minor version number MUST be ignored by an entity with 1878 a smaller minor version number, but MAY be used for informational 1879 purposes by the entity with the larger minor version number (e.g., 1880 the entity with the larger minor version number would simply note 1881 that its correspondent would not be able to understand that value of 1882 the 'type' attribute and therefore would not send it). 1884 The following rules apply to the generation and handling of the 1885 'version' attribute within stream headers: 1887 1. The initiating entity MUST set the value of the 'version' 1888 attribute in the initial stream header to the highest version 1889 number it supports (e.g., if the highest version number it 1890 supports is that defined in this specification, it MUST set the 1891 value to "1.0"). 1893 2. The receiving entity MUST set the value of the 'version' 1894 attribute in the response stream header to either the value 1895 supplied by the initiating entity or the highest version number 1896 supported by the receiving entity, whichever is lower. The 1897 receiving entity MUST perform a numeric comparison on the major 1898 and minor version numbers, not a string match on 1899 ".". 1901 3. If the version number included in the response stream header is 1902 at least one major version lower than the version number included 1903 in the initial stream header and newer version entities cannot 1904 interoperate with older version entities as described, the 1905 initiating entity SHOULD close the stream with an stream error (Section 4.9.3.25). 1908 4. If either entity receives a stream header with no 'version' 1909 attribute, the entity MUST consider the version supported by the 1910 other entity to be "0.9" and SHOULD NOT include a 'version' 1911 attribute in the response stream header. 1913 4.7.6. Summary of Stream Attributes 1915 The following table summarizes the attributes of the root 1916 element. 1918 +----------+--------------------------+-------------------------+ 1919 | | initiating to receiving | receiving to initiating | 1920 +----------+--------------------------+-------------------------+ 1921 | to | JID of receiver | JID of initiator | 1922 | from | JID of initiator | JID of receiver | 1923 | id | ignored | stream identifier | 1924 | xml:lang | default language | default language | 1925 | version | XMPP 1.0+ supported | XMPP 1.0+ supported | 1926 +----------+--------------------------+-------------------------+ 1928 Figure 4: Stream Attributes 1930 4.8. XML Namespaces 1932 Readers are referred to the specification of XML namespaces 1933 [XML-NAMES] for a full understanding of the concepts used in this 1934 section, especially the concept of a "default namespace" as provided 1935 in Section 3 and Section 6.2 of that specification. 1937 4.8.1. Stream Namespace 1939 The root element ("stream header") MUST be qualified by the 1940 namespace 'http://etherx.jabber.org/streams' (the "stream 1941 namespace"). If this rule is violated, the entity that receives the 1942 offending stream header MUST close the stream with a stream error, 1943 which SHOULD be (Section 4.9.3.10), although 1944 some existing implementations send (Section 4.9.3.1) 1945 instead. 1947 4.8.2. Content Namespace 1949 An entity MAY declare a "content namespace" as the default namespace 1950 for data sent over the stream (i.e., data other than elements 1951 qualified by the stream namespace). If so, (1) the content namespace 1952 MUST be other than the stream namespace, and (2) the content 1953 namespace MUST be the same for the initial stream and the response 1954 stream so that both streams are qualified consistently. The content 1955 namespace applies to all first-level child elements sent over the 1956 stream unless explicitly qualified by another namespace (i.e., the 1957 content namespace is the default namespace). 1959 Alternatively (i.e., instead of declaring the content namespace as 1960 the default namespace), an entity MAY explicitly qualify the 1961 namespace for each first-level child element of the stream, using so- 1962 called "prefix-free canonicalization". These two styles are shown in 1963 the following examples. 1965 When a content namespace is declared as the default namespace, in 1966 rough outline a stream will look something like the following. 1968 1975 1976 foo 1977 1978 1980 When a content namespace is not declared as the default namespace and 1981 so-called "prefix-free canonicalization" is used instead, in rough 1982 outline a stream will look something like the following. 1984 1990 1991 foo 1992 1993 1995 Traditionally, most XMPP implementations have used the content- 1996 namespace-as-default-namespace style rather than the prefix-free 1997 canonicalization style for stream headers; however, both styles are 1998 acceptable since they are semantically equivalent. 2000 4.8.3. XMPP Content Namespaces 2002 XMPP as defined in this specification uses two content namespaces: 2003 'jabber:client' and 'jabber:server'. These namespaces are nearly 2004 identical but are used in different contexts (client-to-server 2005 communication for 'jabber:client' and server-to-server communication 2006 for 'jabber:server'). The only difference between the two is that 2007 the 'to' and 'from' attributes are OPTIONAL on stanzas sent over XML 2008 streams qualified by the 'jabber:client' namespace, whereas they are 2009 REQUIRED on stanzas sent over XML streams qualified by the 'jabber: 2010 server' namespace. Support for these content namespaces implies 2011 support for the common attributes (Section 8.1) and basic semantics 2012 (Section 8.2) of all three core stanza types (message, presence, and 2013 IQ). 2015 An implementation MAY support content namespaces other than 'jabber: 2016 client' or 'jabber:server'. However, because such namespaces would 2017 define applications other than XMPP, they are to be defined in 2018 separate specifications. 2020 An implementation MAY refuse to support any other content namespaces 2021 as default namespaces. If an entity receives a first-level child 2022 element qualified by a content namespace it does not support, it MUST 2023 close the stream with an stream error 2024 (Section 4.9.3.10). 2026 Client implementations MUST support the 'jabber:client' content 2027 namespace as a default namespace. The 'jabber:server' content 2028 namespace is out of scope for an XMPP client, and a client MUST NOT 2029 send stanzas qualified by the 'jabber:server' namespace. 2031 Server implementations MUST support as default content namespaces 2032 both the 'jabber:client' namespace (when the stream is used for 2033 communication between a client and a server) and the 'jabber:server' 2034 namespace (when the stream is used for communication between two 2035 servers). When communicating with a connected client, a server MUST 2036 NOT send stanzas qualified by the 'jabber:server' namespace; when 2037 communicating with a peer server, a server MUST NOT send stanzas 2038 qualified by the 'jabber:client' namespace. 2040 Implementation Note: Because a client sends stanzas over a stream 2041 whose content namespace is 'jabber:client', if a server routes to 2042 a peer server a stanza it has received from a connected client 2043 then it needs to "re-scope" the stanza so that its content 2044 namespace is 'jabber:server'. Similarly, if a server delivers to 2045 a connected client a stanza it has received from a peer server 2046 then it needs to "re-scope" the stanza so that its content 2047 namespace is 'jabber:client'. This rule applies to XML stanzas as 2048 defined under Section 4.1 (i.e., a first-level , 2049 , or element qualified by the 'jabber:client' or 2050 'jabber:server' namespace), and by namespace inheritance to all 2051 child elements of a stanza; however the rule does not apply to 2052 elements qualified by namespaces other than 'jabber:client' and 2053 'jabber:server' nor to any children of such elements (e.g., a 2054 element contained within an extension element 2055 (Section 8.4) for reporting purposes). Although it is not 2056 forbidden for an entity to generate stanzas in which an extension 2057 element contains a child element qualified by the 'jabber:client' 2058 or 'jabber:server' namespace, existing implementations handle such 2059 stanzas inconsistently; therefore implementers are advised to 2060 weigh the likely lack of interoperability against the possible 2061 utility of such stanzas. Finally, servers are advised to apply 2062 stanza re-scoping to other stream connection methods and 2063 alternative XMPP connection methods, such as those specified in 2064 [XEP-0124], [XEP-0206], [XEP-0114], and [XEP-0225]. 2066 4.8.4. Other Namespaces 2068 Either party to a stream MAY send data qualified by namespaces other 2069 than the content namespace and the stream namespace. For example, 2070 this is how data related to TLS negotiation and SASL negotiation are 2071 exchanged, as well as XMPP extensions such as Stream Management 2072 [XEP-0198] and Server Dialback [XEP-0220]. 2074 Interoperability Note: For historical reasons, some server 2075 implementations expect a declaration of the 'jabber:server: 2076 dialback' namespace on server-to-server streams, as explained in 2077 [XEP-0220]. 2079 However, an XMPP server MUST NOT route or deliver data received over 2080 an input stream if that data is (a) qualified by another namespace 2081 and (b) addressed to an entity other than the server, unless the 2082 other party to the output stream over which the server would send the 2083 data has explicitly negotiated or advertised support for receiving 2084 arbitrary data from the server. This rule is included because XMPP 2085 is designed for the exchange of XML stanzas (not arbitrary XML data), 2086 and because allowing an entity to send arbitrary data to other 2087 entities could significantly increase the potential for exchanging 2088 malicious information. As an example of this rule, the server 2089 hosting the example.net domain would not route the following first- 2090 level XML element from to : 2092 2095 2096 2098 This rule also applies to first-level elements that look like stanzas 2099 but that are improperly namespaced and therefore really are not 2100 stanzas at all (see also Section 4.8.5), for example: 2102 2105 hi 2106 2108 Upon receiving arbitrary first-level XML elements over an input 2109 stream, a server MUST either ignore the data or close the stream with 2110 a stream error, which SHOULD be 2111 (Section 4.9.3.24). 2113 4.8.5. Namespace Declarations and Prefixes 2115 Because the content namespace is other than the stream namespace, if 2116 a content namespace is declared as the default namespace then the 2117 following statements are true: 2119 1. The stream header needs to contain a namespace declaration for 2120 both the content namespace and the stream namespace. 2122 2. The stream namespace declaration needs to include a namespace 2123 prefix for the stream namespace. 2125 Interoperability Note: For historical reasons, an implementation 2126 MAY accept only the prefix 'stream' for the stream namespace 2127 (resulting in prefixed names such as and ); this specification retains that allowance from 2130 [RFC3920] for the purpose of backward compatibility. 2131 Implementations are advised that using a prefix other than 2132 'stream' for the stream namespace might result in interoperability 2133 problems. If an entity receives a stream header with a stream 2134 namespace prefix it does not accept, it MUST close the stream with 2135 a stream error, which SHOULD be 2136 (Section 4.9.3.2), although some existing implementations send 2137 (Section 4.9.3.1) instead. 2139 An implementation MUST NOT generate namespace prefixes for elements 2140 qualified by the content namespace (i.e., the default namespace for 2141 data sent over the stream) if the content namespace is 'jabber: 2142 client' or 'jabber:server'. For example, the following is illegal: 2144 2152 2153 foo 2154 2156 An XMPP entity MUST NOT accept data that violates this rule (in 2157 particular, an XMPP server MUST NOT route or deliver such data to 2158 another entity); instead it MUST either ignore the data or close the 2159 stream with a stream error, which SHOULD be 2160 (Section 4.9.3.2). 2162 Namespaces declared in a stream header MUST apply only to that stream 2163 (e.g., the 'jabber:server:dialback' namespace used in Server Dialback 2164 [XEP-0220]). In particular, because XML stanzas intended for routing 2165 or delivery over streams with other entities will lose the namespace 2166 context declared in the header of the stream in which those stanzas 2167 originated, namespaces for extended content within such stanzas MUST 2168 NOT be declared in that stream header (see also Section 8.4). If 2169 either party to a stream declares such namespaces, the other party to 2170 the stream SHOULD close the stream with an 2171 stream error (Section 4.9.3.10). In any case, an entity MUST ensure 2172 that such namespaces are properly declared (according to this 2173 section) when routing or delivering stanzas from an input stream to 2174 an output stream. 2176 4.9. Stream Errors 2178 The root stream element MAY contain an child element that is 2179 qualified by the stream namespace. The error child SHALL be sent by 2180 a compliant entity if it perceives that a stream-level error has 2181 occurred. 2183 4.9.1. Rules 2185 The following rules apply to stream-level errors. 2187 4.9.1.1. Stream Errors Are Unrecoverable 2189 Stream-level errors are unrecoverable. Therefore, if an error occurs 2190 at the level of the stream, the entity that detects the error MUST 2191 send an element with an appropriate child element specifying 2192 the error condition and then immediately close the stream as 2193 described under Section 4.4. 2195 C: No closing tag! 2197 S: 2198 2200 2201 2203 The entity that receives the stream error then SHALL close the stream 2204 as explained under Section 4.4. 2206 C: 2208 4.9.1.2. Stream Errors Can Occur During Setup 2210 If the error is triggered by the initial stream header, the receiving 2211 entity MUST still send the opening tag, include the 2212 element as a child of the stream element, and send the closing 2213 tag (preferably in the same TCP packet). 2215 C: 2216 2224 S: 2225 2233 2234 2236 2237 2239 4.9.1.3. Stream Errors When the Host is Unspecified or Unknown 2241 If the initiating entity provides no 'to' attribute or provides an 2242 unknown host in the 'to' attribute and the error occurs during stream 2243 setup, the value of the 'from' attribute returned by the receiving 2244 entity in the stream header sent before closing the stream MUST be 2245 either an authoritative FQDN for the receiving entity or the empty 2246 string. 2248 C: 2249 2257 S: 2258 2266 2267 2269 2270 2272 4.9.1.4. Where Stream Errors Are Sent 2274 When two TCP connections are used between the initiating entity and 2275 the receiving entity (one in each direction) rather than using a 2276 single bidirectional connection, the following rules apply: 2278 o Stream-level errors related to the initial stream are returned by 2279 the receiving entity on the response stream via the same TCP 2280 connection. 2282 o Stanza errors triggered by outbound stanzas sent from the 2283 initiating entity over the initial stream via the same TCP 2284 connection are returned by the receiving entity on the response 2285 stream via the other ("return") TCP connection, since they are 2286 inbound stanzas from the perspective of the initiating entity. 2288 4.9.2. Syntax 2290 The syntax for stream errors is as follows, where XML data shown 2291 within the square brackets '[' and ']' is OPTIONAL. 2293 2294 2295 [ 2297 OPTIONAL descriptive text 2298 ] 2299 [OPTIONAL application-specific condition element] 2300 2302 The "defined-condition" MUST correspond to one of the stream error 2303 conditions defined under Section 4.9.3. However, because additional 2304 error conditions might be defined in the future, if an entity 2305 receives a stream error condition that it does not understand then it 2306 MUST treat the unknown condition as equivalent to (Section 4.9.3.21). If the designers of an XMPP protocol 2308 extension or the developers of an XMPP implementation need to 2309 communicate a stream error condition that is not defined in this 2310 specification, they can do so by defining an application-specific 2311 error condition element qualified by an application-specific 2312 namespace. 2314 The element: 2316 o MUST contain a child element corresponding to one of the defined 2317 stream error conditions (Section 4.9.3); this element MUST be 2318 qualified by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace. 2320 o MAY contain a child element containing XML character data 2321 that describes the error in more detail; this element MUST be 2322 qualified by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace 2323 and SHOULD possess an 'xml:lang' attribute specifying the natural 2324 language of the XML character data. 2326 o MAY contain a child element for an application-specific error 2327 condition; this element MUST be qualified by an application- 2328 defined namespace, and its structure is defined by that namespace 2329 (see Section 4.9.4). 2331 The element is OPTIONAL. If included, it MUST be used only 2332 to provide descriptive or diagnostic information that supplements the 2333 meaning of a defined condition or application-specific condition. It 2334 MUST NOT be interpreted programmatically by an application. It MUST 2335 NOT be used as the error message presented to a human user, but MAY 2336 be shown in addition to the error message associated with the defined 2337 condition element (and, optionally, the application-specific 2338 condition element). 2340 4.9.3. Defined Stream Error Conditions 2342 The following stream-level error conditions are defined. 2344 4.9.3.1. bad-format 2346 The entity has sent XML that cannot be processed. 2348 (In the following example, the client sends an XMPP message that is 2349 not well-formed XML, which alternatively might trigger a stream error (Section 4.9.3.13).) 2352 C: 2353 No closing tag! 2354 2356 S: 2357 2359 2360 2362 This error can be used instead of the more specific XML-related 2363 errors, such as , , , , and . However, 2365 the more specific errors are RECOMMENDED. 2367 4.9.3.2. bad-namespace-prefix 2369 The entity has sent a namespace prefix that is unsupported, or has 2370 sent no namespace prefix on an element that needs such a prefix (see 2371 Section 11.2). 2373 (In the following example, the client specifies a namespace prefix of 2374 "foobar" for the XML stream namespace.) 2375 C: 2376 2383 S: 2384 2392 2393 2395 2396 2398 4.9.3.3. conflict 2400 The server either (1) is closing the existing stream for this entity 2401 because a new stream has been initiated that conflicts with the 2402 existing stream, or (2) is refusing a new stream for this entity 2403 because allowing the new stream would conflict with an existing 2404 stream (e.g., because the server allows only a certain number of 2405 connections from the same IP address or allows only one server-to- 2406 server stream for a given domain pair as a way of helping to ensure 2407 in-order processing as described under Section 10.1). 2409 C: 2410 2417 S: 2418 2426 2427 2429 2430 2432 If a client receives a stream error (Section 4.9.3.3), 2433 during the resource binding aspect of its reconnection attempt it 2434 MUST NOT blindly request the resourcepart it used during the former 2435 session but instead MUST choose a different resourcepart; details are 2436 provided under Section 7. 2438 4.9.3.4. connection-timeout 2440 One party is closing the stream because it has reason to believe that 2441 the other party has permanently lost the ability to communicate over 2442 the stream. The lack of ability to communicate can be discovered 2443 using various methods, such as whitespace keepalives as specified 2444 under Section 4.4, XMPP-level pings as defined in [XEP-0199], and 2445 XMPP Stream Management as defined in [XEP-0198]. 2447 P: 2448 2450 2451 2453 Interoperability Note: RFC 3920 specified that the stream error (Section 4.9.3.4) is to be used if the peer 2455 has not generated any traffic over the stream for some period of 2456 time. That behavior is no longer recommended; instead, the error 2457 SHOULD be used only if the connected client or peer server has not 2458 responded to data sent over the stream. 2460 4.9.3.5. host-gone 2462 The value of the 'to' attribute provided in the initial stream header 2463 corresponds to an FQDN that is no longer serviced by the receiving 2464 entity. 2466 (In the following example, the peer specifies a 'to' address of 2467 "foo.im.example.com" when connecting to the "im.example.com" server, 2468 but the server no longer hosts a service at that address.) 2470 P: 2471 2478 S: 2479 2487 2488 2490 2491 2493 4.9.3.6. host-unknown 2495 The value of the 'to' attribute provided in the initial stream header 2496 does not correspond to an FQDN that is serviced by the receiving 2497 entity. 2499 (In the following example, the peer specifies a 'to' address of 2500 "example.org" when connecting to the "im.example.com" server, but the 2501 server knows nothing of that address.) 2502 P: 2503 2510 S: 2511 2519 2520 2522 2523 2525 4.9.3.7. improper-addressing 2527 A stanza sent between two servers lacks a 'to' or 'from' attribute, 2528 the 'from' or 'to' attribute has no value, or the value violates the 2529 rules for XMPP addresses [XMPP-ADDR]. 2531 (In the following example, the peer sends a stanza without a 'to' 2532 address over a server-to-server stream.) 2534 P: 2535 Wherefore art thou? 2536 2538 S: 2539 2541 2542 2544 4.9.3.8. internal-server-error 2546 The server has experienced a misconfiguration or other internal error 2547 that prevents it from servicing the stream. 2549 S: 2550 2552 2553 2555 4.9.3.9. invalid-from 2557 The data provided in a 'from' attribute does not match an authorized 2558 JID or validated domain as negotiated (1) between two servers using 2559 SASL or Server Dialback, or (2) between a client and a server via 2560 SASL authentication and resource binding. 2562 (In the following example, a peer that has authenticated only as 2563 "example.net" attempts to send a stanza from an address at 2564 "example.org".) 2566 P: 2567 Neither, fair saint, if either thee dislike. 2568 2570 S: 2571 2573 2574 2576 4.9.3.10. invalid-namespace 2578 The stream namespace name is something other than 2579 "http://etherx.jabber.org/streams" (see Section 11.2) or the content 2580 namespace declared as the default namespace is not supported (e.g., 2581 something other than "jabber:client" or "jabber:server"). 2583 (In the following example, the client specifies a namespace of 2584 'http://wrong.namespace.example.org/' for the stream.) 2585 C: 2586 2593 S: 2594 2602 2603 2605 2606 2608 4.9.3.11. invalid-xml 2610 The entity has sent invalid XML over the stream to a server that 2611 performs validation (see Section 11.4). 2613 (In the following example, the peer attempts to send an IQ stanza of 2614 type "subscribe" but the XML schema defines no such value for the 2615 'type' attribute.) 2617 P: 2621 2622 2624 S: 2625 2627 2628 2630 4.9.3.12. not-authorized 2632 The entity has attempted to send XML stanzas or other outbound data 2633 before the stream has been authenticated, or otherwise is not 2634 authorized to perform an action related to stream negotiation; the 2635 receiving entity MUST NOT process the offending data before sending 2636 the stream error. 2638 (In the following example, the client attempts to send XML stanzas 2639 before authenticating with the server.) 2641 C: 2642 2649 S: 2650 2659 C: 2660 Wherefore art thou? 2661 2663 S: 2664 2666 2667 2669 4.9.3.13. not-well-formed 2671 The initiating entity has sent XML that violates the well-formedness 2672 rules of [XML] or [XML-NAMES]. 2674 (In the following example, the client sends an XMPP message that is 2675 not namespace-well-formed.) 2676 C: 2677 What is this foo? 2678 2680 S: 2681 2683 2684 2686 Interoperability Note: In RFC 3920, the name of this error 2687 condition was "xml-not-well-formed" instead of "not-well-formed". 2688 The name was changed because the element name violates the constraint from Section 3 of [XML] that 2690 "names beginning with a match to (('X'|'x')('M'|'m')('L'|'l')) are 2691 reserved for standardization in this or future versions of this 2692 specification". 2694 4.9.3.14. policy-violation 2696 The entity has violated some local service policy (e.g., a stanza 2697 exceeds a configured size limit); the server MAY choose to specify 2698 the policy in the element or in an application-specific 2699 condition element. 2701 (In the following example, the client sends an XMPP message that is 2702 too large according to the server's local service policy.) 2704 C: 2705 [ ... the-emacs-manual ... ] 2706 2708 S: 2709 2711 2712 2714 S: 2716 4.9.3.15. remote-connection-failed 2718 The server is unable to properly connect to a remote entity that is 2719 needed for authentication or authorization (e.g., in certain 2720 scenarios related to Server Dialback [XEP-0220]); this condition is 2721 not to be used when the cause of the error is within the 2722 administrative domain of the XMPP service provider, in which case the 2723 condition is more appropriate. 2725 C: 2726 2733 S: 2734 2742 2743 2745 2746 2748 4.9.3.16. reset 2750 The server is closing the stream because it has new (typically 2751 security-critical) features to offer, because the keys or 2752 certificates used to establish a secure context for the stream have 2753 expired or have been revoked during the life of the stream 2754 (Section 13.7.2.3), because the TLS sequence number has wrapped 2755 (Section 5.3.5), etc. The reset applies to the stream and to any 2756 security context established for that stream (e.g., via TLS and 2757 SASL), which means that encryption and authentication need to be 2758 negotiated again for the new stream (e.g., TLS session resumption 2759 cannot be used). 2761 S: 2762 2764 2765 2767 4.9.3.17. resource-constraint 2769 The server lacks the system resources necessary to service the 2770 stream. 2772 C: 2773 2780 S: 2781 2789 2790 2792 2793 2795 4.9.3.18. restricted-xml 2797 The entity has attempted to send restricted XML features such as a 2798 comment, processing instruction, DTD subset, or XML entity reference 2799 (see Section 11.1). 2801 (In the following example, the client sends an XMPP message 2802 containing an XML comment.) 2804 C: 2805 2806 This message has no subject. 2807 2809 S: 2810 2812 2813 2815 4.9.3.19. see-other-host 2817 The server will not provide service to the initiating entity but is 2818 redirecting traffic to another host under the administrative control 2819 of the same service provider. The XML character data of the element returned by the server MUST specify the 2821 alternate FQDN or IP address at which to connect, which MUST be a 2822 valid domainpart or a domainpart plus port number (separated by the 2823 ':' character in the form "domainpart:port"). If the domainpart is 2824 the same as the source domain, derived domain, or resolved IPv4 or 2825 IPv6 address to which the initiating entity originally connected 2826 (differing only by the port number), then the initiating entity 2827 SHOULD simply attempt to reconnect at that address. (The format of 2828 an IPv6 address MUST follow [IPv6-ADDR], which includes the enclosing 2829 the IPv6 address in square brackets '[' and ']' as originally defined 2830 by [URI].) Otherwise, the initiating entity MUST resolve the FQDN 2831 specified in the element as described under 2832 Section 3.2. 2834 C: 2835 2842 S: 2843 2851 2852 2854 [2001:41D0:1:A49b::1]:9222 2855 2856 2857 2859 When negotiating a stream with the host to which it has been 2860 redirected, the initiating entity MUST apply the same policies it 2861 would have applied to the original connection attempt (e.g., a policy 2862 requiring TLS), MUST specify the same 'to' address on the initial 2863 stream header, and MUST verify the identity of the new host using the 2864 same reference identifier(s) it would have used for the original 2865 connection attempt (in accordance with [TLS-CERTS]). Even if the 2866 receiving entity returns a error before the 2867 confidentiality and integrity of the stream have been established 2868 (thus introducing the possibility of a denial of service attack), the 2869 fact that the initiating entity needs to verify the identity of the 2870 XMPP service based on the same reference identifiers implies that the 2871 initiating entity will not connect to a malicious entity. To reduce 2872 the possibility of a denial of service attack, (a) the receiving 2873 entity SHOULD NOT close the stream with a stream 2874 error until after the confidentiality and integrity of the stream 2875 have been protected via TLS or an equivalent security layer (such as 2876 the SASL GSSAPI mechanism) and (b) the receiving entity MAY have a 2877 policy of following redirects only if it has authenticated the 2878 receiving entity. In addition, the initiating entity SHOULD abort 2879 the connection attempt after a certain number of successive redirects 2880 (e.g., at least 2 but no more than 5). 2882 4.9.3.20. system-shutdown 2884 The server is being shut down and all active streams are being 2885 closed. 2887 S: 2888 2890 2891 2893 4.9.3.21. undefined-condition 2895 The error condition is not one of those defined by the other 2896 conditions in this list; this error condition SHOULD NOT be used 2897 except in conjunction with an application-specific condition. 2899 S: 2900 2902 2903 2904 2906 4.9.3.22. unsupported-encoding 2908 The initiating entity has encoded the stream in an encoding that is 2909 not supported by the server (see Section 11.6) or has otherwise 2910 improperly encoded the stream (e.g., by violating the rules of the 2911 [UTF-8] encoding). 2913 (In the following example, the client attempts to encode data using 2914 UTF-16 instead of UTF-8.) 2915 C: 2916 2923 S: 2924 2932 2933 2935 2936 2938 4.9.3.23. unsupported-feature 2940 The receiving entity has advertised a mandatory-to-negotiate stream 2941 feature that the initiating entity does not support, and has offered 2942 no other mandatory-to-negotiate feature alongside the unsupported 2943 feature. 2945 (In the following example, the receiving entity requires negotiation 2946 of an example feature but the initiating entity does not support the 2947 feature.) 2949 R: 2950 2951 2952 2953 2955 I: 2956 2958 2959 2961 4.9.3.24. unsupported-stanza-type 2963 The initiating entity has sent a first-level child of the stream that 2964 is not supported by the server, either because the receiving entity 2965 does not understand the namespace or because the receiving entity 2966 does not understand the element name for the applicable namespace 2967 (which might be the content namespace declared as the default 2968 namespace). 2970 (In the following example, the client attempts to send a first-level 2971 child element of qualified by the 'jabber:client' 2972 namespace, but the schema for that namespace defines no such 2973 element.) 2975 C: 2976 2977 2978 2979 Soliloquy 2980 2981 To be, or not to be: that is the question: 2982 Whether 'tis nobler in the mind to suffer 2983 The slings and arrows of outrageous fortune, 2984 Or to take arms against a sea of troubles, 2985 And by opposing end them? 2986 2987 2989 tag:denmark.example,2003:entry-32397 2990 2003-12-13T18:30:02Z 2991 2003-12-13T18:30:02Z 2992 2993 2994 2995 2997 S: 2998 3000 3001 3003 4.9.3.25. unsupported-version 3005 The 'version' attribute provided by the initiating entity in the 3006 stream header specifies a version of XMPP that is not supported by 3007 the server. 3009 C: 3010 3017 S: 3018 3026 3027 3029 3030 3032 4.9.4. Application-Specific Conditions 3034 As noted, an application MAY provide application-specific stream 3035 error information by including a properly-namespaced child in the 3036 error element. The application-specific element SHOULD supplement or 3037 further qualify a defined element. Thus the element will 3038 contain two or three child elements. 3040 C: 3041 3042 My keyboard layout is: 3044 QWERTYUIOP{}| 3045 ASDFGHJKL:" 3046 ZXCVBNM<>? 3047 3048 3050 S: 3051 3053 3054 Some special application diagnostic information! 3055 3056 3057 3058 3060 4.10. Simplified Stream Examples 3062 This section contains two highly simplified examples of a stream- 3063 based connection between a client and a server; these examples are 3064 included for the purpose of illustrating the concepts introduced thus 3065 far, but the reader needs to be aware that these examples elide many 3066 details (see Section 9 for more complete examples). 3068 A basic connection: 3070 C: 3071 3079 S: 3080 3089 [ ... stream negotiation ... ] 3091 C: 3094 Art thou not Romeo, and a Montague? 3095 3097 S: 3100 Neither, fair saint, if either thee dislike. 3101 3103 C: 3105 S: 3106 A connection gone bad: 3108 C: 3109 3117 S: 3118 3127 [ ... stream negotiation ... ] 3129 C: 3132 No closing tag! 3133 3135 S: 3136 3138 3139 3141 More detailed examples are provided under Section 9. 3143 5. STARTTLS Negotiation 3145 5.1. Fundamentals 3147 XMPP includes a method for securing the stream from tampering and 3148 eavesdropping. This channel encryption method makes use of the 3149 Transport Layer Security [TLS] protocol, specifically a "STARTTLS" 3150 extension that is modelled after similar extensions for the [IMAP], 3151 [POP3], and [ACAP] protocols as described in [USINGTLS]. The XML 3152 namespace name for the STARTTLS extension is 3153 'urn:ietf:params:xml:ns:xmpp-tls'. 3155 5.2. Support 3157 Support for STARTTLS is REQUIRED in XMPP client and server 3158 implementations. An administrator of a given deployment MAY specify 3159 that TLS is mandatory-to-negotiate for client-to-server 3160 communication, server-to-server communication, or both. An 3161 initiating entity SHOULD use TLS to secure its stream with the 3162 receiving entity before proceeding with SASL authentication. 3164 5.3. Stream Negotiation Rules 3166 5.3.1. Mandatory-to-Negotiate 3168 If the receiving entity advertises only the STARTTLS feature or if 3169 the receiving entity includes the child element as 3170 explained under Section 5.4.1, the parties MUST consider TLS as 3171 mandatory-to-negotiate. If TLS is mandatory-to-negotiate, the 3172 receiving entity SHOULD NOT advertise support for any stream feature 3173 except STARTTLS during the initial stage of the stream negotiation 3174 process, because further stream features might depend on prior 3175 negotiation of TLS given the order of layers in XMPP (e.g., the 3176 particular SASL mechanisms offered by the receiving entity will 3177 likely depend on whether TLS has been negotiated). 3179 5.3.2. Restart 3181 After TLS negotiation, the parties MUST restart the stream. 3183 5.3.3. Data Formatting 3185 During STARTTLS negotiation, the entities MUST NOT send any 3186 whitespace as separators between XML elements (i.e., from the last 3187 character of the first-level element qualified by the 3188 'urn:ietf:params:xml:ns:xmpp-tls' namespace as sent by the initiating 3189 entity, until the last character of the first-level 3190 element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace 3191 as sent by the receiving entity). This prohibition helps to ensure 3192 proper security layer byte precision. Any such whitespace shown in 3193 the STARTTLS examples provided in this document is included only for 3194 the sake of readability. 3196 5.3.4. Order of TLS and SASL Negotiations 3198 If the initiating entity chooses to use TLS, STARTTLS negotiation 3199 MUST be completed before proceeding to SASL negotiation (Section 6); 3200 this order of negotiation is necessary to help safeguard 3201 authentication information sent during SASL negotiation, as well as 3202 to make it possible to base the use of the SASL EXTERNAL mechanism on 3203 a certificate (or other credentials) provided during prior TLS 3204 negotiation. 3206 5.3.5. TLS Renegotiation 3208 The TLS protocol allows either party in a TLS-protected channel to 3209 initiate a new handshake that establishes new cryptographic 3210 parameters (see [TLS-NEG]). The cases most commonly mentioned are: 3212 1. Refreshing encryption keys. 3214 2. Wrapping the TLS sequence number as explained in Section 6.1 of 3215 [TLS]. 3217 3. Protecting client credentials by completing server authentication 3218 first and then completing client authentication over the 3219 protected channel. 3221 Because it is relatively inexpensive to establish streams in XMPP, 3222 for the first two cases it is preferable to use an XMPP stream reset 3223 (as described under Section 4.9.3.16) instead of performing TLS 3224 renegotiation. 3226 The third case has improved security characteristics when the TLS 3227 client (which might be an XMPP server) presents credentials to the 3228 TLS server. If communicating such credentials to an unauthenticated 3229 TLS server might leak private information, it can be appropriate to 3230 complete TLS negotiation for the purpose of authenticating the TLS 3231 server to the TLS client and then attempt TLS renegotiation for the 3232 purpose of authenticating the TLS client to the TLS server. However, 3233 this case is extremely rare because the credentials presented by an 3234 XMPP server or XMPP client acting as a TLS client are almost always 3235 public (i.e., a PKIX certificate) and therefore providing those 3236 credentials before authenticating the XMPP server acting as a TLS 3237 server would not in general leak private information. 3239 As a result, implementers are encouraged to carefully weigh the costs 3240 and benefits of TLS renegotiation before supporting it in their 3241 software, and XMPP entities that act as TLS clients are discouraged 3242 from attempting TLS renegotiation unless the certificate (or other 3243 credential information) sent during TLS negotiation is known to be 3244 private. 3246 Support for TLS renegotiation is strictly OPTIONAL. However, 3247 implementations that support TLS renegotiation MUST implement and use 3248 the TLS Renegotiation Extension [TLS-NEG]. 3250 If an entity that does not support TLS renegotiation detects a 3251 renegotiation attempt, then it MUST immediately close the underlying 3252 TCP connection without returning a stream error (since the violation 3253 has occurred at the TLS layer, not the XMPP layer, as described under 3254 Section 13.3). 3256 If an entity that supports TLS renegotiation detects a TLS 3257 renegotiation attempt that does not use the TLS Renegotiation 3258 Extension [TLS-NEG], then it MUST immediately close the underlying 3259 TCP connection without returning a stream error (since the violation 3260 has occurred at the TLS layer, not the XMPP layer as described under 3261 Section 13.3). 3263 5.3.6. TLS Extensions 3265 Either party to a stream MAY include any TLS extension during the TLS 3266 negotiation itself. This is a matter for the TLS layer, not the XMPP 3267 layer. 3269 5.4. Process 3271 5.4.1. Exchange of Stream Headers and Stream Features 3273 The initiating entity resolves the FQDN of the receiving entity as 3274 specified under Section 3, opens a TCP connection to the advertised 3275 port at the resolved IP address, and sends an initial stream header 3276 to the receiving entity. 3278 I: 3286 The receiving entity MUST send a response stream header to the 3287 initiating entity over the TCP connection opened by the initiating 3288 entity. 3290 R: 3299 The receiving entity then MUST send stream features to the initiating 3300 entity. If the receiving entity supports TLS, the stream features 3301 MUST include an advertisement for support of STARTTLS negotiation, 3302 i.e., a element qualified by the 3303 'urn:ietf:params:xml:ns:xmpp-tls' namespace. 3305 If the receiving entity considers STARTTLS negotiation to be 3306 mandatory-to-negotiate, the element MUST contain an empty 3307 child element. 3309 R: 3310 3311 3312 3313 3315 5.4.2. Initiation of STARTTLS Negotiation 3317 5.4.2.1. STARTTLS Command 3319 In order to begin the STARTTLS negotiation, the initiating entity 3320 issues the STARTTLS command (i.e., a element qualified by 3321 the 'urn:ietf:params:xml:ns:xmpp-tls' namespace) to instruct the 3322 receiving entity that it wishes to begin a STARTTLS negotiation to 3323 secure the stream. 3325 I: 3327 The receiving entity MUST reply with either a element 3328 (proceed case) or a element (failure case) qualified by 3329 the 'urn:ietf:params:xml:ns:xmpp-tls' namespace. 3331 5.4.2.2. Failure Case 3333 If the failure case occurs, the receiving entity MUST return a 3334 element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' 3335 namespace, close the XML stream, and terminate the underlying TCP 3336 connection. 3338 R: 3340 R: 3342 Causes for the failure case include but are not limited to: 3344 1. The initiating entity has sent a malformed STARTTLS command. 3346 2. The receiving entity did not offer the STARTTLS feature in its 3347 stream features. 3349 3. The receiving entity cannot complete STARTTLS negotiation because 3350 of an internal error. 3352 Informational Note: STARTTLS failure is not triggered by TLS 3353 errors such as bad_certificate or handshake_failure, which are 3354 generated and handled during the TLS negotiation itself as 3355 described in [TLS]. 3357 If the failure case occurs, the initiating entity MAY attempt to 3358 reconnect as explained under Section 3.3. 3360 5.4.2.3. Proceed Case 3362 If the proceed case occurs, the receiving entity MUST return a 3363 element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' 3364 namespace. 3366 R: 3368 The receiving entity MUST consider the TLS negotiation to have begun 3369 immediately after sending the closing '>' character of the 3370 element to the initiating entity. The initiating entity MUST 3371 consider the TLS negotiation to have begun immediately after 3372 receiving the closing '>' character of the element from 3373 the receiving entity. 3375 The entities now proceed to TLS negotiation as explained in the next 3376 section. 3378 5.4.3. TLS Negotiation 3380 5.4.3.1. Rules 3382 In order to complete TLS negotiation over the TCP connection, the 3383 entities MUST follow the process defined in [TLS]. 3385 The following rules apply: 3387 1. The entities MUST NOT send any further XML data until the TLS 3388 negotiation is complete. 3390 2. When using any of the mandatory-to-implement (MTI) ciphersuites 3391 specified under Section 13.8, the receiving entity MUST present a 3392 certificate. 3394 3. So that mutual certificate authentication will be possible, the 3395 receiving entity SHOULD send a certificate request to the 3396 initiating entity and the initiating entity SHOULD send a 3397 certificate to the receiving entity (but for privacy reasons 3398 might opt not to send a certificate until after the receiving 3399 entity has authenticated to the initiating entity). 3401 4. The receiving entity SHOULD choose which certificate to present 3402 based on the domainpart contained in the 'to' attribute of the 3403 initial stream header (in essence, this domainpart is 3404 functionally equivalent to the Server Name Indication defined for 3405 TLS in [TLS-EXT]). 3407 5. To determine if the TLS negotiation will succeed, the initiating 3408 entity MUST attempt to validate the receiving entity's 3409 certificate in accordance with the certificate validation 3410 procedures specified under Section 13.7.2. 3412 6. If the initiating entity presents a certificate, the receiving 3413 entity too MUST attempt to validate the initiating entity's 3414 certificate in accordance with the certificate validation 3415 procedures specified under Section 13.7.2. 3417 7. Following successful TLS negotiation, all further data 3418 transmitted by either party MUST be protected with the negotiated 3419 algorithms, keys, and secrets (i.e., encrypted, integrity- 3420 protected, or both depending on the ciphersuite used). 3422 Security Warning: See Section 13.8 regarding ciphersuites that 3423 MUST be supported for TLS; naturally, other ciphersuites MAY be 3424 supported as well. 3426 5.4.3.2. TLS Failure 3428 If the TLS negotiation results in failure, the receiving entity MUST 3429 terminate the TCP connection. 3431 The receiving entity MUST NOT send a closing tag before 3432 terminating the TCP connection (since the failure has occurred at the 3433 TLS layer, not the XMPP layer as described under Section 13.3). 3435 The initiating entity MAY attempt to reconnect as explained under 3436 Section 3.3, with or without attempting TLS negotiation (in 3437 accordance with local service policy, user-configured preferences, 3438 etc.). 3440 5.4.3.3. TLS Success 3442 If the TLS negotiation is successful, then the entities MUST proceed 3443 as follows. 3445 1. The initiating entity MUST discard any information transmitted in 3446 layers above TCP that it obtained from the receiving entity in an 3447 insecure manner before TLS took effect (e.g., the receiving 3448 entity's 'from' address or the stream ID and stream features 3449 received from the receiving entity). 3451 2. The receiving entity MUST discard any information transmitted in 3452 layers above TCP that it obtained from the initiating entity in 3453 an insecure manner before TLS took effect (e.g., the initiating 3454 entity's 'from' address). 3456 3. The initiating entity MUST send a new initial stream header to 3457 the receiving entity over the encrypted connection (as specified 3458 under Section 4.3.3, the initiating entity MUST NOT send a 3459 closing tag before sending the new initial stream 3460 header, since the receiving entity and initiating entity MUST 3461 consider the original stream to be replaced upon success of the 3462 TLS negotiation). 3464 I: 3472 4. The receiving entity MUST respond with a new response stream 3473 header over the encrypted connection (for which it MUST generate 3474 a new stream ID instead of re-using the old stream ID). 3476 R: 3485 5. The receiving entity also MUST send stream features to the 3486 initiating entity, which MUST NOT include the STARTTLS feature 3487 but which SHOULD include the SASL stream feature as described 3488 under Section 6 (see especially Section 6.4.1 regarding the few 3489 reasons why the SASL stream feature would not be offered here). 3491 R: 3492 3493 EXTERNAL 3494 SCRAM-SHA-1-PLUS 3495 SCRAM-SHA-1 3496 PLAIN 3497 3498 3500 6. SASL Negotiation 3502 6.1. Fundamentals 3504 XMPP includes a method for authenticating a stream by means of an 3505 XMPP-specific profile of the Simple Authentication and Security Layer 3506 protocol (see [SASL]). SASL provides a generalized method for adding 3507 authentication support to connection-based protocols, and XMPP uses 3508 an XML namespace profile of SASL that conforms to the profiling 3509 requirements of [SASL]. The XML namespace name for the SASL 3510 extension is 'urn:ietf:params:xml:ns:xmpp-sasl'. 3512 6.2. Support 3514 Support for SASL negotiation is REQUIRED in XMPP client and server 3515 implementations. 3517 6.3. Stream Negotiation Rules 3518 6.3.1. Mandatory-to-Negotiate 3520 The parties to a stream MUST consider SASL as mandatory-to-negotiate. 3522 6.3.2. Restart 3524 After SASL negotiation, the parties MUST restart the stream. 3526 6.3.3. Mechanism Preferences 3528 Any entity that will act as a SASL client or a SASL server MUST 3529 maintain an ordered list of its preferred SASL mechanisms according 3530 to the client or server, where the list is ordered according to local 3531 policy or user configuration (which SHOULD be in order of perceived 3532 strength to enable the strongest authentication possible). The 3533 initiating entity MUST maintain its own preference order independent 3534 of the preference order of the receiving entity. A server MUST offer 3535 and a client MUST try SASL mechanisms in preference order. For 3536 example, if the server offers the ordered list "PLAIN SCRAM-SHA-1 3537 GSSAPI" or "SCRAM-SHA-1 GSSAPI PLAIN" but the client's ordered list 3538 is "GSSAPI SCRAM-SHA-1", the client MUST try GSSAPI first and then 3539 SCRAM-SHA-1 but MUST NOT try PLAIN (since PLAIN is not on its list). 3541 6.3.4. Mechanism Offers 3543 If the receiving entity considers TLS negotiation (Section 5) to be 3544 mandatory-to-negotiate before it will accept authentication with a 3545 particular SASL mechanism, it MUST NOT advertise that mechanism in 3546 its list of available SASL mechanisms before TLS negotiation has been 3547 completed. 3549 The receiving entity SHOULD offer the SASL EXTERNAL mechanism if both 3550 of the following conditions hold: 3552 1. During TLS negotiation the initiating entity presented a 3553 certificate that is acceptable to the receiving entity for 3554 purposes of strong identity verification in accordance with local 3555 service policies (e.g., because said certificate is unexpired, is 3556 unrevoked, and is anchored to a root trusted by the receiving 3557 entity). 3559 2. The receiving entity expects that the initiating entity will be 3560 able to authenticate and authorize as the identity provided in 3561 the certificate; in the case of a server-to-server stream, the 3562 receiving entity might have such an expectation because a DNS 3563 domain name presented in the initiating entity's certificate 3564 matches the domain referenced in the 'from' attribute of the 3565 initial stream header, where the matching rules of [TLS-CERTS] 3566 apply; in the case of a client-to-server stream, the receiving 3567 entity might have such an expectation because the bare JID 3568 presented in the initiating entity's certificate matches a user 3569 account that is registered with the server or because other 3570 information contained in the initiating entity's certificate 3571 matches that of an entity that has permission to use the server 3572 for access to an XMPP network. 3574 However, the receiving entity MAY offer the SASL EXTERNAL mechanism 3575 under other circumstances, as well. 3577 When the receiving entity offers the SASL EXTERNAL mechanism, the 3578 receiving entity SHOULD list the EXTERNAL mechanism first among its 3579 offered SASL mechanisms and the initiating entity SHOULD attempt SASL 3580 negotiation using the EXTERNAL mechanism first (this preference will 3581 tend to increase the likelihood that the parties can negotiate mutual 3582 certificate authentication). 3584 Section 13.8 specifies SASL mechanisms that MUST be supported; 3585 naturally, other SASL mechanisms MAY be supported as well. 3587 Informational Note: Best practices for the use of SASL in the 3588 context of XMPP are described in [XEP-0175] for the ANONYMOUS 3589 mechanism and in [XEP-0178] for the EXTERNAL mechanism. 3591 6.3.5. Data Formatting 3593 The following data formatting rules apply to the SASL negotiation: 3595 1. During SASL negotiation, the entities MUST NOT send any 3596 whitespace as separators between XML elements (i.e., from the 3597 last character of the first-level element qualified by 3598 the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace as sent by the 3599 initiating entity, until the last character of the first-level 3600 element qualified by the 3601 'urn:ietf:params:xml:ns:xmpp-sasl' namespace as sent by the 3602 receiving entity). This prohibition helps to ensure proper 3603 security layer byte precision. Any such whitespace shown in the 3604 SASL examples provided in this document is included only for the 3605 sake of readability. 3607 2. Any XML character data contained within the XML elements MUST be 3608 encoded using base 64, where the encoding adheres to the 3609 definition in Section 4 of [BASE64] and where the padding bits 3610 are set to zero. 3612 3. As formally specified in the XML schema for the 3613 'urn:ietf:params:xml:ns:xmpp-sasl' namespace under Appendix A.4, 3614 the receiving entity MAY include one or more application-specific 3615 child elements inside the element to provide 3616 information that might be needed by the initiating entity in 3617 order to complete successful SASL negotiation using one or more 3618 of the offered mechanisms; however, the syntax and semantics of 3619 all such elements are out of scope for this specification (see 3620 [XEP-0233] for one example). 3622 6.3.6. Security Layers 3624 Upon successful SASL negotiation that involves negotiation of a 3625 security layer, both the initiating entity and the receiving MUST 3626 discard any application-layer state (i.e, state from the XMPP layer, 3627 excluding state from the TLS negotiation or SASL negotiation). 3629 6.3.7. Simple User Name 3631 Some SASL mechanisms (e.g., CRAM-MD5, DIGEST-MD5, and SCRAM) specify 3632 that the authentication identity used in the context of such 3633 mechanisms is a "simple user name" (see Section 2 of [SASL] as well 3634 as [SASLPREP]). The exact form of the simple user name in any 3635 particular mechanism or deployment thereof is a local matter, and a 3636 simple user name does not necessarily map to an application 3637 identifier such as a JID or JID component (e.g., a localpart). 3638 However, in the absence of local information provided by the server, 3639 an XMPP client SHOULD assume that the authentication identity for 3640 such a SASL mechanism is a simple user name equal to the localpart of 3641 the user's JID. 3643 6.3.8. Authorization Identity 3645 An authorization identity is an OPTIONAL identity included by the 3646 initiating entity to specify an identity to act as (see Section 2 of 3647 [SASL]). In client-to-server streams it would most likely be used by 3648 an administrator to perform some management task on behalf of another 3649 user, whereas in server-to-server streams it would most likely be 3650 used to specify a particular add-on service at an XMPP service (e.g., 3651 a multi-user chat server at conference.example.com that is hosted by 3652 the example.com XMPP service). If the initiating entity wishes to 3653 act on behalf of another entity and the selected SASL mechanism 3654 supports transmission of an authorization identity, the initiating 3655 entity MUST provide an authorization identity during SASL 3656 negotiation. If the initiating entity does not wish to act on behalf 3657 of another entity, it MUST NOT provide an authorization identity. 3659 In the case of client-to-server communication, the value of an 3660 authorization identity MUST be a bare JID () 3661 rather than a full JID (). 3663 In the case of server-to-server communication, the value of an 3664 authorization identity MUST be a domainpart only (). 3666 If the initiating entity provides an authorization identity during 3667 SASL negotiation, the receiving entity is responsible for verifying 3668 that the initiating entity is in fact allowed to assume the specified 3669 authorization identity; if not, the receiving entity MUST return an 3670 SASL error as described under Section 6.5.6. 3672 6.3.9. Realms 3674 The receiving entity MAY include a realm when negotiating certain 3675 SASL mechanisms (e.g., both the GSSAPI and DIGEST-MD5 mechanisms 3676 allow the authentication exchange to include a realm, though in 3677 different ways, whereas the EXTERNAL, SCRAM, and PLAIN mechanisms do 3678 not). If the receiving entity does not communicate a realm, the 3679 initiating entity MUST NOT assume that any realm exists. The realm 3680 MUST be used only for the purpose of authentication; in particular, 3681 an initiating entity MUST NOT attempt to derive an XMPP domainpart 3682 from the realm information provided by the receiving entity. 3684 6.3.10. Round Trips 3686 [SASL] specifies that a using protocol such as XMPP can define two 3687 methods by which the protocol can save round trips where allowed for 3688 the SASL mechanism: 3690 1. When the SASL client (the XMPP "initiating entity") requests an 3691 authentication exchange, it can include "initial response" data 3692 with its request if appropriate for the SASL mechanism in use. 3693 In XMPP this is done by including the initial response as the XML 3694 character data of the element. 3696 2. At the end of the authentication exchange, the SASL server (the 3697 XMPP "receiving entity") can include "additional data with 3698 success" if appropriate for the SASL mechanism in use. In XMPP 3699 this is done by including the additional data as the XML 3700 character data of the element. 3702 For the sake of protocol efficiency, it is REQUIRED for clients and 3703 servers to support these methods and RECOMMENDED to use them; however 3704 clients and servers MUST support the less efficient modes as well. 3706 6.4. Process 3708 The process for SASL negotiation is as follows. 3710 6.4.1. Exchange of Stream Headers and Stream Features 3712 If SASL negotiation follows successful STARTTLS negotiation 3713 (Section 5), then the SASL negotiation occurs over the protected 3714 stream that has already been negotiated. If not, the initiating 3715 entity resolves the FQDN of the receiving entity as specified under 3716 Section 3, opens a TCP connection to the advertised port at the 3717 resolved IP address, and sends an initial stream header to the 3718 receiving entity. In either case, the receiving entity will receive 3719 an initial stream from the initiating entity. 3721 I: 3729 When the receiving entity processes an initial stream header from the 3730 initiating entity, it MUST send a response stream header to the 3731 initiating entity (for which it MUST generate a unique stream ID; if 3732 TLS negotiation has already succeeded then this stream ID MUST be 3733 different from the stream ID sent before TLS negotiation succeeded). 3735 R: 3744 The receiving entity also MUST send stream features to the initiating 3745 entity. The stream features SHOULD include an advertisement for 3746 support of SASL negotiation, i.e., a element qualified 3747 by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace. Typically there 3748 are only three cases in which support for SASL negotiation would not 3749 be advertised here: 3751 o TLS negotiation needs to happen before SASL can be offered (i.e., 3752 TLS is required and the receiving entity is responding to the very 3753 first initial stream header it has received for this connection 3754 attempt). 3756 o SASL negotiation is impossible for a server-to-server connection 3757 (i.e., the initiating server has not provided a certificate that 3758 would enable strong authentication and therefore the receiving 3759 server is falling back to weak identity verification using the 3760 Server Dialback protocol [XEP-0220]). 3762 o SASL has already been negotiated (i.e., the receiving entity is 3763 responding to an initial stream header sent as a stream restart 3764 after successful SASL negotiation). 3766 The element MUST contain one child element 3767 for each authentication mechanism the receiving entity offers to the 3768 initiating entity. As noted, the order of elements in 3769 the XML indicates the preference order of the SASL mechanisms 3770 according to the receiving entity (which is not necessarily the 3771 preference order according to the initiating entity). 3773 R: 3774 3775 EXTERNAL 3776 SCRAM-SHA-1-PLUS 3777 SCRAM-SHA-1 3778 PLAIN 3779 3780 3782 6.4.2. Initiation 3784 In order to begin the SASL negotiation, the initiating entity sends 3785 an element qualified by the 3786 'urn:ietf:params:xml:ns:xmpp-sasl' namespace and includes an 3787 appropriate value for the 'mechanism' attribute, thus starting the 3788 handshake for that particular authentication mechanism. This element 3789 MAY contain XML character data (in SASL terminology, the "initial 3790 response") if the mechanism supports or requires it; if the 3791 initiating entity needs to send a zero-length initial response, it 3792 MUST transmit the response as a single equals sign character ("="), 3793 which indicates that the response is present but contains no data. 3795 I: AGp1bGlldAByMG0zMG15cjBtMzA= 3798 If the initiating entity subsequently sends another element 3799 and the ongoing authentication handshake has not yet completed, the 3800 receiving entity MUST discard the ongoing handshake and MUST process 3801 a new handshake for the subsequently requested SASL mechanism. 3803 6.4.3. Challenge-Response Sequence 3805 If necessary, the receiving entity challenges the initiating entity 3806 by sending a element qualified by the 3807 'urn:ietf:params:xml:ns:xmpp-sasl' namespace; this element MAY 3808 contain XML character data (which MUST be generated in accordance 3809 with the definition of the SASL mechanism chosen by the initiating 3810 entity). 3812 The initiating entity responds to the challenge by sending a 3813 element qualified by the 3814 'urn:ietf:params:xml:ns:xmpp-sasl' namespace; this element MAY 3815 contain XML character data (which MUST be generated in accordance 3816 with the definition of the SASL mechanism chosen by the initiating 3817 entity). 3819 If necessary, the receiving entity sends more challenges and the 3820 initiating entity sends more responses. 3822 This series of challenge/response pairs continues until one of three 3823 things happens: 3825 o The initiating entity aborts the handshake for this authentication 3826 mechanism. 3827 o The receiving entity reports failure of the handshake. 3828 o The receiving entity reports success of the handshake. 3830 These scenarios are described in the following sections. 3832 6.4.4. Abort 3834 The initiating entity aborts the handshake for this authentication 3835 mechanism by sending an element qualified by the 3836 'urn:ietf:params:xml:ns:xmpp-sasl' namespace. 3838 I: 3840 Upon receiving an element, the receiving entity MUST return 3841 a element qualified by the 3842 'urn:ietf:params:xml:ns:xmpp-sasl' namespace and containing an 3843 child element. 3845 R: 3846 3847 3849 6.4.5. SASL Failure 3851 The receiving entity reports failure of the handshake for this 3852 authentication mechanism by sending a element qualified by 3853 the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace (the particular 3854 cause of failure MUST be communicated in an appropriate child element 3855 of the element as defined under Section 6.5). 3857 R: 3858 3859 3861 Where appropriate for the chosen SASL mechanism, the receiving entity 3862 SHOULD allow a configurable but reasonable number of retries (at 3863 least 2 and no more than 5); this enables the initiating entity 3864 (e.g., an end-user client) to tolerate incorrectly-provided 3865 credentials (e.g., a mistyped password) without being forced to 3866 reconnect (which it would if the receiving entity immediately 3867 returned a SASL failure and closed the stream). 3869 If the initiating entity attempts a reasonable number of retries with 3870 the same SASL mechanism and all attempts fail, it MAY fall back to 3871 the next mechanism in its ordered list by sending a new 3872 request to the receiving entity, thus starting a new handshake for 3873 that authentication mechanism. If all handshakes fail and there are 3874 no remaining mechanisms in the initiating entity's list of supported 3875 and acceptable mechanisms, the initiating entity SHOULD simply close 3876 the stream as described under Section 4.4 (instead of waiting for the 3877 stream to time out). 3879 If the initiating entity exceeds the number of retries, the receiving 3880 entity MUST close the stream with a stream error, which SHOULD be 3881 (Section 4.9.3.14), although some existing 3882 implementations send (Section 4.9.3.12) instead. 3884 Implementation Note: For server-to-server streams, if the 3885 receiving entity cannot offer the SASL EXTERNAL mechanism or any 3886 other SASL mechanism based on the security context established 3887 during TLS negotiation, the receiving entity MAY attempt to 3888 complete weak identity verification using the Server Dialback 3889 protocol [XEP-0220]; however, if according to local service 3890 policies weak identity verification is insufficient then the 3891 receiving entity SHOULD instead close the stream with a stream error (Section 4.9.3.14) instead of waiting for 3893 the stream to time out. 3895 6.4.6. SASL Success 3897 Before considering the SASL handshake to be a success, if the 3898 initiating entity provided a 'from' attribute on an initial stream 3899 header whose confidentiality and integrity were protected via TLS or 3900 an equivalent security layer (such as the SASL GSSAPI mechanism) then 3901 the receiving entity SHOULD correlate the authentication identity 3902 resulting from the SASL negotiation with that 'from' address; if the 3903 two identities do not match then the receiving entity SHOULD 3904 terminate the connection attempt (however, the receiving entity might 3905 have legitimate reasons not to terminate the connection attempt, for 3906 example because it has overridden a connecting client's address to 3907 correct the JID format or assign a JID based on information presented 3908 in an end-user certificate). 3910 The receiving entity reports success of the handshake by sending a 3911 element qualified by the 3912 'urn:ietf:params:xml:ns:xmpp-sasl' namespace; this element MAY 3913 contain XML character data (in SASL terminology, "additional data 3914 with success") if the chosen SASL mechanism supports or requires it; 3915 if the receiving entity needs to send additional data of zero length, 3916 it MUST transmit the data as a single equals sign character ("="). 3918 R: 3920 Informational Note: For client-to-server streams, the 3921 authorization identity communicated during SASL negotiation is 3922 used to determine the canonical address for the initiating client 3923 according to the receiving server, as described under 3924 Section 4.3.6. 3926 Upon receiving the element, the initiating entity MUST 3927 initiate a new stream over the existing TCP connection by sending a 3928 new initial stream header to the receiving entity (as specified under 3929 Section 4.3.3, the initiating entity MUST NOT send a closing 3930 tag before sending the new initial stream header, since the 3931 receiving entity and initiating entity MUST consider the original 3932 stream to be replaced upon success of the SASL negotiation). 3934 I: 3942 Upon receiving the new initial stream header from the initiating 3943 entity, the receiving entity MUST respond by sending a new response 3944 stream header to the initiating entity (for which it MUST generate a 3945 new stream ID instead of re-using the old stream ID). 3947 R: 3956 The receiving entity MUST also send stream features, containing any 3957 further available features or containing no features (via an empty 3958 element). 3960 R: 3961 3962 3964 6.5. SASL Errors 3966 The syntax of SASL errors is as follows , where the XML data shown 3967 within the square brackets '[' and ']' is OPTIONAL. 3969 3970 3971 [ 3972 OPTIONAL descriptive text 3973 ] 3974 3976 The "defined-condition" MUST be one of the SASL-related error 3977 conditions defined in the following sections. However, because 3978 additional error conditions might be defined in the future, if an 3979 entity receives a SASL error condition that it does not understand 3980 then it MUST treat the unknown condition as a generic authentication 3981 failure, i.e., as equivalent to (Section 6.5.10). 3983 Inclusion of the element is OPTIONAL, and can be used to 3984 provide application-specific information about the error condition, 3985 which information MAY be displayed to a human but only as a 3986 supplement to the defined condition. 3988 Because XMPP itself defines an application profile of SASL and there 3989 is no expectation that more specialized XMPP applications will be 3990 built on top of SASL, the SASL error format does not provide 3991 extensibility for application-specific error conditions as is done 3992 for XML streams (Section 4.9.4) and XML stanzas (Section 8.3.4). 3994 6.5.1. aborted 3996 The receiving entity acknowledges that the authentication handshake 3997 has been aborted by the initiating entity; sent in reply to the 3998 element. 4000 I: 4002 R: 4003 4004 4006 6.5.2. account-disabled 4008 The account of the initiating entity has been temporarily disabled; 4009 sent in reply to an element (with or without initial response 4010 data) or a element. 4012 I: AGp1bGlldAByMG0zMG15cjBtMzA= 4015 R: 4016 4017 Call 212-555-1212 for assistance. 4018 4020 6.5.3. credentials-expired 4022 The authentication failed because the initiating entity provided 4023 credentials that have expired; sent in reply to a element 4024 or an element with initial response data. 4026 I: 4027 [ ... ] 4028 4030 R: 4031 4032 4034 6.5.4. encryption-required 4036 The mechanism requested by the initiating entity cannot be used 4037 unless the confidentiality and integrity of the underlying stream are 4038 protected (typically via TLS); sent in reply to an element 4039 (with or without initial response data). 4041 I: AGp1bGlldAByMG0zMG15cjBtMzA= 4044 R: 4045 4046 4048 6.5.5. incorrect-encoding 4050 The data provided by the initiating entity could not be processed 4051 because the Base 64 encoding is incorrect (e.g., because the encoding 4052 does not adhere to the definition in Section 4 of [BASE64]); sent in 4053 reply to a element or an element with initial 4054 response data. 4056 I: [ ... ] 4059 R: 4060 4061 4063 6.5.6. invalid-authzid 4065 The authzid provided by the initiating entity is invalid, either 4066 because it is incorrectly formatted or because the initiating entity 4067 does not have permissions to authorize that ID; sent in reply to a 4068 element or an element with initial response data. 4070 I: 4071 [ ... ] 4072 4074 R: 4075 4076 4078 6.5.7. invalid-mechanism 4080 The initiating entity did not specify a mechanism, or requested a 4081 mechanism that is not supported by the receiving entity; sent in 4082 reply to an element. 4084 I: 4087 R: 4088 4089 4091 6.5.8. malformed-request 4093 The request is malformed (e.g., the element includes initial 4094 response data but the mechanism does not allow that, or the data sent 4095 violates the syntax for the specified SASL mechanism); sent in reply 4096 to an , , , or element. 4098 (In the following example, the XML character data of the 4099 element contains more than 255 UTF-8-encoded Unicode characters and 4100 therefore violates the "token" production for the SASL ANONYMOUS 4101 mechanism as specified in [ANONYMOUS].) 4103 I: [ ... some-long-token ... ] 4106 R: 4107 4108 4110 6.5.9. mechanism-too-weak 4112 The mechanism requested by the initiating entity is weaker than 4113 server policy permits for that initiating entity; sent in reply to an 4114 element (with or without initial response data). 4116 I: AGp1bGlldAByMG0zMG15cjBtMzA= 4119 R: 4120 4121 4123 6.5.10. not-authorized 4125 The authentication failed because the initiating entity did not 4126 provide proper credentials, or because some generic authentication 4127 failure has occurred but the receiving entity does not wish to 4128 disclose specific information about the cause of the failure; sent in 4129 reply to a element or an element with initial 4130 response data. 4132 I: 4133 [ ... ] 4134 4136 R: 4137 4138 4140 Security Warning: This error condition includes but is not limited 4141 to the case of incorrect credentials or a nonexistent username. 4142 In order to discourage directory harvest attacks, no 4143 differentiation is made between incorrect credentials and a 4144 nonexistent username. 4146 6.5.11. temporary-auth-failure 4148 The authentication failed because of a temporary error condition 4149 within the receiving entity, and it is advisable for the initiating 4150 entity to try again later; sent in reply to an element or a 4151 element. 4153 I: 4154 [ ... ] 4155 4157 R: 4158 4159 4161 6.6. SASL Definition 4163 The profiling requirements of [SASL] require that the following 4164 information be supplied by the definition of a using protocol. 4166 service name: "xmpp" 4168 initiation sequence: After the initiating entity provides an opening 4169 XML stream header and the receiving entity replies in kind, the 4170 receiving entity provides a list of acceptable authentication 4171 methods. The initiating entity chooses one method from the list 4172 and sends it to the receiving entity as the value of the 4173 'mechanism' attribute possessed by an element, optionally 4174 including an initial response to avoid a round trip. 4176 exchange sequence: Challenges and responses are carried through the 4177 exchange of elements from receiving entity to 4178 initiating entity and elements from initiating entity 4179 to receiving entity. The receiving entity reports failure by 4180 sending a element and success by sending a 4181 element; the initiating entity aborts the exchange by sending an 4182 element. Upon successful negotiation, both sides 4183 consider the original XML stream to be closed and new stream 4184 headers are sent by both entities. 4186 security layer negotiation: The security layer takes effect 4187 immediately after sending the closing '>' character of the 4188 element for the receiving entity, and immediately after 4189 receiving the closing '>' character of the element for 4190 the initiating entity. The order of layers is first [TCP], then 4191 [TLS], then [SASL], then XMPP. 4193 use of the authorization identity: The authorization identity can be 4194 used in XMPP to denote the non-default of a 4195 client; an empty string is equivalent to an absent authorization 4196 identity. 4198 7. Resource Binding 4200 7.1. Fundamentals 4202 After a client authenticates with a server, it MUST bind a specific 4203 resource to the stream so that the server can properly address the 4204 client. That is, there MUST be an XMPP resource associated with the 4205 bare JID () of the client, so that the address 4206 for use over that stream is a full JID of the form 4207 (including the resourcepart). This 4208 ensures that the server can deliver XML stanzas to and receive XML 4209 stanzas from the client in relation to entities other than the server 4210 itself or the client's account, as explained under Section 10. 4212 Informational Note: The client could exchange stanzas with the 4213 server itself or the client's account before binding a resource 4214 since the full JID is needed only for addressing outside the 4215 context of the stream negotiated between the client and the 4216 server, but this is not commonly done. 4218 After a client has bound a resource to the stream, it is referred to 4219 as a "connected resource". A server SHOULD allow an entity to 4220 maintain multiple connected resources simultaneously, where each 4221 connected resource is associated with a distinct XML stream and is 4222 differentiated from the other connected resources by a distinct 4223 resourcepart. 4225 Security Warning: A server SHOULD enable the administrator of an 4226 XMPP service to limit the number of connected resources in order 4227 to prevent certain denial of service attacks as described under 4228 Section 13.12. 4230 If, before completing the resource binding step, the client attempts 4231 to send an XML stanza to an entity other than the server itself or 4232 the client's account, the server MUST NOT process the stanza and MUST 4233 close the stream with a stream error 4234 (Section 4.9.3.12). 4236 The XML namespace name for the resource binding extension is 4237 'urn:ietf:params:xml:ns:xmpp-bind'. 4239 7.2. Support 4241 Support for resource binding is REQUIRED in XMPP client and server 4242 implementations. 4244 7.3. Stream Negotiation Rules 4246 7.3.1. Mandatory-to-Negotiate 4248 The parties to a stream MUST consider resource binding as mandatory- 4249 to-negotiate. 4251 7.3.2. Restart 4253 After resource binding, the parties MUST NOT restart the stream. 4255 7.4. Advertising Support 4257 Upon sending a new response stream header to the client after 4258 successful SASL negotiation, the server MUST include a 4259 element qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace 4260 in the stream features it presents to the client. 4262 The server MUST NOT include the resource binding stream feature until 4263 after the client has authenticated, typically by means of successful 4264 SASL negotiation. 4266 S: 4275 S: 4276 4277 4279 Upon being informed that resource binding is mandatory-to-negotiate, 4280 the client MUST bind a resource to the stream as described in the 4281 following sections. 4283 7.5. Generation of Resource Identifiers 4285 A resourcepart MUST at a minimum be unique among the connected 4286 resources for that . Enforcement of this 4287 policy is the responsibility of the server. 4289 Security Warning: A resourcepart can be security-critical. For 4290 example, if a malicious entity can guess a client's resourcepart 4291 then it might be able to determine if the client (and therefore 4292 the controlling principal) is online or offline, thus resulting in 4293 a presence leak as described under Section 13.10.2. To prevent 4294 that possibility, a client can either (1) generate a random 4295 resourcepart on its own or (2) ask the server to generate a 4296 resourcepart on its behalf. One method for ensuring that the 4297 resourcepart is random is to generate a Universally Unique 4298 Identifier (UUID) as specified in [UUID]. 4300 7.6. Server-Generated Resource Identifier 4302 A server MUST be able to generate an XMPP resourcepart on behalf of a 4303 client. The resourcepart generated by the server MUST be random (see 4304 [RANDOM]). 4306 7.6.1. Success Case 4308 A client requests a server-generated resourcepart by sending an IQ 4309 stanza of type "set" (see Section 8.2.3) containing an empty 4310 element qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' 4311 namespace. 4313 C: 4314 4315 4317 Once the server has generated an XMPP resourcepart for the client, it 4318 MUST return an IQ stanza of type "result" to the client, which MUST 4319 include a child element that specifies the full JID for the 4320 connected resource as determined by the server. 4322 S: 4323 4324 4325 juliet@im.example.com/4db06f06-1ea4-11dc-aca3-000bcd821bfb 4326 4327 4328 4330 7.6.2. Error Cases 4332 When a client asks the server to generate a resourcepart during 4333 resource binding, the following stanza error conditions are defined: 4335 o The account has reached a limit on the number of simultaneous 4336 connected resources allowed. 4337 o The client is otherwise not allowed to bind a resource to the 4338 stream. 4340 Naturally, it is possible that error conditions not specified here 4341 might occur, as described under under Section 8.3. 4343 7.6.2.1. Resource Constraint 4345 If the account has reached a limit on the number of simultaneous 4346 connected resources allowed, the server MUST return a stanza error (Section 8.3.3.18). 4349 S: 4350 4351 4353 4354 4356 7.6.2.2. Not Allowed 4358 If the client is otherwise not allowed to bind a resource to the 4359 stream, the server MUST return a stanza error 4360 (Section 8.3.3.10). 4362 S: 4363 4364 4366 4367 4369 7.7. Client-Submitted Resource Identifier 4371 Instead of asking the server to generate a resourcepart on its 4372 behalf, a client MAY attempt to submit a resourcepart that it has 4373 generated or that the controlling user has provided. 4375 7.7.1. Success Case 4377 A client asks its server to accept a client-submitted resourcepart by 4378 sending an IQ stanza of type "set" containing a element with 4379 a child element containing non-zero-length XML character 4380 data. 4382 C: 4383 4384 balcony 4385 4386 4388 The server SHOULD accept the client-submitted resourcepart. It does 4389 so by returning an IQ stanza of type "result" to the client, 4390 including a child element that specifies the full JID for the 4391 connected resource and contains without modification the client- 4392 submitted text. 4394 S: 4395 4396 juliet@im.example.com/balcony 4397 4398 4400 Alternatively, in accordance with local service policies the server 4401 MAY refuse the client-submitted resourcepart and override it with a 4402 resourcepart that the server generates. 4404 S: 4405 4406 4407 juliet@im.example.com/balcony 4db06f06-1ea4-11dc-aca3-000bcd821bfb 4408 4409 4411 4413 7.7.2. Error Cases 4415 When a client attempts to submit its own XMPP resourcepart during 4416 resource binding, the following stanza error conditions are defined 4417 in addition to those described under Section 7.6.2: 4419 o The provided resourcepart cannot be processed by the server. 4420 o The provided resourcepart is already in use. 4422 Naturally, it is possible that error conditions not specified here 4423 might occur, as described under under Section 8.3. 4425 7.7.2.1. Bad Request 4427 If the provided resourcepart cannot be processed by the server (e.g. 4428 because it is of zero length or because it otherwise violates the 4429 rules for resourceparts specified in [XMPP-ADDR]), the server can 4430 return a stanza error (Section 8.3.3.1) but SHOULD 4431 instead process the resourcepart so that it is in conformance. 4433 S: 4434 4435 4436 4437 4439 7.7.2.2. Conflict 4441 If there is a currently-connected client whose session has the 4442 resourcepart being requested by the newly-connecting client, the 4443 server MUST do one of the following (which of these the server does 4444 is a matter for implementation or local service policy, although 4445 suggestions are provided below). 4447 1. Override the resourcepart provided by the newly-connecting client 4448 with a server-generated resourcepart. 4450 This behavior is encouraged, because it simplifies the resource 4451 binding process for client implementations. 4453 2. Disallow the resource binding attempt of the newly-connecting 4454 client and maintain the session of the currently-connected 4455 client. 4457 This behavior is neither encouraged nor discouraged, despite the 4458 fact that it was implicitly encouraged in RFC 3920; however, note 4459 that handling of the error is unevenly supported 4460 among existing client implementations, which often treat it as an 4461 authentication error and have been observed to discard cached 4462 credentials when receiving it. 4464 3. Terminate the session of the currently-connected client and allow 4465 the resource binding attempt of the newly-connecting client. 4467 Although this was the traditional behavior of early XMPP server 4468 implementations, it is now discouraged because it can lead to a 4469 neverending cycle of two clients effectively disconnecting each 4470 other; however, note that this behavior can be appropriate in 4471 some deployment scenarios or if the server knows that the 4472 currently-connected client has a dead connection or broken stream 4473 as described under Section 4.6. 4475 If the server follows behavior #1, it returns an stanza of type 4476 "result" to the newly-connecting client, where the child of 4477 the element contains XML character data that indicates the 4478 full JID of the client, including the resourcepart that was generated 4479 by the server. 4481 S: 4482 4483 4484 juliet@im.example.com/balcony 4db06f06-1ea4-11dc-aca3-000bcd821bfb 4485 4486 4487 4489 If the server follows behavior #2, it sends a stanza 4490 error (Section 8.3.3.2) in response to the resource binding attempt 4491 of the newly-connecting client but maintains the XML stream so that 4492 the newly-connecting client has an opportunity to negotiate a non- 4493 conflicting resourcepart (i.e., the newly-connecting client needs to 4494 choose a different resourcepart before making another attempt to bind 4495 a resource). 4497 S: 4498 4499 4500 4501 4503 If the server follows behavior #3, it returns a stream 4504 error (Section 4.9.3.3) to the currently-connected client (as 4505 described under Section 4.9.3.3) and returns an IQ stanza of type 4506 "result" (indicating success) in response to the resource binding 4507 attempt of the newly-connecting client. 4509 S: 4510 4511 4512 juliet@im.example.com/balcony 4513 4514 4515 4517 7.7.3. Retries 4519 If an error occurs when a client submits a resourcepart, the server 4520 SHOULD allow a configurable but reasonable number of retries (at 4521 least 5 and no more than 10); this enables the client to tolerate 4522 incorrectly-provided resourceparts (e.g., bad data formats or 4523 duplicate text strings) without being forced to reconnect. 4525 After the client has reached the retry limit, the server MUST close 4526 the stream with a stream error 4527 (Section 4.9.3.14). 4529 8. XML Stanzas 4531 After a client and a server (or two servers) have completed stream 4532 negotiation, either party can send XML stanzas. Three kinds of XML 4533 stanza are defined for the 'jabber:client' and 'jabber:server' 4534 namespaces: , , and . In addition, there 4535 are five common attributes for these stanza types. These common 4536 attributes, as well as the basic semantics of the three stanza types, 4537 are defined in this specification; more detailed information 4538 regarding the syntax of XML stanzas for instant messaging and 4539 presence applications is provided in [XMPP-IM], and for other 4540 applications in the relevant XMPP extension specifications. 4542 Support for the XML stanza syntax and semantics defined in this 4543 specification is REQUIRED in XMPP client and server implementations. 4545 Security Warning: A server MUST NOT process a partial stanza and 4546 MUST NOT attach meaning to the transmission timing of any part of 4547 a stanza (before receipt of the close tag). 4549 8.1. Common Attributes 4551 The following five attributes are common to message, presence, and IQ 4552 stanzas. 4554 8.1.1. to 4556 The 'to' attribute specifies the JID of the intended recipient for 4557 the stanza. 4559 4560 Art thou not Romeo, and a Montague? 4561 4563 For information about server processing of inbound and outbound XML 4564 stanzas based on the 'to' address, refer to Section 10. 4566 8.1.1.1. Client-to-Server Streams 4568 The following rules apply to inclusion of the 'to' attribute in 4569 stanzas sent from a connected client to its server over an XML stream 4570 qualified by the 'jabber:client' namespace. 4572 1. A stanza with a specific intended recipient (e.g., a conversation 4573 partner, a remote service, the server itself, even another 4574 resource associated with the user's bare JID) MUST possess a 'to' 4575 attribute whose value is an XMPP address. 4577 2. A stanza sent from a client to a server for direct processing by 4578 the server (e.g., roster processing as described in [XMPP-IM] or 4579 presence sent to the server for broadcasting to other entities) 4580 MUST NOT possess a 'to' attribute. 4582 The following rules apply to inclusion of the 'to' attribute in 4583 stanzas sent from a server to a connected client over an XML stream 4584 qualified by the 'jabber:client' namespace. 4586 1. If the server has received the stanza from another connected 4587 client or from a peer server, the server MUST NOT modify the 'to' 4588 address before delivering the stanza to the client. 4590 2. If the server has itself generated the stanza (e.g., a response 4591 to an IQ stanza of type "get" or "set", even if the stanza did 4592 not include a 'to' address), the stanza MAY include a 'to' 4593 address, which MUST be the full JID of the client; however, if 4594 the stanza does not include a 'to' address then the client MUST 4595 treat it as if the 'to' address were included with a value of the 4596 client's full JID. 4598 Implementation Note: It is the server's responsibility to deliver 4599 only stanzas that are addressed to the client's full JID or the 4600 user's bare JID; thus there is no need for the client to check the 4601 'to' address of incoming stanzas. However, if the client does 4602 check the 'to' address then it is suggested to check at most the 4603 bare JID portion (not the full JID), since the 'to' address might 4604 be the user's bare JID, the client's current full JID, or even a 4605 full JID with a different resourcepart (e.g., in the case of so- 4606 called "offline messages" as described in [XEP-0160]). 4608 8.1.1.2. Server-to-Server Streams 4610 The following rules apply to inclusion of the 'to' attribute in the 4611 context of XML streams qualified by the 'jabber:server' namespace 4612 (i.e., server-to-server streams). 4614 1. A stanza MUST possess a 'to' attribute whose value is an XMPP 4615 address; if a server receives a stanza that does not meet this 4616 restriction, it MUST close the stream with an stream error (Section 4.9.3.7). 4619 2. The domainpart of the JID contained in the stanza's 'to' 4620 attribute MUST match the FQDN of the receiving server (or any 4621 validated domain thereof) as communicated via SASL negotiation 4622 (see Section 6), Server Dialback (see [XEP-0220]), or similar 4623 means; if a server receives a stanza that does not meet this 4624 restriction, it MUST close the stream with a 4625 stream error (Section 4.9.3.6) or a stream error 4626 (Section 4.9.3.5). 4628 8.1.2. from 4630 The 'from' attribute specifies the JID of the sender. 4632 4634 Art thou not Romeo, and a Montague? 4635 4637 8.1.2.1. Client-to-Server Streams 4639 The following rules apply to the 'from' attribute in the context of 4640 XML streams qualified by the 'jabber:client' namespace (i.e., client- 4641 to-server streams). 4643 1. When a server receives an XML stanza from a connected client, the 4644 server MUST add a 'from' attribute to the stanza or override the 4645 'from' attribute specified by the client, where the value of the 4646 'from' attribute MUST be the full JID 4647 () determined by the server for 4648 the connected resource that generated the stanza (see 4649 Section 4.3.6), or the bare JID () in the 4650 case of subscription-related presence stanzas (see [XMPP-IM]). 4652 2. When the server generates a stanza on its own behalf for delivery 4653 to the client from the server itself, the stanza MUST include a 4654 'from' attribute whose value is the bare JID (i.e., ) 4655 of the server as agreed upon during stream negotiation (e.g., 4656 based on the 'to' attribute of the initial stream header). 4658 3. When the server generates a stanza from the server for delivery 4659 to the client on behalf of the account of the connected client 4660 (e.g., in the context of data storage services provided by the 4661 server on behalf of the client), the stanza MUST either (a) not 4662 include a 'from' attribute or (b) include a 'from' attribute 4663 whose value is the account's bare JID (). 4665 4. A server MUST NOT send to the client a stanza without a 'from' 4666 attribute if the stanza was not generated by the server on its 4667 own behalf (e.g., if it was generated by another client or a peer 4668 server and the server is merely delivering it to the client on 4669 behalf of some other entity); therefore, when a client receives a 4670 stanza that does not include a 'from' attribute, it MUST assume 4671 that the stanza is from the user's account on the server. 4673 8.1.2.2. Server-to-Server Streams 4675 The following rules apply to the 'from' attribute in the context of 4676 XML streams qualified by the 'jabber:server' namespace (i.e., server- 4677 to-server streams). 4679 1. A stanza MUST possess a 'from' attribute whose value is an XMPP 4680 address; if a server receives a stanza that does not meet this 4681 restriction, it MUST close the stream with an stream error (Section 4.9.3.7). 4684 2. The domainpart of the JID contained in the stanza's 'from' 4685 attribute MUST match the FQDN of the sending server (or any 4686 validated domain thereof) as communicated via SASL negotiation 4687 (see Section 6), Server Dialback (see [XEP-0220]), or similar 4688 means; if a server receives a stanza that does not meet this 4689 restriction, it MUST close the stream with an 4690 stream error (Section 4.9.3.9). 4692 Enforcement of these rules helps to prevent certain denial of service 4693 attacks as described under Section 13.12. 4695 8.1.3. id 4697 The 'id' attribute is used by the originating entity to track any 4698 response or error stanza that it might receive in relation to the 4699 generated stanza from another entity (such as an intermediate server 4700 or the intended recipient). 4702 It is up to the originating entity whether the value of the 'id' 4703 attribute is unique only within its current stream or unique 4704 globally. 4706 For and stanzas, it is RECOMMENDED for the 4707 originating entity to include an 'id' attribute; for stanzas, 4708 it is REQUIRED. 4710 If the generated stanza includes an 'id' attribute then it is 4711 REQUIRED for the response or error stanza to also include an 'id' 4712 attribute, where the value of the 'id' attribute MUST match that of 4713 the generated stanza. 4715 The semantics of IQ stanzas impose additional restrictions as 4716 described under Section 8.2.3. 4718 8.1.4. type 4720 The 'type' attribute specifies the purpose or context of the message, 4721 presence, or IQ stanza. The particular allowable values for the 4722 'type' attribute vary depending on whether the stanza is a message, 4723 presence, or IQ stanza. The defined values for message and presence 4724 stanzas are specific to instant messaging and presence applications 4725 and therefore are defined in [XMPP-IM], whereas the values for IQ 4726 stanzas specify the part of the semantics for all structured request- 4727 response exchanges (no matter what the payload) and therefore are 4728 specified under Section 8.2.3. The only 'type' value common to all 4729 three kinds of stanzas is "error" as described under Section 8.3. 4731 8.1.5. xml:lang 4733 A stanza SHOULD possess an 'xml:lang' attribute (as defined in 4734 Section 2.12 of [XML]) if the stanza contains XML character data that 4735 is intended to be presented to a human user (as explained in 4736 [CHARSETS], "internationalization is for humans"). The value of the 4737 'xml:lang' attribute specifies the default language of any such 4738 human-readable XML character data. 4740 4741 dnd 4742 Wooing Juliet 4744 4746 The value of the 'xml:lang' attribute MAY be overridden by the 'xml: 4747 lang' attribute of a specific child element. 4749 4750 dnd 4751 Wooing Juliet 4752 Dvořím se Julii 4753 4761 dnd 4762 Wooing Juliet 4763 4765 S: 4768 dnd 4769 Wooing Juliet 4770 4772 If an inbound stanza received by a client or server does not possess 4773 an 'xml:lang' attribute, an implementation MUST assume that the 4774 default language is that specified for the entity's input stream as 4775 defined under Section 4.7.4. 4777 The value of the 'xml:lang' attribute MUST conform to the NMTOKEN 4778 datatype (as defined in Section 2.3 of [XML]) and MUST conform to the 4779 format defined in [LANGTAGS]. 4781 A server MUST NOT modify or delete 'xml:lang' attributes on stanzas 4782 it receives from other entities. 4784 8.2. Basic Semantics 4786 8.2.1. Message Semantics 4788 The stanza is a "push" mechanism whereby one entity pushes 4789 information to another entity, similar to the communications that 4790 occur in a system such as email. All message stanzas will possess a 4791 'to' attribute that specifies the intended recipient of the message 4792 (see Section 8.1.1 and Section 10.3), unless the message is being 4793 sent to the bare JID of a connected client's account. Upon receiving 4794 a message stanza with a 'to' address, a server SHOULD attempt to 4795 route or deliver it to the intended recipient (see Section 10 for 4796 general routing and delivery rules related to XML stanzas). 4798 8.2.2. Presence Semantics 4800 The stanza is a specialized "broadcast" or "publish- 4801 subscribe" mechanism, whereby multiple entities receive information 4802 (in this case, network availability information) about an entity to 4803 which they have subscribed. In general, a publishing client SHOULD 4804 send a presence stanza with no 'to' attribute, in which case the 4805 server to which the client is connected will broadcast that stanza to 4806 all subscribed entities. However, a publishing client MAY also send 4807 a presence stanza with a 'to' attribute, in which case the server 4808 will route or deliver that stanza to the intended recipient. 4809 Although the stanza is most often used by XMPP clients, 4810 it can also be used by servers, add-on services, and any other kind 4811 of XMPP entity. See Section 10 for general routing and delivery 4812 rules related to XML stanzas, and [XMPP-IM] for rules specific to 4813 presence applications. 4815 8.2.3. IQ Semantics 4817 Info/Query, or IQ, is a "request-response" mechanism, similar in some 4818 ways to the Hypertext Transfer Protocol [HTTP]. The semantics of IQ 4819 enable an entity to make a request of, and receive a response from, 4820 another entity. The data content of the request and response is 4821 defined by the schema or other structural definition associated with 4822 the XML namespace that qualifies the direct child element of the IQ 4823 element (see Section 8.4), and the interaction is tracked by the 4824 requesting entity through use of the 'id' attribute. Thus, IQ 4825 interactions follow a common pattern of structured data exchange such 4826 as get/result or set/result (although an error can be returned in 4827 reply to a request if appropriate): 4829 Requesting Responding 4830 Entity Entity 4831 ---------- ---------- 4832 | | 4833 | | 4834 | [ ... payload ... ] | 4835 | | 4836 | -------------------------> | 4837 | | 4838 | | 4839 | [ ... payload ... ] | 4840 | | 4841 | <------------------------- | 4842 | | 4843 | | 4844 | [ ... payload ... ] | 4845 | | 4846 | -------------------------> | 4847 | | 4848 | | 4849 | [ ... condition ... ] | 4850 | | 4851 | <------------------------- | 4852 | | 4854 Figure 5: Semantics of IQ Stanzas 4856 To enforce these semantics, the following rules apply: 4858 1. The 'id' attribute is REQUIRED for IQ stanzas. 4860 2. The 'type' attribute is REQUIRED for IQ stanzas. The value MUST 4861 be one of the following; if not, the recipient or an intermediate 4862 router MUST return a stanza error 4863 (Section 8.3.3.1). 4865 * get -- The stanza requests information, inquires about what 4866 data is needed in order to complete further operations, etc. 4868 * set -- The stanza provides data that is needed for an 4869 operation to be completed, sets new values, replaces existing 4870 values, etc. 4872 * result -- The stanza is a response to a successful get or set 4873 request. 4875 * error -- The stanza reports an error that has occurred 4876 regarding processing or delivery of a get or set request (see 4877 Section 8.3). 4879 3. An entity that receives an IQ request of type "get" or "set" MUST 4880 reply with an IQ response of type "result" or "error". The 4881 response MUST preserve the 'id' attribute of the request (or be 4882 empty if the generated stanza did not include an 'id' attribute). 4884 4. An entity that receives a stanza of type "result" or "error" MUST 4885 NOT respond to the stanza by sending a further IQ response of 4886 type "result" or "error"; however, the requesting entity MAY send 4887 another request (e.g., an IQ of type "set" to provide obligatory 4888 information discovered through a get/result pair). 4890 5. An IQ stanza of type "get" or "set" MUST contain exactly one 4891 child element, which specifies the semantics of the particular 4892 request. 4894 6. An IQ stanza of type "result" MUST include zero or one child 4895 elements. 4897 7. An IQ stanza of type "error" MAY include the child element 4898 contained in the associated "get" or "set" and MUST include an 4899 child; for details, see Section 8.3. 4901 8.3. Stanza Errors 4903 Stanza-related errors are handled in a manner similar to stream 4904 errors (Section 4.9). Unlike stream errors, stanza errors are 4905 recoverable; therefore they do not result in termination of the XML 4906 stream and underlying TCP connection. Instead, the entity that 4907 discovers the error condition returns an error stanza, which is a 4908 stanza that: 4910 o is of the same kind (message, presence, or IQ) as the generated 4911 stanza that triggered the error 4913 o has a 'type' attribute set to a value of "error" 4915 o typically swaps the 'from' and 'to' addresses of the generated 4916 stanza 4918 o mirrors the 'id' attribute (if any) of the generated stanza that 4919 triggered the error 4921 o contains an child element that specifies the error 4922 condition and therefore provides a hint regarding actions that the 4923 sender might be able to take in an effort to remedy the error 4924 (however, it is not always possible to remedy the error) 4926 8.3.1. Rules 4928 The following rules apply to stanza errors: 4930 1. The receiving or processing entity that detects an error 4931 condition in relation to a stanza SHOULD return an error stanza 4932 (and MUST do so for IQ stanzas). 4934 2. The error stanza SHOULD simply swap the 'from' and 'to' addresses 4935 from the generated stanza, unless doing so would (1) result in an 4936 information leak (see under Section 13.10) or other breach of 4937 security, or (2) force the sender of the error stanza to include 4938 a malformed JID in the 'from' or 'to' address of the error 4939 stanza. 4941 3. If the generated stanza was or and 4942 included an 'id' attribute then it is REQUIRED for the error 4943 stanza to also include an 'id' attribute. If the generated 4944 stanza was then the error stanza MUST include an 'id' 4945 attribute. In all cases, the value of the 'id' attribute MUST 4946 match that of the generated stanza (or be empty if the generated 4947 stanza did not include an 'id' attribute). 4949 4. An error stanza MUST contain an child element. 4951 5. The entity that returns an error stanza MAY pass along its JID to 4952 the sender of the generated stanza (e.g., for diagnostic or 4953 tracking purposes) through the addition of a 'by' attribute to 4954 the child element. 4956 6. The entity that returns an error stanza MAY include the original 4957 XML sent so that the sender can inspect and, if necessary, 4958 correct the XML before attempting to resend (however, this is a 4959 courtesy only and the originating entity MUST NOT depend on 4960 receiving the original payload); naturally, the entity MUST NOT 4961 include the original data if it not well-formed XML, violates the 4962 XML restrictions of XMPP (see under Section 11.1), or is 4963 otherwise harmful (e.g, exceeds a size limit). 4965 7. An child MUST NOT be included if the 'type' attribute 4966 has a value other than "error" (or if there is no 'type' 4967 attribute). 4969 8. An entity that receives an error stanza MUST NOT respond to the 4970 stanza with a further error stanza; this helps to prevent 4971 looping. 4973 8.3.2. Syntax 4975 The syntax for stanza-related errors is as follows, where XML data 4976 shown within the square brackets '[' and ']' is OPTIONAL, 'intended- 4977 recipient' is the JID of the entity to which the original stanza was 4978 addressed, 'sender' is the JID of the originating entity, and 'error- 4979 generator' is the entity that detects the fact that an error has 4980 occurred and thus returns an error stanza. 4982 4983 [OPTIONAL to include sender XML here] 4984 4986 4987 [ 4989 OPTIONAL descriptive text 4990 ] 4991 [OPTIONAL application-specific condition element] 4992 4993 4995 The "stanza-kind" MUST be one of message, presence, or iq. 4997 The "error-type" MUST be one of the following: 4999 o auth -- retry after providing credentials 5000 o cancel -- do not retry (the error cannot be remedied) 5001 o continue -- proceed (the condition was only a warning) 5002 o modify -- retry after changing the data sent 5003 o wait -- retry after waiting (the error is temporary) 5005 The "defined-condition" MUST correspond to one of the stanza error 5006 conditions defined under Section 8.3.3. However, because additional 5007 error conditions might be defined in the future, if an entity 5008 receives a stanza error condition that it does not understand then it 5009 MUST treat the unknown condition as equivalent to (Section 8.3.3.21). If the designers of an XMPP protocol 5011 extension or the developers of an XMPP implementation need to 5012 communicate a stanza error condition that is not defined in this 5013 specification, they can do so by defining an application-specific 5014 error condition element qualified by an application-specific 5015 namespace. 5017 The element: 5019 o MUST contain a defined condition element. 5021 o MAY contain a child element containing XML character data 5022 that describes the error in more detail; this element MUST be 5023 qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace 5024 and SHOULD possess an 'xml:lang' attribute specifying the natural 5025 language of the XML character data. 5027 o MAY contain a child element for an application-specific error 5028 condition; this element MUST be qualified by an application- 5029 specific namespace that defines the syntax and semantics of the 5030 element. 5032 The element is OPTIONAL. If included, it is to be used only 5033 to provide descriptive or diagnostic information that supplements the 5034 meaning of a defined condition or application-specific condition. It 5035 MUST NOT be interpreted programmatically by an application. It 5036 SHOULD NOT be used as the error message presented to a human user, 5037 but MAY be shown in addition to the error message associated with the 5038 defined condition element (and, optionally, the application-specific 5039 condition element). 5041 Interoperability Note: The syntax defined in [RFC3920] included a 5042 legacy 'code' attribute, whose semantics have been replaced by the 5043 defined condition elements; information about mapping defined 5044 condition elements to values of the legacy 'code' attribute can be 5045 found in [XEP-0086]. 5047 8.3.3. Defined Conditions 5049 The following conditions are defined for use in stanza errors. 5051 The error-type value that is RECOMMENDED for each defined condition 5052 is the usual expected type; however, in some circumstances a 5053 different type might be more appropriate. 5055 8.3.3.1. bad-request 5057 The sender has sent a stanza containing XML that does not conform to 5058 the appropriate schema or that cannot be processed (e.g., an IQ 5059 stanza that includes an unrecognized value of the 'type' attribute, 5060 or an element that is qualified by a recognized namespace but that 5061 violates the defined syntax for the element); the associated error 5062 type SHOULD be "modify". 5064 C: 5068 5069 5071 S: 5075 5076 5077 5078 5080 8.3.3.2. conflict 5082 Access cannot be granted because an existing resource exists with the 5083 same name or address; the associated error type SHOULD be "cancel". 5085 C: 5086 5087 balcony 5088 5089 5091 S: 5092 5093 5094 5095 5097 8.3.3.3. feature-not-implemented 5099 The feature represented in the XML stanza is not implemented by the 5100 intended recipient or an intermediate server and therefore the stanza 5101 cannot be processed (e.g., the entity understands the namespace but 5102 does not recognize the element name); the associated error type 5103 SHOULD be "cancel" or "modify". 5105 C: 5109 5110 5111 5112 5114 E: 5118 5119 5121 5124 5125 5127 8.3.3.4. forbidden 5129 The requesting entity does not possess the necessary permissions to 5130 perform an action that only certain authorized roles or individuals 5131 are allowed to complete (i.e., it typically relates to authorization 5132 rather than authentication); the associated error type SHOULD be 5133 "auth". 5135 C: 5139 5140 5142 E: 5147 5148 5149 5150 5152 8.3.3.5. gone 5154 The recipient or server can no longer be contacted at this address, 5155 typically on a permanent basis (as opposed to the error 5156 condition, which is used for temporary addressing failures); the 5157 associated error type SHOULD be "cancel" and the error stanza SHOULD 5158 include a new address (if available) as the XML character data of the 5159 element (which MUST be a Uniform Resource Identifier [URI] or 5160 Internationalized Resource Identifier [IRI] at which the entity can 5161 be contacted, typically an XMPP IRI as specified in [XMPP-URI]). 5163 C: 5168 Thy lips are warm. 5169 5171 S: 5176 5178 5179 xmpp:romeo@afterlife.example.net 5180 5181 5182 5184 8.3.3.6. internal-server-error 5186 The server has experienced a misconfiguration or other internal error 5187 that prevents it from processing the stanza; the associated error 5188 type SHOULD be "cancel". 5190 C: 5194 5195 5197 E: 5202 5203 5205 5206 5208 8.3.3.7. item-not-found 5210 The addressed JID or item requested cannot be found; the associated 5211 error type SHOULD be "cancel". 5213 C: 5217 S: 5221 5222 5223 5224 5226 Security Warning: An application MUST NOT return this error if 5227 doing so would provide information about the intended recipient's 5228 network availability to an entity that is not authorized to know 5229 such information (for a more detailed discussion of presence 5230 authorization, refer to the discussion of presence subscriptions 5231 in [XMPP-IM]); instead it MUST return a 5232 stanza error (Section 8.3.3.19). 5234 8.3.3.8. jid-malformed 5236 The sending entity has provided (e.g., during resource binding) or 5237 communicated (e.g., in the 'to' address of a stanza) an XMPP address 5238 or aspect thereof that violates the rules defined in [XMPP-ADDR]; the 5239 associated error type SHOULD be "modify". 5241 C: 5245 5246 5248 E: 5253 5255 5257 5258 5260 Implementation Note: Enforcement of the format for XMPP localparts 5261 is primarily the responsibility of the service at which the 5262 associated account or entity is located (e.g., the example.com 5263 service is responsible for returning errors 5264 related to all JIDs of the form ), whereas 5265 enforcement of the format for XMPP domainparts is primarily the 5266 responsibility of the service that seeks to route a stanza to the 5267 service identified by that domainpart (e.g., the example.org 5268 service is responsible for returning errors 5269 related to stanzas that users of that service have to tried send 5270 to JIDs of the form ). However, any entity 5271 that detects a malformed JID MAY return this error. 5273 8.3.3.9. not-acceptable 5275 The recipient or server understands the request but cannot process it 5276 because the request does not meet criteria defined by the recipient 5277 or server (e.g., a request to subscribe to information that does not 5278 simultaneously include configuration parameters needed by the 5279 recipient); the associated error type SHOULD be "modify". 5281 C: 5282 [ ... the-emacs-manual ... ] 5283 5285 S: 5286 5287 5289 5290 5292 8.3.3.10. not-allowed 5294 The recipient or server does not allow any entity to perform the 5295 action (e.g., sending to entities at a blacklisted domain); the 5296 associated error type SHOULD be "cancel". 5298 C: 5302 5303 5305 E: 5310 5311 5312 5313 5315 8.3.3.11. not-authorized 5317 The sender needs to provide credentials before being allowed to 5318 perform the action, or has provided improper credentials (the name 5319 "not-authorized", which was borrowed from the "401 Unauthorized" 5320 error of [HTTP], might lead the reader to think that this condition 5321 relates to authorization, but instead it is typically used in 5322 relation to authentication); the associated error type SHOULD be 5323 "auth". 5325 C: 5329 5330 5332 E: 5336 5337 5338 5339 5341 8.3.3.12. policy-violation 5343 The entity has violated some local service policy (e.g., a message 5344 contains words that are prohibited by the service) and the server MAY 5345 choose to specify the policy in the element or in an 5346 application-specific condition element; the associated error type 5347 SHOULD be "modify" or "wait" depending on the policy being violated. 5349 (In the following example, the client sends an XMPP message 5350 containing words that are forbidden according to the server's local 5351 service policy.) 5353 C: 5356 %#&@^!!! 5357 5359 S: 5362 5363 5365 5366 5368 8.3.3.13. recipient-unavailable 5370 The intended recipient is temporarily unavailable, undergoing 5371 maintenance, etc.; the associated error type SHOULD be "wait". 5373 C: 5377 5378 5380 E: 5384 5385 5387 5388 5390 Security Warning: An application MUST NOT return this error if 5391 doing so would provide information about the intended recipient's 5392 network availability to an entity that is not authorized to know 5393 such information (for a more detailed discussion of presence 5394 authorization, refer to the discussion of presence subscriptions 5395 in [XMPP-IM]); instead it MUST return a 5396 stanza error (Section 8.3.3.19). 5398 8.3.3.14. redirect 5400 The recipient or server is redirecting requests for this information 5401 to another entity, typically in a temporary fashion (as opposed to 5402 the error condition, which is used for permanent addressing 5403 failures); the associated error type SHOULD be "modify" and the error 5404 stanza SHOULD contain the alternate address in the XML character data 5405 of the element (which MUST be a URI or IRI with which the 5406 sender can communicate, typically an XMPP IRI as specified in 5407 [XMPP-URI]). 5409 C: 5413 5414 5416 E: 5421 5422 5423 xmpp:characters@conference.example.org 5424 5425 5426 5428 Security Warning: An application receiving a stanza-level redirect 5429 SHOULD warn a human user of the redirection attempt and request 5430 approval before proceeding to communicate with the entity whose 5431 address is contained in the XML character data of the 5432 element, because that entity might have a different identity or 5433 might enforce different security policies. The end-to-end 5434 authentication or signing of XMPP stanzas could help to mitigate 5435 this risk, since it would enable the sender to determine if the 5436 entity to which it has been redirected has the same identity as 5437 the entity it originally attempted to contact. An application MAY 5438 have a policy of following redirects only if it has authenticated 5439 the receiving entity. In addition, an application SHOULD abort 5440 the communication attempt after a certain number of successive 5441 redirects (e.g., at least 2 but no more than 5). 5443 8.3.3.15. registration-required 5445 The requesting entity is not authorized to access the requested 5446 service because prior registration is necessary (examples of prior 5447 registration include members-only rooms in XMPP multi-user chat 5448 [XEP-0045] and gateways to non-XMPP instant messaging services, which 5449 traditionally required registration in order to use the gateway 5450 [XEP-0100]); the associated error type SHOULD be "auth". 5452 C: 5456 5457 5459 E: 5463 5464 5466 5467 5469 8.3.3.16. remote-server-not-found 5471 A remote server or service specified as part or all of the JID of the 5472 intended recipient does not exist or cannot be resolved (e.g., there 5473 is no _xmpp-server._tcp DNS SRV record, the A or AAAA fallback 5474 resolution fails, or A/AAAA lookups succeed but there is no response 5475 on the IANA-registered port 5269); the associated error type SHOULD 5476 be "cancel". 5478 C: 5483 yt? 5484 5486 E: 5491 5492 5494 5495 5497 8.3.3.17. remote-server-timeout 5499 A remote server or service specified as part or all of the JID of the 5500 intended recipient (or needed to fulfill a request) was resolved but 5501 communications could not be established within a reasonable amount of 5502 time (e.g., an XML stream cannot be established at the resolved IP 5503 address and port, or an XML stream can be established but stream 5504 negotiation fails because of problems with TLS, SASL, Server 5505 Dialback, etc.); the associated error type SHOULD be "wait" (unless 5506 the error is of a more permanent nature, e.g., the remote server is 5507 found but it cannot be authenticated or it violates security 5508 policies). 5510 C: 5515 yt? 5516 5518 E: 5523 5524 5526 5527 5529 8.3.3.18. resource-constraint 5531 The server or recipient is busy or lacks the system resources 5532 necessary to service the request; the associated error type SHOULD be 5533 "wait". 5535 C: 5539 5540 5541 5542 5544 E: 5548 5549 5551 5552 5554 8.3.3.19. service-unavailable 5556 The server or recipient does not currently provide the requested 5557 service; the associated error type SHOULD be "cancel". 5559 C: 5561 Hello? 5562 5564 S: 5566 5567 5569 5570 5572 Security Warning: An application MUST return a stanza error (Section 8.3.3.19) instead of (Section 8.3.3.7) or 5575 (Section 8.3.3.13) if sending one of the latter errors would 5576 provide information about the intended recipient's network 5577 availability to an entity that is not authorized to know such 5578 information (for a more detailed discussion of presence 5579 authorization, refer to [XMPP-IM]). 5581 8.3.3.20. subscription-required 5583 The requesting entity is not authorized to access the requested 5584 service because a prior subscription is necessary (examples of prior 5585 subscription include authorization to receive presence information as 5586 defined in [XMPP-IM] and opt-in data feeds for XMPP publish-subscribe 5587 as defined in [XEP-0060]); the associated error type SHOULD be 5588 "auth". 5590 C: 5595 ACT II, SCENE II 5596 help, I forgot my lines! 5597 5599 E: 5604 5605 5607 5608 5610 8.3.3.21. undefined-condition 5612 The error condition is not one of those defined by the other 5613 conditions in this list; any error type can be associated with this 5614 condition, and it SHOULD NOT used except in conjunction with an 5615 application-specific condition. 5617 C: 5621 My lord, dispatch; read o'er these articles. 5622 5623 5626 5628 S: 5632 5636 5639 5640 5641 5643 5644 5647 5648 5649 5651 8.3.3.22. unexpected-request 5653 The recipient or server understood the request but was not expecting 5654 it at this time (e.g., the request was out of order); the associated 5655 error type SHOULD be "wait" or "modify". 5657 C: 5661 5662 5665 5666 5668 E: 5672 5673 5675 5677 5678 5680 8.3.4. Application-Specific Conditions 5682 As noted, an application MAY provide application-specific stanza 5683 error information by including a properly-namespaced child within the 5684 error element. Typically, the application-specific element 5685 supplements or further qualifies a defined element. Thus, the 5686 element will contain two or three child elements. 5688 5689 5690 5691 5692 5693 5694 5695 5696 5698 5700 [ ... application-specific information ... ] 5701 5702 5703 5704 5706 An entity that receives an application-specific error condition it 5707 does not understand MUST ignore that condition but appropriately 5708 process the rest of the error stanza. 5710 8.4. Extended Content 5712 Although the message, presence, and IQ stanzas provide basic 5713 semantics for messaging, availability, and request-response 5714 interactions, XMPP uses XML namespaces (see [XML-NAMES]) to extend 5715 the basic stanza syntax for the purpose of providing additional 5716 functionality. 5718 A message or presence stanza MAY contain one or more optional child 5719 elements specifying content that extends the meaning of the message 5720 (e.g., an XHTML-formatted version of the message body as described in 5721 [XEP-0071]), and an IQ stanza of type "get" or "set" MUST contain one 5722 such child element. Such a child element MAY have any name and MUST 5723 possess a namespace declaration (other than "jabber:client", "jabber: 5724 server", or "http://etherx.jabber.org/streams") that defines the data 5725 contained within the child element. Such a child element is called 5726 an "extension element". An extension element can be included either 5727 at the direct child level of the stanza or in any mix of levels. 5729 Similarly, "extension attributes" are allowed. That is: a stanza 5730 itself (i.e., an , , or element qualified 5731 by the "jabber:client" or "jabber:server" content namespace) or any 5732 child element of such a stanza (whether an extension element or a 5733 child element qualified by the content namespace) MAY also include 5734 one or more attributes qualified by XML namespaces other than the 5735 content namespace or the reserved 5736 "http://www.w3.org/XML/1998/namespace" namespace (including the so- 5737 called "empty namespace" if the attribute is not prefixed as 5738 described under [XML-NAMES]). 5740 Interoperability Note: For the sake of backward compatibility and 5741 maximum interoperability, an entity that generates a stanza SHOULD 5742 NOT include such attributes in the stanza itself or in child 5743 elements of the stanza that are qualified by the content 5744 namespaces "jabber:client" or "jabber:server" (e.g., the 5745 child of the stanza). 5747 An extension element or extension attribute is said to be "extended 5748 content" and the qualifying namespace for such an element or 5749 attribute is said to be an "extended namespace". 5751 Informational Note: Although extended namespaces for XMPP are 5752 commonly defined by the XMPP Standards Foundation (XSF) and by the 5753 IETF, no specification or IETF standards action is necessary to 5754 define extended namespaces, and any individual or organization is 5755 free to define XMPP extensions. 5757 To illustrate these concepts, several examples follow. 5759 The following stanza contains one direct child element whose extended 5760 namespace is 'jabber:iq:roster': 5762 5765 5766 5768 The following stanza contains two direct child elements with two 5769 different extended namespaces. 5771 5772 5776 5777 sha1-hash-of-image 5778 5779 5781 The following stanza contains two child elements, one of which is 5782 qualified by the "jabber:client" or "jabber:server" content namespace 5783 and one of which is qualified by an extended namespace; the extension 5784 element in turn contains a child element that is qualified by a 5785 different extended namespace. 5787 5788 Hello? 5789 5790 5791

Hello? 5792 5793 5794 5796 It is conventional in the XMPP community for implementations to not 5797 generate namespace prefixes for elements that are qualified by 5798 extended namespaces (in the XML community, this convention is 5799 sometimes called "prefix-free canonicalization"). However, if an 5800 implementation generates such namespace prefixes then it MUST include 5801 the namespace declaration in the stanza itself or a child element of 5802 the stanza, not in the stream header (see Section 4.8.4). 5804 Routing entities (typically servers) SHOULD try to maintain prefixes 5805 when serializing XML stanzas for processing, but receiving entities 5806 MUST NOT depend on the prefix strings to have any particular value 5807 (the allowance for the 'stream' prefix, described under 5808 Section 4.8.5, is an exception to this rule, albeit for streams 5809 rather than stanzas). 5811 Support for any given extended namespace is OPTIONAL on the part of 5812 any implementation. If an entity does not understand such a 5813 namespace, the entity's expected behavior depends on whether the 5814 entity is (1) the recipient or (2) a server that is routing or 5815 delivering the stanza to the recipient. 5817 If a recipient receives a stanza that contains an element or 5818 attribute it does not understand, it MUST NOT attempt to process that 5819 XML data and instead MUST proceed as follows. 5821 o If an intended recipient receives a message stanza whose only 5822 child element is qualified by a namespace it does not understand, 5823 then depending on the XMPP application it MUST either ignore the 5824 entire stanza or return a stanza error, which SHOULD be (Section 8.3.3.19). 5827 o If an intended recipient receives a presence stanza whose only 5828 child element is qualified by a namespace it does not understand, 5829 then it MUST ignore the child element by treating the presence 5830 stanza as if it contained no child element. 5832 o If an intended recipient receives a message or presence stanza 5833 that contains XML data qualified by a namespace it does not 5834 understand, then it MUST ignore the portion of the stanza 5835 qualified by the unknown namespace. 5837 o If an intended recipient receives an IQ stanza of type "get" or 5838 "set" containing a child element qualified by a namespace it does 5839 not understand, then the entity MUST return an IQ stanza of type 5840 "error" with an error condition of . 5842 If a server handles a stanza that is intended for delivery to another 5843 entity and that contains a child element it does not understand, it 5844 MUST route the stanza unmodified to a remote server or deliver the 5845 stanza unmodified to a connected client associated with a local 5846 account. 5848 9. Detailed Examples 5850 The detailed examples in this section further illustrate the 5851 protocols defined in this specification. 5853 9.1. Client-to-Server Examples 5855 The following examples show the XMPP data flow for a client 5856 negotiating an XML stream with a server, exchanging XML stanzas, and 5857 closing the negotiated stream. The server is "im.example.com", the 5858 server requires use of TLS, the client authenticates via the SASL 5859 SCRAM-SHA-1 mechanism as , and the client 5860 binds a client-submitted resource to the stream. It is assumed that 5861 before sending the initial stream header, the client has already 5862 resolved an SRV record of _xmpp-client._tcp.im.example.com and has 5863 opened a TCP connection to the advertised port at the resolved IP 5864 address. 5866 9.1.1. TLS 5868 Step 1: Client initiates stream to server: 5870 C: 5878 Step 2: Server responds by sending a response stream header to 5879 client: 5881 S: 5890 Step 3: Server sends stream features to client (only the STARTTLS 5891 extension at this point, which is mandatory-to-negotiate): 5893 S: 5894 5895 5896 5897 5899 Step 4: Client sends STARTTLS command to server: 5901 C: 5903 Step 5: Server informs client that it is allowed to proceed: 5905 S: 5907 Step 5 (alt): Server informs client that STARTTLS negotiation has 5908 failed, closes the XML stream, and terminates the TCP connection 5909 (thus the stream negotiation process ends unsuccessfully and the 5910 parties do not move on to the next step): 5912 S: 5913 5915 Step 6: Client and server attempt to complete TLS negotiation over 5916 the existing TCP connection (see [TLS] for details). 5918 Step 7: If TLS negotiation is successful, client initiates a new 5919 stream to server over the TLS-protected TCP connection: 5921 C: 5929 Step 7 (alt): If TLS negotiation is unsuccessful, server closes TCP 5930 connection (thus the stream negotiation process ends unsuccessfully 5931 and the parties do not move on to the next step): 5933 9.1.2. SASL 5935 Step 8: Server responds by sending a stream header to client along 5936 with any available stream features: 5938 S: 5947 S: 5948 5949 SCRAM-SHA-1-PLUS 5950 SCRAM-SHA-1 5951 PLAIN 5952 5953 5955 Step 9: Client selects an authentication mechanism, in this case 5956 SCRAM-SHA-1, including initial response data: 5958 C: 5960 biwsbj1qdWxpZXQscj1vTXNUQUF3QUFBQU1BQUFBTlAwVEFBQUFBQUJQVTBBQQ== 5961 5963 The decoded base 64 data is 5964 "n,,n=juliet,r=oMsTAAwAAAAMAAAANP0TAAAAAABPU0AA". 5966 Step 10: Server sends a challenge: 5968 S: 5969 cj1vTXNUQUF3QUFBQU1BQUFBTlAwVEFBQUFBQUJQVTBBQWUxMjQ2OTViLTY5Y 5970 TktNGRlNi05YzMwLWI1MWIzODA4YzU5ZSxzPU5qaGtZVE0wTURndE5HWTBaaT 5971 AwTmpkbUxUa3hNbVV0TkRsbU5UTm1ORE5rTURNeixpPTQwOTY= 5972 5974 The decoded base 64 data is "r=oMsTAAwAAAAMAAAANP0TAAAAAABPU0AAe12469 5975 5b-69a9-4de6-9c30- 5976 b51b3808c59e,s=NjhkYTM0MDgtNGY0Zi00NjdmLTkxMmUtNDlmNTNmNDNkMDMz,i=409 5977 6" (line breaks not included in actual data). 5979 Step 11: Client sends a response: 5981 C: 5982 Yz1iaXdzLHI9b01zVEFBd0FBQUFNQUFBQU5QMFRBQUFBQUFCUFUwQUFlMTI0N 5983 jk1Yi02OWE5LTRkZTYtOWMzMC1iNTFiMzgwOGM1OWUscD1VQTU3dE0vU3ZwQV 5984 RCa0gyRlhzMFdEWHZKWXc9 5985 5987 The decoded base 64 data is "c=biws, r=oMsTAAwAAAAMAAAANP0TAAAAAABPU0 5988 AAe124695b-69a9-4de6-9c30-b51b3808c59e, p=UA57tM/ 5989 SvpATBkH2FXs0WDXvJYw=" (line breaks not included in actual data). 5991 Step 12: Server informs client of success, including additional data 5992 with success: 5994 S: 5995 dj1wTk5ERlZFUXh1WHhDb1NFaVc4R0VaKzFSU289 5996 5998 The decoded base 64 data is "v=pNNDFVEQxuXxCoSEiW8GEZ+1RSo=". 6000 Step 12 (alt): Server returns a SASL error to client (thus the stream 6001 negotiation process ends unsuccessfully and the parties do not move 6002 on to the next step): 6004 S: 6005 6006 6007 6009 Step 13: Client initiates a new stream to server: 6011 C: 6019 9.1.3. Resource Binding 6021 Step 14: Server responds by sending a stream header to client along 6022 with supported features (in this case resource binding): 6024 S: 6033 S: 6034 6035 6037 Upon being informed that resource binding is mandatory-to-negotiate, 6038 the client needs to bind a resource to the stream; here we assume 6039 that the client submits a human-readable text string. 6041 Step 15: Client binds a resource: 6043 C: 6044 6045 balcony 6046 6047 6049 Step 16: Server accepts submitted resourcepart and informs client of 6050 successful resource binding: 6052 S: 6053 6054 6055 juliet@im.example.com/balcony 6056 6057 6058 6060 Step 16 (alt): Server returns error to client (thus the stream 6061 negotiation process ends unsuccessfully and the parties do not move 6062 on to the next step): 6064 S: 6065 6066 6067 6068 6070 9.1.4. Stanza Exchange 6072 Now the client is allowed to send XML stanzas over the negotiated 6073 stream. 6075 C: 6080 Art thou not Romeo, and a Montague? 6081 6083 If necessary, sender's server negotiates XML streams with intended 6084 recipient's server (see Section 9.2). 6086 The intended recipient replies and the message is delivered to the 6087 client. 6089 E: 6094 Neither, fair saint, if either thee dislike. 6095 6097 The client can subsequently send and receive an unbounded number of 6098 subsequent XML stanzas over the stream. 6100 9.1.5. Close 6102 Desiring to send no further messages, the client closes its stream to 6103 the server but waits for incoming data from the server. 6105 C: 6107 Consistent with Section 4.4, the server might send additional data to 6108 the client and then closes its stream to the client. 6110 S: 6112 The client now sends a TLS close_notify alert, receives a responding 6113 close_notify alert from the server, and then terminates the 6114 underlying TCP connection. 6116 9.2. Server-to-Server Examples 6118 The following examples show the data flow for a server negotiating an 6119 XML stream with a peer server, exchanging XML stanzas, and closing 6120 the negotiated stream. The initiating server ("Server1") is 6121 im.example.com; the receiving server ("Server2") is example.net and 6122 it requires use of TLS; im.example.com presents a certificate and 6123 authenticates via the SASL EXTERNAL mechanism. It is assumed that 6124 before sending the initial stream header, Server1 has already 6125 resolved an SRV record of _xmpp-server._tcp.example.net and has 6126 opened a TCP connection to the advertised port at the resolved IP 6127 address. Note how Server1 declares the content namespace "jabber: 6128 server" as the default namespace and uses prefixes for stream-related 6129 elements, whereas Server2 uses prefix-free canonicalization. 6131 9.2.1. TLS 6133 Step 1: Server1 initiates stream to Server2: 6135 S1: 6142 Step 2: Server2 responds by sending a response stream header to 6143 Server1: 6145 S2: 6152 Step 3: Server2 sends stream features to Server1 (only the STARTTLS 6153 extension at this point, which is mandatory-to-negotiate): 6155 S2: 6156 6157 6158 6159 6161 Step 4: Server1 sends the STARTTLS command to Server2: 6163 S1: 6165 Step 5: Server2 informs Server1 that it is allowed to proceed: 6167 S2: 6169 Step 5 (alt): Server2 informs Server1 that STARTTLS negotiation has 6170 failed, closes the stream, and terminates the TCP connection (thus 6171 the stream negotiation process ends unsuccessfully and the parties do 6172 not move on to the next step): 6174 S2: 6175 6177 Step 6: Server1 and Server2 attempt to complete TLS negotiation via 6178 TCP (see [TLS] for details). 6180 Step 7: If TLS negotiation is successful, Server1 initiates a new 6181 stream to Server2 over the TLS-protected TCP connection: 6183 S1: 6190 Step 7 (alt): If TLS negotiation is unsuccessful, Server2 closes TCP 6191 connection (thus the stream negotiation process ends unsuccessfully 6192 and the parties do not move on to the next step). 6194 9.2.2. SASL 6196 Step 8: Server2 sends a response stream header to Server1 along with 6197 available stream features (including a preference for the SASL 6198 EXTERNAL mechanism): 6200 S2: 6207 S2: 6208 6209 EXTERNAL 6210 6211 6213 Step 9: Server1 selects the EXTERNAL mechanism (including an empty 6214 response of "="): 6216 S1: = 6219 Step 10: Server2 returns success: 6221 S2: 6223 Step 10 (alt): Server2 informs Server1 of failed authentication (thus 6224 the stream negotiation process ends unsuccessfully and the parties do 6225 not move on to the next step): 6227 S2: 6228 6229 6230 6232 Step 11: Server1 initiates a new stream to Server2: 6234 S1: 6241 Step 12: Server2 responds by sending a stream header to Server1 along 6242 with any additional features (or, in this case, an empty features 6243 element): 6245 S2: 6252 S2: 6254 9.2.3. Stanza Exchange 6256 Now Server1 is allowed to send XML stanzas to Server2 over the 6257 negotiated stream from im.example.com to example.net; here we assume 6258 that the transferred stanzas are those shown earlier for client-to- 6259 server communication, albeit over a server-to-server stream qualified 6260 by the 'jabber:server' namespace. 6262 Server1 sends XML stanza to Server2: 6264 S1: 6269 Art thou not Romeo, and a Montague? 6270 6272 9.2.4. Close 6274 Desiring to send no further messages, Server1 closes its stream to 6275 Server2 but waits for incoming data from Server2. (In practice, the 6276 stream would most likely remain open for some time, since Server1 and 6277 Server2 do not immediately know if the stream will be needed for 6278 further communication.) 6279 S1: 6281 Consistent with the recommended stream closing handshake, Server2 6282 closes the stream as well: 6284 S2: 6286 Server1 now sends a TLS close_notify alert, receives a responding 6287 close_notify alert from Server2, and then terminates the underlying 6288 TCP connection. 6290 10. Server Rules for Processing XML Stanzas 6292 Each server implementation will contain its own logic for processing 6293 stanzas it receives. Such logic determines whether the server needs 6294 to route a given stanza to another domain, deliver it to a local 6295 entity (typically a connected client associated with a local 6296 account), or handle it directly within the server itself. This 6297 section provides general rules for processing XML stanzas. However, 6298 particular XMPP applications MAY specify delivery rules that modify 6299 or supplement the following rules (e.g., a set of delivery rules for 6300 instant messaging and presence applications is defined in [XMPP-IM]). 6302 10.1. In-Order Processing 6304 An XMPP server MUST ensure in-order processing of the stanzas and 6305 other XML elements it receives over a given input stream from a 6306 connected client or remote server. 6308 In-order processing applies (a) to any XML elements used to negotiate 6309 and manage XML streams, and (b) to all uses of XML stanzas, including 6310 but not limited to the following: 6312 1. Stanzas sent by a client to its server or to its own bare JID for 6313 direct processing by the server (e.g., in-order processing of a 6314 roster get and initial presence as described in [XMPP-IM]). 6316 2. Stanzas sent by a connected client and intended for delivery to 6317 another entity associated with the server (e.g., stanzas 6318 addressed from to 6319 ). The server MUST ensure that it delivers 6320 stanzas addressed to the intended recipient in the order it 6321 receives them over the input stream from the sending client, 6322 treating stanzas addressed to the bare JID and the full JID of 6323 the intended recipient as equivalent for delivery purposes. 6325 3. Stanzas sent by a connected client and intended for delivery to 6326 an entity located at a remote domain (e.g., stanzas addressed 6327 from to ). The 6328 routing server MUST ensure that it routes stanzas addressed to 6329 the intended recipient in the order it receives them over the 6330 input stream from the sending client, treating stanzas addressed 6331 to the bare JID and the full JID of the intended recipient as 6332 equivalent for routing purposes. To help ensure in-order 6333 processing, the routing server MUST route such stanzas over a 6334 single output stream to the remote domain, rather than sending 6335 some stanzas over one server-to-server stream and other stanzas 6336 over another server-to-server stream. 6338 4. Stanzas routed from one server to another server for delivery to 6339 an entity associated with the remote domain (e.g., stanzas 6340 addressed from to and 6341 routed by over a server-to-server stream to 6342 ). The delivering server MUST ensure that it 6343 delivers stanzas to the intended recipient in the order it 6344 receives them over the input stream from the routing server, 6345 treating stanzas addressed to the bare JID and the full JID of 6346 the intended recipient as equivalent for delivery purposes. 6348 5. Stanzas sent by one server to another server for direct 6349 processing by the server that is hosting the remote domain (e.g., 6350 stanzas addressed from to ). 6352 If the server's processing of a particular request could have an 6353 effect on its processing of subsequent data it might receive over 6354 that input stream (e.g., enforcement of communication policies), it 6355 MUST suspend processing of subsequent data until it has processed the 6356 request. 6358 In-order processing applies only to a single input stream. Therefore 6359 a server is not responsible for ensuring the coherence of data it 6360 receives across multiple input streams associated with the same local 6361 account (e.g., stanzas received over two different input streams from 6362 and ) 6363 or the same remote domain (e.g., two different input streams 6364 negotiated by a remote domain; however, a server MAY close the stream 6365 with a stream error (Section 4.9.3.3) if a remote server 6366 attempts to negotiate more than one stream, as described under 6367 Section 4.9.3.3). 6369 10.2. General Considerations 6371 At high level, there are three primary considerations at play in 6372 server processing of XML stanzas, which sometimes are at odds but 6373 need to be managed in a consistent way: 6375 1. It is good to deliver a stanza to the intended recipient if 6376 possible. 6378 2. If a stanza cannot be delivered, it is helpful to inform the 6379 sender. 6381 3. It is bad to facilitate directory harvesting attacks 6382 (Section 13.11) and presence leaks (Section 13.10.2). 6384 With regarding to possible delivery-related attacks, the following 6385 points need to be kept in mind: 6387 1. From the perspective of an attacker, there is little if any 6388 effective difference between the server's (i) delivering the 6389 stanza or storing it offline for later delivery (see [XMPP-IM]) 6390 and (ii) silently ignoring it (because an error is not returned 6391 immediately in any of those cases); therefore, in scenarios where 6392 a server delivers a stanza or places the stanza into offline 6393 storage for later delivery, it needs to silently ignore the 6394 stanza if that account does not exist. 6396 2. How a server processes stanzas sent to the bare JID 6397 has implications for directory harvesting, 6398 because an attacker could determine whether an account exists if 6399 the server responds differently depending on whether there there 6400 is an account for a given bare JID. 6402 3. How a server processes stanzas sent to a full JID has 6403 implications for presence leaks, because an attacker could send 6404 requests to multiple full JIDs and receive different replies 6405 depending on whether the user has a device currently online at 6406 that full JID. The use of randomized resourceparts (whether 6407 generated by the client or the server as described under 6408 Section 7) significantly helps to mitigate this attack, so it is 6409 of somewhat lesser concern than the directory harvesting attack. 6411 Naturally, presence is not leaked if the entity to which a user's 6412 server returns an error already knows the user's presence or is 6413 authorized to do so (e.g., by means of a presence subscription or 6414 directed presence), and a server does not enable a directory 6415 harvesting attack if it returns an error to an entity that already 6416 knows if a user exists (e.g., because the entity is in the user's 6417 contact list); these matters are discussed more fully in [XMPP-IM]. 6419 10.3. No 'to' Address 6421 If the stanza possesses no 'to' attribute, the server MUST handle it 6422 directly on behalf of the entity that sent it, where the meaning of 6423 "handle it directly" depends on whether the stanza is message, 6424 presence, or IQ. Because all stanzas received from other servers 6425 MUST possess a 'to' attribute, this rule applies only to stanzas 6426 received from a local entity (typically a client) that is connected 6427 to the server. 6429 10.3.1. Message 6431 If the server receives a message stanza with no 'to' attribute, it 6432 MUST treat the message as if the 'to' address were the bare JID 6433 of the sending entity. 6435 10.3.2. Presence 6437 If the server receives a presence stanza with no 'to' attribute, it 6438 MUST broadcast it to the entities that are subscribed to the sending 6439 entity's presence, if applicable ([XMPP-IM] defines the semantics of 6440 such broadcasting for presence applications). 6442 10.3.3. IQ 6444 If the server receives an IQ stanza with no 'to' attribute, it MUST 6445 process the stanza on behalf of the account from which received the 6446 stanza, as follows: 6448 1. If the IQ stanza is of type "get" or "set" and the server 6449 understands the namespace that qualifies the payload, the server 6450 MUST handle the stanza on behalf of the sending entity or return 6451 an appropriate error to the sending entity. Although the meaning 6452 of "handle" is determined by the semantics of the qualifying 6453 namespace, in general the server will respond to the IQ stanza of 6454 type "get" or "set" by returning an appropriate IQ stanza of type 6455 "result" or "error", responding as if the server were the bare 6456 JID of the sending entity. As an example, if the sending entity 6457 sends an IQ stanza of type "get" where the payload is qualified 6458 by the 'jabber:iq:roster' namespace (as described in [XMPP-IM]), 6459 then the server will return the roster associated with the 6460 sending entity's bare JID to the particular resource of the 6461 sending entity that requested the roster. 6463 2. If the IQ stanza is of type "get" or "set" and the server does 6464 not understand the namespace that qualifies the payload, the 6465 server MUST return an error to the sending entity, which MUST be 6466 . 6468 3. If the IQ stanza is of type "error" or "result", the server MUST 6469 handle the error or result in accordance with the payload of the 6470 associated IQ stanza or type "get" or "set" (if there is no such 6471 associated stanza, the server MUST ignore the error or result 6472 stanza). 6474 10.4. Remote Domain 6476 If the domainpart of the JID contained in the 'to' attribute does not 6477 match one of the configured FQDNs of the server, the server SHOULD 6478 attempt to route the stanza to the remote domain (subject to local 6479 service provisioning and security policies regarding inter-domain 6480 communication, since such communication is OPTIONAL for any given 6481 deployment). As described in the following sections, there are two 6482 possible cases. 6484 Security Warning: These rules apply only client-to-server streams. 6485 As described under Section 8.1.1.2, a server MUST NOT accept a 6486 stanza over a server-to-server stream if the domainpart of the JID 6487 in the 'to' attribute does not match an FQDN serviced by the 6488 receiving server. 6490 10.4.1. Existing Stream 6492 If a server-to-server stream already exists between the two domains, 6493 the sender's server SHOULD attempt to route the stanza to the 6494 authoritative server for the remote domain over the existing stream. 6496 10.4.2. No Existing Stream 6498 If there exists no server-to-server stream between the two domains, 6499 the sender's server will proceed as follows: 6501 1. Resolve the FQDN of the remote domain (as described under 6502 Section 13.9.2). 6504 2. Negotiate a server-to-server stream between the two domains (as 6505 defined under Section 5 and Section 6). 6507 3. Route the stanza to the authoritative server for the remote 6508 domain over the newly-established stream. 6510 10.4.3. Error Handling 6512 If routing of a stanza to the intended recipient's server is 6513 unsuccessful, the sender's server MUST return an error to the sender. 6514 If resolution of the remote domain is unsuccessful, the stanza error 6515 MUST be (Section 8.3.3.16). If resolution 6516 succeeds but streams cannot be negotiated, the stanza error MUST be 6517 (Section 8.3.3.17). 6519 If stream negotiation with the intended recipient's server is 6520 successful but the remote server cannot deliver the stanza to the 6521 recipient, the remote server MUST return an appropriate error to the 6522 sender by way of the sender's server. 6524 10.5. Local Domain 6526 If the domainpart of the JID contained in the 'to' attribute matches 6527 one of the configured FQDNs of the server, the server MUST first 6528 determine if the FQDN is serviced by the server itself or by a 6529 specialized local service. If the latter, the server MUST route the 6530 stanza to that service. If the former, the server MUST proceed as 6531 follows. However, the server MUST NOT route or "forward" the stanza 6532 to another domain, because it is the server's responsibility to 6533 process all stanzas for which the domainpart of the 'to' address 6534 matches one of the configured FQDNs of the server (among other 6535 things, this helps to prevent looping). 6537 10.5.1. domainpart 6539 If the JID contained in the 'to' attribute is of the form 6540 , then the server MUST either (a) handle the stanza as 6541 appropriate for the stanza kind or (b) return an error stanza to the 6542 sender. 6544 10.5.2. domainpart/resourcepart 6546 If the JID contained in the 'to' attribute is of the form 6547 , then the server MUST either (a) handle the 6548 stanza as appropriate for the stanza kind or (b) return an error 6549 stanza to the sender. 6551 10.5.3. localpart@domainpart 6553 An address of this type is normally associated with an account on the 6554 server. The following rules provide some general guidelines; more 6555 detailed rules in the context of instant messaging and presence 6556 applications are provided in [XMPP-IM]. 6558 10.5.3.1. No Such User 6560 If there is no local account associated with the 6561 , how the stanza is processed depends on the 6562 stanza type. 6564 o For a message stanza, the server MUST either (a) silently ignore 6565 the stanza or (b) return a stanza error 6566 (Section 8.3.3.19) to the sender. 6568 o For a presence stanza, the server SHOULD ignore the stanza (or 6569 behave as described in [XMPP-IM]). 6571 o For an IQ stanza, the server MUST return a 6572 stanza error (Section 8.3.3.19) to the sender. 6574 10.5.3.2. User Exists 6576 If the JID contained in the 'to' attribute is of the form 6577 , how the stanza is processed depends on the 6578 stanza type. 6580 o For a message stanza, if there exists at least one connected 6581 resource for the account then the server SHOULD deliver it to at 6582 least one of the connected resources. If there exists no 6583 connected resource then the server MUST either (a) store the 6584 message offline for delivery when the account next has a connected 6585 resource or (b) return a stanza error 6586 (Section 8.3.3.19). 6588 o For a presence stanza, if there exists at least one connected 6589 resource that has sent initial presence (i.e., has a "presence 6590 session" as defined in [XMPP-IM]) then the server SHOULD deliver 6591 it to such resources. If there exists no connected resource then 6592 the server SHOULD ignore the stanza (or behave as described in 6593 [XMPP-IM]). 6595 o For an IQ stanza, the server MUST handle it directly on behalf of 6596 the intended recipient. 6598 10.5.4. localpart@domainpart/resourcepart 6600 If the JID contained in the 'to' attribute is of the form 6601 and the user exists but there is 6602 no connected resource that exactly matches the full JID, the stanza 6603 SHOULD be processed as if the JID were of the form 6604 as described under Section 10.5.3.2. 6606 If the JID contained in the 'to' attribute is of the form 6607 , the user exists, and there is a 6608 connected resource that exactly matches the full JID, the server MUST 6609 deliver the stanza to that connected resource. 6611 11. XML Usage 6613 11.1. XML Restrictions 6615 XMPP defines a class of data objects called XML streams as well as 6616 the behavior of computer programs that process XML streams. XMPP is 6617 an application profile or restricted form of the Extensible Markup 6618 Language [XML], and a complete XML stream (including start and end 6619 stream tags) is a conforming XML document. 6621 However, XMPP does not deal with XML documents but with XML streams. 6622 Because XMPP does not require the parsing of arbitrary and complete 6623 XML documents, there is no requirement that XMPP needs to support the 6624 full feature set of [XML]. Furthermore, XMPP uses XML to define 6625 protocol data structures and extensions for the purpose of structured 6626 interactions between network entities and therefore adheres to the 6627 recommendations provided in [XML-GUIDE] regarding restrictions on the 6628 use of XML in IETF protocols. As a result, the following features of 6629 XML are prohibited in XMPP: 6631 o comments (as defined in Section 2.5 of [XML]) 6632 o processing instructions (Section 2.6 therein) 6633 o internal or external DTD subsets (Section 2.8 therein) 6634 o internal or external entity references (Section 4.2 therein) with 6635 the exception of the predefined entities (Section 4.6 therein) 6637 An XMPP implementation MUST behave as follows with regard to these 6638 features: 6640 1. An XMPP implementation MUST NOT inject characters matching such 6641 features into an XML stream. 6643 2. If an XMPP implementation receives characters matching such 6644 features over an XML stream, it MUST close the stream with a 6645 stream error, which SHOULD be 6646 (Section 4.9.3.18), although some existing implementations send 6647 (Section 4.9.3.1) instead. 6649 11.2. XML Namespace Names and Prefixes 6651 XML namespaces (see [XML-NAMES]) are used within XMPP streams to 6652 create strict boundaries of data ownership. The basic function of 6653 namespaces is to separate different vocabularies of XML elements that 6654 are structurally mixed together. Ensuring that XMPP streams are 6655 namespace-aware enables any allowable XML to be structurally mixed 6656 with any data element within XMPP. XMPP-specific rules for XML 6657 namespace names and prefixes are defined under Section 4.8 for XML 6658 streams and Section 8.4 for XML stanzas. 6660 11.3. Well-Formedness 6662 In XML, there are two varieties of well-formedness: 6664 o "XML-well-formedness" in accordance with the definition of "well- 6665 formed" from Section 2.1 of [XML]. 6667 o "Namespace-well-formedness" in accordance with the definition of 6668 "namespace-well-formed" from Section 7 of [XML-NAMES]. 6670 The following rules apply. 6672 1. An XMPP entity MUST NOT generate data that is not XML-well- 6673 formed. 6675 2. An XMPP entity MUST NOT accept data that is not XML-well-formed; 6676 instead it MUST close the stream over which the data was received 6677 with a stream error (Section 4.9.3.13). 6679 3. An XMPP entity MUST NOT generate data that is not namespace-well- 6680 formed. 6682 4. An XMPP entity MUST NOT accept data that is not namespace-well- 6683 formed (in particular, an XMPP server MUST NOT route or deliver 6684 data that is not namespace-well-formed); instead it MUST return 6685 either a stanza error (Section 8.3.3.9) or 6686 close the stream with a stream error 6687 (Section 4.9.3.13), where it is preferable to close the stream 6688 with a stream error because accepting such data can open an 6689 entity to certain denial of service attacks. 6691 Interoperability Note: Because these restrictions were 6692 underspecified in [RFC3920], it is possible that implementations 6693 based on that specification will send data that does not comply 6694 with these restrictions. 6696 11.4. Validation 6698 A server is not responsible for ensuring that XML data delivered to a 6699 connected client or routed to a peer server is valid, in accordance 6700 with the definition of "valid" provided in Section 2.8 of [XML]. An 6701 implementation MAY choose to accept or send only data that has been 6702 explicitly validated against the schemas provided in this document, 6703 but such behavior is OPTIONAL. Clients are advised not to rely on 6704 the ability to send data that does not conform to the schemas, and 6705 SHOULD ignore any non-conformant elements or attributes on the 6706 incoming XML stream. 6708 Informational Note: The terms "valid" and "well-formed" are 6709 distinct in XML. 6711 11.5. Inclusion of XML Declaration 6713 Before sending a stream header, an implementation SHOULD send an XML 6714 declaration (matching the "XMLDecl" production from [XML]). 6715 Applications MUST follow the rules provided in [XML] regarding the 6716 format of the XML declaration and the circumstances under which the 6717 XML declaration is included. 6719 Because external markup declarations are prohibited in XMPP (as 6720 described under Section 11.1), the standalone document declaration 6721 (matching the "SDDecl" production from [XML]) would have no meaning 6722 and therefore MUST NOT be included in an XML declaration sent over an 6723 XML stream. If an XMPP entity receives an XML declaration containing 6724 a standalone document declaration set to a value of "no", the entity 6725 MUST either ignore the standalone document declaration or close the 6726 stream with a stream error, which SHOULD be 6727 (Section 4.9.3.18). 6729 11.6. Character Encoding 6731 Implementations MUST support the UTF-8 transformation of Universal 6732 Character Set [UCS2] characters, as needed for conformance with 6733 [CHARSETS] and as defined in [UTF-8]. Implementations MUST NOT 6734 attempt to use any other encoding. If one party to an XML stream 6735 detects that the other party has attempted to send XML data with an 6736 encoding other than UTF-8, it MUST close the stream with a stream 6737 error, which SHOULD be (Section 4.9.3.22), 6738 although some existing implementations send 6739 (Section 4.9.3.1) instead. 6741 Because it is mandatory for an XMPP implementation to support all and 6742 only the UTF-8 encoding and because UTF-8 always has the same byte 6743 order, an implementation MUST NOT send a byte order mark ("BOM") at 6744 the beginning of the data stream. If an entity receives the 6745 [UNICODE] character U+FEFF anywhere in an XML stream (including as 6746 the first character of the stream), it MUST interpret that character 6747 as a zero width no-break space, not as a byte order mark. 6749 11.7. Whitespace 6751 Except where explicitly disallowed (e.g., during TLS negotiation 6752 (Section 5) and SASL negotiation (Section 6)), either entity MAY send 6753 whitespace as separators between XML stanzas or between any other 6754 first-level elements sent over the stream. One common use for 6755 sending such whitespace is explained under Section 4.4. 6757 11.8. XML Versions 6759 XMPP is an application profile of XML 1.0. A future version of XMPP 6760 might be defined in terms of higher versions of XML, but this 6761 specification defines XMPP only in terms of XML 1.0. 6763 12. Internationalization Considerations 6765 As specified under Section 11.6, XML streams MUST be encoded in 6766 UTF-8. 6768 As specified under Section 4.7, an XML stream SHOULD include an 'xml: 6769 lang' attribute specifying the default language for any XML character 6770 data that is intended to be presented to a human user. As specified 6771 under Section 8.1.5, an XML stanza SHOULD include an 'xml:lang' 6772 attribute if the stanza contains XML character data that is intended 6773 to be presented to a human user. A server SHOULD apply the default 6774 'xml:lang' attribute to stanzas it routes or delivers on behalf of 6775 connected entities, and MUST NOT modify or delete 'xml:lang' 6776 attributes on stanzas it receives from other entities. 6778 Internationalization of XMPP addresses is specified in [XMPP-ADDR]. 6780 13. Security Considerations 6782 13.1. Fundamentals 6784 XMPP technologies are typically deployed using a decentralized 6785 client-server architecture. As a result, several paths are possible 6786 when two XMPP entities need to communicate: 6788 1. Both entities are servers. In this case, the entities can 6789 establish a direct server-to-server stream between themselves. 6791 2. One entity is a server and the other entity is a client whose 6792 account is hosted on that server. In this case, the entities can 6793 establish a direct client-to-server stream between themselves. 6795 3. Both entities are clients whose accounts are hosted on the same 6796 server. In this case, the entities cannot establish a direct 6797 stream between themselves, but there is only one intermediate 6798 entity between them, whose policies they might understand and in 6799 which they might have some level of trust (e.g., the server might 6800 require the use of Transport Layer Security for all client 6801 connections). 6803 4. Both entities are clients but their accounts are hosted on 6804 different servers. In this case, the entities cannot establish a 6805 direct stream between themselves and there are two intermediate 6806 entities between them; each client might have some trust in the 6807 server that hosts its account but might know nothing about the 6808 policies of the server to which the other client connects. 6810 This specification covers only the security of a direct XML stream 6811 between two servers or between a client and a server (cases #1 and 6812 #2), where each stream can be considered a single "hop" along a 6813 communication path. The goal of security for a multi-hop path (cases 6814 #3 and #4), although very desirable, is out of scope for this 6815 specification. 6817 In accordance with [SEC-GUIDE], this specification covers 6818 communication security (confidentiality, data integrity, and peer 6819 entity authentication), non-repudiation, and systems security 6820 (unauthorized usage, inappropriate usage, and denial of service). We 6821 also discuss common security issues such as information leaks, 6822 firewalls, and directory harvesting, as well as best practices 6823 related to the re-use of technologies such as base 64, DNS, 6824 cryptographic hash functions, SASL, TLS, UTF-8, and XML. 6826 13.2. Threat Model 6828 The threat model for XMPP is in essence the standard "Internet Threat 6829 Model" described in [SEC-GUIDE]. Attackers are assumed to be 6830 interested in and capable of launching the following attacks against 6831 unprotected XMPP systems: 6833 o Eavesdropping 6834 o Sniffing passwords 6835 o Breaking passwords through dictionary attacks 6836 o Discovering usernames through directory harvesting attacks 6837 o Replaying, inserting, deleting, or modifying stanzas 6838 o Spoofing users 6839 o Gaining unauthorized entry to a server or account 6840 o Using a server or account inappropriately 6841 o Denying service to other entities 6842 o Subverting communication streams through man-in-the-middle attacks 6843 o Gaining control over on-path servers 6845 Where appropriate, the following sections describe methods for 6846 protecting against these threats. 6848 13.3. Order of Layers 6850 The order of layers in which protocols MUST be stacked is as follows: 6852 1. TCP 6853 2. TLS 6854 3. SASL 6855 4. XMPP 6857 This order has important security implications, as described 6858 throughout these security considerations. 6860 Within XMPP, XML stanzas are further ordered on top of XML streams, 6861 as described under Section 4. 6863 13.4. Confidentiality and Integrity 6865 The use of Transport Layer Security (TLS) with appropriate 6866 ciphersuites provides a reliable mechanism to ensure the 6867 confidentiality and integrity of data exchanged between a client and 6868 a server or between two servers. Therefore TLS can help to protect 6869 against eavesdropping, password sniffing, man-in-the-middle attacks, 6870 and stanza replays, insertion, deletion, and modification over an XML 6871 stream. XMPP clients and servers MUST support TLS as defined under 6872 Section 5. 6874 Informational Note: The confidentiality and integrity of a stream 6875 can be protected by methods other than TLS, e.g. by means of a 6876 SASL mechanism that involves negotiation of a security layer. 6878 Security Warning: The use of TLS in XMPP applies to a single 6879 stream. Because XMPP is typically deployed using a distributed 6880 client-server architecture (as explained under Section 2.5), a 6881 stanza might traverse multiple streams, and not all of those 6882 streams might be TLS-protected. For example, a stanza sent from a 6883 client with a session at one server (e.g., 6884 ) and intended for delivery to a client 6885 with a session at another server (e.g., 6886 ) will traverse three streams: (1) the 6887 stream from the sender's client to its server, (2) the stream from 6888 the sender's server to the recipient's server, and (3) the stream 6889 from the recipient's server to the recipient's client. 6890 Furthermore, the stanza will be processed as cleartext within the 6891 sender's server and the recipient's server. Therefore, even if 6892 the stream from the sender's client to its server is protected, 6893 the confidentiality and integrity of a stanza sent over that 6894 protected stream cannot be guaranteed when the stanza is processed 6895 by the sender's server, sent from the sender's server to the 6896 recipient's server, processed by the recipient's server, or sent 6897 from the recipient's server to the recipient's client. Only a 6898 robust technology for end-to-end encryption could ensure the 6899 confidentiality and integrity of a stanza as it traverses all of 6900 the "hops" along a communication path (e.g., a technology that 6901 meets the requirements defined in [E2E-REQS]). Unfortunately, the 6902 XMPP community has so far failed to produce an end-to-end 6903 encryption technology that might be suitable for widespread 6904 implementation and deployment, and definition of such a technology 6905 is out of scope for this document. 6907 13.5. Peer Entity Authentication 6909 The use of the Simple Authentication and Security Layer (SASL) for 6910 authentication provides a reliable mechanism for peer entity 6911 authentication. Therefore SASL helps to protect against user 6912 spoofing, unauthorized usage, and man-in-the middle attacks. XMPP 6913 clients and servers MUST support SASL as defined under Section 6. 6915 13.6. Strong Security 6917 [STRONGSEC] defines "strong security" and its importance to 6918 communication over the Internet. For the purpose of XMPP 6919 communication over client-to-server and server-to-server streams, the 6920 term "strong security" refers to the use of security technologies 6921 that provide both mutual authentication and integrity checking (e.g., 6922 a combination of TLS encryption and SASL authentication using 6923 appropriate SASL mechanisms). 6925 Implementations MUST support strong security. Service provisioning 6926 SHOULD use strong security. 6928 An implementation SHOULD make it possible for an end user or service 6929 administrator to provision a deployment with specific trust anchors 6930 for the certificate presented by a connecting entity (either client 6931 or server); when an application is thus provisioned, it MUST NOT use 6932 a generic PKI trust store to authenticate the connecting entity. 6933 More detailed rules and guidelines regarding certificate validation 6934 are provided in the next section. 6936 The initial stream and the response stream MUST be secured 6937 separately, although security in both directions MAY be established 6938 via mechanisms that provide mutual authentication. 6940 13.7. Certificates 6942 Channel encryption of an XML stream using Transport Layer Security as 6943 described under Section 5, and in some cases also authentication as 6944 described under Section 6, is commonly based on a digital certificate 6945 presented by the receiving entity (or, in the case of mutual 6946 certificate authentication, both the receiving entity and the 6947 initiating entity). This section describes best practices regarding 6948 the generation of digital certificates to be presented by XMPP 6949 entities and the verification of digital certificates presented by 6950 XMPP entities. 6952 In general, the following sections rely on and extend the rules and 6953 guidelines provided in the [PKIX] profile of [X509], and in 6954 [TLS-CERTS]. The reader is referred to those specifications for a 6955 detailed understanding of PKIX certificates and their use in TLS. 6957 13.7.1. Certificate Generation 6959 13.7.1.1. General Considerations 6961 The following rules apply to end entity public key certificates that 6962 are issued to XMPP servers or clients: 6964 1. The certificate MUST conform to [PKIX]. 6966 2. The certificate MUST NOT contain a basicConstraints extension 6967 with the cA boolean set to TRUE. 6969 3. The subject field MUST NOT be null. 6971 4. The signatureAlgorithm SHOULD be the PKCS #1 version 1.5 6972 signature algorithm with SHA-256 as defined by [PKIX-ALGO], or a 6973 strong algorithm if available. 6975 5. The certificate SHOULD include an Authority Information Access 6976 (AIA) extension that specifies the address of an Online 6977 Certificate Status Protocol [OCSP] responder (if not, a relying 6978 party would need to fall back on the use of Certificate 6979 Revocation Lists (CRLs) as described in [PKIX]). 6981 The following rules apply to certification authority (CA) 6982 certificates that are used by issuers of XMPP end entity 6983 certificates: 6985 1. The certificate MUST conform to [PKIX]. 6987 2. The certificate MUST contain a keyUsage extension with the 6988 digitalSignature bit set. 6990 3. The subject field MUST NOT be null. 6992 4. The signatureAlgorithm SHOULD be the PKCS #1 version 1.5 6993 signature algorithm with SHA-256 as defined by [PKIX-ALGO]. 6995 5. For issuers of public key certificates, the issuer's certificate 6996 MUST contain a basicConstraints extension with the cA boolean set 6997 to TRUE. 6999 13.7.1.2. Server Certificates 7001 13.7.1.2.1. Rules 7003 In a digital certificate to be presented by an XMPP server (i.e., a 7004 "server certificate"), it is RECOMMENDED for the certificate to 7005 include one or more JIDs (i.e., domainparts) associated with domains 7006 serviced at the server. The rules and guidelines defined in 7007 [TLS-CERTS] apply to XMPP server certificates, with the following 7008 supplemental rules for XMPP: 7010 o Support for the DNS-ID identifier type [PKIX] is REQUIRED in XMPP 7011 client and server software implementations. Certification 7012 authorities that issue XMPP-specific certificates MUST support the 7013 DNS-ID identifier type. XMPP service providers SHOULD include the 7014 DNS-ID identifier type in certificate requests. 7016 o Support for the SRV-ID identifier type [PKIX-SRV] is REQUIRED for 7017 XMPP client and server software implementations (for verification 7018 purposes XMPP client implementations need to support only the 7019 "_xmpp-client" service type, whereas XMPP server implementations 7020 need to support both the "_xmpp-client" and "_xmpp-server" service 7021 types). Certification authorities that issue XMPP-specific 7022 certificates SHOULD support the SRV-ID identifier type. XMPP 7023 service providers SHOULD include the SRV-ID identifier type in 7024 certificate requests. 7026 o Support for the XmppAddr identifier type (specified under 7027 Section 13.7.1.4) is encouraged in XMPP client and server software 7028 implementations for the sake of backward-compatibility, but is no 7029 longer encouraged in certificates issued by certification 7030 authorities or requested by XMPP service providers. 7032 o DNS domain names in server certificates MAY contain the wildcard 7033 character '*' as the complete left-most label within the 7034 identifier. 7036 13.7.1.2.2. Examples 7038 For our first (relatively simple) example, consider a company called 7039 "Example Products, Inc." It hosts an XMPP service at 7040 "im.example.com" (i.e., user addresses at the service are of the form 7041 "user@im.example.com"), and SRV lookups for the xmpp-client and xmpp- 7042 server services at "im.example.com" yield one machine, called 7043 "x.example.com", as follows: 7045 _xmpp-client._tcp.im.example.com. 400 IN SRV 20 0 5222 x.example.com 7046 _xmpp-server._tcp.im.example.com. 400 IN SRV 20 0 5269 x.example.com 7048 The certificate presented by x.example.com contains the following 7049 representations: 7051 o An otherName type of SRVName (id-on-dnsSRV) containing an 7052 IA5String (ASCII) string of: "_xmpp-client.im.example.com" 7054 o An otherName type of SRVName (id-on-dnsSRV) containing an 7055 IA5String (ASCII) string of: "_xmpp-server.im.example.com" 7057 o A dNSName containing an ASCII string of "im.example.com" 7059 o An otherName type of XmppAddr (id-on-xmppAddr) containing a UTF-8 7060 string of: "im.example.com" 7062 o A CN containing an ASCII string of "Example Products, Inc." 7064 For our second (more complex) example, consider an ISP called 7065 "Example Internet Services". It hosts an XMPP service at 7066 "example.net" (i.e., user addresses at the service are of the form 7067 "user@example.net"), but SRV lookups for the xmpp-client and xmpp- 7068 server services at "example.net" yield two machines ("x1.example.net" 7069 and "x2.example.net"), as follows: 7071 _xmpp-client._tcp.example.net. 68400 IN SRV 20 0 5222 x1.example.net. 7072 _xmpp-client._tcp.example.net. 68400 IN SRV 20 0 5222 x2.example.net. 7073 _xmpp-server._tcp.example.net. 68400 IN SRV 20 0 5269 x1.example.net. 7074 _xmpp-server._tcp.example.net. 68400 IN SRV 20 0 5269 x2.example.net. 7076 Example Internet Services also hosts chatrooms at chat.example.net, 7077 and provides an xmpp-server SRV record for that service as well (thus 7078 enabling entities from remote domains to access that service). It 7079 also might provide other such services in the future, so it wishes to 7080 represent a wildcard in its certificate to handle such growth. 7082 The certificate presented by either x1.example.net or x2.example.net 7083 contains the following representations: 7085 o An otherName type of SRVName (id-on-dnsSRV) containing an 7086 IA5String (ASCII) string of: "_xmpp-client.example.net" 7088 o An otherName type of SRVName (id-on-dnsSRV) containing an 7089 IA5String (ASCII) string of: "_xmpp-server.example.net" 7091 o An otherName type of SRVName (id-on-dnsSRV) containing an 7092 IA5String (ASCII) string of: "_xmpp-server.chat.example.net" 7094 o A dNSName containing an ASCII string of "example.net" 7096 o A dNSName containing an ASCII string of "*.example.net" 7098 o An otherName type of XmppAddr (id-on-xmppAddr) containing a UTF-8 7099 string of: "example.net" 7101 o An otherName type of XmppAddr (id-on-xmppAddr) containing a UTF-8 7102 string of: "chat.example.net" 7104 o A CN containing an ASCII string of "Example Internet Services" 7106 13.7.1.3. Client Certificates 7108 In a digital certificate to be presented by an XMPP client controlled 7109 by a human user (i.e., a "client certificate"), it is RECOMMENDED for 7110 the certificate to include one or more JIDs associated with an XMPP 7111 user. If included, a JID MUST be represented as an XmppAddr as 7112 specified under Section 13.7.1.4. 7114 13.7.1.4. XmppAddr Identifier Type 7116 The XmppAddr identifier type is a UTF8String within an otherName 7117 entity inside the subjectAltName, using the [ASN.1] Object Identifier 7118 "id-on-xmppAddr" specified below. 7120 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 7121 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 7123 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } -- other name forms 7125 id-on-xmppAddr OBJECT IDENTIFIER ::= { id-on 5 } 7127 XmppAddr ::= UTF8String 7129 As an alternative to the "id-on-xmppAddr" notation, this Object 7130 Identifier MAY be represented in dotted display format (i.e., 7131 "1.3.6.1.5.5.7.8.5") or in the Uniform Resource Name notation 7132 specified in [URN-OID] (i.e., "urn:oid:1.3.6.1.5.5.7.8.5"). 7134 Thus for example the JID as included in a 7135 certificate could be formatted in any of the following three ways: 7137 id-on-xmppAddr: 7138 subjectAltName=otherName:id-on-xmppAddr;UTF8:juliet@im.example.com 7140 dotted display format: subjectAltName=otherName: 7141 1.3.6.1.5.5.7.8.5;UTF8:juliet@im.example.com 7143 URN notation: subjectAltName=otherName:urn:oid: 7144 1.3.6.1.5.5.7.8.5;UTF8:juliet@im.example.com 7146 Use of the "id-on-xmppAddr" format is RECOMMENDED in the generation 7147 of certificates, but all three formats MUST be supported for the 7148 purpose of certificate validation. 7150 The "id-on-xmppAddr" object identifier MAY be used on conjunction 7151 with the extended key usage extension specified in Section 4.2.1.12 7152 of [PKIX] in order to explicitly define and limit the intended use of 7153 a certificate to the XMPP network. 7155 13.7.2. Certificate Validation 7157 When an XMPP entity is presented with a server certificate or client 7158 certificate by a peer for the purpose of encryption or authentication 7159 of XML streams as described under Section 5 and Section 6, the entity 7160 MUST attempt to validate the certificate to determine if the 7161 certificate will be considered a "trusted certificate", i.e., a 7162 certificate that is acceptable for encryption and/or authentication 7163 in accordance with the XMPP entity's local service policies or 7164 configured settings. 7166 For both server certificates and client certificates, the validating 7167 entity MUST do the following: 7169 1. Attempt to verify the integrity of the certificate. 7171 2. Attempt to verify that the certificate has been properly signed 7172 by the issuing Certificate Authority. 7174 3. Attempt to validate the full certification path. 7176 4. Check the rules for end entity public key certificates and 7177 certification authority certificates specified under 7178 Section 13.7.1.1 for the general case and under either 7179 Section 13.7.1.2 or Section 13.7.1.2 for XMPP server or client 7180 certificates, respectively. 7182 5. Check certificate revocation messages via Certificate Revocation 7183 Lists (CRLs), the Online Certificate Status Protocol [OCSP], or 7184 both. 7186 If any of those validation attempts fail, the validating entity MUST 7187 unilaterally terminate the session. 7189 The following sections describe the additional identity verification 7190 rules that apply to server-to-server and client-to-server streams. 7192 Once the identity of the stream peer has been validated, the 7193 validating entity SHOULD also correlate the validated identity with 7194 the 'from' address (if any) of the stream header it received from the 7195 peer. If the two identities do not match, the validating entity 7196 SHOULD terminate the connection attempt (however, there might be good 7197 reasons why the identities do not match, as described under 7198 Section 4.7.1). 7200 13.7.2.1. Server Certificates 7202 For server certificates, the rules and guidelines defined in 7203 [TLS-CERTS] apply, with the proviso that the XmppAddr identifier 7204 specified under Section 13.7.1.4 is allowed as a reference 7205 identifier. 7207 The identities to be checked are set as follows: 7209 o The initiating entity sets its reference identifier to the 'to' 7210 address it communicates in the initial stream header; i.e., this 7211 is the identity it expects the receiving entity to provide in a 7212 PKIX certificate. 7214 o The receiving entity sets its reference identifier to the 'from' 7215 address communicated by the initiating entity in the initial 7216 stream header; i.e., this is the identity that the initiating 7217 entity is trying to assert. 7219 In the case of server-to-server communication, the matching procedure 7220 described in [TLS-CERTS] can be performed by an application server 7221 (receiving entity) when verifying an incoming server-to-server 7222 connection from a peer server (initiating entity). In this case, the 7223 receiving entity verifies the identity of the initiating entity and 7224 uses as its reference identifier the DNS domain name asserted by the 7225 initiating entity in the 'from' attribute of the initial stream 7226 header. However, the matching procedure described in [TLS-CERTS] 7227 remains unchanged and is applied in the same way. 7229 13.7.2.2. Client Certificates 7231 When an XMPP server validates a certificate presented by a client, 7232 there are three possible cases, as discussed in the following 7233 sections. 7235 The identities to be checked are set as follows: 7237 o The client sets its reference identifier to the 'to' address it 7238 communicates in the initial stream header; i.e., this is the 7239 identity it expects the server to provide in a PKIX certificate. 7241 o The server sets its reference identifier to the 'from' address 7242 communicated by the initiating entity in the initial stream 7243 header; i.e., this is the identity that the client is trying to 7244 assert. 7246 13.7.2.2.1. Case #1 7248 If the client certificate appears to be certified by a certification 7249 path terminating in a trust anchor (as described in Section 6.1 of 7250 [PKIX]), the server MUST check the certificate for any instances of 7251 the XmppAddr as described under Section 13.7.1.4. There are three 7252 possible sub-cases: 7254 Sub-Case #1: The server finds one XmppAddr for which the domainpart 7255 of the represented JID matches one of the configured FQDNs of the 7256 server; the server SHOULD use this represented JID as the 7257 validated identity of the client. 7259 Sub-Case #2: The server finds more than one XmppAddr for which the 7260 domainpart of the represented JID matches one of the configured 7261 FQDNs of the server; the server SHOULD use one of these 7262 represented JIDs as the validated identity of the client, choosing 7263 among them based on the bare JID contained in the 'from' address 7264 of the initial stream header (if any), based on the domainpart 7265 contained in the 'to' address of the initial stream header, or in 7266 accordance with local service policies (such as a lookup in a user 7267 database based on other information contained in the client 7268 certificate). 7270 Sub-Case #3: The server finds no XmppAddrs, or finds at least one 7271 XmppAddr but the domainpart of the represented JID does not match 7272 one of the configured FQDNs of the server; the server MUST NOT use 7273 the represented JID (if any) as the validated identity of the 7274 client but instead MUST validate the identity of the client using 7275 other means in accordance with local service policies (such as a 7276 lookup in a user database based on other information contained in 7277 the client certificate). If the identity cannot be so validated, 7278 the server MAY abort the validation process and terminate the TLS 7279 negotiation. 7281 13.7.2.2.2. Case #2 7283 If the client certificate is certified by a Certificate Authority not 7284 known to the server, the server MUST proceed as under Case #1, Sub- 7285 Case #3. 7287 13.7.2.2.3. Case #3 7289 If the client certificate is self-signed, the server MUST proceed as 7290 under Case #1, Sub-Case #3. 7292 13.7.2.3. Checking of Certificates in Long-Lived Streams 7294 Because XMPP uses long-lived XML streams, it is possible that a 7295 certificate presented during stream negotiation might expire or be 7296 revoked while the stream is still live (this is especially relevant 7297 in the context of server-to-server streams). Therefore, each party 7298 to a long-lived stream SHOULD: 7300 1. Cache the expiration date of the certificate presented by the 7301 other party and any certificates on which that certificate 7302 depends (such as a root or intermediate certificate for a 7303 certification authority), and close the stream when any such 7304 certificate expires, with a stream error of 7305 (Section 4.9.3.16). 7307 2. Periodically query the Online Certificate Status Protocol [OCSP] 7308 responder listed in the Authority Information Access (AIA) 7309 extension of the certificate presented by the other party and any 7310 certificates on which that certificate depends (such as a root or 7311 intermediate certificate for a certification authority), and 7312 close the stream if any such certificate has been revoked, with a 7313 stream error of (Section 4.9.3.16). It is RECOMMENDED 7314 to query the OSCP responder at or near the time communicated via 7315 the nextUpdate field received in the OCSP response or, if the 7316 nextUpdate field is not set, to query every 24 hours. 7318 After the stream is closed, the initiating entity from the closed 7319 stream will need to re-connect and the receiving entity will need to 7320 authenticate the initiating entity based on whatever certificate it 7321 presents during negotiation of the new stream. 7323 13.7.2.4. Use of Certificates in XMPP Extensions 7325 Certificates MAY be used in extensions to XMPP for the purpose of 7326 application-layer encryption or authentication above the level of XML 7327 streams (e.g., for end-to-end encryption). Such extensions will 7328 define their own certificate handling rules. At a minimum, such 7329 extensions are encouraged to remain consistent with the rules defined 7330 in this specification, specifying additional rules only when 7331 necessary. 7333 13.8. Mandatory-to-Implement TLS and SASL Technologies 7335 The following TLS ciphersuites and SASL mechanisms are mandatory-to- 7336 implement (naturally, implementations MAY support other ciphersuites 7337 and mechanisms as well). For security considerations related to TLS 7338 ciphersuites, see Section 13.9.4 and [TLS]. For security 7339 considerations related to SASL mechanisms, see Section 13.9.4, 7340 [SASL], and specifications for particular SASL mechanisms such as 7341 [SCRAM], [DIGEST-MD5], and [PLAIN]. 7343 13.8.1. For Authentication Only 7345 For authentication only, servers and clients MUST support the SASL 7346 Salted Challenge Response mechanism [SCRAM], in particular the SCRAM- 7347 SHA-1 and SCRAM-SHA-1-PLUS variants. 7349 Security Warning: Even though it is possible to complete 7350 authentication only without confidentiality, it is RECOMMENDED for 7351 servers and clients to protect the stream with TLS before 7352 attempting authentication with SASL, both to help protect the 7353 information exchanged during SASL negotiation and to help prevent 7354 certain downgrade attacks as described under Section 13.9.4 and 7355 Section 13.9.5. Even if TLS is used, implementations SHOULD also 7356 enforce channel binding as described under Section 13.9.4. 7358 Interoperability Note: The SCRAM-SHA-1 or SASL-SCRAM-SHA-1-PLUS 7359 variants of the SCRAM mechanism replace the SASL DIGEST-MD5 7360 mechanism as XMPP's mandatory-to-implement password-based method 7361 for authentication only. For backward-compatibility with existing 7362 deployed infrastructure, implementations are encouraged to 7363 continue supporting the DIGEST-MD5 mechanism as specified in 7364 [DIGEST-MD5]; however, there are known interoperability issues 7365 with DIGEST-MD5 that make it impractical in the long term. 7367 13.8.2. For Confidentiality Only 7369 For confidentiality only, servers MUST support TLS with the 7370 TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite. 7372 Security Warning: Because a connection with confidentiality only 7373 has weaker security properties than a connection with both 7374 confidentiality and authentication, it is RECOMMENDED for servers 7375 and clients to prefer connections with both qualities (e.g., by 7376 protecting the stream with TLS before attempting authentication 7377 with SASL). In practice, confidentiality only is employed merely 7378 for server-to-server connections when the peer server does not 7379 present a trusted certificate and the servers use Server Dialback 7380 [XEP-0220] for weak identity verification, but TLS with 7381 confidentiality only is still desirable to protect the connection 7382 against casual eavesdropping. 7384 13.8.3. For Confidentiality and Authentication With Passwords 7386 For both confidentiality and authentication with passwords, servers 7387 and clients MUST implement TLS with the TLS_RSA_WITH_AES_128_CBC_SHA 7388 ciphersuite plus SASL SCRAM, in particular the SCRAM-SHA-1 and SCRAM- 7389 SHA-1-PLUS variants (with SCRAM-SHA1-PLUS being preferred, as 7390 described under Section 13.9.4). 7392 As further explained in the following Security Warning, in certain 7393 circumstances a server MAY offer TLS with the 7394 TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite plus SASL PLAIN when it is 7395 not possible to offer more secure alternatives; in addition, clients 7396 SHOULD implement PLAIN over TLS in order to maximize interoperability 7397 with servers that are not able to deploy more secure alternatives. 7399 Security Warning: In practice, many servers offer, and many 7400 clients use, TLS plus SASL PLAIN. The SCRAM-SHA-1 and especially 7401 SCRAM-SHA-1-PLUS variants of the SCRAM mechanism are strongly 7402 preferred over the PLAIN mechanism because of their superior 7403 security properties (including for SCRAM-SHA-1-PLUS the ability to 7404 enforce channel binding as described under Section 13.9.4). A 7405 client SHOULD treat TLS plus SASL PLAIN as a technology of last 7406 resort to be used only when interacting with a server that does 7407 not offer SCRAM (or other alternatives that are more secure than 7408 TLS plus SASL PLAIN), MUST prefer more secure mechanisms (e.g., 7409 EXTERNAL, SCRAM-SHA-1-PLUS, SCRAM-SHA-1, or the older DIGEST-MD5 7410 mechanism) to the PLAIN mechanism, and MUST NOT use the PLAIN 7411 mechanism if the stream does not at a minimum have confidentiality 7412 and integrity protection via TLS with full certificate validation 7413 as described under Section 13.7.2.1. A server MUST NOT offer SASL 7414 PLAIN if the confidentiality and integrity of the stream are not 7415 protected via TLS or an equivalent security layer. A server 7416 SHOULD NOT offer TLS plus SASL PLAIN unless it is unable to offer 7417 some variant of SASL SCRAM (or other alternatives that are more 7418 secure than TLS plus SASL PLAIN), e.g., because the XMPP service 7419 depends for authentication purposes on a database or directory 7420 that is not under the control of the XMPP administrators, such as 7421 Pluggable Authentication Modules (PAM), an LDAP directory [LDAP], 7422 or an Authentication, Authorization, and Accounting (AAA) key 7423 management protocol (for guidance, refer to [AAA]); however, 7424 offering TLS plus SASL PLAIN even when the server supports more 7425 secure alternatives might be appropriate if the server needs to 7426 enable interoperability with an installed base of clients that do 7427 not yet support SCRAM or other alternatives that are more secure 7428 than TLS plus SASL PLAIN. 7430 13.8.4. For Confidentiality and Authentication Without Passwords 7432 For both confidentiality and authentication without passwords, 7433 servers MUST and clients SHOULD implement TLS with the 7434 TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite plus the SASL EXTERNAL 7435 mechanism (see Appendix A of [SASL]) with PKIX certificates. 7437 13.9. Technology Reuse 7439 13.9.1. Use of Base 64 in SASL 7441 Both the client and the server MUST verify any base 64 data received 7442 during SASL negotiation (Section 6). An implementation MUST reject 7443 (not ignore) any characters that are not explicitly allowed by the 7444 base 64 alphabet; this helps to guard against creation of a covert 7445 channel that could be used to "leak" information. 7447 An implementation MUST NOT break on invalid input and MUST reject any 7448 sequence of base 64 characters containing the pad ('=') character if 7449 that character is included as something other than the last character 7450 of the data (e.g., "=AAA" or "BBBB=CCC"); this helps to guard against 7451 buffer overflow attacks and other attacks on the implementation. 7453 While base 64 encoding visually hides otherwise easily recognized 7454 information (such as passwords), it does not provide any 7455 computational confidentiality. 7457 All uses of base 64 encoding MUST follow the definition in Section 4 7458 of [BASE64] and padding bits MUST be set to zero. 7460 13.9.2. Use of DNS 7462 XMPP typically relies on the Domain Name System (specifically 7463 [DNS-SRV] records) to resolve a fully-qualified domain name to an IP 7464 address before a client connects to a server or before a peer server 7465 connects to another server. Before attempting to negotiate an XML 7466 stream, the initiating entity MUST NOT proceed until it has resolved 7467 the DNS domain name of the receiving entity as specified under 7468 Section 3 (although it is not necessary to resolve the DNS domain 7469 name before each connection attempt, because DNS resolution results 7470 can be temporarily cached in accordance with time-to-live values). 7471 However, in the absence of a secure DNS option (e.g., as provided by 7472 [DNSSEC]), a malicious attacker with access to the DNS server data, 7473 or able to cause spoofed answers to be cached in a recursive 7474 resolver, can potentially cause the initiating entity to connect to 7475 any XMPP server chosen by the attacker. Deployment and validation of 7476 server certificates helps to prevent such attacks. 7478 13.9.3. Use of Hash Functions 7480 XMPP itself does not directly mandate the use of any particular 7481 cryptographic hash function. However, technologies on which XMPP 7482 depends (e.g., TLS and particular SASL mechanisms), as well as 7483 various XMPP extensions, might make use of cryptographic hash 7484 functions. Those who implement XMPP technologies or who develop XMPP 7485 extensions are advised to closely monitor the state of the art 7486 regarding attacks against cryptographic hash functions in Internet 7487 protocols as they relate to XMPP. For helpful guidance, refer to 7488 [HASHES]. 7490 13.9.4. Use of SASL 7492 Because the initiating entity chooses an acceptable SASL mechanism 7493 from the list presented by the receiving entity, the initiating 7494 entity depends on the receiving entity's list for authentication. 7495 This dependency introduces the possibility of a downgrade attack if 7496 an attacker can gain control of the channel and therefore present a 7497 weak list of mechanisms. To mitigate this attack, the parties SHOULD 7498 protect the channel using TLS before attempting SASL negotiation and 7499 either perform full certificate validation as described under 7500 Section 13.7.2.1 or use a SASL mechanism that provides channel 7501 bindings, such as SCRAM-SHA-1-PLUS. (Protecting the channel via TLS 7502 with full certificate validation can help to ensure the 7503 confidentiality and integrity of the information exchanged during 7504 SASL negotiation.) 7506 The SASL framework itself does not provide a method for binding SASL 7507 authentication to a security layer providing confidentiality and 7508 integrity protection that was negotiated at a lower layer (e.g., 7509 TLS). Such a binding is known as a "channel binding" (see 7510 [CHANNEL]). Some SASL mechanisms provide channel bindings, which in 7511 the case of XMPP would typically be a binding to TLS (see 7512 [CHANNEL-TLS]). If a SASL mechanism provides a channel binding 7513 (e.g., this is true of [SCRAM]), then XMPP entities using that 7514 mechanism SHOULD prefer the channel binding variant (e.g., preferring 7515 "SCRAM-SHA-1-PLUS" over "SCRAM-SHA-1"). If a SASL mechanism does not 7516 provide a channel binding, then the mechanism cannot provide a way to 7517 verify that the source and destination end points to which the lower 7518 layer's security is bound are equivalent to the end points that SASL 7519 is authenticating; furthermore, if the end points are not identical, 7520 then the lower layer's security cannot be trusted to protect data 7521 transmitted between the SASL-authenticated entities. In such a 7522 situation, a SASL security layer SHOULD be negotiated that 7523 effectively ignores the presence of the lower-layer security. 7525 Many deployed XMPP services authenticate client connections by means 7526 of passwords. It is well known that most human users choose 7527 relatively weak passwords. Although service provisioning is out of 7528 scope for this document, XMPP servers that allow password-based 7529 authentication SHOULD enforce minimal criteria for password strength 7530 to help prevent dictionary attacks. Because all password-based 7531 authentication mechanisms are susceptible to password guessing 7532 attacks, XMPP servers MUST limit the number of retries allowed during 7533 SASL authentication, as described under Section 6.4.5. 7535 Some SASL mechanisms (e.g., [ANONYMOUS]) do not provide strong peer 7536 entity authentication of the client to the server. Service 7537 administrators are advised to enable such mechanisms with caution. 7538 Best practices for the use of the SASL ANONYMOUS mechanism in XMPP 7539 are described in [XEP-0175]. 7541 13.9.5. Use of TLS 7543 Implementations of TLS typically support multiple versions of the 7544 Transport Layer Security protocol as well as the older Secure Sockets 7545 Layer (SSL) protocol. Because of known security vulnerabilities, 7546 XMPP servers and clients MUST NOT request, offer, or use SSL 2.0. 7547 For further details, see Appendix E.2 of [TLS] along with [TLS-SSL2]. 7549 To prevent man-in-the-middle attacks, the TLS client (which might be 7550 an XMPP client or an XMPP server) MUST verify the certificate of the 7551 TLS server and MUST check its understanding of the server FQDN 7552 against the server's identity as presented in the TLS Certificate 7553 message as described under Section 13.7.2.1 (for further details, see 7554 [TLS-CERTS]. 7556 Support for TLS renegotiation is strictly OPTIONAL. However, 7557 implementations that support TLS renegotiation MUST implement and use 7558 the TLS Renegotiation Extension [TLS-NEG]. Further details are 7559 provided under Section 5.3.5. 7561 13.9.6. Use of UTF-8 7563 The use of UTF-8 makes it possible to transport non-ASCII characters, 7564 and thus enables character "spoofing" scenarios, in which a displayed 7565 value appears to be something other than it is. Furthermore, there 7566 are known attack scenarios related to the decoding of UTF-8 data. On 7567 both of these points, refer to [UTF-8] for more information. 7569 13.9.7. Use of XML 7571 Because XMPP is an application profile of the Extensible Markup 7572 Language [XML], many of the security considerations described in 7573 [XML-MEDIA] and [XML-GUIDE] also apply to XMPP. Several aspects of 7574 XMPP mitigate the risks described there, such as the prohibitions 7575 specified under Section 11.1 and the lack of external references to 7576 style sheets or transformations, but these mitigating factors are by 7577 no means comprehensive. 7579 13.10. Information Leaks 7581 13.10.1. IP Addresses 7583 A client's IP address and method of access MUST NOT be made public by 7584 a server (e.g., as typically occurs in [IRC]). 7586 13.10.2. Presence Information 7588 One of the core aspects of XMPP is presence: information about the 7589 network availability of an XMPP entity (i.e., whether the entity is 7590 currently online or offline). A "presence leak" occurs when an 7591 entity's network availability is inadvertently and involuntarily 7592 revealed to a second entity that is not authorized to know the first 7593 entity's network availability. 7595 Although presence is discussed more fully in [XMPP-IM], it is 7596 important to note that an XMPP server MUST NOT leak presence. In 7597 particular at the core XMPP level, real-time addressing and network 7598 availability is associated with a specific connected resource; 7599 therefore, any disclosure of a connected resource's full JID 7600 comprises a presence leak. To help prevent such a presence leak, a 7601 server MUST NOT return different stanza errors depending on whether a 7602 potential attacker sends XML stanzas to the entity's bare JID 7603 () or full JID 7604 (). 7606 13.11. Directory Harvesting 7608 If a server generates an error stanza in response to receiving a 7609 stanza for a user account that does not exist, using the stanza error condition (Section 8.3.3.19) can help 7611 protect against directory harvesting attacks, since this is the same 7612 error condition that is returned if, for instance, the namespace of 7613 an IQ child element is not understood, or if "offline message 7614 storage" ([XEP-0160]) or message forwarding is not enabled for a 7615 domain. However, subtle differences in the exact XML of error 7616 stanzas, as well as in the timing with which such errors are 7617 returned, can enable an attacker to determine the network presence of 7618 a user when more advanced blocking technologies are not used (see for 7619 instance [XEP-0016] and [XEP-0191]). Therefore, a server that 7620 exercises a higher level of caution might not return any error at all 7621 in response to certain kinds of received stanzas, so that a non- 7622 existent user appears to behave like a user that has no interest in 7623 conversing with the sender. 7625 13.12. Denial of Service 7627 [DOS] defines denial of service as follows: 7629 A Denial-of-Service (DoS) attack is an attack in which one or more 7630 machines target a victim and attempt to prevent the victim from 7631 doing useful work. The victim can be a network server, client or 7632 router, a network link or an entire network, an individual 7633 Internet user or a company doing business using the Internet, an 7634 Internet Service Provider (ISP), country, or any combination of or 7635 variant on these. 7637 Some considerations discussed in this document help to prevent denial 7638 of service attacks (e.g., the mandate that a server MUST NOT process 7639 XML stanzas from clients that have not yet provided appropriate 7640 authentication credentials and MUST NOT process XML stanzas from peer 7641 servers whose identity it has not either authenticated via SASL or 7642 weakly verified via Server Dialback). 7644 In addition, [XEP-0205] provides a detailed discussion of potential 7645 denial of service attacks against XMPP systems along with best 7646 practices for preventing such attacks. The recommendations include: 7648 1. A server implementation SHOULD enable a server administrator to 7649 limit the number of TCP connections that it will accept from a 7650 given IP address at any one time. If an entity attempts to 7651 connect but the maximum number of TCP connections has been 7652 reached, the receiving server MUST NOT allow the new connection 7653 to proceed. 7655 2. A server implementation SHOULD enable a server administrator to 7656 limit the number of TCP connection attempts that it will accept 7657 from a given IP address in a given time period. If an entity 7658 attempts to connect but the maximum number of connection attempts 7659 has been reached, the receiving server MUST NOT allow the new 7660 connection to proceed. 7662 3. A server implementation SHOULD enable a server administrator to 7663 limit the number of connected resources it will allow an account 7664 to bind at any one time. If a client attempts to bind a resource 7665 but it has already reached the configured number of allowable 7666 resources, the receiving server MUST return a stanza error (Section 8.3.3.18). 7669 4. A server implementation SHOULD enable a server administrator to 7670 limit the size of stanzas it will accept from a connected client 7671 or peer server (where "size" is inclusive of all XML markup as 7672 defined in Section 2.4 of [XML], from the opening "<" character 7673 of the stanza to the closing ">" character). A deployed server's 7674 maximum stanza size MUST NOT be smaller than 10000 bytes, which 7675 reflects a reasonable compromise between the benefits of 7676 expressiveness for originating entities and the costs of stanza 7677 processing for servers. A server implementation SHOULD NOT 7678 blindly set 10000 bytes as the default for all deployments but 7679 instead SHOULD enable server administrators to set their own 7680 limits. If a connected resource or peer server sends a stanza 7681 that violates the upper limit, the receiving server MUST either 7682 return a stanza error (Section 8.3.3.12), 7683 thus allowing the sender to recover, or close the stream with a 7684 stream error (Section 4.9.3.14). 7686 5. A server implementation SHOULD enable a server administrator to 7687 limit the number of XML stanzas that a connected client is 7688 allowed to send to distinct recipients within a given time 7689 period. If a connected client sends too many stanzas to distinct 7690 recipients in a given time period, the receiving server SHOULD 7691 NOT process the stanza and instead SHOULD return a stanza error (Section 8.3.3.12). 7694 6. A server implementation SHOULD enable a server administrator to 7695 limit the amount of bandwidth it will allow a connected client or 7696 peer server to use in a given time period. 7698 7. A server implementation MAY enable a server administrator to 7699 limit the types of stanzas (based on the extended content 7700 "payload") that it will allow a connected resource or peer server 7701 send over an active connection. Such limits and restrictions are 7702 a matter of deployment policy. 7704 8. A server implementation MAY refuse to route or deliver any stanza 7705 that it considers to be abusive, with or without returning an 7706 error to the sender. 7708 For more detailed recommendations regarding denial of service attacks 7709 in XMPP systems, refer to [XEP-0205]. 7711 13.13. Firewalls 7713 Although DNS SRV records can instruct connecting entities to use TCP 7714 ports other than 5222 (client-to-server) and 5269 (server-to-server), 7715 communication using XMPP typically occurs over those ports, which are 7716 registered with the IANA (see Section 14). Use of these well-known 7717 ports allows administrators to easily enable or disable XMPP activity 7718 through existing and commonly-deployed firewalls. 7720 13.14. Interdomain Federation 7722 The term "federation" is commonly used to describe communication 7723 between two servers. 7725 Because service provisioning is a matter of policy, it is OPTIONAL 7726 for any given server to support federation. If a particular server 7727 enables federation, it SHOULD enable strong security as previously 7728 described to ensure both authentication and confidentiality; 7729 compliant implementations SHOULD support TLS and SASL for this 7730 purpose. 7732 Before RFC 3920 defined TLS plus SASL EXTERNAL with certificates for 7733 encryption and authentication of server-to-server streams, the only 7734 method for weak identity verification of a peer server was Server 7735 Dialback as defined in [XEP-0220]. Even when [DNSSEC] is used, 7736 Server Dialback provides only weak identity verification and provides 7737 no confidentiality or integrity. At the time of writing, Server 7738 Dialback is still the most widely-used technique for some level of 7739 assurance over server-to-server streams. This reality introduces the 7740 possibility of a downgrade attack from TLS + SASL EXTERNAL to Server 7741 Dialback if an attacker can gain control of the channel and therefore 7742 convince the initiating server that the receiving server does not 7743 support TLS or does not have an appropriate certificate. To help 7744 prevent this attack, the parties SHOULD protect the channel using TLS 7745 before proceeding, even if the presented certificates are self-signed 7746 or otherwise untrusted. 7748 13.15. Non-Repudiation 7750 Systems that provide both peer entity authentication and data 7751 integrity have the potential to enable an entity to prove to a third 7752 party that another entity intended to send particular data. Although 7753 XMPP systems can provide both peer entity authentication and data 7754 integrity, XMPP was never designed to provide non-repudiation. 7756 14. IANA Considerations 7758 The following subsections update the registrations provided in 7759 [RFC3920]. This section is to be interpreted according to 7760 [IANA-GUIDE]. 7762 14.1. XML Namespace Name for TLS Data 7764 A URN sub-namespace for STARTTLS negotiation data in the Extensible 7765 Messaging and Presence Protocol (XMPP) is defined as follows. (This 7766 namespace name adheres to the format defined in [XML-REG].) 7768 URI: urn:ietf:params:xml:ns:xmpp-tls 7769 Specification: RFC XXXX 7770 Description: This is the XML namespace name for STARTTLS negotiation 7771 data in the Extensible Messaging and Presence Protocol (XMPP) as 7772 defined by RFC XXXX. 7773 Registrant Contact: IESG 7775 14.2. XML Namespace Name for SASL Data 7777 A URN sub-namespace for SASL negotiation data in the Extensible 7778 Messaging and Presence Protocol (XMPP) is defined as follows. (This 7779 namespace name adheres to the format defined in [XML-REG].) 7781 URI: urn:ietf:params:xml:ns:xmpp-sasl 7782 Specification: RFC XXXX 7783 Description: This is the XML namespace name for SASL negotiation 7784 data in the Extensible Messaging and Presence Protocol (XMPP) as 7785 defined by RFC XXXX. 7786 Registrant Contact: IESG 7788 14.3. XML Namespace Name for Stream Errors 7790 A URN sub-namespace for stream error data in the Extensible Messaging 7791 and Presence Protocol (XMPP) is defined as follows. (This namespace 7792 name adheres to the format defined in [XML-REG].) 7794 URI: urn:ietf:params:xml:ns:xmpp-streams 7795 Specification: RFC XXXX 7796 Description: This is the XML namespace name for stream error data in 7797 the Extensible Messaging and Presence Protocol (XMPP) as defined 7798 by RFC XXXX. 7799 Registrant Contact: IESG 7801 14.4. XML Namespace Name for Resource Binding 7803 A URN sub-namespace for resource binding in the Extensible Messaging 7804 and Presence Protocol (XMPP) is defined as follows. (This namespace 7805 name adheres to the format defined in [XML-REG].) 7807 URI: urn:ietf:params:xml:ns:xmpp-bind 7808 Specification: RFC XXXX 7809 Description: This is the XML namespace name for resource binding in 7810 the Extensible Messaging and Presence Protocol (XMPP) as defined 7811 by RFC XXXX. 7812 Registrant Contact: IESG 7814 14.5. XML Namespace Name for Stanza Errors 7816 A URN sub-namespace for stanza error data in the Extensible Messaging 7817 and Presence Protocol (XMPP) is defined as follows. (This namespace 7818 name adheres to the format defined in [XML-REG].) 7820 URI: urn:ietf:params:xml:ns:xmpp-stanzas 7821 Specification: RFC XXXX 7822 Description: This is the XML namespace name for stanza error data in 7823 the Extensible Messaging and Presence Protocol (XMPP) as defined 7824 by RFC XXXX. 7825 Registrant Contact: IESG 7827 14.6. GSSAPI Service Name 7829 The IANA has registered "xmpp" as a [GSS-API] service name, as 7830 defined under Section 6.6. 7832 14.7. Port Numbers and Service Names 7834 The IANA has registered "xmpp-client" and "xmpp-server" as keywords 7835 for [TCP] ports 5222 and 5269 respectively. In accordance with 7836 [IANA-PORTS], this document updates the existing registration, as 7837 follows. 7839 Service Name: xmpp-client 7840 Transport Protocol: TCP 7841 Description: A service offering support for connections by XMPP 7842 client applications 7843 Registrant: IETF XMPP Working Group 7844 Contact: IESG 7845 Reference: RFC XXXX 7846 Port Number: 5222 7848 Service Name: xmpp-server 7849 Transport Protocol: TCP 7850 Description: A service offering support for connections by XMPP 7851 server applications 7852 Registrant: IETF XMPP Working Group 7853 Contact: IESG 7854 Reference: RFC XXXX 7855 Port Number: 5269 7857 15. Conformance Requirements 7859 This section describes a protocol feature set that summarizes the 7860 conformance requirements of this specification. This feature set is 7861 appropriate for use in software certification, interoperability 7862 testing, and implementation reports. For each feature, this section 7863 provides the following information: 7865 o A human-readable name 7867 o An informational description 7869 o A reference to the particular section of this document that 7870 normatively defines the feature 7872 o Whether the feature applies to the Client role, the Server role, 7873 or both (where "N/A" signifies that the feature is not applicable 7874 to the specified role) 7876 o Whether the feature MUST or SHOULD be implemented, where the 7877 capitalized terms are to be understood as described in [KEYWORDS] 7879 The feature set specified here attempts to adhere to the concepts and 7880 formats proposed by Larry Masinter within the IETF's NEWTRK Working 7881 Group in 2005, as captured in [INTEROP]. Although this feature set 7882 is more detailed than called for by [REPORTS], it provides a suitable 7883 basis for the generation of implementation reports to be submitted in 7884 support of advancing this specification from Proposed Standard to 7885 Draft Standard in accordance with [PROCESS]. 7887 Feature: bind-gen 7888 Description: Generate a random resource on demand. 7889 Section: Section 7.6 7890 Roles: Client N/A, Server MUST. 7892 Feature: bind-mtn 7893 Description: Consider resource binding as mandatory-to-negotiate. 7894 Section: Section 7.3.1 7895 Roles: Client MUST, Server MUST. 7897 Feature: bind-restart 7898 Description: Do not restart the stream after negotiation of resource 7899 binding. 7900 Section: Section 7.3.2 7901 Roles: Client MUST, Server MUST. 7903 Feature: bind-support 7904 Description: Support binding of client resources to an authenticated 7905 stream. 7906 Section: Section 7 7907 Roles: Client MUST, Server MUST. 7909 Feature: sasl-correlate 7910 Description: When authenticating a stream peer using SASL, correlate 7911 the authentication identifier resulting from SASL negotiation with 7912 the 'from' address (if any) of the stream header it received from 7913 the peer. 7914 Section: Section 6.4.6 7915 Roles: Client SHOULD, Server SHOULD. 7917 Feature: sasl-errors 7918 Description: Support SASL errors during the negotiation process. 7919 Section: Section 6.5 7920 Roles: Client MUST, Server MUST. 7922 Feature: sasl-mtn 7923 Description: Consider SASL as mandatory-to-negotiate. 7924 Section: Section 6.3.1 7925 Roles: Client MUST, Server MUST. 7927 Feature: sasl-restart 7928 Description: Initiate or handle a stream restart after SASL 7929 negotiation. 7930 Section: Section 6.3.2 7931 Roles: Client MUST, Server MUST. 7933 Feature: sasl-support 7934 Description: Support the Simple Authentication and Security Layer 7935 for stream authentication. 7936 Section: Section 6 7937 Roles: Client MUST, Server MUST. 7939 Feature: security-mti-auth-scram 7940 Description: Support the SASL Salted Challenge Response (SCRAM) 7941 mechanism for authentication only (this implies support for both 7942 the SCRAM-SHA-1 and SCRAM-SHA-1-PLUS variants). 7943 Section: Section 13.8 7944 Roles: Client MUST, Server MUST. 7946 Feature: security-mti-both-external 7947 Description: Support TLS with SASL EXTERNAL for confidentiality and 7948 authentication. 7949 Section: Section 13.8 7950 Roles: Client SHOULD, Server MUST. 7952 Feature: security-mti-both-plain 7953 Description: Support TLS using the TLS_RSA_WITH_AES_128_CBC_SHA 7954 ciphersuite plus the SASL PLAIN mechanism for confidentiality and 7955 authentication. 7956 Section: Section 13.8 7957 Roles: Client SHOULD, Server MAY. 7959 Feature: security-mti-both-scram 7960 Description: Support TLS using the TLS_RSA_WITH_AES_128_CBC_SHA 7961 ciphersuite plus the SCRAM-SHA-1 and SCRAM-SHA-1-PLUS variants of 7962 the SASL SCRAM mechanism for confidentiality and authentication. 7963 Section: Section 13.8 7964 Roles: Client MUST, Server MUST. 7966 Feature: security-mti-confidentiality 7967 Description: Support TLS using the TLS_RSA_WITH_AES_128_CBC_SHA 7968 ciphersuite for confidentiality only. 7969 Section: Section 13.8 7970 Roles: Client N/A, Server SHOULD. 7972 Feature: stanza-attribute-from 7973 Description: Support the common 'from' attribute for all stanza 7974 kinds. 7976 Section: Section 8.1.1 7977 Roles: Client MUST, Server MUST. 7979 Feature: stanza-attribute-from-stamp 7980 Description: Stamp or rewrite the 'from' address of all stanzas 7981 received from connected clients. 7982 Section: Section 8.1.2.1 7983 Roles: Client N/A, Server MUST. 7985 Feature: stanza-attribute-from-validate 7986 Description: Validate the 'from' address of all stanzas received 7987 from peer servers. 7988 Section: Section 8.1.2.2 7989 Roles: Client N/A, Server MUST. 7991 Feature: stanza-attribute-id 7992 Description: Support the common 'id' attribute for all stanza kinds. 7993 Section: Section 8.1.3 7994 Roles: Client MUST, Server MUST. 7996 Feature: stanza-attribute-to 7997 Description: Support the common 'to' attribute for all stanza kinds. 7998 Section: Section 8.1.1 7999 Roles: Client MUST, Server MUST. 8001 Feature: stanza-attribute-to-validate 8002 Description: Ensure that all stanzas received from peer servers 8003 include a 'to' address. 8004 Section: Section 8.1.1 8005 Roles: Client N/A, Server MUST. 8007 Feature: stanza-attribute-type 8008 Description: Support the common 'type' attribute for all stanza 8009 kinds. 8010 Section: Section 8.1.4 8011 Roles: Client MUST, Server MUST. 8013 Feature: stanza-attribute-xmllang 8014 Description: Support the common 'xml:lang' attribute for all stanza 8015 kinds. 8016 Section: Section 8.1.5 8017 Roles: Client MUST, Server MUST. 8019 Feature: stanza-error 8020 Description: Generate and handle stanzas of type "error" for all 8021 stanza kinds. 8022 Section: Section 8.3 8023 Roles: Client MUST, Server MUST. 8025 Feature: stanza-error-child 8026 Description: Ensure that stanzas of type "error" include an 8027 child element. 8028 Section: Section 8.3 8029 Roles: Client MUST, Server MUST. 8031 Feature: stanza-error-id 8032 Description: Ensure that stanzas of type "error" preserve the 'id' 8033 provided in the triggering stanza. 8034 Section: Section 8.3 8035 Roles: Client MUST, Server MUST. 8037 Feature: stanza-error-reply 8038 Description: Do not reply to a stanza of type "error" with another 8039 stanza of type "error". 8040 Section: Section 8.3 8041 Roles: Client MUST, Server MUST. 8043 Feature: stanza-extension 8044 Description: Correctly process XML data qualified by an unsupported 8045 XML namespace, where "correctly process" means to ignore that 8046 portion of the stanza in the case of a message or presence stanza 8047 and return an error in the case of an IQ stanza (for the intended 8048 recipient), and to route or deliver the stanza (for a routing 8049 entity such as a server). 8050 Section: Section 8.4 8051 Roles: Client MUST, Server MUST. 8053 Feature: stanza-iq-child 8054 Description: Include exactly one child element in an stanza of 8055 type "get" or "set", zero or one child elements in an stanza 8056 of type "result", and one or two child elements in an stanza 8057 of type "error". 8058 Section: Section 8.2.3 8059 Roles: Client MUST, Server MUST. 8061 Feature: stanza-iq-id 8062 Description: Ensure that all stanzas include an 'id' 8063 attribute. 8065 Section: Section 8.2.3 8066 Roles: Client MUST, Server MUST. 8068 Feature: stanza-iq-reply 8069 Description: Reply to an stanza of type "get" or "set" with an 8070 stanza of type "result" or "error". 8071 Section: Section 8.2.3 8072 Roles: Client MUST, Server MUST. 8074 Feature: stanza-iq-type 8075 Description: Ensure that all stanzas include a 'type' 8076 attribute whose value is "get", "set", "result", or "error". 8077 Section: Section 8.2.3 8078 Roles: Client MUST, Server MUST. 8080 Feature: stanza-kind-iq 8081 Description: Support the stanza. 8082 Section: Section 8.2.3 8083 Roles: Client MUST, Server MUST. 8085 Feature: stanza-kind-message 8086 Description: Support the stanza. 8087 Section: Section 8.2.1 8088 Roles: Client MUST, Server MUST. 8090 Feature: stanza-kind-presence 8091 Description: Support the stanza. 8092 Section: Section 8.2.2 8093 Roles: Client MUST, Server MUST. 8095 Feature: stream-attribute-initial-from 8096 Description: Include a 'from' attribute in the initial stream 8097 header. 8098 Section: Section 4.7.1 8099 Roles: Client SHOULD, Server MUST. 8101 Feature: stream-attribute-initial-lang 8102 Description: Include an 'xml:lang' attribute in the initial stream 8103 header. 8104 Section: Section 4.7.4 8105 Roles: Client SHOULD, Server SHOULD. 8107 Feature: stream-attribute-initial-to 8108 Description: Include a 'to' attribute in the initial stream header. 8110 Section: Section 4.7.2 8111 Roles: Client MUST, Server MUST. 8113 Feature: stream-attribute-response-from 8114 Description: Include a 'from' attribute in the response stream 8115 header. 8116 Section: Section 4.7.1 8117 Roles: Client N/A, Server MUST. 8119 Feature: stream-attribute-response-id 8120 Description: Include an 'id' attribute in the response stream 8121 header. 8122 Section: Section 4.7.3 8123 Roles: Client N/A, Server MUST. 8125 Feature: stream-attribute-response-id-unique 8126 Description: Ensure that the 'id' attribute in the response stream 8127 header is unique within the context of the receiving entity. 8128 Section: Section 4.7.3 8129 Roles: Client N/A, Server MUST. 8131 Feature: stream-attribute-response-to 8132 Description: Include a 'to' attribute in the response stream header. 8133 Section: Section 4.7.2 8134 Roles: Client N/A, Server SHOULD. 8136 Feature: stream-error-generate 8137 Description: Generate a stream error (followed by a closing stream 8138 tag and termination of the TCP connection) upon detecting a 8139 stream-related error condition. 8140 Section: Section 4.9 8141 Roles: Client MUST, Server MUST. 8143 Feature: stream-fqdn-resolution 8144 Description: Resolve FQDNs before opening a TCP connection to the 8145 receiving entity. 8146 Section: Section 3.2 8147 Roles: Client MUST, Server MUST. 8149 Feature: stream-negotiation-complete 8150 Description: Do not consider the stream negotiation process to be 8151 complete until the receiving entity sends a stream features 8152 advertisement that is empty or that contains only voluntary-to- 8153 negotiate features. 8155 Section: Section 4.3.5 8156 Roles: Client MUST, Server MUST. 8158 Feature: stream-negotiation-features 8159 Description: Send stream features after sending a response stream 8160 header. 8161 Section: Section 4.3.2 8162 Roles: Client N/A, Server MUST. 8164 Feature: stream-negotiation-restart 8165 Description: Consider the previous stream to be replaced upon 8166 negotiation of a stream feature that necessitates a stream 8167 restart, and send or receive a new initial stream header after 8168 negotiation of such a stream feature. 8169 Section: Section 4.3.3 8170 Roles: Client MUST, Server MUST. 8172 Feature: stream-reconnect 8173 Description: Reconnect with exponential backoff if a TCP connection 8174 is terminated unexpectedly. 8175 Section: Section 3.3 8176 Roles: Client MUST, Server MUST. 8178 Feature: stream-tcp-binding 8179 Description: Bind an XML stream to a TCP connection. 8180 Section: Section 3 8181 Roles: Client MUST, Server MUST. 8183 Feature: tls-certs 8184 Description: Check the identity specified in a certificate that is 8185 presented during TLS negotiation. 8186 Section: Section 13.7.2 8187 Roles: Client MUST, Server MUST. 8189 Feature: tls-mtn 8190 Description: Consider TLS as mandatory-to-negotiate if STARTTLS is 8191 the only feature advertised or if the STARTTLS feature 8192 advertisement includes an empty element. 8193 Section: Section 5.3.1 8194 Roles: Client MUST, Server MUST. 8196 Feature: tls-restart 8197 Description: Initiate or handle a stream restart after TLS 8198 negotiation. 8200 Section: Section 5.3.2 8201 Roles: Client MUST, Server MUST. 8203 Feature: tls-support 8204 Description: Support Transport Layer Security for stream encryption. 8205 Section: Section 5 8206 Roles: Client MUST, Server MUST. 8208 Feature: tls-correlate 8209 Description: When validating a certificate presented by a stream 8210 peer during TLS negotiation, correlate the validated identity with 8211 the 'from' address (if any) of the stream header it received from 8212 the peer. 8213 Section: Section 13.7.2 8214 Roles: Client SHOULD, Server SHOULD. 8216 Feature: xml-namespace-content-client 8217 Description: Support 'jabber:client' as a content namespace. 8218 Section: Section 4.8.2 8219 Roles: Client MUST, Server MUST. 8221 Feature: xml-namespace-content-server 8222 Description: Support 'jabber:server' as a content namespace. 8223 Section: Section 4.8.2 8224 Roles: Client N/A, Server MUST. 8226 Feature: xml-namespace-streams-declaration 8227 Description: Ensure that there is a namespace declaration for the 8228 'http://etherx.jabber.org/streams' namespace. 8229 Section: Section 4.8.1 8230 Roles: Client MUST, Server MUST. 8232 Feature: xml-namespace-streams-prefix 8233 Description: Ensure that all elements qualified by the 8234 'http://etherx.jabber.org/streams' namespace are prefixed by the 8235 prefix (if any) defined in the namespace declaration. 8236 Section: Section 4.8.1 8237 Roles: Client MUST, Server MUST. 8239 Feature: xml-restriction-comment 8240 Description: Do not generate or accept XML comments. 8241 Section: Section 11.1 8242 Roles: Client MUST, Server MUST. 8244 Feature: xml-restriction-dtd 8245 Description: Do not generate or accept internal or external DTD 8246 subsets. 8247 Section: Section 11.1 8248 Roles: Client MUST, Server MUST. 8250 Feature: xml-restriction-pi 8251 Description: Do not generate or accept XML processing instructions. 8252 Section: Section 11.1 8253 Roles: Client MUST, Server MUST. 8255 Feature: xml-restriction-ref 8256 Description: Do not generate or accept internal or external entity 8257 references with the exception of the predefined entities. 8258 Section: Section 11.1 8259 Roles: Client MUST, Server MUST. 8261 Feature: xml-wellformed-xml 8262 Description: Do not generate or accept data that is not XML-well- 8263 formed. 8264 Section: Section 11.3 8265 Roles: Client MUST, Server MUST. 8267 Feature: xml-wellformed-ns 8268 Description: Do not generate or accept data that is not namespace- 8269 well-formed. 8270 Section: Section 11.3 8271 Roles: Client MUST, Server MUST. 8273 16. References 8275 16.1. Normative References 8277 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 8278 Encodings", RFC 4648, October 2006. 8280 [CHANNEL] Williams, N., "On the Use of Channel Bindings to Secure 8281 Channels", RFC 5056, November 2007. 8283 [CHANNEL-TLS] 8284 Altman, J., Williams, N., and L. Zhu, "Channel Bindings 8285 for TLS", RFC 5929, July 2010. 8287 [CHARSETS] 8288 Alvestrand, H., "IETF Policy on Character Sets and 8289 Languages", BCP 18, RFC 2277, January 1998. 8291 [DNS-CONCEPTS] 8292 Mockapetris, P., "Domain names - concepts and facilities", 8293 STD 13, RFC 1034, November 1987. 8295 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 8296 specifying the location of services (DNS SRV)", RFC 2782, 8297 February 2000. 8299 [IPv6-ADDR] 8300 Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 8301 Address Text Representation", RFC 5952, August 2010. 8303 [KEYWORDS] 8304 Bradner, S., "Key words for use in RFCs to Indicate 8305 Requirement Levels", BCP 14, RFC 2119, March 1997. 8307 [LANGMATCH] 8308 Phillips, A. and M. Davis, "Matching of Language Tags", 8309 BCP 47, RFC 4647, September 2006. 8311 [LANGTAGS] 8312 Phillips, A. and M. Davis, "Tags for Identifying 8313 Languages", BCP 47, RFC 5646, September 2009. 8315 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 8316 Adams, "X.509 Internet Public Key Infrastructure Online 8317 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 8319 [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 8320 Housley, R., and W. Polk, "Internet X.509 Public Key 8321 Infrastructure Certificate and Certificate Revocation List 8322 (CRL) Profile", RFC 5280, May 2008. 8324 [PKIX-ALGO] 8325 Jonsson, J. and B. Kaliski, "Public-Key Cryptography 8326 Standards (PKCS) #1: RSA Cryptography Specifications 8327 Version 2.1", RFC 3447, February 2003. 8329 [PKIX-SRV] 8330 Santesson, S., "Internet X.509 Public Key Infrastructure 8331 Subject Alternative Name for Expression of Service Name", 8332 RFC 4985, August 2007. 8334 [PLAIN] Zeilenga, K., "The PLAIN Simple Authentication and 8335 Security Layer (SASL) Mechanism", RFC 4616, August 2006. 8337 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 8338 Requirements for Security", BCP 106, RFC 4086, June 2005. 8340 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and 8341 Security Layer (SASL)", RFC 4422, June 2006. 8343 [SCRAM] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 8344 "Salted Challenge Response Authentication Mechanism 8345 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. 8347 [STRONGSEC] 8348 Schiller, J., "Strong Security Requirements for Internet 8349 Engineering Task Force Standard Protocols", BCP 61, 8350 RFC 3365, August 2002. 8352 [TCP] Postel, J., "Transmission Control Protocol", STD 7, 8353 RFC 793, September 1981. 8355 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 8356 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 8358 [TLS-CERTS] 8359 Saint-Andre, P. and J. Hodges, "Representation and 8360 Verification of Domain-Based Application Service Identity 8361 within Internet Public Key Infrastructure Using X.509 8362 (PKIX) Certificates in the Context of Transport Layer 8363 Security (TLS)", draft-saintandre-tls-server-id-check-12 8364 (work in progress), December 2010. 8366 [TLS-NEG] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 8367 "Transport Layer Security (TLS) Renegotiation Indication 8368 Extension", RFC 5746, February 2010. 8370 [TLS-SSL2] 8371 Polk, T. and S. Turner, "Prohibiting SSL Version 2.0", 8372 draft-ietf-tls-ssl2-must-not-04 (work in progress), 8373 December 2010. 8375 [UCS2] International Organization for Standardization, 8376 "Information Technology - Universal Multiple-octet coded 8377 Character Set (UCS) - Amendment 2: UCS Transformation 8378 Format 8 (UTF-8)", ISO Standard 10646-1 Addendum 2, 8379 October 1996. 8381 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 8382 6.0", 2010, 8383 . 8385 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 8386 10646", STD 63, RFC 3629, November 2003. 8388 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 8389 Resource Identifier (URI): Generic Syntax", STD 66, 8390 RFC 3986, January 2005. 8392 [X509] International Telecommunications Union, "Information 8393 technology - Open Systems Interconnection - The Directory: 8394 Public-key and attribute certificate frameworks", ITU- 8395 T Recommendation X.509, ISO Standard 9594-8, March 2000. 8397 [XML] Maler, E., Yergeau, F., Sperberg-McQueen, C., Paoli, J., 8398 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth 8399 Edition)", World Wide Web Consortium Recommendation REC- 8400 xml-20081126, November 2008, 8401 . 8403 [XML-GUIDE] 8404 Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for 8405 the Use of Extensible Markup Language (XML) 8406 within IETF Protocols", BCP 70, RFC 3470, January 2003. 8408 [XML-MEDIA] 8409 Murata, M., St. Laurent, S., and D. Kohn, "XML Media 8410 Types", RFC 3023, January 2001. 8412 [XML-NAMES] 8413 Thompson, H., Hollander, D., Layman, A., Bray, T., and R. 8414 Tobin, "Namespaces in XML 1.0 (Third Edition)", World Wide 8415 Web Consortium Recommendation REC-xml-names-20091208, 8416 December 2009, 8417 . 8419 [XMPP-ADDR] 8420 Saint-Andre, P., "Extensible Messaging and Presence 8421 Protocol (XMPP): Address Format", 8422 draft-ietf-xmpp-address-08 (work in progress), 8423 December 2010. 8425 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence 8426 Protocol (XMPP): Instant Messaging and Presence", 8427 draft-ietf-xmpp-3921bis-17 (work in progress), 8428 November 2010. 8430 16.2. Informative References 8432 [AAA] Housley, R. and B. Aboba, "Guidance for Authentication, 8433 Authorization, and Accounting (AAA) Key Management", 8434 BCP 132, RFC 4962, July 2007. 8436 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 8437 Specifications: ABNF", STD 68, RFC 5234, January 2008. 8439 [ACAP] Newman, C. and J. Myers, "ACAP -- Application 8440 Configuration Access Protocol", RFC 2244, November 1997. 8442 [ANONYMOUS] 8443 Zeilenga, K., "Anonymous Simple Authentication and 8444 Security Layer (SASL) Mechanism", RFC 4505, June 2006. 8446 [ASN.1] CCITT, "Recommendation X.208: Specification of Abstract 8447 Syntax Notation One (ASN.1)", 1988. 8449 [DIGEST-MD5] 8450 Leach, P. and C. Newman, "Using Digest Authentication as a 8451 SASL Mechanism", RFC 2831, May 2000. 8453 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. 8454 Rose, "DNS Security Introduction and Requirements", 8455 RFC 4033, March 2005. 8457 [DNS-TXT] Rosenbaum, R., "Using the Domain Name System To Store 8458 Arbitrary String Attributes", RFC 1464, May 1993. 8460 [DOS] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 8461 Service Considerations", RFC 4732, December 2006. 8463 [E2E-REQS] 8464 Saint-Andre, P., "Requirements for End-to-End Encryption 8465 in the Extensible Messaging and Presence Protocol (XMPP)", 8466 draft-ietf-xmpp-e2e-requirements-01 (work in progress), 8467 March 2010. 8469 [EMAIL-ARCH] 8470 Crocker, D., "Internet Mail Architecture", RFC 5598, 8471 July 2009. 8473 [ETHERNET] 8474 "Information technology - Telecommunications and 8475 information exchange between systems - Local and 8476 metropolitan area networks - Specific requirements - Part 8477 3: Carrier sense multiple access with collision detection 8478 (CSMA/CD) access method and physical layer 8479 specifications"", IEEE Standard 802.3, September 1998. 8481 [GSS-API] Linn, J., "Generic Security Service Application Program 8482 Interface Version 2, Update 1", RFC 2743, January 2000. 8484 [HASHES] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 8485 Hashes in Internet Protocols", RFC 4270, November 2005. 8487 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 8488 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 8489 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 8491 [IANA-GUIDE] 8492 Narten, T. and H. Alvestrand, "Guidelines for Writing an 8493 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 8494 May 2008. 8496 [IANA-PORTS] 8497 Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 8498 Cheshire, "Internet Assigned Numbers Authority (IANA) 8499 Procedures for the Management of the Transport Protocol 8500 Port Number and Service Name Registry", 8501 draft-ietf-tsvwg-iana-ports-09 (work in progress), 8502 December 2010. 8504 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 8505 4rev1", RFC 3501, March 2003. 8507 [IMP-REQS] 8508 Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging 8509 / Presence Protocol Requirements", RFC 2779, 8510 February 2000. 8512 [INTEROP] Masinter, L., "Formalizing IETF Interoperability 8513 Reporting", draft-ietf-newtrk-interop-reports-00 (work in 8514 progress), October 2005. 8516 [IRC] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, 8517 April 2000. 8519 [IRI] Duerst, M. and M. Suignard, "Internationalized Resource 8520 Identifiers (IRIs)", RFC 3987, January 2005. 8522 [LDAP] Zeilenga, K., "Lightweight Directory Access Protocol 8523 (LDAP): Technical Specification Road Map", RFC 4510, 8524 June 2006. 8526 [LINKLOCAL] 8527 Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 8528 Configuration of IPv4 Link-Local Addresses", RFC 3927, 8529 May 2005. 8531 [MAILBOXES] 8532 Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 8533 FUNCTIONS", RFC 2142, May 1997. 8535 [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 8536 STD 53, RFC 1939, May 1996. 8538 [PROCESS] Bradner, S., "The Internet Standards Process -- Revision 8539 3", BCP 9, RFC 2026, October 1996. 8541 [REPORTS] Dusseault, L. and R. Sparks, "Guidance on Interoperation 8542 and Implementation Reports for Advancement to Draft 8543 Standard", BCP 9, RFC 5657, September 2009. 8545 [REST] Fielding, R., "Architectural Styles and the Design of 8546 Network-based Software Architectures", 2000. 8548 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 8549 Protocol (XMPP): Core", RFC 3920, October 2004. 8551 [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence 8552 Protocol (XMPP): Instant Messaging and Presence", 8553 RFC 3921, October 2004. 8555 [SASLPREP] 8556 Zeilenga, K., "SASLprep: Stringprep Profile for User Names 8557 and Passwords", RFC 4013, February 2005. 8559 [SEC-TERMS] 8560 Shirey, R., "Internet Security Glossary, Version 2", 8561 RFC 4949, August 2007. 8563 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 8564 October 2008. 8566 [SEC-GUIDE] 8567 Rescorla, E. and B. Korver, "Guidelines for Writing RFC 8568 Text on Security Considerations", BCP 72, RFC 3552, 8569 July 2003. 8571 [TLS-EXT] 3rd, D., "Transport Layer Security (TLS) Extensions: 8572 Extension Definitions", draft-ietf-tls-rfc4366-bis-12 8573 (work in progress), September 2010. 8575 [TLS-RESUME] 8576 Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 8577 "Transport Layer Security (TLS) Session Resumption without 8578 Server-Side State", RFC 5077, January 2008. 8580 [URN-OID] Mealling, M., "A URN Namespace of Object Identifiers", 8581 RFC 3061, February 2001. 8583 [USINGTLS] 8584 Newman, C., "Using TLS with IMAP, POP3 and ACAP", 8585 RFC 2595, June 1999. 8587 [UUID] Leach, P., Mealling, M., and R. Salz, "A Universally 8588 Unique IDentifier (UUID) URN Namespace", RFC 4122, 8589 July 2005. 8591 [XEP-0001] 8592 Saint-Andre, P., "XMPP Extension Protocols", XSF XEP 0001, 8593 January 2008. 8595 [XEP-0016] 8596 Millard, P. and P. Saint-Andre, "Privacy Lists", XSF 8597 XEP 0016, February 2007. 8599 [XEP-0045] 8600 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, 8601 July 2007. 8603 [XEP-0060] 8604 Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 8605 Subscribe", XSF XEP 0060, September 2008. 8607 [XEP-0071] 8608 Saint-Andre, P., "XHTML-IM", XSF XEP 0071, September 2008. 8610 [XEP-0077] 8611 Saint-Andre, P., "In-Band Registration", XSF XEP 0077, 8612 January 2006. 8614 [XEP-0086] 8615 Norris, R. and P. Saint-Andre, "Error Condition Mappings", 8616 XSF XEP 0086, February 2004. 8618 [XEP-0100] 8619 Saint-Andre, P. and D. Smith, "Gateway Interaction", XSF 8620 XEP 0100, October 2005. 8622 [XEP-0114] 8623 Saint-Andre, P., "Jabber Component Protocol", XSF 8624 XEP 0114, March 2005. 8626 [XEP-0124] 8627 Paterson, I., Smith, D., and P. Saint-Andre, 8628 "Bidirectional-streams Over Synchronous HTTP (BOSH)", XSF 8629 XEP 0124, April 2009. 8631 [XEP-0138] 8632 Hildebrand, J. and P. Saint-Andre, "Stream Compression", 8633 XSF XEP 0138, May 2009. 8635 [XEP-0156] 8636 Hildebrand, J. and P. Saint-Andre, "Discovering 8637 Alternative XMPP Connection Methods", XSF XEP 0156, 8638 June 2007. 8640 [XEP-0160] 8641 Saint-Andre, P., "Best Practices for Handling Offline 8642 Messages", XSF XEP 0160, January 2006. 8644 [XEP-0174] 8645 Saint-Andre, P., "Link-Local Messaging", XSF XEP 0174, 8646 November 2008. 8648 [XEP-0175] 8649 Saint-Andre, P., "Best Practices for Use of SASL 8650 ANONYMOUS", XSF XEP 0175, November 2007. 8652 [XEP-0178] 8653 Saint-Andre, P. and P. Millard, "Best Practices for Use of 8654 SASL EXTERNAL with Certificates", XSF XEP 0178, 8655 February 2007. 8657 [XEP-0191] 8658 Saint-Andre, P., "Simple Communications Blocking", XSF 8659 XEP 0191, February 2007. 8661 [XEP-0198] 8662 Karneges, J., Hildebrand, J., Saint-Andre, P., and F. 8663 Forno, "Stream Management", XSF XEP 0198, June 2009. 8665 [XEP-0199] 8666 Saint-Andre, P., "XMPP Ping", XSF XEP 0199, June 2009. 8668 [XEP-0205] 8669 Saint-Andre, P., "Best Practices to Discourage Denial of 8670 Service Attacks", XSF XEP 0205, January 2009. 8672 [XEP-0206] 8673 Paterson, I., "XMPP Over BOSH", XSF XEP 0206, 8674 October 2008. 8676 [XEP-0220] 8677 Miller, J., Saint-Andre, P., and P. Hancke, "Server 8678 Dialback", XSF XEP 0220, March 2010. 8680 [XEP-0225] 8681 Saint-Andre, P., "Component Connections", XSF XEP 0225, 8682 October 2008. 8684 [XEP-0233] 8685 Miller, M., Saint-Andre, P., and J. Hildebrand, "Domain- 8686 Based Service Names in XMPP SASL Negotiation", XSF 8687 XEP 0233, June 2010. 8689 [XEP-0288] 8690 Hancke, P. and D. Cridland, "Bidirectional Server-to- 8691 Server Connections", XSF XEP 0288, October 2010. 8693 [XML-FRAG] 8694 Grosso, P. and D. Veillard, "XML Fragment Interchange", 8695 World Wide Web Consortium CR CR-xml-fragment-20010212, 8696 February 2001, 8697 . 8699 [XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 8700 January 2004. 8702 [XML-SCHEMA] 8703 Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech, 8704 "XML Schema Part 1: Structures Second Edition", World Wide 8705 Web Consortium Recommendation REC-xmlschema-1-20041028, 8706 October 2004, 8707 . 8709 [XMPP-URI] 8710 Saint-Andre, P., "Internationalized Resource Identifiers 8711 (IRIs) and Uniform Resource Identifiers (URIs) for the 8712 Extensible Messaging and Presence Protocol (XMPP)", 8713 RFC 5122, February 2008. 8715 Appendix A. XML Schemas 8717 The following schemas formally define various namespaces used in this 8718 document, in conformance with [XML-SCHEMA]. Because validation of 8719 XML streams and stanzas is optional, these schemas are not normative 8720 and are provided for descriptive purposes only. 8722 A.1. Stream Namespace 8723 8725 8731 8732 8733 8734 8735 8737 8738 8739 8741 8744 8747 8750 8754 8755 8756 8757 8758 8759 8760 8761 8762 8763 8764 8765 8766 8767 8768 8769 8770 8771 8772 8773 8774 8775 8777 8778 8779 8780 8784 8785 8786 8788 8789 8790 8791 8792 8795 8799 8800 8801 8803 8805 A.2. Stream Error Namespace 8807 8809 8815 8816 8817 8818 8819 8820 8821 8822 8823 8824 8825 8826 8827 8828 8829 8830 8831 8832 8833 8834 8835 8836 8837 8838 8839 8841 8842 8843 8844 8845 8846 8847 8848 8849 8850 8851 8852 8853 8854 8855 8856 8857 8858 8859 8860 8861 8862 8863 8864 8865 8866 8867 8868 8869 8871 8872 8873 8874 8875 8876 8877 8878 8879 8881 8882 8883 8884 8885 8887 8889 A.3. STARTTLS Namespace 8891 8893 8899 8900 8901 8902 8903 8904 8905 8907 8909 8911 8912 8913 8914 8915 8917 8919 A.4. SASL Namespace 8921 8923 8929 8930 8931 8932 8936 8940 8941 8942 8944 8946 8947 8948 8949 8950 8953 8954 8955 8956 8958 8960 8962 8964 8965 8966 8967 8968 8969 8970 8971 8972 8973 8974 8975 8976 8977 8978 8979 8980 8981 8982 8983 8984 8985 8986 8987 8988 8989 8990 8991 8992 8994 8995 8996 8997 8998 9000 9002 A.5. Client Namespace 9004 9006 9012 9015 9016 9017 9018 9019 9020 9021 9022 9023 9027 9029 9030 9033 9036 9039 9042 9043 9044 9045 9046 9047 9048 9049 9050 9051 9052 9053 9054 9056 9057 9058 9059 9060 9061 9062 9063 9064 9066 9067 9068 9069 9070 9071 9072 9073 9074 9076 9077 9078 9079 9080 9083 9084 9085 9086 9088 9089 9090 9091 9092 9093 9094 9095 9096 9100 9102 9103 9106 9109 9112 9113 9114 9115 9116 9117 9118 9119 9120 9121 9122 9123 9124 9125 9126 9127 9128 9129 9130 9131 9132 9133 9134 9135 9136 9137 9139 9140 9141 9142 9143 9144 9145 9146 9147 9149 9150 9151 9152 9153 9154 9156 9158 9159 9160 9161 9165 9167 9168 9171 9174 9177 9178 9179 9180 9181 9182 9183 9184 9185 9186 9187 9188 9189 9191 9192 9193 9194 9195 9197 9198 9201 9202 9203 9204 9205 9206 9207 9208 9209 9210 9211 9212 9213 9215 9217 A.6. Server Namespace 9219 9221 9227 9230 9231 9232 9233 9234 9235 9236 9237 9238 9242 9244 9245 9248 9251 9254 9257 9258 9259 9260 9261 9262 9263 9264 9265 9266 9267 9268 9269 9271 9272 9273 9274 9275 9276 9277 9278 9279 9281 9282 9283 9284 9285 9286 9287 9288 9289 9291 9292 9293 9294 9295 9298 9299 9300 9301 9303 9304 9305 9306 9307 9310 9311 9312 9313 9315 9316 9317 9318 9319 9320 9321 9322 9323 9327 9329 9330 9333 9336 9339 9340 9341 9342 9343 9344 9345 9346 9347 9348 9349 9350 9351 9352 9353 9354 9356 9357 9358 9359 9360 9361 9362 9363 9364 9365 9367 9368 9369 9370 9371 9372 9373 9374 9375 9377 9378 9379 9380 9381 9382 9384 9386 9387 9388 9389 9393 9395 9396 9399 9402 9405 9406 9407 9408 9409 9410 9411 9412 9413 9414 9415 9417 9418 9420 9421 9422 9423 9424 9426 9427 9430 9431 9432 9433 9434 9435 9436 9437 9438 9439 9440 9441 9442 9444 9446 A.7. Resource Binding Namespace 9448 9450 9456 9457 9458 9459 9460 9461 9462 9463 9465 9466 9467 9468 9469 9470 9472 9473 9474 9475 9476 9477 9479 9481 A.8. Stanza Error Namespace 9483 9485 9491 9492 9493 9494 9495 9496 9497 9498 9499 9500 9501 9502 9503 9504 9505 9506 9507 9508 9509 9510 9511 9512 9514 9515 9516 9517 9518 9519 9520 9521 9522 9523 9524 9525 9526 9527 9528 9529 9530 9531 9532 9533 9534 9535 9536 9537 9538 9539 9541 9542 9543 9544 9545 9546 9547 9548 9549 9551 9552 9553 9554 9555 9557 9559 Appendix B. Contact Addresses 9561 Consistent with [MAILBOXES], organization that offer XMPP services 9562 are encouraged to provide an Internet mailbox of "XMPP" for inquiries 9563 related to that service, where the host portion of the resulting 9564 mailto URI is the organization's domain, not the domain of the XMPP 9565 service itself (e.g., the XMPP service might be offered at 9566 im.example.com but the Internet mailbox would be ). 9568 Appendix C. Account Provisioning 9570 Account provisioning is out of scope for this specification. 9571 Possible methods for account provisioning include account creation by 9572 a server administrator and in-band account registration using the 9573 'jabber:iq:register' namespace as documented in [XEP-0077]. An XMPP 9574 server implementation or administrative function MUST ensure that any 9575 JID assigned during account provisioning (including localpart, 9576 domainpart, resourcepart, and separator characters) conforms to the 9577 canonical format for XMPP addresses defined in [XMPP-ADDR]. 9579 Appendix D. Differences from RFC 3920 9581 Based on consensus derived from implementation and deployment 9582 experience as well as formal interoperability testing, the following 9583 substantive modifications were made from RFC 3920 (in addition to 9584 numerous changes of an editorial nature). 9586 o Moved specification of the XMPP address format to a separate 9587 document. 9588 o Recommended or mandated use of the 'from' and 'to' attributes on 9589 stream headers. 9590 o More fully specified the stream closing handshake. 9591 o Specified the recommended stream reconnection algorithm. 9592 o Changed the name of the stream error 9593 condition to for compliance with the XML 9594 specification. 9595 o Removed the unnecessary and unused stream error (see 9596 RFC 3920 for historical documentation). 9597 o Specified return of the stream error in response 9598 to receipt of prohibited XML features. 9599 o More completely specified the format and handling of the stream error, including consistency with RFC 3986 and 9601 RFC 5952 with regard to IPv6 addresses (e.g., enclosing the IPv6 9602 address in square brackets '[' and ']'). 9603 o Specified that the SASL SCRAM mechanism is a mandatory-to- 9604 implement technology for client-to-server streams. 9605 o Specified that TLS plus the SASL PLAIN mechanism is a mandatory- 9606 to-implement technology for client-to-server streams. 9607 o Specified that support for the SASL EXTERNAL mechanism is required 9608 for servers but only recommended for clients (since end-user X.509 9609 certificates are difficult to obtain and not yet widely deployed). 9610 o Removed the hard two-connection rule for server-to-server streams. 9611 o More clearly specified the certificate profile for both public key 9612 certificates and issuer certificates. 9613 o Added the stream error (Section 4.9.3.16) condition to 9614 handle expired/revoked certificates or the addition of security- 9615 critical features to an existing stream. 9616 o Added the , , 9617 , , and SASL error conditions to handle error flows mistakenly 9619 left out of RFC 3920, discussed in RFC 4422 but not in RFC 2222, 9620 or needed to handle generic authentication failure. 9621 o Removed the unused stanza error. 9622 o Removed the unnecessary requirement for escaping of characters 9623 that map to certain predefined entities, since they do not need to 9624 be escaped in XML. 9625 o Clarified the process of DNS SRV lookups and fallbacks. 9626 o Clarified the handling of SASL security layers. 9627 o Clarified that a SASL simple user name is the localpart, not the 9628 bare JID. 9629 o Clarified the stream negotiation process and associated flow 9630 chart. 9631 o Clarified the handling of stream features. 9633 o Added a 'by' attribute to the element for stanza errors 9634 so that the entity that has detected the error can include its JID 9635 for diagnostic or tracking purposes. 9636 o Clarified the handling of data that violates the well-formedness 9637 definitions for XML 1.0 and XML namespaces. 9638 o Specified the security considerations in more detail, especially 9639 with regard to presence leaks and denial of service attacks. 9640 o Moved documentation of the Server Dialback protocol from this 9641 specification to a separate specification maintained by the XMPP 9642 Standards Foundation. 9644 Appendix E. Acknowledgements 9646 This document is an update to, and derived from, RFC 3920. This 9647 document would have been impossible without the work of the 9648 contributors and commenters acknowledged there. 9650 Hundreds of people have provided implementation feedback, bug 9651 reports, requests for clarification, and suggestions for improvement 9652 since publication of RFC 3920. Although the document editor has 9653 endeavored to address all such feedback, he is solely responsible for 9654 any remaining errors and ambiguities. 9656 Special thanks are due to Kevin Smith, Matthew Wild, Dave Cridland, 9657 Philipp Hancke, Waqas Hussain, Florian Zeitz, Ben Campbell, Jehan 9658 Pages, Paul Aurich, Justin Karneges, Kurt Zeilenga, Simon Josefsson, 9659 Ralph Meijer, Curtis King, and others for their comments during 9660 Working Group Last Call. 9662 Thanks also to Yaron Sheffer and Elwyn Davies for their reviews on 9663 behalf of the Security Directorate and the General Area Review Team, 9664 respectively. 9666 The Working Group chairs were Ben Campbell and Joe Hildebrand. The 9667 responsible Area Director was Gonzalo Camarillo. 9669 Author's Address 9671 Peter Saint-Andre 9672 Cisco 9673 1899 Wyknoop Street, Suite 600 9674 Denver, CO 80202 9675 USA 9677 Phone: +1-303-308-3282 9678 Email: psaintan@cisco.com