diff options
Diffstat (limited to 'doc/rfc/rfc3920.txt')
| -rw-r--r-- | doc/rfc/rfc3920.txt | 5043 |
1 files changed, 5043 insertions, 0 deletions
diff --git a/doc/rfc/rfc3920.txt b/doc/rfc/rfc3920.txt new file mode 100644 index 0000000..2abd1cd --- /dev/null +++ b/doc/rfc/rfc3920.txt @@ -0,0 +1,5043 @@ + + + + + + +Network Working Group P. Saint-Andre, Ed. +Request for Comments: 3920 Jabber Software Foundation +Category: Standards Track October 2004 + + + Extensible Messaging and Presence Protocol (XMPP): Core + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This memo defines the core features of the Extensible Messaging and + Presence Protocol (XMPP), a protocol for streaming Extensible Markup + Language (XML) elements in order to exchange structured information + in close to real time between any two network endpoints. While XMPP + provides a generalized, extensible framework for exchanging XML data, + it is used mainly for the purpose of building instant messaging and + presence applications that meet the requirements of RFC 2779. + + + + + + + + + + + + + + + + + + + + + + + +Saint-Andre, Ed. Standards Track [Page 1] + +RFC 3920 XMPP Core October 2004 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Generalized Architecture . . . . . . . . . . . . . . . . . . 3 + 3. Addressing Scheme . . . . . . . . . . . . . . . . . . . . . 5 + 4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . 7 + 5. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 6. Use of SASL . . . . . . . . . . . . . . . . . . . . . . . . 27 + 7. Resource Binding . . . . . . . . . . . . . . . . . . . . . . 37 + 8. Server Dialback . . . . . . . . . . . . . . . . . . . . . . 41 + 9. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . 48 + 10. Server Rules for Handling XML Stanzas . . . . . . . . . . . 58 + 11. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 60 + 12. Core Compliance Requirements . . . . . . . . . . . . . . . . 62 + 13. Internationalization Considerations . . . . . . . . . . . . 64 + 14. Security Considerations . . . . . . . . . . . . . . . . . . 64 + 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 69 + 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 71 + A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . . . . . 75 + B. Resourceprep . . . . . . . . . . . . . . . . . . . . . . . . 76 + C. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . 78 + D. Differences Between Core Jabber Protocols and XMPP . . . . . 87 + Contributors. . . . . . . . . . . . . . . . . . . . . . . . . . . 89 + Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . . 89 + Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 89 + Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 90 + +1. Introduction + +1.1. Overview + + The Extensible Messaging and Presence Protocol (XMPP) is an open + Extensible Markup Language [XML] protocol for near-real-time + messaging, presence, and request-response services. The basic syntax + and semantics were developed originally within the Jabber open-source + community, mainly in 1999. In 2002, the XMPP WG was chartered with + developing an adaptation of the Jabber protocol that would be + suitable as an IETF instant messaging (IM) and presence technology. + As a result of work by the XMPP WG, the current memo defines the core + features of XMPP 1.0; the extensions required to provide the instant + messaging and presence functionality defined in RFC 2779 [IMP-REQS] + are specified in the Extensible Messaging and Presence Protocol + (XMPP): Instant Messaging and Presence [XMPP-IM]. + + + + + + + + +Saint-Andre, Ed. Standards Track [Page 2] + +RFC 3920 XMPP Core October 2004 + + +1.2. Terminology + + The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", + "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14, RFC 2119 [TERMS]. + +2. Generalized Architecture + +2.1. Overview + + Although XMPP is not wedded to any specific network architecture, to + date it usually has been implemented via a client-server architecture + wherein a client utilizing XMPP accesses a server over a [TCP] + connection, and servers also communicate with each other over TCP + connections. + + The following diagram provides a high-level overview of this + architecture (where "-" represents communications that use XMPP and + "=" represents communications that use any other protocol). + + C1----S1---S2---C3 + | + C2----+--G1===FN1===FC1 + + The symbols are as follows: + + o C1, C2, C3 = XMPP clients + + o S1, S2 = XMPP servers + + o G1 = A gateway that translates between XMPP and the protocol(s) + used on a foreign (non-XMPP) messaging network + + o FN1 = A foreign messaging network + + o FC1 = A client on a foreign messaging network + +2.2. Server + + A server acts as an intelligent abstraction layer for XMPP + communications. Its primary responsibilities are: + + o to manage connections from or sessions for other entities, in the + form of XML streams (Section 4) to and from authorized clients, + servers, and other entities + + + + + +Saint-Andre, Ed. Standards Track [Page 3] + +RFC 3920 XMPP Core October 2004 + + + o to route appropriately-addressed XML stanzas (Section 9) among + such entities over XML streams + + Most XMPP-compliant servers also assume responsibility for the + storage of data that is used by clients (e.g., contact lists for + users of XMPP-based instant messaging and presence applications); in + this case, the XML data is processed directly by the server itself on + behalf of the client and is not routed to another entity. + +2.3. Client + + Most clients connect directly to a server over a [TCP] connection and + use XMPP to take full advantage of the functionality provided by a + server and any associated services. Multiple resources (e.g., + devices or locations) MAY connect simultaneously to a server on + behalf of each authorized client, with each resource differentiated + by the resource identifier of an XMPP address (e.g., <node@domain/ + home> vs. <node@domain/work>) as defined under Addressing Scheme + (Section 3). The RECOMMENDED port for connections between a client + and a server is 5222, as registered with the IANA (see Port Numbers + (Section 15.9)). + +2.4. Gateway + + A gateway is a special-purpose server-side service whose primary + function is to translate XMPP into the protocol used by a foreign + (non-XMPP) messaging system, as well as to translate the return data + back into XMPP. Examples are gateways to email (see [SMTP]), + Internet Relay Chat (see [IRC]), SIMPLE (see [SIMPLE]), Short Message + Service (SMS), and legacy instant messaging services such as AIM, + ICQ, MSN Messenger, and Yahoo! Instant Messenger. Communications + between gateways and servers, and between gateways and the foreign + messaging system, are not defined in this document. + +2.5. Network + + Because each server is identified by a network address and because + server-to-server communications are a straightforward extension of + the client-to-server protocol, in practice, the system consists of a + network of servers that inter-communicate. Thus, for example, + <juliet@example.com> is able to exchange messages, presence, and + other information with <romeo@example.net>. This pattern is familiar + from messaging protocols (such as [SMTP]) that make use of network + addressing standards. Communications between any two servers are + OPTIONAL. If enabled, such communications SHOULD occur over XML + streams that are bound to [TCP] connections. The RECOMMENDED port + for connections between servers is 5269, as registered with the IANA + (see Port Numbers (Section 15.9)). + + + +Saint-Andre, Ed. Standards Track [Page 4] + +RFC 3920 XMPP Core October 2004 + + +3. Addressing Scheme + +3.1. Overview + + An entity is anything that can be considered a network endpoint + (i.e., an ID on the network) and that can communicate using XMPP. + All such entities are uniquely addressable in a form that is + consistent with RFC 2396 [URI]. For historical reasons, the address + of an XMPP entity is called a Jabber Identifier or JID. A valid JID + contains a set of ordered elements formed of a domain identifier, + node identifier, and resource identifier. + + The syntax for a JID is defined below using the Augmented Backus-Naur + Form as defined in [ABNF]. (The IPv4address and IPv6address rules + are defined in Appendix B of [IPv6]; the allowable character + sequences that conform to the node rule are defined by the Nodeprep + profile of [STRINGPREP] as documented in Appendix A of this memo; the + allowable character sequences that conform to the resource rule are + defined by the Resourceprep profile of [STRINGPREP] as documented in + Appendix B of this memo; and the sub-domain rule makes reference to + the concept of an internationalized domain label as described in + [IDNA].) + + + jid = [ node "@" ] domain [ "/" resource ] + domain = fqdn / address-literal + fqdn = (sub-domain 1*("." sub-domain)) + sub-domain = (internationalized domain label) + address-literal = IPv4address / IPv6address + + All JIDs are based on the foregoing structure. The most common use + of this structure is to identify an instant messaging user, the + server to which the user connects, and the user's connected resource + (e.g., a specific client) in the form of <user@host/resource>. + However, node types other than clients are possible; for example, a + specific chat room offered by a multi-user chat service could be + addressed as <room@service> (where "room" is the name of the chat + room and "service" is the hostname of the multi-user chat service) + and a specific occupant of such a room could be addressed as + <room@service/nick> (where "nick" is the occupant's room nickname). + Many other JID types are possible (e.g., <domain/resource> could be a + server-side script or service). + + Each allowable portion of a JID (node identifier, domain identifier, + and resource identifier) MUST NOT be more than 1023 bytes in length, + resulting in a maximum total size (including the '@' and '/' + separators) of 3071 bytes. + + + + +Saint-Andre, Ed. Standards Track [Page 5] + +RFC 3920 XMPP Core October 2004 + + +3.2. Domain Identifier + + The domain identifier is the primary identifier and is the only + REQUIRED element of a JID (a mere domain identifier is a valid JID). + It usually represents the network gateway or "primary" server to + which other entities connect for XML routing and data management + capabilities. However, the entity referenced by a domain identifier + is not always a server, and may be a service that is addressed as a + subdomain of a server that provides functionality above and beyond + the capabilities of a server (e.g., a multi-user chat service, a user + directory, or a gateway to a foreign messaging system). + + The domain identifier for every server or service that will + communicate over a network MAY be an IP address but SHOULD be a fully + qualified domain name (see [DNS]). A domain identifier MUST be an + "internationalized domain name" as defined in [IDNA], to which the + Nameprep [NAMEPREP] profile of stringprep [STRINGPREP] can be applied + without failing. Before comparing two domain identifiers, a server + MUST (and a client SHOULD) first apply the Nameprep profile to the + labels (as defined in [IDNA]) that make up each identifier. + +3.3. Node Identifier + + The node identifier is an optional secondary identifier placed before + the domain identifier and separated from the latter by the '@' + character. It usually represents the entity requesting and using + network access provided by the server or gateway (i.e., a client), + although it can also represent other kinds of entities (e.g., a chat + room associated with a multi-user chat service). The entity + represented by a node identifier is addressed within the context of a + specific domain; within instant messaging and presence applications + of XMPP, this address is called a "bare JID" and is of the form + <node@domain>. + + A node identifier MUST be formatted such that the Nodeprep profile of + [STRINGPREP] can be applied to it without failing. Before comparing + two node identifiers, a server MUST (and a client SHOULD) first apply + the Nodeprep profile to each identifier. + +3.4. Resource Identifier + + The resource identifier is an optional tertiary identifier placed + after the domain identifier and separated from the latter by the '/' + character. A resource identifier may modify either a <node@domain> + or a mere <domain> address. It usually represents a specific + session, connection (e.g., a device or location), or object (e.g., a + participant in a multi-user chat room) belonging to the entity + associated with a node identifier. A resource identifier is opaque + + + +Saint-Andre, Ed. Standards Track [Page 6] + +RFC 3920 XMPP Core October 2004 + + + to both servers and other clients, and is typically defined by a + client implementation when it provides the information necessary to + complete Resource Binding (Section 7) (although it may be generated + by a server on behalf of a client), after which it is referred to as + a "connected resource". An entity MAY maintain multiple connected + resources simultaneously, with each connected resource differentiated + by a distinct resource identifier. + + A resource identifier MUST be formatted such that the Resourceprep + profile of [STRINGPREP] can be applied without failing. Before + comparing two resource identifiers, a server MUST (and a client + SHOULD) first apply the Resourceprep profile to each identifier. + +3.5. Determination of Addresses + + After SASL negotiation (Section 6) and, if appropriate, Resource + Binding (Section 7), the receiving entity for a stream MUST determine + the initiating entity's JID. + + For server-to-server communications, the initiating entity's JID + SHOULD be the authorization identity, derived from the authentication + identity, as defined by the Simple Authentication and Security Layer + (SASL) specification [SASL], if no authorization identity was + specified during SASL negotiation (Section 6). + + For client-to-server communications, the "bare JID" (<node@domain>) + SHOULD be the authorization identity, derived from the authentication + identity, as defined in [SASL], if no authorization identity was + specified during SASL negotiation (Section 6); the resource + identifier portion of the "full JID" (<node@domain/resource>) SHOULD + be the resource identifier negotiated by the client and server during + Resource Binding (Section 7). + + The receiving entity MUST ensure that the resulting JID (including + node identifier, domain identifier, resource identifier, and + separator characters) conforms to the rules and formats defined + earlier in this section; to meet this restriction, the receiving + entity may need to replace the JID sent by the initiating entity with + the canonicalized JID as determined by the receiving entity. + +4. XML Streams + +4.1. Overview + + Two fundamental concepts make possible the rapid, asynchronous + exchange of relatively small payloads of structured information + between presence-aware entities: XML streams and XML stanzas. These + terms are defined as follows: + + + +Saint-Andre, Ed. Standards Track [Page 7] + +RFC 3920 XMPP Core October 2004 + + + Definition of XML Stream: An XML stream is a container for the + exchange of XML elements between any two entities over a network. + The start of an XML stream is denoted unambiguously by an opening + XML <stream> tag (with appropriate attributes and namespace + declarations), while the end of the XML stream is denoted + unambiguously by a closing XML </stream> tag. During the life of + the stream, the entity that initiated it can send an unbounded + number of XML elements over the stream, either elements used to + negotiate the stream (e.g., to negotiate Use of TLS (Section 5) or + use of SASL (Section 6)) or XML stanzas (as defined herein, + <message/>, <presence/>, or <iq/> elements qualified by the + default namespace). The "initial stream" is negotiated from the + initiating entity (usually a client or server) to the receiving + entity (usually a server), and can be seen as corresponding to the + initiating entity's "session" with the receiving entity. The + initial stream enables unidirectional communication from the + initiating entity to the receiving entity; in order to enable + information exchange from the receiving entity to the initiating + entity, the receiving entity MUST negotiate a stream in the + opposite direction (the "response stream"). + + Definition of XML Stanza: An XML stanza is a discrete semantic unit + of structured information that is sent from one entity to another + over an XML stream. An XML stanza exists at the direct child + level of the root <stream/> element and is said to be + well-balanced if it matches the production [43] content of [XML]. + The start of any XML stanza is denoted unambiguously by the + element start tag at depth=1 of the XML stream (e.g., <presence>), + and the end of any XML stanza is denoted unambiguously by the + corresponding close tag at depth=1 (e.g., </presence>). An XML + stanza MAY contain child elements (with accompanying attributes, + elements, and XML character data) as necessary in order to convey + the desired information. The only XML stanzas defined herein are + the <message/>, <presence/>, and <iq/> elements qualified by the + default namespace for the stream, as described under XML Stanzas + (Section 9); an XML element sent for the purpose of Transport + Layer Security (TLS) negotiation (Section 5), Simple + Authentication and Security Layer (SASL) negotiation (Section 6), + or server dialback (Section 8) is not considered to be an XML + stanza. + + Consider the example of a client's session with a server. In order + to connect to a server, a client MUST initiate an XML stream by + sending an opening <stream> tag to the server, optionally preceded by + a text declaration specifying the XML version and the character + encoding supported (see Inclusion of Text Declaration (Section 11.4); + see also Character Encoding (Section 11.5)). Subject to local + policies and service provisioning, the server SHOULD then reply with + + + +Saint-Andre, Ed. Standards Track [Page 8] + +RFC 3920 XMPP Core October 2004 + + + a second XML stream back to the client, again optionally preceded by + a text declaration. Once the client has completed SASL negotiation + (Section 6), the client MAY send an unbounded number of XML stanzas + over the stream to any recipient on the network. When the client + desires to close the stream, it simply sends a closing </stream> tag + to the server (alternatively, the stream may be closed by the + server), after which both the client and server SHOULD terminate the + underlying connection (usually a TCP connection) as well. + + Those who are accustomed to thinking of XML in a document-centric + manner may wish to view a client's session with a server as + consisting of two open-ended XML documents: one from the client to + the server and one from the server to the client. From this + perspective, the root <stream/> element can be considered the + document entity for each "document", and the two "documents" are + built up through the accumulation of XML stanzas sent over the two + XML streams. However, this perspective is a convenience only; XMPP + does not deal in documents but in XML streams and XML stanzas. + + In essence, then, an XML stream acts as an envelope for all the XML + stanzas sent during a session. We can represent this in a simplistic + fashion as follows: + + |--------------------| + | <stream> | + |--------------------| + | <presence> | + | <show/> | + | </presence> | + |--------------------| + | <message to='foo'> | + | <body/> | + | </message> | + |--------------------| + | <iq to='bar'> | + | <query/> | + | </iq> | + |--------------------| + | ... | + |--------------------| + | </stream> | + |--------------------| + + + + + + + + + +Saint-Andre, Ed. Standards Track [Page 9] + +RFC 3920 XMPP Core October 2004 + + +4.2. Binding to TCP + + Although there is no necessary coupling of an XML stream to a [TCP] + connection (e.g., two entities could connect to each other via + another mechanism such as polling over [HTTP]), this specification + defines a binding of XMPP to TCP only. In the context of + client-to-server communications, a server MUST allow a client to + share a single TCP connection for XML stanzas sent from client to + server and from server to client. In the context of server-to-server + communications, a server MUST use one TCP connection for XML stanzas + sent from the server to the peer and another TCP connection + (initiated by the peer) for stanzas from the peer to the server, for + a total of two TCP connections. + +4.3. Stream Security + + When negotiating XML streams in XMPP 1.0, TLS SHOULD be used as + defined under Use of TLS (Section 5) and SASL MUST be used as defined + under Use of SASL (Section 6). The "initial stream" (i.e., the + stream from the initiating entity to the receiving entity) and the + "response stream" (i.e., the stream from the receiving entity to the + initiating entity) MUST be secured separately, although security in + both directions MAY be established via mechanisms that provide mutual + authentication. An entity SHOULD NOT attempt to send XML Stanzas + (Section 9) over the stream before the stream has been authenticated, + but if it does, then the other entity MUST NOT accept such stanzas + and SHOULD return a <not-authorized/> stream error and then terminate + both the XML stream and the underlying TCP connection; note well that + this applies to XML stanzas only (i.e., <message/>, <presence/>, and + <iq/> elements scoped by the default namespace) and not to XML + elements used for stream negotiation (e.g., elements used to + negotiate Use of TLS (Section 5) or Use of SASL (Section 6)). + +4.4. Stream Attributes + + The attributes of the stream element are as follows: + + o to -- The 'to' attribute SHOULD be used only in the XML stream + header from the initiating entity to the receiving entity, and + MUST be set to a hostname serviced by the receiving entity. There + SHOULD NOT be a 'to' attribute set in the XML stream header by + which the receiving entity replies to the initiating entity; + however, if a 'to' attribute is included, it SHOULD be silently + ignored by the initiating entity. + + + + + + + +Saint-Andre, Ed. Standards Track [Page 10] + +RFC 3920 XMPP Core October 2004 + + + o from -- The 'from' attribute SHOULD be used only in the XML stream + header from the receiving entity to the initiating entity, and + MUST be set to a hostname serviced by the receiving entity that is + granting access to the initiating entity. There SHOULD NOT be a + 'from' attribute on the XML stream header sent from the initiating + entity to the receiving entity; however, if a 'from' attribute is + included, it SHOULD be silently ignored by the receiving entity. + + o id -- The 'id' attribute SHOULD be used only in the XML stream + header from the receiving entity to the initiating entity. This + attribute is a unique identifier created by the receiving entity + to function as a session key for the initiating entity's streams + with the receiving entity, and MUST be unique within the receiving + application (normally a server). Note well that the stream ID may + be security-critical and therefore MUST be both unpredictable and + nonrepeating (see [RANDOM] for recommendations regarding + randomness for security purposes). There SHOULD NOT be an 'id' + attribute on the XML stream header sent from the initiating entity + to the receiving entity; however, if an 'id' attribute is + included, it SHOULD be silently ignored by the receiving entity. + + o xml:lang -- An 'xml:lang' attribute (as defined in Section 2.12 of + [XML]) SHOULD be included by the initiating entity on the header + for the initial stream to specify the default language of any + human-readable XML character data it sends over that stream. If + the attribute is included, the receiving entity SHOULD remember + that value as the default for both the initial stream and the + response stream; if the attribute is not included, the receiving + entity SHOULD use a configurable default value for both streams, + which it MUST communicate in the header for the response stream. + For all stanzas sent over the initial stream, if the initiating + entity does not include an 'xml:lang' attribute, the receiving + entity SHOULD apply the default value; if the initiating entity + does include an 'xml:lang' attribute, the receiving entity MUST + NOT modify or delete it (see also xml:lang (Section 9.1.5)). The + value of the 'xml:lang' attribute MUST be an NMTOKEN (as defined + in Section 2.3 of [XML]) and MUST conform to the format defined in + RFC 3066 [LANGTAGS]. + + o version -- The presence of the version attribute set to a value of + at least "1.0" signals support for the stream-related protocols + (including stream features) defined in this specification. + Detailed rules regarding the generation and handling of this + attribute are defined below. + + + + + + + +Saint-Andre, Ed. Standards Track [Page 11] + +RFC 3920 XMPP Core October 2004 + + + We can summarize as follows: + + | initiating to receiving | receiving to initiating + ---------+---------------------------+----------------------- + to | hostname of receiver | silently ignored + from | silently ignored | hostname of receiver + id | silently ignored | session key + xml:lang | default language | default language + version | signals XMPP 1.0 support | signals XMPP 1.0 support + +4.4.1. Version Support + + The version of XMPP specified herein is "1.0"; in particular, this + encapsulates the stream-related protocols (Use of TLS (Section 5), + Use of SASL (Section 6), and Stream Errors (Section 4.7)), as well as + the semantics of the three defined XML stanza types (<message/>, + <presence/>, and <iq/>). The numbering scheme for XMPP versions is + "<major>.<minor>". The major and minor numbers MUST be treated as + separate integers and each number MAY be incremented higher than a + single digit. Thus, "XMPP 2.4" would be a lower version than "XMPP + 2.13", which in turn would be lower than "XMPP 12.3". Leading zeros + (e.g., "XMPP 6.01") MUST be ignored by recipients and MUST NOT be + sent. + + The major version number should be incremented only if the stream and + stanza formats or required actions have changed so dramatically that + an older version entity would not be able to interoperate with a + newer version entity if it simply ignored the elements and attributes + it did not understand and took the actions specified in the older + specification. The minor version number indicates new capabilities, + and MUST be ignored by an entity with a smaller minor version number, + but used for informational purposes by the entity with the larger + minor version number. For example, a minor version number might + indicate the ability to process a newly defined value of the 'type' + attribute for message, presence, or IQ stanzas; the entity with the + larger minor version number would simply note that its correspondent + would not be able to understand that value of the 'type' attribute + and therefore would not send it. + + The following rules apply to the generation and handling of the + 'version' attribute within stream headers by implementations: + + 1. The initiating entity MUST set the value of the 'version' + attribute on the initial stream header to the highest version + number it supports (e.g., if the highest version number it + supports is that defined in this specification, it MUST set the + value to "1.0"). + + + + +Saint-Andre, Ed. Standards Track [Page 12] + +RFC 3920 XMPP Core October 2004 + + + 2. The receiving entity MUST set the value of the 'version' + attribute on the response stream header to either the value + supplied by the initiating entity or the highest version number + supported by the receiving entity, whichever is lower. The + receiving entity MUST perform a numeric comparison on the major + and minor version numbers, not a string match on + "<major>.<minor>". + + 3. If the version number included in the response stream header is + at least one major version lower than the version number included + in the initial stream header and newer version entities cannot + interoperate with older version entities as described above, the + initiating entity SHOULD generate an <unsupported-version/> + stream error and terminate the XML stream and underlying TCP + connection. + + 4. If either entity receives a stream header with no 'version' + attribute, the entity MUST consider the version supported by the + other entity to be "0.0" and SHOULD NOT include a 'version' + attribute in the stream header it sends in reply. + +4.5. Namespace Declarations + + The stream element MUST possess both a streams namespace declaration + and a default namespace declaration (as "namespace declaration" is + defined in the XML namespaces specification [XML-NAMES]). For + detailed information regarding the streams namespace and default + namespace, see Namespace Names and Prefixes (Section 11.2). + +4.6. Stream Features + + If the initiating entity includes the 'version' attribute set to a + value of at least "1.0" in the initial stream header, the receiving + entity MUST send a <features/> child element (prefixed by the streams + namespace prefix) to the initiating entity in order to announce any + stream-level features that can be negotiated (or capabilities that + otherwise need to be advertised). Currently, this is used only to + advertise Use of TLS (Section 5), Use of SASL (Section 6), and + Resource Binding (Section 7) as defined herein, and for Session + Establishment as defined in [XMPP-IM]; however, the stream features + functionality could be used to advertise other negotiable features in + the future. If an entity does not understand or support some + features, it SHOULD silently ignore them. If one or more security + features (e.g., TLS and SASL) need to be successfully negotiated + before a non-security-related feature (e.g., Resource Binding) can be + offered, the non-security-related feature SHOULD NOT be included in + the stream features that are advertised before the relevant security + features have been negotiated. + + + +Saint-Andre, Ed. Standards Track [Page 13] + +RFC 3920 XMPP Core October 2004 + + +4.7. Stream Errors + + The root stream element MAY contain an <error/> child element that is + prefixed by the streams namespace prefix. The error child MUST be + sent by a compliant entity (usually a server rather than a client) if + it perceives that a stream-level error has occurred. + +4.7.1. Rules + + The following rules apply to stream-level errors: + + o It is assumed that all stream-level errors are unrecoverable; + therefore, if an error occurs at the level of the stream, the + entity that detects the error MUST send a stream error to the + other entity, send a closing </stream> tag, and terminate the + underlying TCP connection. + + o If the error occurs while the stream is being set up, the + receiving entity MUST still send the opening <stream> tag, include + the <error/> element as a child of the stream element, send the + closing </stream> tag, and terminate the underlying TCP + connection. In this case, if the initiating entity provides an + unknown host in the 'to' attribute (or provides no 'to' attribute + at all), the server SHOULD provide the server's authoritative + hostname in the 'from' attribute of the stream header sent before + termination. + +4.7.2. Syntax + + The syntax for stream errors is as follows: + + <stream:error> + <defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> + <text xmlns='urn:ietf:params:xml:ns:xmpp-streams' + xml:lang='langcode'> + OPTIONAL descriptive text + </text> + [OPTIONAL application-specific condition element] + </stream:error> + + The <error/> element: + + o MUST contain a child element corresponding to one of the defined + stanza error conditions defined below; this element MUST be + qualified by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace + + + + + + +Saint-Andre, Ed. Standards Track [Page 14] + +RFC 3920 XMPP Core October 2004 + + + o MAY contain a <text/> child containing XML character data that + describes the error in more detail; this element MUST be qualified + by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace and SHOULD + possess an 'xml:lang' attribute specifying the natural language of + the XML character data + + o MAY contain a child element for an application-specific error + condition; this element MUST be qualified by an + application-defined namespace, and its structure is defined by + that namespace + + The <text/> element is OPTIONAL. If included, it SHOULD be used only + to provide descriptive or diagnostic information that supplements the + meaning of a defined condition or application-specific condition. It + SHOULD NOT be interpreted programmatically by an application. It + SHOULD NOT be used as the error message presented to a user, but MAY + be shown in addition to the error message associated with the + included condition element (or elements). + +4.7.3. Defined Conditions + + The following stream-level error conditions are defined: + + o <bad-format/> -- the entity has sent XML that cannot be processed; + this error MAY be used instead of the more specific XML-related + errors, such as <bad-namespace-prefix/>, <invalid-xml/>, + <restricted-xml/>, <unsupported-encoding/>, and + <xml-not-well-formed/>, although the more specific errors are + preferred. + + o <bad-namespace-prefix/> -- the entity has sent a namespace prefix + that is unsupported, or has sent no namespace prefix on an element + that requires such a prefix (see XML Namespace Names and Prefixes + (Section 11.2)). + + o <conflict/> -- the server is closing the active stream for this + entity because a new stream has been initiated that conflicts with + the existing stream. + + o <connection-timeout/> -- the entity has not generated any traffic + over the stream for some period of time (configurable according to + a local service policy). + + o <host-gone/> -- the value of the 'to' attribute provided by the + initiating entity in the stream header corresponds to a hostname + that is no longer hosted by the server. + + + + + +Saint-Andre, Ed. Standards Track [Page 15] + +RFC 3920 XMPP Core October 2004 + + + o <host-unknown/> -- the value of the 'to' attribute provided by the + initiating entity in the stream header does not correspond to a + hostname that is hosted by the server. + + o <improper-addressing/> -- a stanza sent between two servers lacks + a 'to' or 'from' attribute (or the attribute has no value). + + o <internal-server-error/> -- the server has experienced a + misconfiguration or an otherwise-undefined internal error that + prevents it from servicing the stream. + + o <invalid-from/> -- the JID or hostname provided in a 'from' + address does not match an authorized JID or validated domain + negotiated between servers via SASL or dialback, or between a + client and a server via authentication and resource binding. + + o <invalid-id/> -- the stream ID or dialback ID is invalid or does + not match an ID previously provided. + + o <invalid-namespace/> -- the streams namespace name is something + other than "http://etherx.jabber.org/streams" or the dialback + namespace name is something other than "jabber:server:dialback" + (see XML Namespace Names and Prefixes (Section 11.2)). + + o <invalid-xml/> -- the entity has sent invalid XML over the stream + to a server that performs validation (see Validation (Section + 11.3)). + + o <not-authorized/> -- the entity has attempted to send data before + the stream has been authenticated, or otherwise is not authorized + to perform an action related to stream negotiation; the receiving + entity MUST NOT process the offending stanza before sending the + stream error. + + o <policy-violation/> -- the entity has violated some local service + policy; the server MAY choose to specify the policy in the <text/> + element or an application-specific condition element. + + o <remote-connection-failed/> -- the server is unable to properly + connect to a remote entity that is required for authentication or + authorization. + + o <resource-constraint/> -- the server lacks the system resources + necessary to service the stream. + + + + + + + +Saint-Andre, Ed. Standards Track [Page 16] + +RFC 3920 XMPP Core October 2004 + + + o <restricted-xml/> -- the entity has attempted to send restricted + XML features such as a comment, processing instruction, DTD, + entity reference, or unescaped character (see Restrictions + (Section 11.1)). + + o <see-other-host/> -- the server will not provide service to the + initiating entity but is redirecting traffic to another host; the + server SHOULD specify the alternate hostname or IP address (which + MUST be a valid domain identifier) as the XML character data of + the <see-other-host/> element. + + o <system-shutdown/> -- the server is being shut down and all active + streams are being closed. + + o <undefined-condition/> -- the error condition is not one of those + defined by the other conditions in this list; this error condition + SHOULD be used only in conjunction with an application-specific + condition. + + o <unsupported-encoding/> -- the initiating entity has encoded the + stream in an encoding that is not supported by the server (see + Character Encoding (Section 11.5)). + + o <unsupported-stanza-type/> -- the initiating entity has sent a + first-level child of the stream that is not supported by the + server. + + o <unsupported-version/> -- the value of the 'version' attribute + provided by the initiating entity in the stream header specifies a + version of XMPP that is not supported by the server; the server + MAY specify the version(s) it supports in the <text/> element. + + o <xml-not-well-formed/> -- the initiating entity has sent XML that + is not well-formed as defined by [XML]. + +4.7.4. Application-Specific Conditions + + As noted, an application MAY provide application-specific stream + error information by including a properly-namespaced child in the + error element. The application-specific element SHOULD supplement or + further qualify a defined element. Thus the <error/> element will + contain two or three child elements: + + + + + + + + + +Saint-Andre, Ed. Standards Track [Page 17] + +RFC 3920 XMPP Core October 2004 + + + <stream:error> + <xml-not-well-formed + xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> + <text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'> + Some special application diagnostic information! + </text> + <escape-your-data xmlns='application-ns'/> + </stream:error> + </stream:stream> + +4.8. Simplified Stream Examples + + This section contains two simplified examples of a stream-based + "session" of a client on a server (where the "C" lines are sent from + the client to the server, and the "S" lines are sent from the server + to the client); these examples are included for the purpose of + illustrating the concepts introduced thus far. + + A basic "session": + + C: <?xml version='1.0'?> + <stream:stream + to='example.com' + xmlns='jabber:client' + xmlns:stream='http://etherx.jabber.org/streams' + version='1.0'> + S: <?xml version='1.0'?> + <stream:stream + from='example.com' + id='someid' + xmlns='jabber:client' + xmlns:stream='http://etherx.jabber.org/streams' + version='1.0'> + ... encryption, authentication, and resource binding ... + C: <message from='juliet@example.com' + to='romeo@example.net' + xml:lang='en'> + C: <body>Art thou not Romeo, and a Montague?</body> + C: </message> + S: <message from='romeo@example.net' + to='juliet@example.com' + xml:lang='en'> + S: <body>Neither, fair saint, if either thee dislike.</body> + S: </message> + C: </stream:stream> + S: </stream:stream> + + + + + +Saint-Andre, Ed. Standards Track [Page 18] + +RFC 3920 XMPP Core October 2004 + + + A "session" gone bad: + + C: <?xml version='1.0'?> + <stream:stream + to='example.com' + xmlns='jabber:client' + xmlns:stream='http://etherx.jabber.org/streams' + version='1.0'> + S: <?xml version='1.0'?> + <stream:stream + from='example.com' + id='someid' + xmlns='jabber:client' + xmlns:stream='http://etherx.jabber.org/streams' + version='1.0'> + ... encryption, authentication, and resource binding ... + C: <message xml:lang='en'> + <body>Bad XML, no closing body tag! + </message> + S: <stream:error> + <xml-not-well-formed + xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> + </stream:error> + S: </stream:stream> + +5. Use of TLS + +5.1. Overview + + XMPP includes a method for securing the stream from tampering and + eavesdropping. This channel encryption method makes use of the + Transport Layer Security (TLS) protocol [TLS], along with a + "STARTTLS" extension that is modelled after similar extensions for + the IMAP [IMAP], POP3 [POP3], and ACAP [ACAP] protocols as described + in RFC 2595 [USINGTLS]. The namespace name for the STARTTLS + extension is 'urn:ietf:params:xml:ns:xmpp-tls'. + + An administrator of a given domain MAY require the use of TLS for + client-to-server communications, server-to-server communications, or + both. Clients SHOULD use TLS to secure the streams prior to + attempting the completion of SASL negotiation (Section 6), and + servers SHOULD use TLS between two domains for the purpose of + securing server-to-server communications. + + + + + + + + +Saint-Andre, Ed. Standards Track [Page 19] + +RFC 3920 XMPP Core October 2004 + + + The following rules apply: + + 1. An initiating entity that complies with this specification MUST + include the 'version' attribute set to a value of "1.0" in the + initial stream header. + + 2. If the TLS negotiation occurs between two servers, communications + MUST NOT proceed until the Domain Name System (DNS) hostnames + asserted by the servers have been resolved (see Server-to-Server + Communications (Section 14.4)). + + 3. When a receiving entity that complies with this specification + receives an initial stream header that includes the 'version' + attribute set to a value of at least "1.0", after sending a + stream header in reply (including the version flag), it MUST + include a <starttls/> element (qualified by the + 'urn:ietf:params:xml:ns:xmpp-tls' namespace) along with the list + of other stream features it supports. + + 4. If the initiating entity chooses to use TLS, TLS negotiation MUST + be completed before proceeding to SASL negotiation; this order of + negotiation is required to help safeguard authentication + information sent during SASL negotiation, as well as to make it + possible to base the use of the SASL EXTERNAL mechanism on a + certificate provided during prior TLS negotiation. + + 5. During TLS negotiation, an entity MUST NOT send any white space + characters (matching production [3] content of [XML]) within the + root stream element as separators between elements (any white + space characters shown in the TLS examples below are included for + the sake of readability only); this prohibition helps to ensure + proper security layer byte precision. + + 6. The receiving entity MUST consider the TLS negotiation to have + begun immediately after sending the closing ">" character of the + <proceed/> element. The initiating entity MUST consider the TLS + negotiation to have begun immediately after receiving the closing + ">" character of the <proceed/> element from the receiving + entity. + + 7. The initiating entity MUST validate the certificate presented by + the receiving entity; see Certificate Validation (Section 14.2) + regarding certificate validation procedures. + + 8. Certificates MUST be checked against the hostname as provided by + the initiating entity (e.g., a user), not the hostname as + resolved via the Domain Name System; e.g., if the user specifies + a hostname of "example.com" but a DNS SRV [SRV] lookup returned + + + +Saint-Andre, Ed. Standards Track [Page 20] + +RFC 3920 XMPP Core October 2004 + + + "im.example.com", the certificate MUST be checked as + "example.com". If a JID for any kind of XMPP entity (e.g., + client or server) is represented in a certificate, it MUST be + represented as a UTF8String within an otherName entity inside the + subjectAltName, using the [ASN.1] Object Identifier + "id-on-xmppAddr" specified in Section 5.1.1 of this document. + + 9. If the TLS negotiation is successful, the receiving entity MUST + discard any knowledge obtained in an insecure manner from the + initiating entity before TLS takes effect. + + 10. If the TLS negotiation is successful, the initiating entity MUST + discard any knowledge obtained in an insecure manner from the + receiving entity before TLS takes effect. + + 11. If the TLS negotiation is successful, the receiving entity MUST + NOT offer the STARTTLS extension to the initiating entity along + with the other stream features that are offered when the stream + is restarted. + + 12. If the TLS negotiation is successful, the initiating entity MUST + continue with SASL negotiation. + + 13. If the TLS negotiation results in failure, the receiving entity + MUST terminate both the XML stream and the underlying TCP + connection. + + 14. See Mandatory-to-Implement Technologies (Section 14.7) regarding + mechanisms that MUST be supported. + +5.1.1. ASN.1 Object Identifier for XMPP Address + + The [ASN.1] Object Identifier "id-on-xmppAddr" described above is + defined as follows: + + id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) + dod(6) internet(1) security(5) mechanisms(5) pkix(7) } + + id-on OBJECT IDENTIFIER ::= { id-pkix 8 } -- other name forms + + id-on-xmppAddr OBJECT IDENTIFIER ::= { id-on 5 } + + XmppAddr ::= UTF8String + + This Object Identifier MAY also be represented in the dotted display + format as "1.3.6.1.5.5.7.8.5". + + + + + +Saint-Andre, Ed. Standards Track [Page 21] + +RFC 3920 XMPP Core October 2004 + + +5.2. Narrative + + When an initiating entity secures a stream with a receiving entity + using TLS, the steps involved are as follows: + + 1. The initiating entity opens a TCP connection and initiates the + stream by sending the opening XML stream header to the receiving + entity, including the 'version' attribute set to a value of at + least "1.0". + + 2. The receiving entity responds by opening a TCP connection and + sending an XML stream header to the initiating entity, including + the 'version' attribute set to a value of at least "1.0". + + 3. The receiving entity offers the STARTTLS extension to the + initiating entity by including it with the list of other + supported stream features (if TLS is required for interaction + with the receiving entity, it SHOULD signal that fact by + including a <required/> element as a child of the <starttls/> + element). + + 4. The initiating entity issues the STARTTLS command (i.e., a + <starttls/> element qualified by the + 'urn:ietf:params:xml:ns:xmpp-tls' namespace) to instruct the + receiving entity that it wishes to begin a TLS negotiation to + secure the stream. + + 5. The receiving entity MUST reply with either a <proceed/> element + or a <failure/> element qualified by the + 'urn:ietf:params:xml:ns:xmpp-tls' namespace. If the failure case + occurs, the receiving entity MUST terminate both the XML stream + and the underlying TCP connection. If the proceed case occurs, + the entities MUST attempt to complete the TLS negotiation over + the TCP connection and MUST NOT send any further XML data until + the TLS negotiation is complete. + + 6. The initiating entity and receiving entity attempt to complete a + TLS negotiation in accordance with [TLS]. + + 7. If the TLS negotiation is unsuccessful, the receiving entity MUST + terminate the TCP connection. If the TLS negotiation is + successful, the initiating entity MUST initiate a new stream by + sending an opening XML stream header to the receiving entity (it + is not necessary to send a closing </stream> tag first, since the + receiving entity and initiating entity MUST consider the original + stream to be closed upon successful TLS negotiation). + + + + + +Saint-Andre, Ed. Standards Track [Page 22] + +RFC 3920 XMPP Core October 2004 + + + 8. Upon receiving the new stream header from the initiating entity, + the receiving entity MUST respond by sending a new XML stream + header to the initiating entity along with the available features + (but not including the STARTTLS feature). + +5.3. Client-to-Server Example + + The following example shows the data flow for a client securing a + stream using STARTTLS (note: the alternate steps shown below are + provided to illustrate the protocol for failure cases; they are not + exhaustive and would not necessarily be triggered by the data sent in + the example). + + Step 1: Client initiates stream to server: + + <stream:stream + xmlns='jabber:client' + xmlns:stream='http://etherx.jabber.org/streams' + to='example.com' + version='1.0'> + + Step 2: Server responds by sending a stream tag to client: + + <stream:stream + xmlns='jabber:client' + xmlns:stream='http://etherx.jabber.org/streams' + id='c2s_123' + from='example.com' + version='1.0'> + + Step 3: Server sends the STARTTLS extension to client along with + authentication mechanisms and any other stream features: + + <stream:features> + <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'> + <required/> + </starttls> + <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> + <mechanism>DIGEST-MD5</mechanism> + <mechanism>PLAIN</mechanism> + </mechanisms> + </stream:features> + + Step 4: Client sends the STARTTLS command to server: + + <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> + + + + + +Saint-Andre, Ed. Standards Track [Page 23] + +RFC 3920 XMPP Core October 2004 + + + Step 5: Server informs client that it is allowed to proceed: + + <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> + + Step 5 (alt): Server informs client that TLS negotiation has failed + and closes both stream and TCP connection: + + <failure xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> + </stream:stream> + + Step 6: Client and server attempt to complete TLS negotiation over + the existing TCP connection. + + Step 7: If TLS negotiation is successful, client initiates a new + stream to server: + + <stream:stream + xmlns='jabber:client' + xmlns:stream='http://etherx.jabber.org/streams' + to='example.com' + version='1.0'> + + Step 7 (alt): If TLS negotiation is unsuccessful, server closes TCP + connection. + + Step 8: Server responds by sending a stream header to client along + with any available stream features: + + <stream:stream + xmlns='jabber:client' + xmlns:stream='http://etherx.jabber.org/streams' + from='example.com' + id='c2s_234' + version='1.0'> + <stream:features> + <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> + <mechanism>DIGEST-MD5</mechanism> + <mechanism>PLAIN</mechanism> + <mechanism>EXTERNAL</mechanism> + </mechanisms> + </stream:features> + + Step 9: Client continues with SASL negotiation (Section 6). + + + + + + + + +Saint-Andre, Ed. Standards Track [Page 24] + +RFC 3920 XMPP Core October 2004 + + +5.4. Server-to-Server Example + + The following example shows the data flow for two servers securing a + stream using STARTTLS (note: the alternate steps shown below are + provided to illustrate the protocol for failure cases; they are not + exhaustive and would not necessarily be triggered by the data sent in + the example). + + Step 1: Server1 initiates stream to Server2: + + <stream:stream + xmlns='jabber:server' + xmlns:stream='http://etherx.jabber.org/streams' + to='example.com' + version='1.0'> + + Step 2: Server2 responds by sending a stream tag to Server1: + + <stream:stream + xmlns='jabber:server' + xmlns:stream='http://etherx.jabber.org/streams' + from='example.com' + id='s2s_123' + version='1.0'> + + Step 3: Server2 sends the STARTTLS extension to Server1 along with + authentication mechanisms and any other stream features: + + <stream:features> + <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'> + <required/> + </starttls> + <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> + <mechanism>DIGEST-MD5</mechanism> + <mechanism>KERBEROS_V4</mechanism> + </mechanisms> + </stream:features> + + Step 4: Server1 sends the STARTTLS command to Server2: + + <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> + + Step 5: Server2 informs Server1 that it is allowed to proceed: + + <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> + + + + + + +Saint-Andre, Ed. Standards Track [Page 25] + +RFC 3920 XMPP Core October 2004 + + + Step 5 (alt): Server2 informs Server1 that TLS negotiation has failed + and closes stream: + + <failure xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> + </stream:stream> + + Step 6: Server1 and Server2 attempt to complete TLS negotiation via + TCP. + + Step 7: If TLS negotiation is successful, Server1 initiates a new + stream to Server2: + + <stream:stream + xmlns='jabber:server' + xmlns:stream='http://etherx.jabber.org/streams' + to='example.com' + version='1.0'> + + Step 7 (alt): If TLS negotiation is unsuccessful, Server2 closes TCP + connection. + + Step 8: Server2 responds by sending a stream header to Server1 along + with any available stream features: + + <stream:stream + xmlns='jabber:server' + xmlns:stream='http://etherx.jabber.org/streams' + from='example.com' + id='s2s_234' + version='1.0'> + <stream:features> + <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> + <mechanism>DIGEST-MD5</mechanism> + <mechanism>KERBEROS_V4</mechanism> + <mechanism>EXTERNAL</mechanism> + </mechanisms> + </stream:features> + + Step 9: Server1 continues with SASL negotiation (Section 6). + + + + + + + + + + + + +Saint-Andre, Ed. Standards Track [Page 26] + +RFC 3920 XMPP Core October 2004 + + +6. Use of SASL + +6.1. Overview + + XMPP includes a method for authenticating a stream by means of an + XMPP-specific profile of the Simple Authentication and Security Layer + (SASL) protocol [SASL]. SASL provides a generalized method for + adding authentication support to connection-based protocols, and XMPP + uses a generic XML namespace profile for SASL that conforms to the + profiling requirements of [SASL]. + + The following rules apply: + + 1. If the SASL negotiation occurs between two servers, + communications MUST NOT proceed until the Domain Name System + (DNS) hostnames asserted by the servers have been resolved (see + Server-to-Server Communications (Section 14.4)). + + 2. If the initiating entity is capable of SASL negotiation, it MUST + include the 'version' attribute set to a value of at least "1.0" + in the initial stream header. + + 3. If the receiving entity is capable of SASL negotiation, it MUST + advertise one or more authentication mechanisms within a + <mechanisms/> element qualified by the + 'urn:ietf:params:xml:ns:xmpp-sasl' namespace in reply to the + opening stream tag received from the initiating entity (if the + opening stream tag included the 'version' attribute set to a + value of at least "1.0"). + + 4. During SASL negotiation, an entity MUST NOT send any white space + characters (matching production [3] content of [XML]) within the + root stream element as separators between elements (any white + space characters shown in the SASL examples below are included + for the sake of readability only); this prohibition helps to + ensure proper security layer byte precision. + + 5. Any XML character data contained within the XML elements used + during SASL negotiation MUST be encoded using base64, where the + encoding adheres to the definition in Section 3 of RFC 3548 + [BASE64]. + + 6. If provision of a "simple username" is supported by the selected + SASL mechanism (e.g., this is supported by the DIGEST-MD5 and + CRAM-MD5 mechanisms but not by the EXTERNAL and GSSAPI + mechanisms), during authentication the initiating entity SHOULD + provide as the simple username its sending domain (IP address or + fully qualified domain name as contained in a domain identifier) + + + +Saint-Andre, Ed. Standards Track [Page 27] + +RFC 3920 XMPP Core October 2004 + + + in the case of server-to-server communications or its registered + account name (user or node name as contained in an XMPP node + identifier) in the case of client-to-server communications. + + 7. If the initiating entity wishes to act on behalf of another + entity and the selected SASL mechanism supports transmission of + an authorization identity, the initiating entity MUST provide an + authorization identity during SASL negotiation. If the + initiating entity does not wish to act on behalf of another + entity, it MUST NOT provide an authorization identity. As + specified in [SASL], the initiating entity MUST NOT provide an + authorization identity unless the authorization identity is + different from the default authorization identity derived from + the authentication identity as described in [SASL]. If provided, + the value of the authorization identity MUST be of the form + <domain> (i.e., a domain identifier only) for servers and of the + form <node@domain> (i.e., node identifier and domain identifier) + for clients. + + 8. Upon successful SASL negotiation that involves negotiation of a + security layer, the receiving entity MUST discard any knowledge + obtained from the initiating entity which was not obtained from + the SASL negotiation itself. + + 9. Upon successful SASL negotiation that involves negotiation of a + security layer, the initiating entity MUST discard any knowledge + obtained from the receiving entity which was not obtained from + the SASL negotiation itself. + + 10. See Mandatory-to-Implement Technologies (Section 14.7) regarding + mechanisms that MUST be supported. + +6.2. Narrative + + When an initiating entity authenticates with a receiving entity using + SASL, the steps involved are as follows: + + 1. The initiating entity requests SASL authentication by including + the 'version' attribute in the opening XML stream header sent to + the receiving entity, with the value set to "1.0". + + 2. After sending an XML stream header in reply, the receiving entity + advertises a list of available SASL authentication mechanisms; + each of these is a <mechanism/> element included as a child + within a <mechanisms/> container element qualified by the + 'urn:ietf:params:xml:ns:xmpp-sasl' namespace, which in turn is a + child of a <features/> element in the streams namespace. If Use + of TLS (Section 5) needs to be established before a particular + + + +Saint-Andre, Ed. Standards Track [Page 28] + +RFC 3920 XMPP Core October 2004 + + + authentication mechanism may be used, the receiving entity MUST + NOT provide that mechanism in the list of available SASL + authentication mechanisms prior to TLS negotiation. If the + initiating entity presents a valid certificate during prior TLS + negotiation, the receiving entity SHOULD offer the SASL EXTERNAL + mechanism to the initiating entity during SASL negotiation (refer + to [SASL]), although the EXTERNAL mechanism MAY be offered under + other circumstances as well. + + 3. The initiating entity selects a mechanism by sending an <auth/> + element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' + namespace to the receiving entity and including an appropriate + value for the 'mechanism' attribute. This element MAY contain + XML character data (in SASL terminology, the "initial response") + if the mechanism supports or requires it; if the initiating + entity needs to send a zero-length initial response, it MUST + transmit the response as a single equals sign ("="), which + indicates that the response is present but contains no data. + + 4. If necessary, the receiving entity challenges the initiating + entity by sending a <challenge/> element qualified by the + 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating + entity; this element MAY contain XML character data (which MUST + be computed in accordance with the definition of the SASL + mechanism chosen by the initiating entity). + + 5. The initiating entity responds to the challenge by sending a + <response/> element qualified by the + 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the receiving + entity; this element MAY contain XML character data (which MUST + be computed in accordance with the definition of the SASL + mechanism chosen by the initiating entity). + + 6. If necessary, the receiving entity sends more challenges and the + initiating entity sends more responses. + + This series of challenge/response pairs continues until one of three + things happens: + + 1. The initiating entity aborts the handshake by sending an <abort/> + element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' + namespace to the receiving entity. Upon receiving an <abort/> + element, the receiving entity SHOULD allow a configurable but + reasonable number of retries (at least 2), after which it MUST + terminate the TCP connection; this enables the initiating entity + (e.g., an end-user client) to tolerate incorrectly-provided + credentials (e.g., a mistyped password) without being forced to + reconnect. + + + +Saint-Andre, Ed. Standards Track [Page 29] + +RFC 3920 XMPP Core October 2004 + + + 2. The receiving entity reports failure of the handshake by sending + a <failure/> element qualified by the + 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating + entity (the particular cause of failure SHOULD be communicated in + an appropriate child element of the <failure/> element as defined + under SASL Errors (Section 6.4)). If the failure case occurs, + the receiving entity SHOULD allow a configurable but reasonable + number of retries (at least 2), after which it MUST terminate the + TCP connection; this enables the initiating entity (e.g., an + end-user client) to tolerate incorrectly-provided credentials + (e.g., a mistyped password) without being forced to reconnect. + + 3. The receiving entity reports success of the handshake by sending + a <success/> element qualified by the + 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating + entity; this element MAY contain XML character data (in SASL + terminology, "additional data with success") if required by the + chosen SASL mechanism. Upon receiving the <success/> element, + the initiating entity MUST initiate a new stream by sending an + opening XML stream header to the receiving entity (it is not + necessary to send a closing </stream> tag first, since the + receiving entity and initiating entity MUST consider the original + stream to be closed upon sending or receiving the <success/> + element). Upon receiving the new stream header from the + initiating entity, the receiving entity MUST respond by sending a + new XML stream header to the initiating entity, along with any + available features (but not including the STARTTLS and SASL + features) or an empty <features/> element (to signify that no + additional features are available); any such additional features + not defined herein MUST be defined by the relevant extension to + XMPP. + +6.3. SASL Definition + + The profiling requirements of [SASL] require that the following + information be supplied by a protocol definition: + + service name: "xmpp" + + initiation sequence: After the initiating entity provides an opening + XML stream header and the receiving entity replies in kind, the + receiving entity provides a list of acceptable authentication + methods. The initiating entity chooses one method from the list + and sends it to the receiving entity as the value of the + 'mechanism' attribute possessed by an <auth/> element, optionally + including an initial response to avoid a round trip. + + + + + +Saint-Andre, Ed. Standards Track [Page 30] + +RFC 3920 XMPP Core October 2004 + + + exchange sequence: Challenges and responses are carried through the + exchange of <challenge/> elements from receiving entity to + initiating entity and <response/> elements from initiating entity + to receiving entity. The receiving entity reports failure by + sending a <failure/> element and success by sending a <success/> + element; the initiating entity aborts the exchange by sending an + <abort/> element. Upon successful negotiation, both sides + consider the original XML stream to be closed and new stream + headers are sent by both entities. + + security layer negotiation: The security layer takes effect + immediately after sending the closing ">" character of the + <success/> element for the receiving entity, and immediately after + receiving the closing ">" character of the <success/> element for + the initiating entity. The order of layers is first [TCP], then + [TLS], then [SASL], then XMPP. + + use of the authorization identity: The authorization identity may be + used by xmpp to denote the non-default <node@domain> of a client + or the sending <domain> of a server. + +6.4. SASL Errors + + The following SASL-related error conditions are defined: + + o <aborted/> -- The receiving entity acknowledges an <abort/> + element sent by the initiating entity; sent in reply to the + <abort/> element. + + o <incorrect-encoding/> -- The data provided by the initiating + entity could not be processed because the [BASE64] encoding is + incorrect (e.g., because the encoding does not adhere to the + definition in Section 3 of [BASE64]); sent in reply to a + <response/> element or an <auth/> element with initial response + data. + + o <invalid-authzid/> -- The authzid provided by the initiating + entity is invalid, either because it is incorrectly formatted or + because the initiating entity does not have permissions to + authorize that ID; sent in reply to a <response/> element or an + <auth/> element with initial response data. + + o <invalid-mechanism/> -- The initiating entity did not provide a + mechanism or requested a mechanism that is not supported by the + receiving entity; sent in reply to an <auth/> element. + + + + + + +Saint-Andre, Ed. Standards Track [Page 31] + +RFC 3920 XMPP Core October 2004 + + + o <mechanism-too-weak/> -- The mechanism requested by the initiating + entity is weaker than server policy permits for that initiating + entity; sent in reply to a <response/> element or an <auth/> + element with initial response data. + + o <not-authorized/> -- The authentication failed because the + initiating entity did not provide valid credentials (this includes + but is not limited to the case of an unknown username); sent in + reply to a <response/> element or an <auth/> element with initial + response data. + + o <temporary-auth-failure/> -- The authentication failed because of + a temporary error condition within the receiving entity; sent in + reply to an <auth/> element or <response/> element. + +6.5. Client-to-Server Example + + The following example shows the data flow for a client authenticating + with a server using SASL, normally after successful TLS negotiation + (note: the alternate steps shown below are provided to illustrate the + protocol for failure cases; they are not exhaustive and would not + necessarily be triggered by the data sent in the example). + + Step 1: Client initiates stream to server: + + <stream:stream + xmlns='jabber:client' + xmlns:stream='http://etherx.jabber.org/streams' + to='example.com' + version='1.0'> + + Step 2: Server responds with a stream tag sent to client: + + <stream:stream + xmlns='jabber:client' + xmlns:stream='http://etherx.jabber.org/streams' + id='c2s_234' + from='example.com' + version='1.0'> + + Step 3: Server informs client of available authentication mechanisms: + + <stream:features> + <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> + <mechanism>DIGEST-MD5</mechanism> + <mechanism>PLAIN</mechanism> + </mechanisms> + </stream:features> + + + +Saint-Andre, Ed. Standards Track [Page 32] + +RFC 3920 XMPP Core October 2004 + + + Step 4: Client selects an authentication mechanism: + + <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' + mechanism='DIGEST-MD5'/> + + Step 5: Server sends a [BASE64] encoded challenge to client: + + <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> + cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi + LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg== + </challenge> + + The decoded challenge is: + + realm="somerealm",nonce="OA6MG9tEQGm2hh",\ + qop="auth",charset=utf-8,algorithm=md5-sess + + Step 5 (alt): Server returns error to client: + + <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> + <incorrect-encoding/> + </failure> + </stream:stream> + + Step 6: Client sends a [BASE64] encoded response to the challenge: + + <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> + dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i + T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw + MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i + LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo + YXJzZXQ9dXRmLTgK + </response> + + The decoded response is: + + username="somenode",realm="somerealm",\ + nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\ + nc=00000001,qop=auth,digest-uri="xmpp/example.com",\ + response=d388dad90d4bbd760a152321f2143af7,charset=utf-8 + + Step 7: Server sends another [BASE64] encoded challenge to client: + + <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> + cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= + </challenge> + + + + + +Saint-Andre, Ed. Standards Track [Page 33] + +RFC 3920 XMPP Core October 2004 + + + The decoded challenge is: + + rspauth=ea40f60335c427b5527b84dbabcdfffd + + Step 7 (alt): Server returns error to client: + + <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> + <temporary-auth-failure/> + </failure> + </stream:stream> + + Step 8: Client responds to the challenge: + + <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/> + + Step 9: Server informs client of successful authentication: + + <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/> + + Step 9 (alt): Server informs client of failed authentication: + + <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> + <temporary-auth-failure/> + </failure> + </stream:stream> + + Step 10: Client initiates a new stream to server: + + <stream:stream + xmlns='jabber:client' + xmlns:stream='http://etherx.jabber.org/streams' + to='example.com' + version='1.0'> + + Step 11: Server responds by sending a stream header to client along + with any additional features (or an empty features element): + + <stream:stream + xmlns='jabber:client' + xmlns:stream='http://etherx.jabber.org/streams' + id='c2s_345' + from='example.com' + version='1.0'> + <stream:features> + <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/> + <session xmlns='urn:ietf:params:xml:ns:xmpp-session'/> + </stream:features> + + + + +Saint-Andre, Ed. Standards Track [Page 34] + +RFC 3920 XMPP Core October 2004 + + +6.6. Server-to-Server Example + + The following example shows the data flow for a server authenticating + with another server using SASL, normally after successful TLS + negotiation (note: the alternate steps shown below are provided to + illustrate the protocol for failure cases; they are not exhaustive + and would not necessarily be triggered by the data sent in the + example). + + Step 1: Server1 initiates stream to Server2: + + <stream:stream + xmlns='jabber:server' + xmlns:stream='http://etherx.jabber.org/streams' + to='example.com' + version='1.0'> + + Step 2: Server2 responds with a stream tag sent to Server1: + + <stream:stream + xmlns='jabber:server' + xmlns:stream='http://etherx.jabber.org/streams' + from='example.com' + id='s2s_234' + version='1.0'> + + Step 3: Server2 informs Server1 of available authentication + mechanisms: + + <stream:features> + <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> + <mechanism>DIGEST-MD5</mechanism> + <mechanism>KERBEROS_V4</mechanism> + </mechanisms> + </stream:features> + + Step 4: Server1 selects an authentication mechanism: + + <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' + mechanism='DIGEST-MD5'/> + + Step 5: Server2 sends a [BASE64] encoded challenge to Server1: + + <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> + cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9 + ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz + </challenge> + + + + +Saint-Andre, Ed. Standards Track [Page 35] + +RFC 3920 XMPP Core October 2004 + + + The decoded challenge is: + + realm="somerealm",nonce="OA6MG9tEQGm2hh",\ + qop="auth",charset=utf-8,algorithm=md5-sess + + Step 5 (alt): Server2 returns error to Server1: + + <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> + <incorrect-encoding/> + </failure> + </stream:stream> + + Step 6: Server1 sends a [BASE64] encoded response to the challenge: + + <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> + dXNlcm5hbWU9ImV4YW1wbGUub3JnIixyZWFsbT0ic29tZXJlYWxtIixub25j + ZT0iT0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5j + PTAwMDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5v + cmciLHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3 + LGNoYXJzZXQ9dXRmLTgK + </response> + + The decoded response is: + + username="example.org",realm="somerealm",\ + nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\ + nc=00000001,qop=auth,digest-uri="xmpp/example.org",\ + response=d388dad90d4bbd760a152321f2143af7,charset=utf-8 + + Step 7: Server2 sends another [BASE64] encoded challenge to Server1: + + <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> + cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= + </challenge> + + The decoded challenge is: + + rspauth=ea40f60335c427b5527b84dbabcdfffd + + Step 7 (alt): Server2 returns error to Server1: + + <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> + <invalid-authzid/> + </failure> + </stream:stream> + + + + + + +Saint-Andre, Ed. Standards Track [Page 36] + +RFC 3920 XMPP Core October 2004 + + + Step 8: Server1 responds to the challenge: + + <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/> + + Step 8 (alt): Server1 aborts negotiation: + + <abort xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/> + + Step 9: Server2 informs Server1 of successful authentication: + + <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/> + + Step 9 (alt): Server2 informs Server1 of failed authentication: + + <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> + <aborted/> + </failure> + </stream:stream> + + Step 10: Server1 initiates a new stream to Server2: + + <stream:stream + xmlns='jabber:server' + xmlns:stream='http://etherx.jabber.org/streams' + to='example.com' + version='1.0'> + + Step 11: Server2 responds by sending a stream header to Server1 along + with any additional features (or an empty features element): + + <stream:stream + xmlns='jabber:client' + xmlns:stream='http://etherx.jabber.org/streams' + from='example.com' + id='s2s_345' + version='1.0'> + <stream:features/> + +7. Resource Binding + + After SASL negotiation (Section 6) with the receiving entity, the + initiating entity MAY want or need to bind a specific resource to + that stream. In general this applies only to clients: in order to + conform to the addressing format (Section 3) and stanza delivery + rules (Section 10) specified herein, there MUST be a resource + identifier associated with the <node@domain> of the client (which is + + + + + +Saint-Andre, Ed. Standards Track [Page 37] + +RFC 3920 XMPP Core October 2004 + + + either generated by the server or provided by the client + application); this ensures that the address for use over that stream + is a "full JID" of the form <node@domain/resource>. + + Upon receiving a success indication within the SASL negotiation, the + client MUST send a new stream header to the server, to which the + server MUST respond with a stream header as well as a list of + available stream features. Specifically, if the server requires the + client to bind a resource to the stream after successful SASL + negotiation, it MUST include an empty <bind/> element qualified by + the 'urn:ietf:params:xml:ns:xmpp-bind' namespace in the stream + features list it presents to the client upon sending the header for + the response stream sent after successful SASL negotiation (but not + before): + + Server advertises resource binding feature to client: + + <stream:stream + xmlns='jabber:client' + xmlns:stream='http://etherx.jabber.org/streams' + id='c2s_345' + from='example.com' + version='1.0'> + <stream:features> + <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/> + </stream:features> + + Upon being so informed that resource binding is required, the client + MUST bind a resource to the stream by sending to the server an IQ + stanza of type "set" (see IQ Semantics (Section 9.2.3)) containing + data qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace. + + If the client wishes to allow the server to generate the resource + identifier on its behalf, it sends an IQ stanza of type "set" that + contains an empty <bind/> element: + + Client asks server to bind a resource: + + <iq type='set' id='bind_1'> + <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/> + </iq> + + A server that supports resource binding MUST be able to generate a + resource identifier on behalf of a client. A resource identifier + generated by the server MUST be unique for that <node@domain>. + + + + + + +Saint-Andre, Ed. Standards Track [Page 38] + +RFC 3920 XMPP Core October 2004 + + + If the client wishes to specify the resource identifier, it sends an + IQ stanza of type "set" that contains the desired resource identifier + as the XML character data of a <resource/> element that is a child of + the <bind/> element: + + Client binds a resource: + + <iq type='set' id='bind_2'> + <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'> + <resource>someresource</resource> + </bind> + </iq> + + Once the server has generated a resource identifier for the client or + accepted the resource identifier provided by the client, it MUST + return an IQ stanza of type "result" to the client, which MUST + include a <jid/> child element that specifies the full JID for the + connected resource as determined by the server: + + Server informs client of successful resource binding: + + <iq type='result' id='bind_2'> + <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'> + <jid>somenode@example.com/someresource</jid> + </bind> + </iq> + + A server SHOULD accept the resource identifier provided by the + client, but MAY override it with a resource identifier that the + server generates; in this case, the server SHOULD NOT return a stanza + error (e.g., <forbidden/>) to the client but instead SHOULD + communicate the generated resource identifier to the client in the IQ + result as shown above. + + When a client supplies a resource identifier, the following stanza + error conditions are possible (see Stanza Errors (Section 9.3)): + + o The provided resource identifier cannot be processed by the server + in accordance with Resourceprep (Appendix B). + + o The client is not allowed to bind a resource to the stream (e.g., + because the node or user has reached a limit on the number of + connected resources allowed). + + o The provided resource identifier is already in use but the server + does not allow binding of multiple connected resources with the + same identifier. + + + + +Saint-Andre, Ed. Standards Track [Page 39] + +RFC 3920 XMPP Core October 2004 + + + The protocol for these error conditions is shown below. + + Resource identifier cannot be processed: + + <iq type='error' id='bind_2'> + <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'> + <resource>someresource</resource> + </bind> + <error type='modify'> + <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> + </error> + </iq> + + Client is not allowed to bind a resource: + + <iq type='error' id='bind_2'> + <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'> + <resource>someresource</resource> + </bind> + <error type='cancel'> + <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> + </error> + </iq> + + Resource identifier is in use: + + <iq type='error' id='bind_2'> + <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'> + <resource>someresource</resource> + </bind> + <error type='cancel'> + <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> + </error> + </iq> + + If, before completing the resource binding step, the client attempts + to send an XML stanza other than an IQ stanza with a <bind/> child + qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace, the + server MUST NOT process the stanza and SHOULD return a + <not-authorized/> stanza error to the client. + + + + + + + + + + + +Saint-Andre, Ed. Standards Track [Page 40] + +RFC 3920 XMPP Core October 2004 + + +8. Server Dialback + +8.1. Overview + + The Jabber protocols from which XMPP was adapted include a "server + dialback" method for protecting against domain spoofing, thus making + it more difficult to spoof XML stanzas. Server dialback is not a + security mechanism, and results in weak verification of server + identities only (see Server-to-Server Communications (Section 14.4) + regarding this method's security characteristics). Domains requiring + robust security SHOULD use TLS and SASL; see Server-to-Server + Communications (Section 14.4) for details. If SASL is used for + server-to-server authentication, dialback SHOULD NOT be used since it + is unnecessary. Documentation of dialback is included mainly for the + sake of backward-compatibility with existing implementations and + deployments. + + The server dialback method is made possible by the existence of the + Domain Name System (DNS), since one server can (normally) discover + the authoritative server for a given domain. Because dialback + depends on DNS, inter-domain communications MUST NOT proceed until + the Domain Name System (DNS) hostnames asserted by the servers have + been resolved (see Server-to-Server Communications (Section 14.4)). + + Server dialback is uni-directional, and results in (weak) + verification of identities for one stream in one direction. Because + server dialback is not an authentication mechanism, mutual + authentication is not possible via dialback. Therefore, server + dialback MUST be completed in each direction in order to enable + bi-directional communications between two domains. + + The method for generating and verifying the keys used in server + dialback MUST take into account the hostnames being used, the stream + ID generated by the receiving server, and a secret known by the + authoritative server's network. The stream ID is security-critical + in server dialback and therefore MUST be both unpredictable and + non-repeating (see [RANDOM] for recommendations regarding randomness + for security purposes). + + Any error that occurs during dialback negotiation MUST be considered + a stream error, resulting in termination of the stream and of the + underlying TCP connection. The possible error conditions are + specified in the protocol description below. + + The following terminology applies: + + o Originating Server -- the server that is attempting to establish a + connection between two domains. + + + +Saint-Andre, Ed. Standards Track [Page 41] + +RFC 3920 XMPP Core October 2004 + + + o Receiving Server -- the server that is trying to authenticate that + the Originating Server represents the domain which it claims to + be. + + o Authoritative Server -- the server that answers to the DNS + hostname asserted by the Originating Server; for basic + environments this will be the Originating Server, but it could be + a separate machine in the Originating Server's network. + +8.2. Order of Events + + The following is a brief summary of the order of events in dialback: + + 1. The Originating Server establishes a connection to the Receiving + Server. + + 2. The Originating Server sends a 'key' value over the connection to + the Receiving Server. + + 3. The Receiving Server establishes a connection to the + Authoritative Server. + + 4. The Receiving Server sends the same 'key' value to the + Authoritative Server. + + 5. The Authoritative Server replies that key is valid or invalid. + + 6. The Receiving Server informs the Originating Server whether it is + authenticated or not. + + + + + + + + + + + + + + + + + + + + + + +Saint-Andre, Ed. Standards Track [Page 42] + +RFC 3920 XMPP Core October 2004 + + + We can represent this flow of events graphically as follows: + + Originating Receiving + Server Server + ----------- --------- + | | + | establish connection | + | ----------------------> | + | | + | send stream header | + | ----------------------> | + | | + | send stream header | + | <---------------------- | + | | Authoritative + | send dialback key | Server + | ----------------------> | ------------- + | | | + | establish connection | + | ----------------------> | + | | + | send stream header | + | ----------------------> | + | | + | send stream header | + | <---------------------- | + | | + | send verify request | + | ----------------------> | + | | + | send verify response | + | <---------------------- | + | + | report dialback result | + | <---------------------- | + | | + +8.3. Protocol + + The detailed protocol interaction between the servers is as follows: + + 1. The Originating Server establishes TCP connection to the + Receiving Server. + + + + + + + + +Saint-Andre, Ed. Standards Track [Page 43] + +RFC 3920 XMPP Core October 2004 + + + 2. The Originating Server sends a stream header to the Receiving + Server: + + <stream:stream + xmlns:stream='http://etherx.jabber.org/streams' + xmlns='jabber:server' + xmlns:db='jabber:server:dialback'> + + Note: The 'to' and 'from' attributes are OPTIONAL on the root stream + element. The inclusion of the xmlns:db namespace declaration with + the name shown indicates to the Receiving Server that the Originating + Server supports dialback. If the namespace name is incorrect, then + the Receiving Server MUST generate an <invalid-namespace/> stream + error condition and terminate both the XML stream and the underlying + TCP connection. + + 3. The Receiving Server SHOULD send a stream header back to the + Originating Server, including a unique ID for this interaction: + + <stream:stream + xmlns:stream='http://etherx.jabber.org/streams' + xmlns='jabber:server' + xmlns:db='jabber:server:dialback' + id='457F9224A0...'> + + Note: The 'to' and 'from' attributes are OPTIONAL on the root stream + element. If the namespace name is incorrect, then the Originating + Server MUST generate an <invalid-namespace/> stream error condition + and terminate both the XML stream and the underlying TCP connection. + Note well that the Receiving Server SHOULD reply but MAY silently + terminate the XML stream and underlying TCP connection depending on + security policies in place; however, if the Receiving Server desires + to proceed, it MUST send a stream header back to the Originating + Server. + + 4. The Originating Server sends a dialback key to the Receiving + Server: + + <db:result + to='Receiving Server' + from='Originating Server'> + 98AF014EDC0... + </db:result> + + Note: This key is not examined by the Receiving Server, since the + Receiving Server does not keep information about the Originating + Server between sessions. The key generated by the Originating Server + MUST be based in part on the value of the ID provided by the + + + +Saint-Andre, Ed. Standards Track [Page 44] + +RFC 3920 XMPP Core October 2004 + + + Receiving Server in the previous step, and in part on a secret shared + by the Originating Server and Authoritative Server. If the value of + the 'to' address does not match a hostname recognized by the + Receiving Server, then the Receiving Server MUST generate a + <host-unknown/> stream error condition and terminate both the XML + stream and the underlying TCP connection. If the value of the 'from' + address matches a domain with which the Receiving Server already has + an established connection, then the Receiving Server MUST maintain + the existing connection until it validates whether the new connection + is legitimate; additionally, the Receiving Server MAY choose to + generate a <not-authorized/> stream error condition for the new + connection and then terminate both the XML stream and the underlying + TCP connection related to the new request. + + 5. The Receiving Server establishes a TCP connection back to the + domain name asserted by the Originating Server, as a result of + which it connects to the Authoritative Server. (Note: As an + optimization, an implementation MAY reuse an existing connection + here.) + + 6. The Receiving Server sends the Authoritative Server a stream + header: + + <stream:stream + xmlns:stream='http://etherx.jabber.org/streams' + xmlns='jabber:server' + xmlns:db='jabber:server:dialback'> + + Note: The 'to' and 'from' attributes are OPTIONAL on the root stream + element. If the namespace name is incorrect, then the Authoritative + Server MUST generate an <invalid-namespace/> stream error condition + and terminate both the XML stream and the underlying TCP connection. + + 7. The Authoritative Server sends the Receiving Server a stream + header: + + <stream:stream + xmlns:stream='http://etherx.jabber.org/streams' + xmlns='jabber:server' + xmlns:db='jabber:server:dialback' + id='1251A342B...'> + + Note: If the namespace name is incorrect, then the Receiving Server + MUST generate an <invalid-namespace/> stream error condition and + terminate both the XML stream and the underlying TCP connection + between it and the Authoritative Server. If a stream error occurs + between the Receiving Server and the Authoritative Server, then the + Receiving Server MUST generate a <remote-connection-failed/> stream + + + +Saint-Andre, Ed. Standards Track [Page 45] + +RFC 3920 XMPP Core October 2004 + + + error condition and terminate both the XML stream and the underlying + TCP connection between it and the Originating Server. + + 8. The Receiving Server sends the Authoritative Server a request for + verification of a key: + + <db:verify + from='Receiving Server' + to='Originating Server' + id='457F9224A0...'> + 98AF014EDC0... + </db:verify> + + Note: Passed here are the hostnames, the original identifier from the + Receiving Server's stream header to the Originating Server in Step 3, + and the key that the Originating Server sent to the Receiving Server + in Step 4. Based on this information, as well as shared secret + information within the Authoritative Server's network, the key is + verified. Any verifiable method MAY be used to generate the key. If + the value of the 'to' address does not match a hostname recognized by + the Authoritative Server, then the Authoritative Server MUST generate + a <host-unknown/> stream error condition and terminate both the XML + stream and the underlying TCP connection. If the value of the 'from' + address does not match the hostname represented by the Receiving + Server when opening the TCP connection (or any validated domain + thereof, such as a validated subdomain of the Receiving Server's + hostname or another validated domain hosted by the Receiving Server), + then the Authoritative Server MUST generate an <invalid-from/> stream + error condition and terminate both the XML stream and the underlying + TCP connection. + + 9. The Authoritative Server verifies whether the key was valid or + invalid: + + <db:verify + from='Originating Server' + to='Receiving Server' + type='valid' + id='457F9224A0...'/> + + or + + <db:verify + from='Originating Server' + to='Receiving Server' + type='invalid' + id='457F9224A0...'/> + + + + +Saint-Andre, Ed. Standards Track [Page 46] + +RFC 3920 XMPP Core October 2004 + + + Note: If the ID does not match that provided by the Receiving Server + in Step 3, then the Receiving Server MUST generate an <invalid-id/> + stream error condition and terminate both the XML stream and the + underlying TCP connection. If the value of the 'to' address does not + match a hostname recognized by the Receiving Server, then the + Receiving Server MUST generate a <host-unknown/> stream error + condition and terminate both the XML stream and the underlying TCP + connection. If the value of the 'from' address does not match the + hostname represented by the Originating Server when opening the TCP + connection (or any validated domain thereof, such as a validated + subdomain of the Originating Server's hostname or another validated + domain hosted by the Originating Server), then the Receiving Server + MUST generate an <invalid-from/> stream error condition and terminate + both the XML stream and the underlying TCP connection. After + returning the verification to the Receiving Server, the Authoritative + Server SHOULD terminate the stream between them. + + 10. The Receiving Server informs the Originating Server of the + result: + + <db:result + from='Receiving Server' + to='Originating Server' + type='valid'/> + + Note: At this point, the connection has either been validated via a + type='valid', or reported as invalid. If the connection is invalid, + then the Receiving Server MUST terminate both the XML stream and the + underlying TCP connection. If the connection is validated, data can + be sent by the Originating Server and read by the Receiving Server; + before that, all XML stanzas sent to the Receiving Server SHOULD be + silently dropped. + + The result of the foregoing is that the Receiving Server has verified + the identity of the Originating Server, so that the Originating + Server can send, and the Receiving Server can accept, XML stanzas + over the "initial stream" (i.e., the stream from the Originating + Server to the Receiving Server). In order to verify the identities + of the entities using the "response stream" (i.e., the stream from + the Receiving Server to the Originating Server), dialback MUST be + completed in the opposite direction as well. + + After successful dialback negotiation, the Receiving Server SHOULD + accept subsequent <db:result/> packets (e.g., validation requests + sent to a subdomain or other hostname serviced by the Receiving + Server) from the Originating Server over the existing validated + connection; this enables "piggybacking" of the original validated + connection in one direction. + + + +Saint-Andre, Ed. Standards Track [Page 47] + +RFC 3920 XMPP Core October 2004 + + + Even if dialback negotiation is successful, a server MUST verify that + all XML stanzas received from the other server include a 'from' + attribute and a 'to' attribute; if a stanza does not meet this + restriction, the server that receives the stanza MUST generate an + <improper-addressing/> stream error condition and terminate both the + XML stream and the underlying TCP connection. Furthermore, a server + MUST verify that the 'from' attribute of stanzas received from the + other server includes a validated domain for the stream; if a stanza + does not meet this restriction, the server that receives the stanza + MUST generate an <invalid-from/> stream error condition and terminate + both the XML stream and the underlying TCP connection. Both of these + checks help to prevent spoofing related to particular stanzas. + +9. XML Stanzas + + After TLS negotiation (Section 5) if desired, SASL negotiation + (Section 6), and Resource Binding (Section 7) if necessary, XML + stanzas can be sent over the streams. Three kinds of XML stanza are + defined for the 'jabber:client' and 'jabber:server' namespaces: + <message/>, <presence/>, and <iq/>. In addition, there are five + common attributes for these kinds of stanza. These common + attributes, as well as the basic semantics of the three stanza kinds, + are defined herein; more detailed information regarding the syntax of + XML stanzas in relation to instant messaging and presence + applications is provided in [XMPP-IM]. + +9.1. Common Attributes + + The following five attributes are common to message, presence, and IQ + stanzas: + +9.1.1. to + + The 'to' attribute specifies the JID of the intended recipient for + the stanza. + + In the 'jabber:client' namespace, a stanza SHOULD possess a 'to' + attribute, although a stanza sent from a client to a server for + handling by that server (e.g., presence sent to the server for + broadcasting to other entities) SHOULD NOT possess a 'to' attribute. + + In the 'jabber:server' namespace, a stanza MUST possess a 'to' + attribute; if a server receives a stanza that does not meet this + restriction, it MUST generate an <improper-addressing/> stream error + condition and terminate both the XML stream and the underlying TCP + connection with the offending server. + + + + + +Saint-Andre, Ed. Standards Track [Page 48] + +RFC 3920 XMPP Core October 2004 + + + If the value of the 'to' attribute is invalid or cannot be contacted, + the entity discovering that fact (usually the sender's or recipient's + server) MUST return an appropriate error to the sender, setting the + 'from' attribute of the error stanza to the value provided in the + 'to' attribute of the offending stanza. + +9.1.2. from + + The 'from' attribute specifies the JID of the sender. + + When a server receives an XML stanza within the context of an + authenticated stream qualified by the 'jabber:client' namespace, it + MUST do one of the following: + + 1. validate that the value of the 'from' attribute provided by the + client is that of a connected resource for the associated entity + + 2. add a 'from' address to the stanza whose value is the bare JID + (<node@domain>) or the full JID (<node@domain/resource>) + determined by the server for the connected resource that + generated the stanza (see Determination of Addresses (Section + 3.5)) + + If a client attempts to send an XML stanza for which the value of the + 'from' attribute does not match one of the connected resources for + that entity, the server SHOULD return an <invalid-from/> stream error + to the client. If a client attempts to send an XML stanza over a + stream that is not yet authenticated, the server SHOULD return a + <not-authorized/> stream error to the client. If generated, both of + these conditions MUST result in closure of the stream and termination + of the underlying TCP connection; this helps to prevent a denial of + service attack launched from a rogue client. + + When a server generates a stanza from the server itself for delivery + to a connected client (e.g., in the context of data storage services + provided by the server on behalf of the client), the stanza MUST + either (1) not include a 'from' attribute or (2) include a 'from' + attribute whose value is the account's bare JID (<node@domain>) or + client's full JID (<node@domain/resource>). A server MUST NOT send + to the client a stanza without a 'from' attribute if the stanza was + not generated by the server itself. When a client receives a stanza + that does not include a 'from' attribute, it MUST assume that the + stanza is from the server to which the client is connected. + + In the 'jabber:server' namespace, a stanza MUST possess a 'from' + attribute; if a server receives a stanza that does not meet this + restriction, it MUST generate an <improper-addressing/> stream error + condition. Furthermore, the domain identifier portion of the JID + + + +Saint-Andre, Ed. Standards Track [Page 49] + +RFC 3920 XMPP Core October 2004 + + + contained in the 'from' attribute MUST match the hostname of the + sending server (or any validated domain thereof, such as a validated + subdomain of the sending server's hostname or another validated + domain hosted by the sending server) as communicated in the SASL + negotiation or dialback negotiation; if a server receives a stanza + that does not meet this restriction, it MUST generate an + <invalid-from/> stream error condition. Both of these conditions + MUST result in closing of the stream and termination of the + underlying TCP connection; this helps to prevent a denial of service + attack launched from a rogue server. + +9.1.3. id + + The optional 'id' attribute MAY be used by a sending entity for + internal tracking of stanzas that it sends and receives (especially + for tracking the request-response interaction inherent in the + semantics of IQ stanzas). It is OPTIONAL for the value of the 'id' + attribute to be unique globally, within a domain, or within a stream. + The semantics of IQ stanzas impose additional restrictions; see IQ + Semantics (Section 9.2.3). + +9.1.4. type + + The 'type' attribute specifies detailed information about the purpose + or context of the message, presence, or IQ stanza. The particular + allowable values for the 'type' attribute vary depending on whether + the stanza is a message, presence, or IQ; the values for message and + presence stanzas are specific to instant messaging and presence + applications and therefore are defined in [XMPP-IM], whereas the + values for IQ stanzas specify the role of an IQ stanza in a + structured request-response "conversation" and thus are defined under + IQ Semantics (Section 9.2.3) below. The only 'type' value common to + all three stanzas is "error"; see Stanza Errors (Section 9.3). + +9.1.5. xml:lang + + A stanza SHOULD possess an 'xml:lang' attribute (as defined in + Section 2.12 of [XML]) if the stanza contains XML character data that + is intended to be presented to a human user (as explained in RFC 2277 + [CHARSET], "internationalization is for humans"). The value of the + 'xml:lang' attribute specifies the default language of any such + human-readable XML character data, which MAY be overridden by the + 'xml:lang' attribute of a specific child element. If a stanza does + not possess an 'xml:lang' attribute, an implementation MUST assume + that the default language is that specified for the stream as defined + under Stream Attributes (Section 4.4) above. The value of the + 'xml:lang' attribute MUST be an NMTOKEN and MUST conform to the + format defined in RFC 3066 [LANGTAGS]. + + + +Saint-Andre, Ed. Standards Track [Page 50] + +RFC 3920 XMPP Core October 2004 + + +9.2. Basic Semantics + +9.2.1. Message Semantics + + The <message/> stanza kind can be seen as a "push" mechanism whereby + one entity pushes information to another entity, similar to the + communications that occur in a system such as email. All message + stanzas SHOULD possess a 'to' attribute that specifies the intended + recipient of the message; upon receiving such a stanza, a server + SHOULD route or deliver it to the intended recipient (see Server + Rules for Handling XML Stanzas (Section 10) for general routing and + delivery rules related to XML stanzas). + +9.2.2. Presence Semantics + + The <presence/> element can be seen as a basic broadcast or + "publish-subscribe" mechanism, whereby multiple entities receive + information about an entity to which they have subscribed (in this + case, network availability information). In general, a publishing + entity SHOULD send a presence stanza with no 'to' attribute, in which + case the server to which the entity is connected SHOULD broadcast or + multiplex that stanza to all subscribing entities. However, a + publishing entity MAY also send a presence stanza with a 'to' + attribute, in which case the server SHOULD route or deliver that + stanza to the intended recipient. See Server Rules for Handling XML + Stanzas (Section 10) for general routing and delivery rules related + to XML stanzas, and [XMPP-IM] for presence-specific rules in the + context of an instant messaging and presence application. + +9.2.3. IQ Semantics + + Info/Query, or IQ, is a request-response mechanism, similar in some + ways to [HTTP]. The semantics of IQ enable an entity to make a + request of, and receive a response from, another entity. The data + content of the request and response is defined by the namespace + declaration of a direct child element of the IQ element, and the + interaction is tracked by the requesting entity through use of the + 'id' attribute. Thus, IQ interactions follow a common pattern of + structured data exchange such as get/result or set/result (although + an error may be returned in reply to a request if appropriate): + + + + + + + + + + + +Saint-Andre, Ed. Standards Track [Page 51] + +RFC 3920 XMPP Core October 2004 + + + Requesting Responding + Entity Entity + ---------- ---------- + | | + | <iq type='get' id='1'> | + | ------------------------> | + | | + | <iq type='result' id='1'> | + | <------------------------ | + | | + | <iq type='set' id='2'> | + | ------------------------> | + | | + | <iq type='error' id='2'> | + | <------------------------ | + | | + + In order to enforce these semantics, the following rules apply: + + 1. The 'id' attribute is REQUIRED for IQ stanzas. + + 2. The 'type' attribute is REQUIRED for IQ stanzas. The value MUST + be one of the following: + + * get -- The stanza is a request for information or + requirements. + + * set -- The stanza provides required data, sets new values, or + replaces existing values. + + * result -- The stanza is a response to a successful get or set + request. + + * error -- An error has occurred regarding processing or + delivery of a previously-sent get or set (see Stanza Errors + (Section 9.3)). + + 3. An entity that receives an IQ request of type "get" or "set" MUST + reply with an IQ response of type "result" or "error" (the + response MUST preserve the 'id' attribute of the request). + + 4. An entity that receives a stanza of type "result" or "error" MUST + NOT respond to the stanza by sending a further IQ response of + type "result" or "error"; however, as shown above, the requesting + entity MAY send another request (e.g., an IQ of type "set" in + order to provide required information discovered through a + get/result pair). + + + + +Saint-Andre, Ed. Standards Track [Page 52] + +RFC 3920 XMPP Core October 2004 + + + 5. An IQ stanza of type "get" or "set" MUST contain one and only one + child element that specifies the semantics of the particular + request or response. + + 6. An IQ stanza of type "result" MUST include zero or one child + elements. + + 7. An IQ stanza of type "error" SHOULD include the child element + contained in the associated "get" or "set" and MUST include an + <error/> child; for details, see Stanza Errors (Section 9.3). + +9.3. Stanza Errors + + Stanza-related errors are handled in a manner similar to stream + errors (Section 4.7). However, unlike stream errors, stanza errors + are recoverable; therefore error stanzas include hints regarding + actions that the original sender can take in order to remedy the + error. + +9.3.1. Rules + + The following rules apply to stanza-related errors: + + o The receiving or processing entity that detects an error condition + in relation to a stanza MUST return to the sending entity a stanza + of the same kind (message, presence, or IQ), whose 'type' + attribute is set to a value of "error" (such a stanza is called an + "error stanza" herein). + + o The entity that generates an error stanza SHOULD include the + original XML sent so that the sender can inspect and, if + necessary, correct the XML before attempting to resend. + + o An error stanza MUST contain an <error/> child element. + + o An <error/> child MUST NOT be included if the 'type' attribute has + a value other than "error" (or if there is no 'type' attribute). + + o An entity that receives an error stanza MUST NOT respond to the + stanza with a further error stanza; this helps to prevent looping. + + + + + + + + + + + +Saint-Andre, Ed. Standards Track [Page 53] + +RFC 3920 XMPP Core October 2004 + + +9.3.2. Syntax + + The syntax for stanza-related errors is as follows: + + <stanza-kind to='sender' type='error'> + [RECOMMENDED to include sender XML here] + <error type='error-type'> + <defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> + <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas' + xml:lang='langcode'> + OPTIONAL descriptive text + </text> + [OPTIONAL application-specific condition element] + </error> + </stanza-kind> + + The stanza-kind is one of message, presence, or iq. + + The value of the <error/> element's 'type' attribute MUST be one of + the following: + + o cancel -- do not retry (the error is unrecoverable) + o continue -- proceed (the condition was only a warning) + o modify -- retry after changing the data sent + o auth -- retry after providing credentials + o wait -- retry after waiting (the error is temporary) + + The <error/> element: + + o MUST contain a child element corresponding to one of the defined + stanza error conditions specified below; this element MUST be + qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace. + + o MAY contain a <text/> child containing XML character data that + describes the error in more detail; this element MUST be qualified + by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace and SHOULD + possess an 'xml:lang' attribute. + + o MAY contain a child element for an application-specific error + condition; this element MUST be qualified by an + application-defined namespace, and its structure is defined by + that namespace. + + The <text/> element is OPTIONAL. If included, it SHOULD be used only + to provide descriptive or diagnostic information that supplements the + meaning of a defined condition or application-specific condition. It + SHOULD NOT be interpreted programmatically by an application. It + + + + +Saint-Andre, Ed. Standards Track [Page 54] + +RFC 3920 XMPP Core October 2004 + + + SHOULD NOT be used as the error message presented to a user, but MAY + be shown in addition to the error message associated with the + included condition element (or elements). + + Finally, to maintain backward compatibility, the schema (specified in + [XMPP-IM]) allows the optional inclusion of a 'code' attribute on the + <error/> element. + +9.3.3. Defined Conditions + + The following conditions are defined for use in stanza errors. + + o <bad-request/> -- the sender has sent XML that is malformed or + that cannot be processed (e.g., an IQ stanza that includes an + unrecognized value of the 'type' attribute); the associated error + type SHOULD be "modify". + + o <conflict/> -- access cannot be granted because an existing + resource or session exists with the same name or address; the + associated error type SHOULD be "cancel". + + o <feature-not-implemented/> -- the feature requested is not + implemented by the recipient or server and therefore cannot be + processed; the associated error type SHOULD be "cancel". + + o <forbidden/> -- the requesting entity does not possess the + required permissions to perform the action; the associated error + type SHOULD be "auth". + + o <gone/> -- the recipient or server can no longer be contacted at + this address (the error stanza MAY contain a new address in the + XML character data of the <gone/> element); the associated error + type SHOULD be "modify". + + o <internal-server-error/> -- the server could not process the + stanza because of a misconfiguration or an otherwise-undefined + internal server error; the associated error type SHOULD be "wait". + + o <item-not-found/> -- the addressed JID or item requested cannot be + found; the associated error type SHOULD be "cancel". + + o <jid-malformed/> -- the sending entity has provided or + communicated an XMPP address (e.g., a value of the 'to' attribute) + or aspect thereof (e.g., a resource identifier) that does not + adhere to the syntax defined in Addressing Scheme (Section 3); the + associated error type SHOULD be "modify". + + + + + +Saint-Andre, Ed. Standards Track [Page 55] + +RFC 3920 XMPP Core October 2004 + + + o <not-acceptable/> -- the recipient or server understands the + request but is refusing to process it because it does not meet + criteria defined by the recipient or server (e.g., a local policy + regarding acceptable words in messages); the associated error type + SHOULD be "modify". + + o <not-allowed/> -- the recipient or server does not allow any + entity to perform the action; the associated error type SHOULD be + "cancel". + + o <not-authorized/> -- the sender must provide proper credentials + before being allowed to perform the action, or has provided + improper credentials; the associated error type SHOULD be "auth". + + o <payment-required/> -- the requesting entity is not authorized to + access the requested service because payment is required; the + associated error type SHOULD be "auth". + + o <recipient-unavailable/> -- the intended recipient is temporarily + unavailable; the associated error type SHOULD be "wait" (note: an + application MUST NOT return this error if doing so would provide + information about the intended recipient's network availability to + an entity that is not authorized to know such information). + + o <redirect/> -- the recipient or server is redirecting requests for + this information to another entity, usually temporarily (the error + stanza SHOULD contain the alternate address, which MUST be a valid + JID, in the XML character data of the <redirect/> element); the + associated error type SHOULD be "modify". + + o <registration-required/> -- the requesting entity is not + authorized to access the requested service because registration is + required; the associated error type SHOULD be "auth". + + o <remote-server-not-found/> -- a remote server or service specified + as part or all of the JID of the intended recipient does not + exist; the associated error type SHOULD be "cancel". + + o <remote-server-timeout/> -- a remote server or service specified + as part or all of the JID of the intended recipient (or required + to fulfill a request) could not be contacted within a reasonable + amount of time; the associated error type SHOULD be "wait". + + o <resource-constraint/> -- the server or recipient lacks the system + resources necessary to service the request; the associated error + type SHOULD be "wait". + + + + + +Saint-Andre, Ed. Standards Track [Page 56] + +RFC 3920 XMPP Core October 2004 + + + o <service-unavailable/> -- the server or recipient does not + currently provide the requested service; the associated error type + SHOULD be "cancel". + + o <subscription-required/> -- the requesting entity is not + authorized to access the requested service because a subscription + is required; the associated error type SHOULD be "auth". + + o <undefined-condition/> -- the error condition is not one of those + defined by the other conditions in this list; any error type may + be associated with this condition, and it SHOULD be used only in + conjunction with an application-specific condition. + + o <unexpected-request/> -- the recipient or server understood the + request but was not expecting it at this time (e.g., the request + was out of order); the associated error type SHOULD be "wait". + +9.3.4. Application-Specific Conditions + + As noted, an application MAY provide application-specific stanza + error information by including a properly-namespaced child in the + error element. The application-specific element SHOULD supplement or + further qualify a defined element. Thus, the <error/> element will + contain two or three child elements: + + <iq type='error' id='some-id'> + <error type='modify'> + <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> + <too-many-parameters xmlns='application-ns'/> + </error> + </iq> + + <message type='error' id='another-id'> + <error type='modify'> + <undefined-condition + xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> + <text xml:lang='en' + xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'> + Some special application diagnostic information... + </text> + <special-application-condition xmlns='application-ns'/> + </error> + </message> + + + + + + + + +Saint-Andre, Ed. Standards Track [Page 57] + +RFC 3920 XMPP Core October 2004 + + +10. Server Rules for Handling XML Stanzas + + Compliant server implementations MUST ensure in-order processing of + XML stanzas between any two entities. + + Beyond the requirement for in-order processing, each server + implementation will contain its own "delivery tree" for handling + stanzas it receives. Such a tree determines whether a stanza needs + to be routed to another domain, processed internally, or delivered to + a resource associated with a connected node. The following rules + apply: + +10.1. No 'to' Address + + If the stanza possesses no 'to' attribute, the server SHOULD process + it on behalf of the entity that sent it. Because all stanzas + received from other servers MUST possess a 'to' attribute, this rule + applies only to stanzas received from a registered entity (such as a + client) that is connected to the server. If the server receives a + presence stanza with no 'to' attribute, the server SHOULD broadcast + it to the entities that are subscribed to the sending entity's + presence, if applicable (the semantics of presence broadcast for + instant messaging and presence applications are defined in + [XMPP-IM]). If the server receives an IQ stanza of type "get" or + "set" with no 'to' attribute and it understands the namespace that + qualifies the content of the stanza, it MUST either process the + stanza on behalf of the sending entity (where the meaning of + "process" is determined by the semantics of the qualifying namespace) + or return an error to the sending entity. + +10.2. Foreign Domain + + If the hostname of the domain identifier portion of the JID contained + in the 'to' attribute does not match one of the configured hostnames + of the server itself or a subdomain thereof, the server SHOULD route + the stanza to the foreign domain (subject to local service + provisioning and security policies regarding inter-domain + communication). There are two possible cases: + + A server-to-server stream already exists between the two domains: The + sender's server routes the stanza to the authoritative server for + the foreign domain over the existing stream + + There exists no server-to-server stream between the two domains: The + sender's server (1) resolves the hostname of the foreign domain + (as defined under Server-to-Server Communications (Section 14.4)), + (2) negotiates a server-to-server stream between the two domains + (as defined under Use of TLS (Section 5) and Use of SASL (Section + + + +Saint-Andre, Ed. Standards Track [Page 58] + +RFC 3920 XMPP Core October 2004 + + + 6)), and (3) routes the stanza to the authoritative server for the + foreign domain over the newly-established stream + + If routing to the recipient's server is unsuccessful, the sender's + server MUST return an error to the sender; if the recipient's server + can be contacted but delivery by the recipient's server to the + recipient is unsuccessful, the recipient's server MUST return an + error to the sender by way of the sender's server. + +10.3. Subdomain + + If the hostname of the domain identifier portion of the JID contained + in the 'to' attribute matches a subdomain of one of the configured + hostnames of the server itself, the server MUST either process the + stanza itself or route the stanza to a specialized service that is + responsible for that subdomain (if the subdomain is configured), or + return an error to the sender (if the subdomain is not configured). + +10.4. Mere Domain or Specific Resource + + If the hostname of the domain identifier portion of the JID contained + in the 'to' attribute matches a configured hostname of the server + itself and the JID contained in the 'to' attribute is of the form + <domain> or <domain/resource>, the server (or a defined resource + thereof) MUST either process the stanza as appropriate for the stanza + kind or return an error stanza to the sender. + +10.5. Node in Same Domain + + If the hostname of the domain identifier portion of the JID contained + in the 'to' attribute matches a configured hostname of the server + itself and the JID contained in the 'to' attribute is of the form + <node@domain> or <node@domain/resource>, the server SHOULD deliver + the stanza to the intended recipient of the stanza as represented by + the JID contained in the 'to' attribute. The following rules apply: + + 1. If the JID contains a resource identifier (i.e., is of the form + <node@domain/resource>) and there exists a connected resource + that matches the full JID, the recipient's server SHOULD deliver + the stanza to the stream or session that exactly matches the + resource identifier. + + 2. If the JID contains a resource identifier and there exists no + connected resource that matches the full JID, the recipient's + server SHOULD return a <service-unavailable/> stanza error to the + sender. + + + + + +Saint-Andre, Ed. Standards Track [Page 59] + +RFC 3920 XMPP Core October 2004 + + + 3. If the JID is of the form <node@domain> and there exists at least + one connected resource for the node, the recipient's server + SHOULD deliver the stanza to at least one of the connected + resources, according to application-specific rules (a set of + delivery rules for instant messaging and presence applications is + defined in [XMPP-IM]). + +11. XML Usage within XMPP + +11.1. Restrictions + + XMPP is a simplified and specialized protocol for streaming XML + elements in order to exchange structured information in close to real + time. Because XMPP does not require the parsing of arbitrary and + complete XML documents, there is no requirement that XMPP needs to + support the full feature set of [XML]. In particular, the following + restrictions apply. + + With regard to XML generation, an XMPP implementation MUST NOT inject + into an XML stream any of the following: + + o comments (as defined in Section 2.5 of [XML]) + + o processing instructions (Section 2.6 therein) + + o internal or external DTD subsets (Section 2.8 therein) + + o internal or external entity references (Section 4.2 therein) with + the exception of predefined entities (Section 4.6 therein) + + o character data or attribute values containing unescaped characters + that map to the predefined entities (Section 4.6 therein); such + characters MUST be escaped + + With regard to XML processing, if an XMPP implementation receives + such restricted XML data, it MUST ignore the data. + +11.2. XML Namespace Names and Prefixes + + XML Namespaces [XML-NAMES] are used within all XMPP-compliant XML to + create strict boundaries of data ownership. The basic function of + namespaces is to separate different vocabularies of XML elements that + are structurally mixed together. Ensuring that XMPP-compliant XML is + namespace-aware enables any allowable XML to be structurally mixed + with any data element within XMPP. Rules for XML namespace names and + prefixes are defined in the following subsections. + + + + + +Saint-Andre, Ed. Standards Track [Page 60] + +RFC 3920 XMPP Core October 2004 + + +11.2.1. Streams Namespace + + A streams namespace declaration is REQUIRED in all XML stream + headers. The name of the streams namespace MUST be + 'http://etherx.jabber.org/streams'. The element names of the + <stream/> element and its <features/> and <error/> children MUST be + qualified by the streams namespace prefix in all instances. An + implementation SHOULD generate only the 'stream:' prefix for these + elements, and for historical reasons MAY accept only the 'stream:' + prefix. + +11.2.2. Default Namespace + + A default namespace declaration is REQUIRED and is used in all XML + streams in order to define the allowable first-level children of the + root stream element. This namespace declaration MUST be the same for + the initial stream and the response stream so that both streams are + qualified consistently. The default namespace declaration applies to + the stream and all stanzas sent within a stream (unless explicitly + qualified by another namespace, or by the prefix of the streams + namespace or the dialback namespace). + + A server implementation MUST support the following two default + namespaces (for historical reasons, some implementations MAY support + only these two default namespaces): + + o jabber:client -- this default namespace is declared when the + stream is used for communications between a client and a server + + o jabber:server -- this default namespace is declared when the + stream is used for communications between two servers + + A client implementation MUST support the 'jabber:client' default + namespace, and for historical reasons MAY support only that default + namespace. + + An implementation MUST NOT generate namespace prefixes for elements + in the default namespace if the default namespace is 'jabber:client' + or 'jabber:server'. An implementation SHOULD NOT generate namespace + prefixes for elements qualified by content (as opposed to stream) + namespaces other than 'jabber:client' and 'jabber:server'. + + Note: The 'jabber:client' and 'jabber:server' namespaces are nearly + identical but are used in different contexts (client-to-server + communications for 'jabber:client' and server-to-server + communications for 'jabber:server'). The only difference between the + two is that the 'to' and 'from' attributes are OPTIONAL on stanzas + sent within 'jabber:client', whereas they are REQUIRED on stanzas + + + +Saint-Andre, Ed. Standards Track [Page 61] + +RFC 3920 XMPP Core October 2004 + + + sent within 'jabber:server'. If a compliant implementation accepts a + stream that is qualified by the 'jabber:client' or 'jabber:server' + namespace, it MUST support the common attributes (Section 9.1) and + basic semantics (Section 9.2) of all three core stanza kinds + (message, presence, and IQ). + +11.2.3. Dialback Namespace + + A dialback namespace declaration is REQUIRED for all elements used in + server dialback (Section 8). The name of the dialback namespace MUST + be 'jabber:server:dialback'. All elements qualified by this + namespace MUST be prefixed. An implementation SHOULD generate only + the 'db:' prefix for such elements and MAY accept only the 'db:' + prefix. + +11.3. Validation + + Except as noted with regard to 'to' and 'from' addresses for stanzas + within the 'jabber:server' namespace, a server is not responsible for + validating the XML elements forwarded to a client or another server; + an implementation MAY choose to provide only validated data elements + but this is OPTIONAL (although an implementation MUST NOT accept XML + that is not well-formed). Clients SHOULD NOT rely on the ability to + send data which does not conform to the schemas, and SHOULD ignore + any non-conformant elements or attributes on the incoming XML stream. + Validation of XML streams and stanzas is OPTIONAL, and schemas are + included herein for descriptive purposes only. + +11.4. Inclusion of Text Declaration + + Implementations SHOULD send a text declaration before sending a + stream header. Applications MUST follow the rules in [XML] regarding + the circumstances under which a text declaration is included. + +11.5. Character Encoding + + Implementations MUST support the UTF-8 (RFC 3629 [UTF-8]) + transformation of Universal Character Set (ISO/IEC 10646-1 [UCS2]) + characters, as required by RFC 2277 [CHARSET]. Implementations MUST + NOT attempt to use any other encoding. + +12. Core Compliance Requirements + + This section summarizes the specific aspects of the Extensible + Messaging and Presence Protocol that MUST be supported by servers and + clients in order to be considered compliant implementations, as well + as additional protocol aspects that SHOULD be supported. For + compliance purposes, we draw a distinction between core protocols + + + +Saint-Andre, Ed. Standards Track [Page 62] + +RFC 3920 XMPP Core October 2004 + + + (which MUST be supported by any server or client, regardless of the + specific application) and instant messaging protocols (which MUST be + supported only by instant messaging and presence applications built + on top of the core protocols). Compliance requirements that apply to + all servers and clients are specified in this section; compliance + requirements for instant messaging servers and clients are specified + in the corresponding section of [XMPP-IM]. + +12.1. Servers + + In addition to all defined requirements with regard to security, XML + usage, and internationalization, a server MUST support the following + core protocols in order to be considered compliant: + + o Application of the [NAMEPREP], Nodeprep (Appendix A), and + Resourceprep (Appendix B) profiles of [STRINGPREP] to addresses + (including ensuring that domain identifiers are internationalized + domain names as defined in [IDNA]) + + o XML streams (Section 4), including Use of TLS (Section 5), Use of + SASL (Section 6), and Resource Binding (Section 7) + + o The basic semantics of the three defined stanza kinds (i.e., + <message/>, <presence/>, and <iq/>) as specified in stanza + semantics (Section 9.2) + + o Generation (and, where appropriate, handling) of error syntax and + semantics related to streams, TLS, SASL, and XML stanzas + + In addition, a server MAY support the following core protocol: + + o Server dialback (Section 8) + +12.2. Clients + + A client MUST support the following core protocols in order to be + considered compliant: + + o XML streams (Section 4), including Use of TLS (Section 5), Use of + SASL (Section 6), and Resource Binding (Section 7) + + o The basic semantics of the three defined stanza kinds (i.e., + <message/>, <presence/>, and <iq/>) as specified in stanza + semantics (Section 9.2) + + o Handling (and, where appropriate, generation) of error syntax and + semantics related to streams, TLS, SASL, and XML stanzas + + + + +Saint-Andre, Ed. Standards Track [Page 63] + +RFC 3920 XMPP Core October 2004 + + + In addition, a client SHOULD support the following core protocols: + + o Generation of addresses to which the [NAMEPREP], Nodeprep + (Appendix A), and Resourceprep (Appendix B) profiles of + [STRINGPREP] can be applied without failing + +13. Internationalization Considerations + + XML streams MUST be encoded in UTF-8 as specified under Character + Encoding (Section 11.5). As specified under Stream Attributes + (Section 4.4), an XML stream SHOULD include an 'xml:lang' attribute + that is treated as the default language for any XML character data + sent over the stream that is intended to be presented to a human + user. As specified under xml:lang (Section 9.1.5), an XML stanza + SHOULD include an 'xml:lang' attribute if the stanza contains XML + character data that is intended to be presented to a human user. A + server SHOULD apply the default 'xml:lang' attribute to stanzas it + routes or delivers on behalf of connected entities, and MUST NOT + modify or delete 'xml:lang' attributes from stanzas it receives from + other entities. + +14. Security Considerations + +14.1. High Security + + For the purposes of XMPP communications (client-to-server and + server-to-server), the term "high security" refers to the use of + security technologies that provide both mutual authentication and + integrity-checking; in particular, when using certificate-based + authentication to provide high security, a chain-of-trust SHOULD be + established out-of-band, although a shared certificate authority + signing certificates could allow a previously unknown certificate to + establish trust in-band. See Section 14.2 below regarding + certificate validation procedures. + + Implementations MUST support high security. Service provisioning + SHOULD use high security, subject to local security policies. + +14.2. Certificate Validation + + When an XMPP peer communicates with another peer securely, it MUST + validate the peer's certificate. There are three possible cases: + + Case #1: The peer contains an End Entity certificate which appears to + be certified by a chain of certificates terminating in a trust + anchor (as described in Section 6.1 of [X509]). + + + + + +Saint-Andre, Ed. Standards Track [Page 64] + +RFC 3920 XMPP Core October 2004 + + + Case #2: The peer certificate is certified by a Certificate Authority + not known to the validating peer. + + Case #3: The peer certificate is self-signed. + + In Case #1, the validating peer MUST do one of two things: + + 1. Verify the peer certificate according to the rules of [X509]. + The certificate SHOULD then be checked against the expected + identity of the peer following the rules described in [HTTP-TLS], + except that a subjectAltName extension of type "xmpp" MUST be + used as the identity if present. If one of these checks fails, + user-oriented clients MUST either notify the user (clients MAY + give the user the opportunity to continue with the connection in + any case) or terminate the connection with a bad certificate + error. Automated clients SHOULD terminate the connection (with a + bad certificate error) and log the error to an appropriate audit + log. Automated clients MAY provide a configuration setting that + disables this check, but MUST provide a setting that enables it. + + 2. The peer SHOULD show the certificate to a user for approval, + including the entire certificate chain. The peer MUST cache the + certificate (or some non-forgeable representation such as a + hash). In future connections, the peer MUST verify that the same + certificate was presented and MUST notify the user if it has + changed. + + In Case #2 and Case #3, implementations SHOULD act as in (2) above. + +14.3. Client-to-Server Communications + + A compliant client implementation MUST support both TLS and SASL for + connections to a server. + + The TLS protocol for encrypting XML streams (defined under Use of TLS + (Section 5)) provides a reliable mechanism for helping to ensure the + confidentiality and data integrity of data exchanged between two + entities. + + The SASL protocol for authenticating XML streams (defined under Use + of SASL (Section 6)) provides a reliable mechanism for validating + that a client connecting to a server is who it claims to be. + + Client-to-server communications MUST NOT proceed until the DNS + hostname asserted by the server has been resolved. Such resolutions + SHOULD first attempt to resolve the hostname using an [SRV] Service + of "xmpp-client" and Proto of "tcp", resulting in resource records + such as "_xmpp-client._tcp.example.com." (the use of the string + + + +Saint-Andre, Ed. Standards Track [Page 65] + +RFC 3920 XMPP Core October 2004 + + + "xmpp-client" for the service identifier is consistent with the IANA + registration). If the SRV lookup fails, the fallback is a normal + IPv4/IPv6 address record resolution to determine the IP address, + using the "xmpp-client" port of 5222, registered with the IANA. + + The IP address and method of access of clients MUST NOT be made + public by a server, nor are any connections other than the original + server connection required. This helps to protect the client's + server from direct attack or identification by third parties. + +14.4. Server-to-Server Communications + + A compliant server implementation MUST support both TLS and SASL for + inter-domain communications. For historical reasons, a compliant + implementation SHOULD also support Server Dialback (Section 8). + + Because service provisioning is a matter of policy, it is OPTIONAL + for any given domain to communicate with other domains, and + server-to-server communications MAY be disabled by the administrator + of any given deployment. If a particular domain enables inter-domain + communications, it SHOULD enable high security. + + Administrators may want to require use of SASL for server-to-server + communications in order to ensure both authentication and + confidentiality (e.g., on an organization's private network). + Compliant implementations SHOULD support SASL for this purpose. + + Inter-domain connections MUST NOT proceed until the DNS hostnames + asserted by the servers have been resolved. Such resolutions MUST + first attempt to resolve the hostname using an [SRV] Service of + "xmpp-server" and Proto of "tcp", resulting in resource records such + as "_xmpp-server._tcp.example.com." (the use of the string + "xmpp-server" for the service identifier is consistent with the IANA + registration; note well that the "xmpp-server" service identifier + supersedes the earlier use of a "jabber" service identifier, since + the earlier usage did not conform to [SRV]; implementations desiring + to be backward compatible should continue to look for or answer to + the "jabber" service identifier as well). If the SRV lookup fails, + the fallback is a normal IPv4/IPv6 address record resolution to + determine the IP address, using the "xmpp-server" port 5269, + registered with the IANA. + + Server dialback helps protect against domain spoofing, thus making it + more difficult to spoof XML stanzas. It is not a mechanism for + authenticating, securing, or encrypting streams between servers as is + done via SASL and TLS, and results in weak verification of server + identities only. Furthermore, it is susceptible to DNS poisoning + attacks unless DNSSec [DNSSEC] is used, and even if the DNS + + + +Saint-Andre, Ed. Standards Track [Page 66] + +RFC 3920 XMPP Core October 2004 + + + information is accurate, dialback cannot protect from attacks where + the attacker is capable of hijacking the IP address of the remote + domain. Domains requiring robust security SHOULD use TLS and SASL. + If SASL is used for server-to-server authentication, dialback SHOULD + NOT be used since it is unnecessary. + +14.5. Order of Layers + + The order of layers in which protocols MUST be stacked is as follows: + + 1. TCP + 2. TLS + 3. SASL + 4. XMPP + + The rationale for this order is that [TCP] is the base connection + layer used by all of the protocols stacked on top of TCP, [TLS] is + often provided at the operating system layer, [SASL] is often + provided at the application layer, and XMPP is the application + itself. + +14.6. Lack of SASL Channel Binding to TLS + + The SASL framework does not provide a mechanism to bind SASL + authentication to a security layer providing confidentiality and + integrity protection that was negotiated at a lower layer. This lack + of a "channel binding" prevents SASL from being able to verify that + the source and destination end points to which the lower layer's + security is bound are equivalent to the end points that SASL is + authenticating. If the end points are not identical, the lower + layer's security cannot be trusted to protect data transmitted + between the SASL authenticated entities. In such a situation, a SASL + security layer should be negotiated that effectively ignores the + presence of the lower layer security. + +14.7. Mandatory-to-Implement Technologies + + At a minimum, all implementations MUST support the following + mechanisms: + + for authentication: the SASL [DIGEST-MD5] mechanism + + for confidentiality: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA + cipher) + + for both: TLS plus SASL EXTERNAL(using the + TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side + certificates) + + + +Saint-Andre, Ed. Standards Track [Page 67] + +RFC 3920 XMPP Core October 2004 + + +14.8. Firewalls + + Communications using XMPP normally occur over [TCP] connections on + port 5222 (client-to-server) or port 5269 (server-to-server), as + registered with the IANA (see IANA Considerations (Section 15)). Use + of these well-known ports allows administrators to easily enable or + disable XMPP activity through existing and commonly-deployed + firewalls. + +14.9. Use of base64 in SASL + + Both the client and the server MUST verify any [BASE64] data received + during SASL negotiation. An implementation MUST reject (not ignore) + any characters that are not explicitly allowed by the base64 + alphabet; this helps to guard against creation of a covert channel + that could be used to "leak" information. An implementation MUST NOT + break on invalid input and MUST reject any sequence of base64 + characters containing the pad ('=') character if that character is + included as something other than the last character of the data + (e.g., "=AAA" or "BBBB=CCC"); this helps to guard against buffer + overflow attacks and other attacks on the implementation. Base 64 + encoding visually hides otherwise easily recognized information, such + as passwords, but does not provide any computational confidentiality. + Base 64 encoding MUST follow the definition in Section 3 of RFC 3548 + [BASE64]. + +14.10. Stringprep Profiles + + XMPP makes use of the [NAMEPREP] profile of [STRINGPREP] for the + processing of domain identifiers; for security considerations related + to Nameprep, refer to the appropriate section of [NAMEPREP]. + + In addition, XMPP defines two profiles of [STRINGPREP]: Nodeprep + (Appendix A) for node identifiers and Resourceprep (Appendix B) for + resource identifiers. + + The Unicode and ISO/IEC 10646 repertoires have many characters that + look similar. In many cases, users of security protocols might do + visual matching, such as when comparing the names of trusted third + parties. Because it is impossible to map similar-looking characters + without a great deal of context, such as knowing the fonts used, + stringprep does nothing to map similar-looking characters together, + nor to prohibit some characters because they look like others. + + A node identifier can be employed as one part of an entity's address + in XMPP. One common usage is as the username of an instant messaging + user; another is as the name of a multi-user chat room; many other + kinds of entities could use node identifiers as part of their + + + +Saint-Andre, Ed. Standards Track [Page 68] + +RFC 3920 XMPP Core October 2004 + + + addresses. The security of such services could be compromised based + on different interpretations of the internationalized node + identifier; for example, a user entering a single internationalized + node identifier could access another user's account information, or a + user could gain access to an otherwise restricted chat room or + service. + + A resource identifier can be employed as one part of an entity's + address in XMPP. One common usage is as the name for an instant + messaging user's connected resource (active session); another is as + the nickname of a user in a multi-user chat room; many other kinds of + entities could use resource identifiers as part of their addresses. + The security of such services could be compromised based on different + interpretations of the internationalized resource identifier; for + example, a user could attempt to initiate multiple sessions with the + same name, or a user could send a message to someone other than the + intended recipient in a multi-user chat room. + +15. IANA Considerations + +15.1. XML Namespace Name for TLS Data + + A URN sub-namespace for TLS-related data in the Extensible Messaging + and Presence Protocol (XMPP) is defined as follows. (This namespace + name adheres to the format defined in The IETF XML Registry + [XML-REG].) + + URI: urn:ietf:params:xml:ns:xmpp-tls + Specification: RFC 3920 + Description: This is the XML namespace name for TLS-related data in + the Extensible Messaging and Presence Protocol (XMPP) as defined + by RFC 3920. + Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org> + +15.2. XML Namespace Name for SASL Data + + A URN sub-namespace for SASL-related data in the Extensible Messaging + and Presence Protocol (XMPP) is defined as follows. (This namespace + name adheres to the format defined in [XML-REG].) + + URI: urn:ietf:params:xml:ns:xmpp-sasl + Specification: RFC 3920 + Description: This is the XML namespace name for SASL-related data in + the Extensible Messaging and Presence Protocol (XMPP) as defined + by RFC 3920. + Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org> + + + + + +Saint-Andre, Ed. Standards Track [Page 69] + +RFC 3920 XMPP Core October 2004 + + +15.3. XML Namespace Name for Stream Errors + + A URN sub-namespace for stream-related error data in the Extensible + Messaging and Presence Protocol (XMPP) is defined as follows. (This + namespace name adheres to the format defined in [XML-REG].) + + URI: urn:ietf:params:xml:ns:xmpp-streams + Specification: RFC 3920 + Description: This is the XML namespace name for stream-related error + data in the Extensible Messaging and Presence Protocol (XMPP) as + defined by RFC 3920. + Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org> + +15.4. XML Namespace Name for Resource Binding + + A URN sub-namespace for resource binding in the Extensible Messaging + and Presence Protocol (XMPP) is defined as follows. (This namespace + name adheres to the format defined in [XML-REG].) + + URI: urn:ietf:params:xml:ns:xmpp-bind + Specification: RFC 3920 + Description: This is the XML namespace name for resource binding in + the Extensible Messaging and Presence Protocol (XMPP) as defined + by RFC 3920. + Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org> + +15.5. XML Namespace Name for Stanza Errors + + A URN sub-namespace for stanza-related error data in the Extensible + Messaging and Presence Protocol (XMPP) is defined as follows. (This + namespace name adheres to the format defined in [XML-REG].) + + URI: urn:ietf:params:xml:ns:xmpp-stanzas + Specification: RFC 3920 + Description: This is the XML namespace name for stanza-related error + data in the Extensible Messaging and Presence Protocol (XMPP) as + defined by RFC 3920. + Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org> + +15.6. Nodeprep Profile of Stringprep + + The Nodeprep profile of stringprep is defined under Nodeprep + (Appendix A). The IANA has registered Nodeprep in the stringprep + profile registry. + + Name of this profile: + + Nodeprep + + + +Saint-Andre, Ed. Standards Track [Page 70] + +RFC 3920 XMPP Core October 2004 + + + RFC in which the profile is defined: + + RFC 3920 + + Indicator whether or not this is the newest version of the profile: + + This is the first version of Nodeprep + +15.7. Resourceprep Profile of Stringprep + + The Resourceprep profile of stringprep is defined under Resourceprep + (Appendix B). The IANA has registered Resourceprep in the stringprep + profile registry. + + Name of this profile: + + Resourceprep + + RFC in which the profile is defined: + + RFC 3920 + + Indicator whether or not this is the newest version of the profile: + + This is the first version of Resourceprep + +15.8. GSSAPI Service Name + + The IANA has registered "xmpp" as a GSSAPI [GSS-API] service name, as + defined under SASL Definition (Section 6.3). + +15.9. Port Numbers + + The IANA has registered "xmpp-client" and "xmpp-server" as keywords + for [TCP] ports 5222 and 5269 respectively. + + These ports SHOULD be used for client-to-server and server-to-server + communications respectively, but their use is OPTIONAL. + +16. References + +16.1. Normative References + + [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", RFC 3548, July 2003. + + + +Saint-Andre, Ed. Standards Track [Page 71] + +RFC 3920 XMPP Core October 2004 + + + [CHARSET] Alvestrand, H., "IETF Policy on Character Sets and + Languages", BCP 18, RFC 2277, January 1998. + + [DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication as + a SASL Mechanism", RFC 2831, May 2000. + + [DNS] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [GSS-API] Linn, J., "Generic Security Service Application Program + Interface Version 2, Update 1", RFC 2743, January 2000. + + [HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. + + [IDNA] Faltstrom, P., Hoffman, P., and A. Costello, + "Internationalizing Domain Names in Applications + (IDNA)", RFC 3490, March 2003. + + [IPv6] Hinden, R. and S. Deering, "Internet Protocol Version 6 + (IPv6) Addressing Architecture", RFC 3513, April 2003. + + [LANGTAGS] Alvestrand, H., "Tags for the Identification of + Languages", BCP 47, RFC 3066, January 2001. + + [NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep + Profile for Internationalized Domain Names (IDN)", RFC + 3491, March 2003. + + [RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller, + "Randomness Recommendations for Security", RFC 1750, + December 1994. + + [SASL] Myers, J., "Simple Authentication and Security Layer + (SASL)", RFC 2222, October 1997. + + [SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC + 2782, February 2000. + + [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of + Internationalized Strings ("stringprep")", RFC 3454, + December 2002. + + [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + + + + + +Saint-Andre, Ed. Standards Track [Page 72] + +RFC 3920 XMPP Core October 2004 + + + [TERMS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", + RFC 2246, January 1999. + + [UCS2] International Organization for Standardization, + "Information Technology - Universal Multiple-octet coded + Character Set (UCS) - Amendment 2: UCS Transformation + Format 8 (UTF-8)", ISO Standard 10646-1 Addendum 2, + October 1996. + + [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [X509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet + X.509 Public Key Infrastructure Certificate and + Certificate Revocation List (CRL) Profile", RFC 3280, + April 2002. + + [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, + "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C + REC-xml, October 2000, <http://www.w3.org/TR/REC-xml>. + + [XML-NAMES] Bray, T., Hollander, D., and A. Layman, "Namespaces in + XML", W3C REC-xml-names, January 1999, + <http://www.w3.org/TR/REC-xml-names>. + +16.2. Informative References + + [ACAP] Newman, C. and J. Myers, "ACAP -- Application + Configuration Access Protocol", RFC 2244, November 1997. + + [ASN.1] CCITT, "Recommendation X.208: Specification of Abstract + Syntax Notation One (ASN.1)", 1988. + + [DNSSEC] Eastlake 3rd, D., "Domain Name System Security + Extensions", RFC 2535, March 1999. + + [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. + + [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION + 4rev1", RFC 3501, March 2003. + + + + + + +Saint-Andre, Ed. Standards Track [Page 73] + +RFC 3920 XMPP Core October 2004 + + + [IMP-REQS] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, + "Instant Messaging / Presence Protocol Requirements", + RFC 2779, February 2000. + + [IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat + Protocol", RFC 1459, May 1993. + + [JEP-0029] Kaes, C., "Definition of Jabber Identifiers (JIDs)", JSF + JEP 0029, October 2003. + + [JEP-0078] Saint-Andre, P., "Non-SASL Authentication", JSF JEP + 0078, July 2004. + + [JEP-0086] Norris, R. and P. Saint-Andre, "Error Condition + Mappings", JSF JEP 0086, February 2004. + + [JSF] Jabber Software Foundation, "Jabber Software + Foundation", <http://www.jabber.org/>. + + [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version + 3", STD 53, RFC 1939, May 1996. + + [SIMPLE] SIMPLE Working Group, "SIMPLE WG", + <http://www.ietf.org/html.charters/simple-charter.html>. + + [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, + April 2001. + + [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifiers (URI): Generic Syntax", RFC 2396, + August 1998. + + [USINGTLS] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC + 2595, June 1999. + + [XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + January 2004. + + [XMPP-IM] Saint-Andre, P., Ed., "Extensible Messaging and Presence + Protocol (XMPP): Instant Messaging and Presence", RFC + 3921, October 2004. + + + + + + + + + + +Saint-Andre, Ed. Standards Track [Page 74] + +RFC 3920 XMPP Core October 2004 + + +Appendix A. Nodeprep + +A.1. Introduction + + This appendix defines the "Nodeprep" profile of [STRINGPREP]. As + such, it specifies processing rules that will enable users to enter + internationalized node identifiers in the Extensible Messaging and + Presence Protocol (XMPP) and have the highest chance of getting the + content of the strings correct. (An XMPP node identifier is the + optional portion of an XMPP address that precedes a domain identifier + and the '@' separator; it is often but not exclusively associated + with an instant messaging username.) These processing rules are + intended only for XMPP node identifiers and are not intended for + arbitrary text or any other aspect of an XMPP address. + + This profile defines the following, as required by [STRINGPREP]: + + o The intended applicability of the profile: internationalized node + identifiers within XMPP + o The character repertoire that is the input and output to + stringprep: Unicode 3.2, specified in Section 2 of this Appendix + o The mappings used: specified in Section 3 + o The Unicode normalization used: specified in Section 4 + o The characters that are prohibited as output: specified in Section + 5 + o Bidirectional character handling: specified in Section 6 + +A.2. Character Repertoire + + This profile uses Unicode 3.2 with the list of unassigned code points + being Table A.1, both defined in Appendix A of [STRINGPREP]. + +A.3. Mapping + + This profile specifies mapping using the following tables from + [STRINGPREP]: + + Table B.1 + Table B.2 + +A.4. Normalization + + This profile specifies the use of Unicode normalization form KC, as + described in [STRINGPREP]. + + + + + + + +Saint-Andre, Ed. Standards Track [Page 75] + +RFC 3920 XMPP Core October 2004 + + +A.5. Prohibited Output + + This profile specifies the prohibition of using the following tables + from [STRINGPREP]. + + Table C.1.1 + Table C.1.2 + Table C.2.1 + Table C.2.2 + Table C.3 + Table C.4 + Table C.5 + Table C.6 + Table C.7 + Table C.8 + Table C.9 + + In addition, the following Unicode characters are also prohibited: + + #x22 (") + #x26 (&) + #x27 (') + #x2F (/) + #x3A (:) + #x3C (<) + #x3E (>) + #x40 (@) + +A.6. Bidirectional Characters + + This profile specifies the checking of bidirectional strings, as + described in Section 6 of [STRINGPREP]. + +Appendix B. Resourceprep + +B.1. Introduction + + This appendix defines the "Resourceprep" profile of [STRINGPREP]. As + such, it specifies processing rules that will enable users to enter + internationalized resource identifiers in the Extensible Messaging + and Presence Protocol (XMPP) and have the highest chance of getting + the content of the strings correct. (An XMPP resource identifier is + the optional portion of an XMPP address that follows a domain + identifier and the '/' separator; it is often but not exclusively + associated with an instant messaging session name.) These processing + rules are intended only for XMPP resource identifiers and are not + intended for arbitrary text or any other aspect of an XMPP address. + + + + +Saint-Andre, Ed. Standards Track [Page 76] + +RFC 3920 XMPP Core October 2004 + + + This profile defines the following, as required by [STRINGPREP]: + + o The intended applicability of the profile: internationalized + resource identifiers within XMPP + + o The character repertoire that is the input and output to + stringprep: Unicode 3.2, specified in Section 2 of this Appendix + + o The mappings used: specified in Section 3 + + o The Unicode normalization used: specified in Section 4 + + o The characters that are prohibited as output: specified in Section + 5 + + o Bidirectional character handling: specified in Section 6 + +B.2. Character Repertoire + + This profile uses Unicode 3.2 with the list of unassigned code points + being Table A.1, both defined in Appendix A of [STRINGPREP]. + +B.3. Mapping + + This profile specifies mapping using the following tables from + [STRINGPREP]: + + Table B.1 + +B.4. Normalization + + This profile specifies using Unicode normalization form KC, as + described in [STRINGPREP]. + + + + + + + + + + + + + + + + + + +Saint-Andre, Ed. Standards Track [Page 77] + +RFC 3920 XMPP Core October 2004 + + +B.5. Prohibited Output + + This profile specifies prohibiting use of the following tables from + [STRINGPREP]. + + Table C.1.2 + Table C.2.1 + Table C.2.2 + Table C.3 + Table C.4 + Table C.5 + Table C.6 + Table C.7 + Table C.8 + Table C.9 + +B.6. Bidirectional Characters + + This profile specifies checking bidirectional strings as described in + Section 6 of [STRINGPREP]. + +Appendix C. XML Schemas + + The following XML schemas are descriptive, not normative. For + schemas defining the 'jabber:client' and 'jabber:server' namespaces, + refer to [XMPP-IM]. + +C.1. Streams namespace + + <?xml version='1.0' encoding='UTF-8'?> + + <xs:schema + xmlns:xs='http://www.w3.org/2001/XMLSchema' + targetNamespace='http://etherx.jabber.org/streams' + xmlns='http://etherx.jabber.org/streams' + elementFormDefault='unqualified'> + + <xs:element name='stream'> + <xs:complexType> + <xs:sequence xmlns:client='jabber:client' + xmlns:server='jabber:server' + xmlns:db='jabber:server:dialback'> + <xs:element ref='features' minOccurs='0' maxOccurs='1'/> + <xs:any namespace='urn:ietf:params:xml:ns:xmpp-tls' + minOccurs='0' + maxOccurs='unbounded'/> + <xs:any namespace='urn:ietf:params:xml:ns:xmpp-sasl' + minOccurs='0' + + + +Saint-Andre, Ed. Standards Track [Page 78] + +RFC 3920 XMPP Core October 2004 + + + maxOccurs='unbounded'/> + <xs:choice minOccurs='0' maxOccurs='1'> + <xs:choice minOccurs='0' maxOccurs='unbounded'> + <xs:element ref='client:message'/> + <xs:element ref='client:presence'/> + <xs:element ref='client:iq'/> + </xs:choice> + <xs:choice minOccurs='0' maxOccurs='unbounded'> + <xs:element ref='server:message'/> + <xs:element ref='server:presence'/> + <xs:element ref='server:iq'/> + <xs:element ref='db:result'/> + <xs:element ref='db:verify'/> + </xs:choice> + </xs:choice> + <xs:element ref='error' minOccurs='0' maxOccurs='1'/> + </xs:sequence> + <xs:attribute name='from' type='xs:string' use='optional'/> + <xs:attribute name='id' type='xs:NMTOKEN' use='optional'/> + <xs:attribute name='to' type='xs:string' use='optional'/> + <xs:attribute name='version' type='xs:decimal' use='optional'/> + <xs:attribute ref='xml:lang' use='optional'/> + </xs:complexType> + </xs:element> + + <xs:element name='features'> + <xs:complexType> + <xs:all xmlns:tls='urn:ietf:params:xml:ns:xmpp-tls' + xmlns:sasl='urn:ietf:params:xml:ns:xmpp-sasl' + xmlns:bind='urn:ietf:params:xml:ns:xmpp-bind' + xmlns:sess='urn:ietf:params:xml:ns:xmpp-session'> + <xs:element ref='tls:starttls' minOccurs='0'/> + <xs:element ref='sasl:mechanisms' minOccurs='0'/> + <xs:element ref='bind:bind' minOccurs='0'/> + <xs:element ref='sess:session' minOccurs='0'/> + </xs:all> + </xs:complexType> + </xs:element> + + <xs:element name='error'> + <xs:complexType> + <xs:sequence xmlns:err='urn:ietf:params:xml:ns:xmpp-streams'> + <xs:group ref='err:streamErrorGroup'/> + <xs:element ref='err:text' + minOccurs='0' + maxOccurs='1'/> + </xs:sequence> + </xs:complexType> + + + +Saint-Andre, Ed. Standards Track [Page 79] + +RFC 3920 XMPP Core October 2004 + + + </xs:element> + + </xs:schema> + +C.2. Stream error namespace + + <?xml version='1.0' encoding='UTF-8'?> + + <xs:schema + xmlns:xs='http://www.w3.org/2001/XMLSchema' + targetNamespace='urn:ietf:params:xml:ns:xmpp-streams' + xmlns='urn:ietf:params:xml:ns:xmpp-streams' + elementFormDefault='qualified'> + + <xs:element name='bad-format' type='empty'/> + <xs:element name='bad-namespace-prefix' type='empty'/> + <xs:element name='conflict' type='empty'/> + <xs:element name='connection-timeout' type='empty'/> + <xs:element name='host-gone' type='empty'/> + <xs:element name='host-unknown' type='empty'/> + <xs:element name='improper-addressing' type='empty'/> + <xs:element name='internal-server-error' type='empty'/> + <xs:element name='invalid-from' type='empty'/> + <xs:element name='invalid-id' type='empty'/> + <xs:element name='invalid-namespace' type='empty'/> + <xs:element name='invalid-xml' type='empty'/> + <xs:element name='not-authorized' type='empty'/> + <xs:element name='policy-violation' type='empty'/> + <xs:element name='remote-connection-failed' type='empty'/> + <xs:element name='resource-constraint' type='empty'/> + <xs:element name='restricted-xml' type='empty'/> + <xs:element name='see-other-host' type='xs:string'/> + <xs:element name='system-shutdown' type='empty'/> + <xs:element name='undefined-condition' type='empty'/> + <xs:element name='unsupported-encoding' type='empty'/> + <xs:element name='unsupported-stanza-type' type='empty'/> + <xs:element name='unsupported-version' type='empty'/> + <xs:element name='xml-not-well-formed' type='empty'/> + + <xs:group name='streamErrorGroup'> + <xs:choice> + <xs:element ref='bad-format'/> + <xs:element ref='bad-namespace-prefix'/> + <xs:element ref='conflict'/> + <xs:element ref='connection-timeout'/> + <xs:element ref='host-gone'/> + <xs:element ref='host-unknown'/> + <xs:element ref='improper-addressing'/> + + + +Saint-Andre, Ed. Standards Track [Page 80] + +RFC 3920 XMPP Core October 2004 + + + <xs:element ref='internal-server-error'/> + <xs:element ref='invalid-from'/> + <xs:element ref='invalid-id'/> + <xs:element ref='invalid-namespace'/> + <xs:element ref='invalid-xml'/> + <xs:element ref='not-authorized'/> + <xs:element ref='policy-violation'/> + <xs:element ref='remote-connection-failed'/> + <xs:element ref='resource-constraint'/> + <xs:element ref='restricted-xml'/> + <xs:element ref='see-other-host'/> + <xs:element ref='system-shutdown'/> + <xs:element ref='undefined-condition'/> + <xs:element ref='unsupported-encoding'/> + <xs:element ref='unsupported-stanza-type'/> + <xs:element ref='unsupported-version'/> + <xs:element ref='xml-not-well-formed'/> + </xs:choice> + </xs:group> + + <xs:element name='text'> + <xs:complexType> + <xs:simpleContent> + <xs:extension base='xs:string'> + <xs:attribute ref='xml:lang' use='optional'/> + </xs:extension> + </xs:simpleContent> + </xs:complexType> + </xs:element> + + <xs:simpleType name='empty'> + <xs:restriction base='xs:string'> + <xs:enumeration value=''/> + </xs:restriction> + </xs:simpleType> + + </xs:schema> + +C.3. TLS namespace + + <?xml version='1.0' encoding='UTF-8'?> + + <xs:schema + xmlns:xs='http://www.w3.org/2001/XMLSchema' + targetNamespace='urn:ietf:params:xml:ns:xmpp-tls' + xmlns='urn:ietf:params:xml:ns:xmpp-tls' + elementFormDefault='qualified'> + + + + +Saint-Andre, Ed. Standards Track [Page 81] + +RFC 3920 XMPP Core October 2004 + + + <xs:element name='starttls'> + <xs:complexType> + <xs:sequence> + <xs:element + name='required' + minOccurs='0' + maxOccurs='1' + type='empty'/> + </xs:sequence> + </xs:complexType> + </xs:element> + + <xs:element name='proceed' type='empty'/> + <xs:element name='failure' type='empty'/> + + <xs:simpleType name='empty'> + <xs:restriction base='xs:string'> + <xs:enumeration value=''/> + </xs:restriction> + </xs:simpleType> + + </xs:schema> + +C.4. SASL namespace + + <?xml version='1.0' encoding='UTF-8'?> + + <xs:schema + xmlns:xs='http://www.w3.org/2001/XMLSchema' + targetNamespace='urn:ietf:params:xml:ns:xmpp-sasl' + xmlns='urn:ietf:params:xml:ns:xmpp-sasl' + elementFormDefault='qualified'> + + <xs:element name='mechanisms'> + <xs:complexType> + <xs:sequence> + <xs:element name='mechanism' + maxOccurs='unbounded' + type='xs:string'/> + </xs:sequence> + </xs:complexType> + </xs:element> + + <xs:element name='auth'> + <xs:complexType> + <xs:simpleContent> + <xs:extension base='empty'> + <xs:attribute name='mechanism' + + + +Saint-Andre, Ed. Standards Track [Page 82] + +RFC 3920 XMPP Core October 2004 + + + type='xs:string' + use='optional'/> + </xs:extension> + </xs:simpleContent> + </xs:complexType> + </xs:element> + + <xs:element name='challenge' type='xs:string'/> + <xs:element name='response' type='xs:string'/> + <xs:element name='abort' type='empty'/> + <xs:element name='success' type='empty'/> + + <xs:element name='failure'> + <xs:complexType> + <xs:choice minOccurs='0'> + <xs:element name='aborted' type='empty'/> + <xs:element name='incorrect-encoding' type='empty'/> + <xs:element name='invalid-authzid' type='empty'/> + <xs:element name='invalid-mechanism' type='empty'/> + <xs:element name='mechanism-too-weak' type='empty'/> + <xs:element name='not-authorized' type='empty'/> + <xs:element name='temporary-auth-failure' type='empty'/> + </xs:choice> + </xs:complexType> + </xs:element> + <xs:simpleType name='empty'> + <xs:restriction base='xs:string'> + <xs:enumeration value=''/> + </xs:restriction> + </xs:simpleType> + + </xs:schema> + +C.5. Resource binding namespace + + <?xml version='1.0' encoding='UTF-8'?> + + <xs:schema + xmlns:xs='http://www.w3.org/2001/XMLSchema' + targetNamespace='urn:ietf:params:xml:ns:xmpp-bind' + xmlns='urn:ietf:params:xml:ns:xmpp-bind' + elementFormDefault='qualified'> + + <xs:element name='bind'> + <xs:complexType> + <xs:choice minOccurs='0' maxOccurs='1'> + <xs:element name='resource' type='xs:string'/> + <xs:element name='jid' type='xs:string'/> + + + +Saint-Andre, Ed. Standards Track [Page 83] + +RFC 3920 XMPP Core October 2004 + + + </xs:choice> + </xs:complexType> + </xs:element> + + </xs:schema> + +C.6. Dialback namespace + + <?xml version='1.0' encoding='UTF-8'?> + + <xs:schema + xmlns:xs='http://www.w3.org/2001/XMLSchema' + targetNamespace='jabber:server:dialback' + xmlns='jabber:server:dialback' + elementFormDefault='qualified'> + + <xs:element name='result'> + <xs:complexType> + <xs:simpleContent> + <xs:extension base='xs:token'> + <xs:attribute name='from' type='xs:string' use='required'/> + <xs:attribute name='to' type='xs:string' use='required'/> + <xs:attribute name='type' use='optional'> + <xs:simpleType> + <xs:restriction base='xs:NCName'> + <xs:enumeration value='invalid'/> + <xs:enumeration value='valid'/> + </xs:restriction> + </xs:simpleType> + </xs:attribute> + </xs:extension> + </xs:simpleContent> + </xs:complexType> + </xs:element> + + <xs:element name='verify'> + <xs:complexType> + <xs:simpleContent> + <xs:extension base='xs:token'> + <xs:attribute name='from' type='xs:string' use='required'/> + <xs:attribute name='id' type='xs:NMTOKEN' use='required'/> + <xs:attribute name='to' type='xs:string' use='required'/> + <xs:attribute name='type' use='optional'> + <xs:simpleType> + <xs:restriction base='xs:NCName'> + <xs:enumeration value='invalid'/> + <xs:enumeration value='valid'/> + </xs:restriction> + + + +Saint-Andre, Ed. Standards Track [Page 84] + +RFC 3920 XMPP Core October 2004 + + + </xs:simpleType> + </xs:attribute> + </xs:extension> + </xs:simpleContent> + </xs:complexType> + </xs:element> + + </xs:schema> + +C.7. Stanza error namespace + + <?xml version='1.0' encoding='UTF-8'?> + + <xs:schema + xmlns:xs='http://www.w3.org/2001/XMLSchema' + targetNamespace='urn:ietf:params:xml:ns:xmpp-stanzas' + xmlns='urn:ietf:params:xml:ns:xmpp-stanzas' + elementFormDefault='qualified'> + + <xs:element name='bad-request' type='empty'/> + <xs:element name='conflict' type='empty'/> + <xs:element name='feature-not-implemented' type='empty'/> + <xs:element name='forbidden' type='empty'/> + <xs:element name='gone' type='xs:string'/> + <xs:element name='internal-server-error' type='empty'/> + <xs:element name='item-not-found' type='empty'/> + <xs:element name='jid-malformed' type='empty'/> + <xs:element name='not-acceptable' type='empty'/> + <xs:element name='not-allowed' type='empty'/> + <xs:element name='payment-required' type='empty'/> + <xs:element name='recipient-unavailable' type='empty'/> + <xs:element name='redirect' type='xs:string'/> + <xs:element name='registration-required' type='empty'/> + <xs:element name='remote-server-not-found' type='empty'/> + <xs:element name='remote-server-timeout' type='empty'/> + <xs:element name='resource-constraint' type='empty'/> + <xs:element name='service-unavailable' type='empty'/> + <xs:element name='subscription-required' type='empty'/> + <xs:element name='undefined-condition' type='empty'/> + <xs:element name='unexpected-request' type='empty'/> + + <xs:group name='stanzaErrorGroup'> + <xs:choice> + <xs:element ref='bad-request'/> + <xs:element ref='conflict'/> + <xs:element ref='feature-not-implemented'/> + <xs:element ref='forbidden'/> + <xs:element ref='gone'/> + + + +Saint-Andre, Ed. Standards Track [Page 85] + +RFC 3920 XMPP Core October 2004 + + + <xs:element ref='internal-server-error'/> + <xs:element ref='item-not-found'/> + <xs:element ref='jid-malformed'/> + <xs:element ref='not-acceptable'/> + <xs:element ref='not-allowed'/> + <xs:element ref='payment-required'/> + <xs:element ref='recipient-unavailable'/> + <xs:element ref='redirect'/> + <xs:element ref='registration-required'/> + <xs:element ref='remote-server-not-found'/> + <xs:element ref='remote-server-timeout'/> + <xs:element ref='resource-constraint'/> + <xs:element ref='service-unavailable'/> + <xs:element ref='subscription-required'/> + <xs:element ref='undefined-condition'/> + <xs:element ref='unexpected-request'/> + </xs:choice> + </xs:group> + + <xs:element name='text'> + <xs:complexType> + <xs:simpleContent> + <xs:extension base='xs:string'> + <xs:attribute ref='xml:lang' use='optional'/> + </xs:extension> + </xs:simpleContent> + </xs:complexType> + </xs:element> + + <xs:simpleType name='empty'> + <xs:restriction base='xs:string'> + <xs:enumeration value=''/> + </xs:restriction> + </xs:simpleType> + + </xs:schema> + + + + + + + + + + + + + + + +Saint-Andre, Ed. Standards Track [Page 86] + +RFC 3920 XMPP Core October 2004 + + +Appendix D. Differences Between Core Jabber Protocols and XMPP + + This section is non-normative. + + XMPP has been adapted from the protocols originally developed in the + Jabber open-source community, which can be thought of as "XMPP 0.9". + Because there exists a large installed base of Jabber implementations + and deployments, it may be helpful to specify the key differences + between the relevant Jabber protocols and XMPP in order to expedite + and encourage upgrades of those implementations and deployments to + XMPP. This section summarizes the core differences, while the + corresponding section of [XMPP-IM] summarizes the differences that + relate specifically to instant messaging and presence applications. + +D.1. Channel Encryption + + It was common practice in the Jabber community to use SSL for channel + encryption on ports other than 5222 and 5269 (the convention is to + use ports 5223 and 5270). XMPP uses TLS over the IANA-registered + ports for channel encryption, as defined under Use of TLS (Section 5) + herein. + +D.2. Authentication + + The client-server authentication protocol developed in the Jabber + community used a basic IQ interaction qualified by the + 'jabber:iq:auth' namespace (documentation of this protocol is + contained in [JEP-0078], published by the Jabber Software Foundation + [JSF]). XMPP uses SASL for authentication, as defined under Use of + SASL (Section 6) herein. + + The Jabber community did not develop an authentication protocol for + server-to-server communications, only the Server Dialback (Section 8) + protocol to prevent server spoofing. XMPP supersedes Server Dialback + with a true server-to-server authentication protocol, as defined + under Use of SASL (Section 6) herein. + +D.3. Resource Binding + + Resource binding in the Jabber community was handled via the + 'jabber:iq:auth' namespace (which was also used for client + authentication with a server). XMPP defines a dedicated namespace + for resource binding as well as the ability for a server to generate + a resource identifier on behalf of a client, as defined under + Resource Binding (Section 7). + + + + + + +Saint-Andre, Ed. Standards Track [Page 87] + +RFC 3920 XMPP Core October 2004 + + +D.4. JID Processing + + JID processing was somewhat loosely defined by the Jabber community + (documentation of forbidden characters and case handling is contained + in [JEP-0029], published by the Jabber Software Foundation [JSF]). + XMPP specifies the use of [NAMEPREP] for domain identifiers and + supplements Nameprep with two additional [STRINGPREP] profiles for + JID processing: Nodeprep (Appendix A) for node identifiers and + Resourceprep (Appendix B) for resource identifiers. + +D.5. Error Handling + + Stream-related errors were handled in the Jabber community via XML + character data text in a <stream:error/> element. In XMPP, + stream-related errors are handled via an extensible mechanism defined + under Stream Errors (Section 4.7) herein. + + Stanza-related errors were handled in the Jabber community via + HTTP-style error codes. In XMPP, stanza-related errors are handled + via an extensible mechanism defined under Stanza Errors (Section 9.3) + herein. (Documentation of a mapping between Jabber and XMPP error + handling mechanisms is contained in [JEP-0086], published by the + Jabber Software Foundation [JSF].) + +D.6. Internationalization + + Although use of UTF-8 has always been standard practice within the + Jabber community, the community did not define mechanisms for + specifying the language of human-readable text provided in XML + character data. XMPP specifies the use of the 'xml:lang' attribute + in such contexts, as defined under Stream Attributes (Section 4.4) + and xml:lang (Section 9.1.5) herein. + +D.7. Stream Version Attribute + + The Jabber community did not include a 'version' attribute in stream + headers. XMPP specifies inclusion of that attribute as a way to + signal support for the stream features (authentication, encryption, + etc.) defined under Version Support (Section 4.4.1) herein. + + + + + + + + + + + + +Saint-Andre, Ed. Standards Track [Page 88] + +RFC 3920 XMPP Core October 2004 + + +Contributors + + Most of the core aspects of the Extensible Messaging and Presence + Protocol were developed originally within the Jabber open-source + community in 1999. This community was founded by Jeremie Miller, who + released source code for the initial version of the jabber server in + January 1999. Major early contributors to the base protocol also + included Ryan Eatmon, Peter Millard, Thomas Muldowney, and Dave + Smith. Work by the XMPP Working Group has concentrated especially on + security and internationalization; in these areas, protocols for the + use of TLS and SASL were originally contributed by Rob Norris, and + stringprep profiles were originally contributed by Joe Hildebrand. + The error code syntax was suggested by Lisa Dusseault. + +Acknowledgements + + Thanks are due to a number of individuals in addition to the + contributors listed. Although it is difficult to provide a complete + list, the following individuals were particularly helpful in defining + the protocols or in commenting on the specifications in this memo: + Thomas Charron, Richard Dobson, Sam Hartman, Schuyler Heath, Jonathan + Hogg, Cullen Jennings, Craig Kaes, Jacek Konieczny, Alexey Melnikov, + Keith Minkler, Julian Missig, Pete Resnick, Marshall Rose, Alexey + Shchepin, Jean-Louis Seguineau, Iain Shigeoka, Greg Troxel, and David + Waite. Thanks also to members of the XMPP Working Group and the IETF + community for comments and feedback provided throughout the life of + this memo. + +Author's Address + + Peter Saint-Andre (editor) + Jabber Software Foundation + + EMail: stpeter@jabber.org + + + + + + + + + + + + + + + + + +Saint-Andre, Ed. Standards Track [Page 89] + +RFC 3920 XMPP Core October 2004 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE + INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the IETF's procedures with respect to rights in IETF Documents can + be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Saint-Andre, Ed. Standards Track [Page 90] + |