P1L1 P1L2 P1L3 P1L4 Network Working Group P. Saint-Andre, Ed. P1L5 Request for Comments: 3920 Jabber Software Foundation P1L6 Category: Standards Track October 2004 P1L7 P1L8 P1L9 Extensible Messaging and Presence Protocol (XMPP): Core P1L10 P1L11 Status of this Memo P1L12 P1L13 This document specifies an Internet standards track protocol for the P1L14 Internet community, and requests discussion and suggestions for P1L15 improvements. Please refer to the current edition of the "Internet P1L16 Official Protocol Standards" (STD 1) for the standardization state P1L17 and status of this protocol. Distribution of this memo is unlimited. P1L18 P1L19 Copyright Notice P1L20 P1L21 Copyright (C) The Internet Society (2004). P1L22 P1L23 Abstract P1L24 P1L25 This memo defines the core features of the Extensible Messaging and P1L26 Presence Protocol (XMPP), a protocol for streaming Extensible Markup P1L27 Language (XML) elements in order to exchange structured information P1L28 in close to real time between any two network endpoints. While XMPP P1L29 provides a generalized, extensible framework for exchanging XML data, P1L30 it is used mainly for the purpose of building instant messaging and P1L31 presence applications that meet the requirements of RFC 2779. P1L32 P1L33 P1L34 P1L35 P1L36 P1L37 P1L38 P1L39 P1L40 P1L41 P1L42 P1L43 P1L44 P1L45 P1L46 P1L47 P1L48 P2L1 Table of Contents P2L2 P2L3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 P2L4 2. Generalized Architecture . . . . . . . . . . . . . . . . . . 3 P2L5 3. Addressing Scheme . . . . . . . . . . . . . . . . . . . . . 5 P2L6 4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . 7 P2L7 5. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . . 19 P2L8 6. Use of SASL . . . . . . . . . . . . . . . . . . . . . . . . 27 P2L9 7. Resource Binding . . . . . . . . . . . . . . . . . . . . . . 37 P2L10 8. Server Dialback . . . . . . . . . . . . . . . . . . . . . . 41 P2L11 9. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . 48 P2L12 10. Server Rules for Handling XML Stanzas . . . . . . . . . . . 58 P2L13 11. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 60 P2L14 12. Core Compliance Requirements . . . . . . . . . . . . . . . . 62 P2L15 13. Internationalization Considerations . . . . . . . . . . . . 64 P2L16 14. Security Considerations . . . . . . . . . . . . . . . . . . 64 P2L17 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 69 P2L18 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 71 P2L19 A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . . . . . 75 P2L20 B. Resourceprep . . . . . . . . . . . . . . . . . . . . . . . . 76 P2L21 C. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . 78 P2L22 D. Differences Between Core Jabber Protocols and XMPP . . . . . 87 P2L23 Contributors. . . . . . . . . . . . . . . . . . . . . . . . . . . 89 P2L24 Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . . 89 P2L25 Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 89 P2L26 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 90 P2L27 P2L28 1. Introduction P2L29 P2L30 1.1. Overview P2L31 P2L32 The Extensible Messaging and Presence Protocol (XMPP) is an open P2L33 Extensible Markup Language [XML] protocol for near-real-time P2L34 messaging, presence, and request-response services. The basic syntax P2L35 and semantics were developed originally within the Jabber open-source P2L36 community, mainly in 1999. In 2002, the XMPP WG was chartered with P2L37 developing an adaptation of the Jabber protocol that would be P2L38 suitable as an IETF instant messaging (IM) and presence technology. P2L39 As a result of work by the XMPP WG, the current memo defines the core P2L40 features of XMPP 1.0; the extensions required to provide the instant P2L41 messaging and presence functionality defined in RFC 2779 [IMP-REQS] P2L42 are specified in the Extensible Messaging and Presence Protocol P2L43 (XMPP): Instant Messaging and Presence [XMPP-IM]. P2L44 P2L45 P2L46 P2L47 P2L48 P3L1 1.2. Terminology P3L2 P3L3 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", P3L4 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and P3L5 "OPTIONAL" in this document are to be interpreted as described in BCP P3L6 14, RFC 2119 [TERMS]. P3L7 P3L8 2. Generalized Architecture P3L9 P3L10 2.1. Overview P3L11 P3L12 Although XMPP is not wedded to any specific network architecture, to P3L13 date it usually has been implemented via a client-server architecture P3L14 wherein a client utilizing XMPP accesses a server over a [TCP] P3L15 connection, and servers also communicate with each other over TCP P3L16 connections. P3L17 P3L18 The following diagram provides a high-level overview of this P3L19 architecture (where "-" represents communications that use XMPP and P3L20 "=" represents communications that use any other protocol). P3L21 P3L22 C1----S1---S2---C3 P3L23 | P3L24 C2----+--G1===FN1===FC1 P3L25 P3L26 The symbols are as follows: P3L27 P3L28 o C1, C2, C3 = XMPP clients P3L29 P3L30 o S1, S2 = XMPP servers P3L31 P3L32 o G1 = A gateway that translates between XMPP and the protocol(s) P3L33 used on a foreign (non-XMPP) messaging network P3L34 P3L35 o FN1 = A foreign messaging network P3L36 P3L37 o FC1 = A client on a foreign messaging network P3L38 P3L39 2.2. Server P3L40 P3L41 A server acts as an intelligent abstraction layer for XMPP P3L42 communications. Its primary responsibilities are: P3L43 P3L44 o to manage connections from or sessions for other entities, in the P3L45 form of XML streams (Section 4) to and from authorized clients, P3L46 servers, and other entities P3L47 P3L48 P4L1 o to route appropriately-addressed XML stanzas (Section 9) among P4L2 such entities over XML streams P4L3 P4L4 Most XMPP-compliant servers also assume responsibility for the P4L5 storage of data that is used by clients (e.g., contact lists for P4L6 users of XMPP-based instant messaging and presence applications); in P4L7 this case, the XML data is processed directly by the server itself on P4L8 behalf of the client and is not routed to another entity. P4L9 P4L10 2.3. Client P4L11 P4L12 Most clients connect directly to a server over a [TCP] connection and P4L13 use XMPP to take full advantage of the functionality provided by a P4L14 server and any associated services. Multiple resources (e.g., P4L15 devices or locations) MAY connect simultaneously to a server on P4L16 behalf of each authorized client, with each resource differentiated P4L17 by the resource identifier of an XMPP address (e.g., vs. ) as defined under Addressing Scheme P4L19 (Section 3). The RECOMMENDED port for connections between a client P4L20 and a server is 5222, as registered with the IANA (see Port Numbers P4L21 (Section 15.9)). P4L22 P4L23 2.4. Gateway P4L24 P4L25 A gateway is a special-purpose server-side service whose primary P4L26 function is to translate XMPP into the protocol used by a foreign P4L27 (non-XMPP) messaging system, as well as to translate the return data P4L28 back into XMPP. Examples are gateways to email (see [SMTP]), P4L29 Internet Relay Chat (see [IRC]), SIMPLE (see [SIMPLE]), Short Message P4L30 Service (SMS), and legacy instant messaging services such as AIM, P4L31 ICQ, MSN Messenger, and Yahoo! Instant Messenger. Communications P4L32 between gateways and servers, and between gateways and the foreign P4L33 messaging system, are not defined in this document. P4L34 P4L35 2.5. Network P4L36 P4L37 Because each server is identified by a network address and because P4L38 server-to-server communications are a straightforward extension of P4L39 the client-to-server protocol, in practice, the system consists of a P4L40 network of servers that inter-communicate. Thus, for example, P4L41 is able to exchange messages, presence, and P4L42 other information with . This pattern is familiar P4L43 from messaging protocols (such as [SMTP]) that make use of network P4L44 addressing standards. Communications between any two servers are P4L45 OPTIONAL. If enabled, such communications SHOULD occur over XML P4L46 streams that are bound to [TCP] connections. The RECOMMENDED port P4L47 for connections between servers is 5269, as registered with the IANA P4L48 (see Port Numbers (Section 15.9)). P5L1 3. Addressing Scheme P5L2 P5L3 3.1. Overview P5L4 P5L5 An entity is anything that can be considered a network endpoint P5L6 (i.e., an ID on the network) and that can communicate using XMPP. P5L7 All such entities are uniquely addressable in a form that is P5L8 consistent with RFC 2396 [URI]. For historical reasons, the address P5L9 of an XMPP entity is called a Jabber Identifier or JID. A valid JID P5L10 contains a set of ordered elements formed of a domain identifier, P5L11 node identifier, and resource identifier. P5L12 P5L13 The syntax for a JID is defined below using the Augmented Backus-Naur P5L14 Form as defined in [ABNF]. (The IPv4address and IPv6address rules P5L15 are defined in Appendix B of [IPv6]; the allowable character P5L16 sequences that conform to the node rule are defined by the Nodeprep P5L17 profile of [STRINGPREP] as documented in Appendix A of this memo; the P5L18 allowable character sequences that conform to the resource rule are P5L19 defined by the Resourceprep profile of [STRINGPREP] as documented in P5L20 Appendix B of this memo; and the sub-domain rule makes reference to P5L21 the concept of an internationalized domain label as described in P5L22 [IDNA].) P5L23 P5L24 P5L25 jid = [ node "@" ] domain [ "/" resource ] P5L26 domain = fqdn / address-literal P5L27 fqdn = (sub-domain 1*("." sub-domain)) P5L28 sub-domain = (internationalized domain label) P5L29 address-literal = IPv4address / IPv6address P5L30 P5L31 All JIDs are based on the foregoing structure. The most common use P5L32 of this structure is to identify an instant messaging user, the P5L33 server to which the user connects, and the user's connected resource P5L34 (e.g., a specific client) in the form of . P5L35 However, node types other than clients are possible; for example, a P5L36 specific chat room offered by a multi-user chat service could be P5L37 addressed as (where "room" is the name of the chat P5L38 room and "service" is the hostname of the multi-user chat service) P5L39 and a specific occupant of such a room could be addressed as P5L40 (where "nick" is the occupant's room nickname). P5L41 Many other JID types are possible (e.g., could be a P5L42 server-side script or service). P5L43 P5L44 Each allowable portion of a JID (node identifier, domain identifier, P5L45 and resource identifier) MUST NOT be more than 1023 bytes in length, P5L46 resulting in a maximum total size (including the '@' and '/' P5L47 separators) of 3071 bytes. P5L48 P6L1 3.2. Domain Identifier P6L2 P6L3 The domain identifier is the primary identifier and is the only P6L4 REQUIRED element of a JID (a mere domain identifier is a valid JID). P6L5 It usually represents the network gateway or "primary" server to P6L6 which other entities connect for XML routing and data management P6L7 capabilities. However, the entity referenced by a domain identifier P6L8 is not always a server, and may be a service that is addressed as a P6L9 subdomain of a server that provides functionality above and beyond P6L10 the capabilities of a server (e.g., a multi-user chat service, a user P6L11 directory, or a gateway to a foreign messaging system). P6L12 P6L13 The domain identifier for every server or service that will P6L14 communicate over a network MAY be an IP address but SHOULD be a fully P6L15 qualified domain name (see [DNS]). A domain identifier MUST be an P6L16 "internationalized domain name" as defined in [IDNA], to which the P6L17 Nameprep [NAMEPREP] profile of stringprep [STRINGPREP] can be applied P6L18 without failing. Before comparing two domain identifiers, a server P6L19 MUST (and a client SHOULD) first apply the Nameprep profile to the P6L20 labels (as defined in [IDNA]) that make up each identifier. P6L21 P6L22 3.3. Node Identifier P6L23 P6L24 The node identifier is an optional secondary identifier placed before P6L25 the domain identifier and separated from the latter by the '@' P6L26 character. It usually represents the entity requesting and using P6L27 network access provided by the server or gateway (i.e., a client), P6L28 although it can also represent other kinds of entities (e.g., a chat P6L29 room associated with a multi-user chat service). The entity P6L30 represented by a node identifier is addressed within the context of a P6L31 specific domain; within instant messaging and presence applications P6L32 of XMPP, this address is called a "bare JID" and is of the form P6L33 . P6L34 P6L35 A node identifier MUST be formatted such that the Nodeprep profile of P6L36 [STRINGPREP] can be applied to it without failing. Before comparing P6L37 two node identifiers, a server MUST (and a client SHOULD) first apply P6L38 the Nodeprep profile to each identifier. P6L39 P6L40 3.4. Resource Identifier P6L41 P6L42 The resource identifier is an optional tertiary identifier placed P6L43 after the domain identifier and separated from the latter by the '/' P6L44 character. A resource identifier may modify either a P6L45 or a mere address. It usually represents a specific P6L46 session, connection (e.g., a device or location), or object (e.g., a P6L47 participant in a multi-user chat room) belonging to the entity P6L48 associated with a node identifier. A resource identifier is opaque P7L1 to both servers and other clients, and is typically defined by a P7L2 client implementation when it provides the information necessary to P7L3 complete Resource Binding (Section 7) (although it may be generated P7L4 by a server on behalf of a client), after which it is referred to as P7L5 a "connected resource". An entity MAY maintain multiple connected P7L6 resources simultaneously, with each connected resource differentiated P7L7 by a distinct resource identifier. P7L8 P7L9 A resource identifier MUST be formatted such that the Resourceprep P7L10 profile of [STRINGPREP] can be applied without failing. Before P7L11 comparing two resource identifiers, a server MUST (and a client P7L12 SHOULD) first apply the Resourceprep profile to each identifier. P7L13 P7L14 3.5. Determination of Addresses P7L15 P7L16 After SASL negotiation (Section 6) and, if appropriate, Resource P7L17 Binding (Section 7), the receiving entity for a stream MUST determine P7L18 the initiating entity's JID. P7L19 P7L20 For server-to-server communications, the initiating entity's JID P7L21 SHOULD be the authorization identity, derived from the authentication P7L22 identity, as defined by the Simple Authentication and Security Layer P7L23 (SASL) specification [SASL], if no authorization identity was P7L24 specified during SASL negotiation (Section 6). P7L25 P7L26 For client-to-server communications, the "bare JID" () P7L27 SHOULD be the authorization identity, derived from the authentication P7L28 identity, as defined in [SASL], if no authorization identity was P7L29 specified during SASL negotiation (Section 6); the resource P7L30 identifier portion of the "full JID" () SHOULD P7L31 be the resource identifier negotiated by the client and server during P7L32 Resource Binding (Section 7). P7L33 P7L34 The receiving entity MUST ensure that the resulting JID (including P7L35 node identifier, domain identifier, resource identifier, and P7L36 separator characters) conforms to the rules and formats defined P7L37 earlier in this section; to meet this restriction, the receiving P7L38 entity may need to replace the JID sent by the initiating entity with P7L39 the canonicalized JID as determined by the receiving entity. P7L40 P7L41 4. XML Streams P7L42 P7L43 4.1. Overview P7L44 P7L45 Two fundamental concepts make possible the rapid, asynchronous P7L46 exchange of relatively small payloads of structured information P7L47 between presence-aware entities: XML streams and XML stanzas. These P7L48 terms are defined as follows: P8L1 Definition of XML Stream: An XML stream is a container for the P8L2 exchange of XML elements between any two entities over a network. P8L3 The start of an XML stream is denoted unambiguously by an opening P8L4 XML tag (with appropriate attributes and namespace P8L5 declarations), while the end of the XML stream is denoted P8L6 unambiguously by a closing XML tag. During the life of P8L7 the stream, the entity that initiated it can send an unbounded P8L8 number of XML elements over the stream, either elements used to P8L9 negotiate the stream (e.g., to negotiate Use of TLS (Section 5) or P8L10 use of SASL (Section 6)) or XML stanzas (as defined herein, P8L11 , , or elements qualified by the P8L12 default namespace). The "initial stream" is negotiated from the P8L13 initiating entity (usually a client or server) to the receiving P8L14 entity (usually a server), and can be seen as corresponding to the P8L15 initiating entity's "session" with the receiving entity. The P8L16 initial stream enables unidirectional communication from the P8L17 initiating entity to the receiving entity; in order to enable P8L18 information exchange from the receiving entity to the initiating P8L19 entity, the receiving entity MUST negotiate a stream in the P8L20 opposite direction (the "response stream"). P8L21 P8L22 Definition of XML Stanza: An XML stanza is a discrete semantic unit P8L23 of structured information that is sent from one entity to another P8L24 over an XML stream. An XML stanza exists at the direct child P8L25 level of the root element and is said to be P8L26 well-balanced if it matches the production [43] content of [XML]. P8L27 The start of any XML stanza is denoted unambiguously by the P8L28 element start tag at depth=1 of the XML stream (e.g., ), P8L29 and the end of any XML stanza is denoted unambiguously by the P8L30 corresponding close tag at depth=1 (e.g., ). An XML P8L31 stanza MAY contain child elements (with accompanying attributes, P8L32 elements, and XML character data) as necessary in order to convey P8L33 the desired information. The only XML stanzas defined herein are P8L34 the , , and elements qualified by the P8L35 default namespace for the stream, as described under XML Stanzas P8L36 (Section 9); an XML element sent for the purpose of Transport P8L37 Layer Security (TLS) negotiation (Section 5), Simple P8L38 Authentication and Security Layer (SASL) negotiation (Section 6), P8L39 or server dialback (Section 8) is not considered to be an XML P8L40 stanza. P8L41 P8L42 Consider the example of a client's session with a server. In order P8L43 to connect to a server, a client MUST initiate an XML stream by P8L44 sending an opening tag to the server, optionally preceded by P8L45 a text declaration specifying the XML version and the character P8L46 encoding supported (see Inclusion of Text Declaration (Section 11.4); P8L47 see also Character Encoding (Section 11.5)). Subject to local P8L48 policies and service provisioning, the server SHOULD then reply with P9L1 a second XML stream back to the client, again optionally preceded by P9L2 a text declaration. Once the client has completed SASL negotiation P9L3 (Section 6), the client MAY send an unbounded number of XML stanzas P9L4 over the stream to any recipient on the network. When the client P9L5 desires to close the stream, it simply sends a closing tag P9L6 to the server (alternatively, the stream may be closed by the P9L7 server), after which both the client and server SHOULD terminate the P9L8 underlying connection (usually a TCP connection) as well. P9L9 P9L10 Those who are accustomed to thinking of XML in a document-centric P9L11 manner may wish to view a client's session with a server as P9L12 consisting of two open-ended XML documents: one from the client to P9L13 the server and one from the server to the client. From this P9L14 perspective, the root element can be considered the P9L15 document entity for each "document", and the two "documents" are P9L16 built up through the accumulation of XML stanzas sent over the two P9L17 XML streams. However, this perspective is a convenience only; XMPP P9L18 does not deal in documents but in XML streams and XML stanzas. P9L19 P9L20 In essence, then, an XML stream acts as an envelope for all the XML P9L21 stanzas sent during a session. We can represent this in a simplistic P9L22 fashion as follows: P9L23 P9L24 |--------------------| P9L25 | | P9L26 |--------------------| P9L27 | | P9L28 | | P9L29 | | P9L30 |--------------------| P9L31 | | P9L32 | | P9L33 | | P9L34 |--------------------| P9L35 | | P9L36 | | P9L37 | | P9L38 |--------------------| P9L39 | ... | P9L40 |--------------------| P9L41 | | P9L42 |--------------------| P9L43 P9L44 P9L45 P9L46 P9L47 P9L48 P10L1 4.2. Binding to TCP P10L2 P10L3 Although there is no necessary coupling of an XML stream to a [TCP] P10L4 connection (e.g., two entities could connect to each other via P10L5 another mechanism such as polling over [HTTP]), this specification P10L6 defines a binding of XMPP to TCP only. In the context of P10L7 client-to-server communications, a server MUST allow a client to P10L8 share a single TCP connection for XML stanzas sent from client to P10L9 server and from server to client. In the context of server-to-server P10L10 communications, a server MUST use one TCP connection for XML stanzas P10L11 sent from the server to the peer and another TCP connection P10L12 (initiated by the peer) for stanzas from the peer to the server, for P10L13 a total of two TCP connections. P10L14 P10L15 4.3. Stream Security P10L16 P10L17 When negotiating XML streams in XMPP 1.0, TLS SHOULD be used as P10L18 defined under Use of TLS (Section 5) and SASL MUST be used as defined P10L19 under Use of SASL (Section 6). The "initial stream" (i.e., the P10L20 stream from the initiating entity to the receiving entity) and the P10L21 "response stream" (i.e., the stream from the receiving entity to the P10L22 initiating entity) MUST be secured separately, although security in P10L23 both directions MAY be established via mechanisms that provide mutual P10L24 authentication. An entity SHOULD NOT attempt to send XML Stanzas P10L25 (Section 9) over the stream before the stream has been authenticated, P10L26 but if it does, then the other entity MUST NOT accept such stanzas P10L27 and SHOULD return a stream error and then terminate P10L28 both the XML stream and the underlying TCP connection; note well that P10L29 this applies to XML stanzas only (i.e., , , and P10L30 elements scoped by the default namespace) and not to XML P10L31 elements used for stream negotiation (e.g., elements used to P10L32 negotiate Use of TLS (Section 5) or Use of SASL (Section 6)). P10L33 P10L34 4.4. Stream Attributes P10L35 P10L36 The attributes of the stream element are as follows: P10L37 P10L38 o to -- The 'to' attribute SHOULD be used only in the XML stream P10L39 header from the initiating entity to the receiving entity, and P10L40 MUST be set to a hostname serviced by the receiving entity. There P10L41 SHOULD NOT be a 'to' attribute set in the XML stream header by P10L42 which the receiving entity replies to the initiating entity; P10L43 however, if a 'to' attribute is included, it SHOULD be silently P10L44 ignored by the initiating entity. P10L45 P10L46 P10L47 P10L48 P11L1 o from -- The 'from' attribute SHOULD be used only in the XML stream P11L2 header from the receiving entity to the initiating entity, and P11L3 MUST be set to a hostname serviced by the receiving entity that is P11L4 granting access to the initiating entity. There SHOULD NOT be a P11L5 'from' attribute on the XML stream header sent from the initiating P11L6 entity to the receiving entity; however, if a 'from' attribute is P11L7 included, it SHOULD be silently ignored by the receiving entity. P11L8 P11L9 o id -- The 'id' attribute SHOULD be used only in the XML stream P11L10 header from the receiving entity to the initiating entity. This P11L11 attribute is a unique identifier created by the receiving entity P11L12 to function as a session key for the initiating entity's streams P11L13 with the receiving entity, and MUST be unique within the receiving P11L14 application (normally a server). Note well that the stream ID may P11L15 be security-critical and therefore MUST be both unpredictable and P11L16 nonrepeating (see [RANDOM] for recommendations regarding P11L17 randomness for security purposes). There SHOULD NOT be an 'id' P11L18 attribute on the XML stream header sent from the initiating entity P11L19 to the receiving entity; however, if an 'id' attribute is P11L20 included, it SHOULD be silently ignored by the receiving entity. P11L21 P11L22 o xml:lang -- An 'xml:lang' attribute (as defined in Section 2.12 of P11L23 [XML]) SHOULD be included by the initiating entity on the header P11L24 for the initial stream to specify the default language of any P11L25 human-readable XML character data it sends over that stream. If P11L26 the attribute is included, the receiving entity SHOULD remember P11L27 that value as the default for both the initial stream and the P11L28 response stream; if the attribute is not included, the receiving P11L29 entity SHOULD use a configurable default value for both streams, P11L30 which it MUST communicate in the header for the response stream. P11L31 For all stanzas sent over the initial stream, if the initiating P11L32 entity does not include an 'xml:lang' attribute, the receiving P11L33 entity SHOULD apply the default value; if the initiating entity P11L34 does include an 'xml:lang' attribute, the receiving entity MUST P11L35 NOT modify or delete it (see also xml:lang (Section 9.1.5)). The P11L36 value of the 'xml:lang' attribute MUST be an NMTOKEN (as defined P11L37 in Section 2.3 of [XML]) and MUST conform to the format defined in P11L38 RFC 3066 [LANGTAGS]. P11L39 P11L40 o version -- The presence of the version attribute set to a value of P11L41 at least "1.0" signals support for the stream-related protocols P11L42 (including stream features) defined in this specification. P11L43 Detailed rules regarding the generation and handling of this P11L44 attribute are defined below. P11L45 P11L46 P11L47 P11L48 P12L1 We can summarize as follows: P12L2 P12L3 | initiating to receiving | receiving to initiating P12L4 ---------+---------------------------+----------------------- P12L5 to | hostname of receiver | silently ignored P12L6 from | silently ignored | hostname of receiver P12L7 id | silently ignored | session key P12L8 xml:lang | default language | default language P12L9 version | signals XMPP 1.0 support | signals XMPP 1.0 support P12L10 P12L11 4.4.1. Version Support P12L12 P12L13 The version of XMPP specified herein is "1.0"; in particular, this P12L14 encapsulates the stream-related protocols (Use of TLS (Section 5), P12L15 Use of SASL (Section 6), and Stream Errors (Section 4.7)), as well as P12L16 the semantics of the three defined XML stanza types (, P12L17 , and ). The numbering scheme for XMPP versions is P12L18 ".". The major and minor numbers MUST be treated as P12L19 separate integers and each number MAY be incremented higher than a P12L20 single digit. Thus, "XMPP 2.4" would be a lower version than "XMPP P12L21 2.13", which in turn would be lower than "XMPP 12.3". Leading zeros P12L22 (e.g., "XMPP 6.01") MUST be ignored by recipients and MUST NOT be P12L23 sent. P12L24 P12L25 The major version number should be incremented only if the stream and P12L26 stanza formats or required actions have changed so dramatically that P12L27 an older version entity would not be able to interoperate with a P12L28 newer version entity if it simply ignored the elements and attributes P12L29 it did not understand and took the actions specified in the older P12L30 specification. The minor version number indicates new capabilities, P12L31 and MUST be ignored by an entity with a smaller minor version number, P12L32 but used for informational purposes by the entity with the larger P12L33 minor version number. For example, a minor version number might P12L34 indicate the ability to process a newly defined value of the 'type' P12L35 attribute for message, presence, or IQ stanzas; the entity with the P12L36 larger minor version number would simply note that its correspondent P12L37 would not be able to understand that value of the 'type' attribute P12L38 and therefore would not send it. P12L39 P12L40 The following rules apply to the generation and handling of the P12L41 'version' attribute within stream headers by implementations: P12L42 P12L43 1. The initiating entity MUST set the value of the 'version' P12L44 attribute on the initial stream header to the highest version P12L45 number it supports (e.g., if the highest version number it P12L46 supports is that defined in this specification, it MUST set the P12L47 value to "1.0"). P12L48 P13L1 2. The receiving entity MUST set the value of the 'version' P13L2 attribute on the response stream header to either the value P13L3 supplied by the initiating entity or the highest version number P13L4 supported by the receiving entity, whichever is lower. The P13L5 receiving entity MUST perform a numeric comparison on the major P13L6 and minor version numbers, not a string match on P13L7 ".". P13L8 P13L9 3. If the version number included in the response stream header is P13L10 at least one major version lower than the version number included P13L11 in the initial stream header and newer version entities cannot P13L12 interoperate with older version entities as described above, the P13L13 initiating entity SHOULD generate an P13L14 stream error and terminate the XML stream and underlying TCP P13L15 connection. P13L16 P13L17 4. If either entity receives a stream header with no 'version' P13L18 attribute, the entity MUST consider the version supported by the P13L19 other entity to be "0.0" and SHOULD NOT include a 'version' P13L20 attribute in the stream header it sends in reply. P13L21 P13L22 4.5. Namespace Declarations P13L23 P13L24 The stream element MUST possess both a streams namespace declaration P13L25 and a default namespace declaration (as "namespace declaration" is P13L26 defined in the XML namespaces specification [XML-NAMES]). For P13L27 detailed information regarding the streams namespace and default P13L28 namespace, see Namespace Names and Prefixes (Section 11.2). P13L29 P13L30 4.6. Stream Features P13L31 P13L32 If the initiating entity includes the 'version' attribute set to a P13L33 value of at least "1.0" in the initial stream header, the receiving P13L34 entity MUST send a child element (prefixed by the streams P13L35 namespace prefix) to the initiating entity in order to announce any P13L36 stream-level features that can be negotiated (or capabilities that P13L37 otherwise need to be advertised). Currently, this is used only to P13L38 advertise Use of TLS (Section 5), Use of SASL (Section 6), and P13L39 Resource Binding (Section 7) as defined herein, and for Session P13L40 Establishment as defined in [XMPP-IM]; however, the stream features P13L41 functionality could be used to advertise other negotiable features in P13L42 the future. If an entity does not understand or support some P13L43 features, it SHOULD silently ignore them. If one or more security P13L44 features (e.g., TLS and SASL) need to be successfully negotiated P13L45 before a non-security-related feature (e.g., Resource Binding) can be P13L46 offered, the non-security-related feature SHOULD NOT be included in P13L47 the stream features that are advertised before the relevant security P13L48 features have been negotiated. P14L1 4.7. Stream Errors P14L2 P14L3 The root stream element MAY contain an child element that is P14L4 prefixed by the streams namespace prefix. The error child MUST be P14L5 sent by a compliant entity (usually a server rather than a client) if P14L6 it perceives that a stream-level error has occurred. P14L7 P14L8 4.7.1. Rules P14L9 P14L10 The following rules apply to stream-level errors: P14L11 P14L12 o It is assumed that all stream-level errors are unrecoverable; P14L13 therefore, if an error occurs at the level of the stream, the P14L14 entity that detects the error MUST send a stream error to the P14L15 other entity, send a closing tag, and terminate the P14L16 underlying TCP connection. P14L17 P14L18 o If the error occurs while the stream is being set up, the P14L19 receiving entity MUST still send the opening tag, include P14L20 the element as a child of the stream element, send the P14L21 closing tag, and terminate the underlying TCP P14L22 connection. In this case, if the initiating entity provides an P14L23 unknown host in the 'to' attribute (or provides no 'to' attribute P14L24 at all), the server SHOULD provide the server's authoritative P14L25 hostname in the 'from' attribute of the stream header sent before P14L26 termination. P14L27 P14L28 4.7.2. Syntax P14L29 P14L30 The syntax for stream errors is as follows: P14L31 P14L32 P14L33 P14L34 P14L36 OPTIONAL descriptive text P14L37 P14L38 [OPTIONAL application-specific condition element] P14L39 P14L40 P14L41 The element: P14L42 P14L43 o MUST contain a child element corresponding to one of the defined P14L44 stanza error conditions defined below; this element MUST be P14L45 qualified by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace P14L46 P14L47 P14L48 P15L1 o MAY contain a child containing XML character data that P15L2 describes the error in more detail; this element MUST be qualified P15L3 by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace and SHOULD P15L4 possess an 'xml:lang' attribute specifying the natural language of P15L5 the XML character data P15L6 P15L7 o MAY contain a child element for an application-specific error P15L8 condition; this element MUST be qualified by an P15L9 application-defined namespace, and its structure is defined by P15L10 that namespace P15L11 P15L12 The element is OPTIONAL. If included, it SHOULD be used only P15L13 to provide descriptive or diagnostic information that supplements the P15L14 meaning of a defined condition or application-specific condition. It P15L15 SHOULD NOT be interpreted programmatically by an application. It P15L16 SHOULD NOT be used as the error message presented to a user, but MAY P15L17 be shown in addition to the error message associated with the P15L18 included condition element (or elements). P15L19 P15L20 4.7.3. Defined Conditions P15L21 P15L22 The following stream-level error conditions are defined: P15L23 P15L24 o -- the entity has sent XML that cannot be processed; P15L25 this error MAY be used instead of the more specific XML-related P15L26 errors, such as , , P15L27 , , and P15L28 , although the more specific errors are P15L29 preferred. P15L30 P15L31 o -- the entity has sent a namespace prefix P15L32 that is unsupported, or has sent no namespace prefix on an element P15L33 that requires such a prefix (see XML Namespace Names and Prefixes P15L34 (Section 11.2)). P15L35 P15L36 o -- the server is closing the active stream for this P15L37 entity because a new stream has been initiated that conflicts with P15L38 the existing stream. P15L39 P15L40 o -- the entity has not generated any traffic P15L41 over the stream for some period of time (configurable according to P15L42 a local service policy). P15L43 P15L44 o -- the value of the 'to' attribute provided by the P15L45 initiating entity in the stream header corresponds to a hostname P15L46 that is no longer hosted by the server. P15L47 P15L48 P16L1 o -- the value of the 'to' attribute provided by the P16L2 initiating entity in the stream header does not correspond to a P16L3 hostname that is hosted by the server. P16L4 P16L5 o -- a stanza sent between two servers lacks P16L6 a 'to' or 'from' attribute (or the attribute has no value). P16L7 P16L8 o -- the server has experienced a P16L9 misconfiguration or an otherwise-undefined internal error that P16L10 prevents it from servicing the stream. P16L11 P16L12 o -- the JID or hostname provided in a 'from' P16L13 address does not match an authorized JID or validated domain P16L14 negotiated between servers via SASL or dialback, or between a P16L15 client and a server via authentication and resource binding. P16L16 P16L17 o -- the stream ID or dialback ID is invalid or does P16L18 not match an ID previously provided. P16L19 P16L20 o -- the streams namespace name is something P16L21 other than "http://etherx.jabber.org/streams" or the dialback P16L22 namespace name is something other than "jabber:server:dialback" P16L23 (see XML Namespace Names and Prefixes (Section 11.2)). P16L24 P16L25 o -- the entity has sent invalid XML over the stream P16L26 to a server that performs validation (see Validation (Section P16L27 11.3)). P16L28 P16L29 o -- the entity has attempted to send data before P16L30 the stream has been authenticated, or otherwise is not authorized P16L31 to perform an action related to stream negotiation; the receiving P16L32 entity MUST NOT process the offending stanza before sending the P16L33 stream error. P16L34 P16L35 o -- the entity has violated some local service P16L36 policy; the server MAY choose to specify the policy in the P16L37 element or an application-specific condition element. P16L38 P16L39 o -- the server is unable to properly P16L40 connect to a remote entity that is required for authentication or P16L41 authorization. P16L42 P16L43 o -- the server lacks the system resources P16L44 necessary to service the stream. P16L45 P16L46 P16L47 P16L48 P17L1 o -- the entity has attempted to send restricted P17L2 XML features such as a comment, processing instruction, DTD, P17L3 entity reference, or unescaped character (see Restrictions P17L4 (Section 11.1)). P17L5 P17L6 o -- the server will not provide service to the P17L7 initiating entity but is redirecting traffic to another host; the P17L8 server SHOULD specify the alternate hostname or IP address (which P17L9 MUST be a valid domain identifier) as the XML character data of P17L10 the element. P17L11 P17L12 o -- the server is being shut down and all active P17L13 streams are being closed. P17L14 P17L15 o -- the error condition is not one of those P17L16 defined by the other conditions in this list; this error condition P17L17 SHOULD be used only in conjunction with an application-specific P17L18 condition. P17L19 P17L20 o -- the initiating entity has encoded the P17L21 stream in an encoding that is not supported by the server (see P17L22 Character Encoding (Section 11.5)). P17L23 P17L24 o -- the initiating entity has sent a P17L25 first-level child of the stream that is not supported by the P17L26 server. P17L27 P17L28 o -- the value of the 'version' attribute P17L29 provided by the initiating entity in the stream header specifies a P17L30 version of XMPP that is not supported by the server; the server P17L31 MAY specify the version(s) it supports in the element. P17L32 P17L33 o -- the initiating entity has sent XML that P17L34 is not well-formed as defined by [XML]. P17L35 P17L36 4.7.4. Application-Specific Conditions P17L37 P17L38 As noted, an application MAY provide application-specific stream P17L39 error information by including a properly-namespaced child in the P17L40 error element. The application-specific element SHOULD supplement or P17L41 further qualify a defined element. Thus the element will P17L42 contain two or three child elements: P17L43 P17L44 P17L45 P17L46 P17L47 P17L48 P18L1 P18L2 P18L4 P18L5 Some special application diagnostic information! P18L6 P18L7 P18L8 P18L9 P18L10 P18L11 4.8. Simplified Stream Examples P18L12 P18L13 This section contains two simplified examples of a stream-based P18L14 "session" of a client on a server (where the "C" lines are sent from P18L15 the client to the server, and the "S" lines are sent from the server P18L16 to the client); these examples are included for the purpose of P18L17 illustrating the concepts introduced thus far. P18L18 P18L19 A basic "session": P18L20 P18L21 C: P18L22 P18L27 S: P18L28 P18L34 ... encryption, authentication, and resource binding ... P18L35 C: P18L38 C: Art thou not Romeo, and a Montague? P18L39 C: P18L40 S: P18L43 S: Neither, fair saint, if either thee dislike. P18L44 S: P18L45 C: P18L46 S: P18L47 P18L48 P19L1 A "session" gone bad: P19L2 P19L3 C: P19L4 P19L9 S: P19L10 P19L16 ... encryption, authentication, and resource binding ... P19L17 C: P19L18 Bad XML, no closing body tag! P19L19 P19L20 S: P19L21 P19L23 P19L24 S: P19L25 P19L26 5. Use of TLS P19L27 P19L28 5.1. Overview P19L29 P19L30 XMPP includes a method for securing the stream from tampering and P19L31 eavesdropping. This channel encryption method makes use of the P19L32 Transport Layer Security (TLS) protocol [TLS], along with a P19L33 "STARTTLS" extension that is modelled after similar extensions for P19L34 the IMAP [IMAP], POP3 [POP3], and ACAP [ACAP] protocols as described P19L35 in RFC 2595 [USINGTLS]. The namespace name for the STARTTLS P19L36 extension is 'urn:ietf:params:xml:ns:xmpp-tls'. P19L37 P19L38 An administrator of a given domain MAY require the use of TLS for P19L39 client-to-server communications, server-to-server communications, or P19L40 both. Clients SHOULD use TLS to secure the streams prior to P19L41 attempting the completion of SASL negotiation (Section 6), and P19L42 servers SHOULD use TLS between two domains for the purpose of P19L43 securing server-to-server communications. P19L44 P19L45 P19L46 P19L47 P19L48 P20L1 The following rules apply: P20L2 P20L3 1. An initiating entity that complies with this specification MUST P20L4 include the 'version' attribute set to a value of "1.0" in the P20L5 initial stream header. P20L6 P20L7 2. If the TLS negotiation occurs between two servers, communications P20L8 MUST NOT proceed until the Domain Name System (DNS) hostnames P20L9 asserted by the servers have been resolved (see Server-to-Server P20L10 Communications (Section 14.4)). P20L11 P20L12 3. When a receiving entity that complies with this specification P20L13 receives an initial stream header that includes the 'version' P20L14 attribute set to a value of at least "1.0", after sending a P20L15 stream header in reply (including the version flag), it MUST P20L16 include a element (qualified by the P20L17 'urn:ietf:params:xml:ns:xmpp-tls' namespace) along with the list P20L18 of other stream features it supports. P20L19 P20L20 4. If the initiating entity chooses to use TLS, TLS negotiation MUST P20L21 be completed before proceeding to SASL negotiation; this order of P20L22 negotiation is required to help safeguard authentication P20L23 information sent during SASL negotiation, as well as to make it P20L24 possible to base the use of the SASL EXTERNAL mechanism on a P20L25 certificate provided during prior TLS negotiation. P20L26 P20L27 5. During TLS negotiation, an entity MUST NOT send any white space P20L28 characters (matching production [3] content of [XML]) within the P20L29 root stream element as separators between elements (any white P20L30 space characters shown in the TLS examples below are included for P20L31 the sake of readability only); this prohibition helps to ensure P20L32 proper security layer byte precision. P20L33 P20L34 6. The receiving entity MUST consider the TLS negotiation to have P20L35 begun immediately after sending the closing ">" character of the P20L36 element. The initiating entity MUST consider the TLS P20L37 negotiation to have begun immediately after receiving the closing P20L38 ">" character of the element from the receiving P20L39 entity. P20L40 P20L41 7. The initiating entity MUST validate the certificate presented by P20L42 the receiving entity; see Certificate Validation (Section 14.2) P20L43 regarding certificate validation procedures. P20L44 P20L45 8. Certificates MUST be checked against the hostname as provided by P20L46 the initiating entity (e.g., a user), not the hostname as P20L47 resolved via the Domain Name System; e.g., if the user specifies P20L48 a hostname of "example.com" but a DNS SRV [SRV] lookup returned P21L1 "im.example.com", the certificate MUST be checked as P21L2 "example.com". If a JID for any kind of XMPP entity (e.g., P21L3 client or server) is represented in a certificate, it MUST be P21L4 represented as a UTF8String within an otherName entity inside the P21L5 subjectAltName, using the [ASN.1] Object Identifier P21L6 "id-on-xmppAddr" specified in Section 5.1.1 of this document. P21L7 P21L8 9. If the TLS negotiation is successful, the receiving entity MUST P21L9 discard any knowledge obtained in an insecure manner from the P21L10 initiating entity before TLS takes effect. P21L11 P21L12 10. If the TLS negotiation is successful, the initiating entity MUST P21L13 discard any knowledge obtained in an insecure manner from the P21L14 receiving entity before TLS takes effect. P21L15 P21L16 11. If the TLS negotiation is successful, the receiving entity MUST P21L17 NOT offer the STARTTLS extension to the initiating entity along P21L18 with the other stream features that are offered when the stream P21L19 is restarted. P21L20 P21L21 12. If the TLS negotiation is successful, the initiating entity MUST P21L22 continue with SASL negotiation. P21L23 P21L24 13. If the TLS negotiation results in failure, the receiving entity P21L25 MUST terminate both the XML stream and the underlying TCP P21L26 connection. P21L27 P21L28 14. See Mandatory-to-Implement Technologies (Section 14.7) regarding P21L29 mechanisms that MUST be supported. P21L30 P21L31 5.1.1. ASN.1 Object Identifier for XMPP Address P21L32 P21L33 The [ASN.1] Object Identifier "id-on-xmppAddr" described above is P21L34 defined as follows: P21L35 P21L36 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) P21L37 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } P21L38 P21L39 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } -- other name forms P21L40 P21L41 id-on-xmppAddr OBJECT IDENTIFIER ::= { id-on 5 } P21L42 P21L43 XmppAddr ::= UTF8String P21L44 P21L45 This Object Identifier MAY also be represented in the dotted display P21L46 format as "1.3.6.1.5.5.7.8.5". P21L47 P21L48 P22L1 5.2. Narrative P22L2 P22L3 When an initiating entity secures a stream with a receiving entity P22L4 using TLS, the steps involved are as follows: P22L5 P22L6 1. The initiating entity opens a TCP connection and initiates the P22L7 stream by sending the opening XML stream header to the receiving P22L8 entity, including the 'version' attribute set to a value of at P22L9 least "1.0". P22L10 P22L11 2. The receiving entity responds by opening a TCP connection and P22L12 sending an XML stream header to the initiating entity, including P22L13 the 'version' attribute set to a value of at least "1.0". P22L14 P22L15 3. The receiving entity offers the STARTTLS extension to the P22L16 initiating entity by including it with the list of other P22L17 supported stream features (if TLS is required for interaction P22L18 with the receiving entity, it SHOULD signal that fact by P22L19 including a element as a child of the P22L20 element). P22L21 P22L22 4. The initiating entity issues the STARTTLS command (i.e., a P22L23 element qualified by the P22L24 'urn:ietf:params:xml:ns:xmpp-tls' namespace) to instruct the P22L25 receiving entity that it wishes to begin a TLS negotiation to P22L26 secure the stream. P22L27 P22L28 5. The receiving entity MUST reply with either a element P22L29 or a element qualified by the P22L30 'urn:ietf:params:xml:ns:xmpp-tls' namespace. If the failure case P22L31 occurs, the receiving entity MUST terminate both the XML stream P22L32 and the underlying TCP connection. If the proceed case occurs, P22L33 the entities MUST attempt to complete the TLS negotiation over P22L34 the TCP connection and MUST NOT send any further XML data until P22L35 the TLS negotiation is complete. P22L36 P22L37 6. The initiating entity and receiving entity attempt to complete a P22L38 TLS negotiation in accordance with [TLS]. P22L39 P22L40 7. If the TLS negotiation is unsuccessful, the receiving entity MUST P22L41 terminate the TCP connection. If the TLS negotiation is P22L42 successful, the initiating entity MUST initiate a new stream by P22L43 sending an opening XML stream header to the receiving entity (it P22L44 is not necessary to send a closing tag first, since the P22L45 receiving entity and initiating entity MUST consider the original P22L46 stream to be closed upon successful TLS negotiation). P22L47 P22L48 P23L1 8. Upon receiving the new stream header from the initiating entity, P23L2 the receiving entity MUST respond by sending a new XML stream P23L3 header to the initiating entity along with the available features P23L4 (but not including the STARTTLS feature). P23L5 P23L6 5.3. Client-to-Server Example P23L7 P23L8 The following example shows the data flow for a client securing a P23L9 stream using STARTTLS (note: the alternate steps shown below are P23L10 provided to illustrate the protocol for failure cases; they are not P23L11 exhaustive and would not necessarily be triggered by the data sent in P23L12 the example). P23L13 P23L14 Step 1: Client initiates stream to server: P23L15 P23L16 P23L21 P23L22 Step 2: Server responds by sending a stream tag to client: P23L23 P23L24 P23L30 P23L31 Step 3: Server sends the STARTTLS extension to client along with P23L32 authentication mechanisms and any other stream features: P23L33 P23L34 P23L35 P23L36 P23L37 P23L38 P23L39 DIGEST-MD5 P23L40 PLAIN P23L41 P23L42 P23L43 P23L44 Step 4: Client sends the STARTTLS command to server: P23L45 P23L46 P23L47 P23L48 P24L1 Step 5: Server informs client that it is allowed to proceed: P24L2 P24L3 P24L4 P24L5 Step 5 (alt): Server informs client that TLS negotiation has failed P24L6 and closes both stream and TCP connection: P24L7 P24L8 P24L9 P24L10 P24L11 Step 6: Client and server attempt to complete TLS negotiation over P24L12 the existing TCP connection. P24L13 P24L14 Step 7: If TLS negotiation is successful, client initiates a new P24L15 stream to server: P24L16 P24L17 P24L22 P24L23 Step 7 (alt): If TLS negotiation is unsuccessful, server closes TCP P24L24 connection. P24L25 P24L26 Step 8: Server responds by sending a stream header to client along P24L27 with any available stream features: P24L28 P24L29 P24L35 P24L36 P24L37 DIGEST-MD5 P24L38 PLAIN P24L39 EXTERNAL P24L40 P24L41 P24L42 P24L43 Step 9: Client continues with SASL negotiation (Section 6). P24L44 P24L45 P24L46 P24L47 P24L48 P25L1 5.4. Server-to-Server Example P25L2 P25L3 The following example shows the data flow for two servers securing a P25L4 stream using STARTTLS (note: the alternate steps shown below are P25L5 provided to illustrate the protocol for failure cases; they are not P25L6 exhaustive and would not necessarily be triggered by the data sent in P25L7 the example). P25L8 P25L9 Step 1: Server1 initiates stream to Server2: P25L10 P25L11 P25L16 P25L17 Step 2: Server2 responds by sending a stream tag to Server1: P25L18 P25L19 P25L25 P25L26 Step 3: Server2 sends the STARTTLS extension to Server1 along with P25L27 authentication mechanisms and any other stream features: P25L28 P25L29 P25L30 P25L31 P25L32 P25L33 P25L34 DIGEST-MD5 P25L35 KERBEROS_V4 P25L36 P25L37 P25L38 P25L39 Step 4: Server1 sends the STARTTLS command to Server2: P25L40 P25L41 P25L42 P25L43 Step 5: Server2 informs Server1 that it is allowed to proceed: P25L44 P25L45 P25L46 P25L47 P25L48 P26L1 Step 5 (alt): Server2 informs Server1 that TLS negotiation has failed P26L2 and closes stream: P26L3 P26L4 P26L5 P26L6 P26L7 Step 6: Server1 and Server2 attempt to complete TLS negotiation via P26L8 TCP. P26L9 P26L10 Step 7: If TLS negotiation is successful, Server1 initiates a new P26L11 stream to Server2: P26L12 P26L13 P26L18 P26L19 Step 7 (alt): If TLS negotiation is unsuccessful, Server2 closes TCP P26L20 connection. P26L21 P26L22 Step 8: Server2 responds by sending a stream header to Server1 along P26L23 with any available stream features: P26L24 P26L25 P26L31 P26L32 P26L33 DIGEST-MD5 P26L34 KERBEROS_V4 P26L35 EXTERNAL P26L36 P26L37 P26L38 P26L39 Step 9: Server1 continues with SASL negotiation (Section 6). P26L40 P26L41 P26L42 P26L43 P26L44 P26L45 P26L46 P26L47 P26L48 P27L1 6. Use of SASL P27L2 P27L3 6.1. Overview P27L4 P27L5 XMPP includes a method for authenticating a stream by means of an P27L6 XMPP-specific profile of the Simple Authentication and Security Layer P27L7 (SASL) protocol [SASL]. SASL provides a generalized method for P27L8 adding authentication support to connection-based protocols, and XMPP P27L9 uses a generic XML namespace profile for SASL that conforms to the P27L10 profiling requirements of [SASL]. P27L11 P27L12 The following rules apply: P27L13 P27L14 1. If the SASL negotiation occurs between two servers, P27L15 communications MUST NOT proceed until the Domain Name System P27L16 (DNS) hostnames asserted by the servers have been resolved (see P27L17 Server-to-Server Communications (Section 14.4)). P27L18 P27L19 2. If the initiating entity is capable of SASL negotiation, it MUST P27L20 include the 'version' attribute set to a value of at least "1.0" P27L21 in the initial stream header. P27L22 P27L23 3. If the receiving entity is capable of SASL negotiation, it MUST P27L24 advertise one or more authentication mechanisms within a P27L25 element qualified by the P27L26 'urn:ietf:params:xml:ns:xmpp-sasl' namespace in reply to the P27L27 opening stream tag received from the initiating entity (if the P27L28 opening stream tag included the 'version' attribute set to a P27L29 value of at least "1.0"). P27L30 P27L31 4. During SASL negotiation, an entity MUST NOT send any white space P27L32 characters (matching production [3] content of [XML]) within the P27L33 root stream element as separators between elements (any white P27L34 space characters shown in the SASL examples below are included P27L35 for the sake of readability only); this prohibition helps to P27L36 ensure proper security layer byte precision. P27L37 P27L38 5. Any XML character data contained within the XML elements used P27L39 during SASL negotiation MUST be encoded using base64, where the P27L40 encoding adheres to the definition in Section 3 of RFC 3548 P27L41 [BASE64]. P27L42 P27L43 6. If provision of a "simple username" is supported by the selected P27L44 SASL mechanism (e.g., this is supported by the DIGEST-MD5 and P27L45 CRAM-MD5 mechanisms but not by the EXTERNAL and GSSAPI P27L46 mechanisms), during authentication the initiating entity SHOULD P27L47 provide as the simple username its sending domain (IP address or P27L48 fully qualified domain name as contained in a domain identifier) P28L1 in the case of server-to-server communications or its registered P28L2 account name (user or node name as contained in an XMPP node P28L3 identifier) in the case of client-to-server communications. P28L4 P28L5 7. If the initiating entity wishes to act on behalf of another P28L6 entity and the selected SASL mechanism supports transmission of P28L7 an authorization identity, the initiating entity MUST provide an P28L8 authorization identity during SASL negotiation. If the P28L9 initiating entity does not wish to act on behalf of another P28L10 entity, it MUST NOT provide an authorization identity. As P28L11 specified in [SASL], the initiating entity MUST NOT provide an P28L12 authorization identity unless the authorization identity is P28L13 different from the default authorization identity derived from P28L14 the authentication identity as described in [SASL]. If provided, P28L15 the value of the authorization identity MUST be of the form P28L16 (i.e., a domain identifier only) for servers and of the P28L17 form (i.e., node identifier and domain identifier) P28L18 for clients. P28L19 P28L20 8. Upon successful SASL negotiation that involves negotiation of a P28L21 security layer, the receiving entity MUST discard any knowledge P28L22 obtained from the initiating entity which was not obtained from P28L23 the SASL negotiation itself. P28L24 P28L25 9. Upon successful SASL negotiation that involves negotiation of a P28L26 security layer, the initiating entity MUST discard any knowledge P28L27 obtained from the receiving entity which was not obtained from P28L28 the SASL negotiation itself. P28L29 P28L30 10. See Mandatory-to-Implement Technologies (Section 14.7) regarding P28L31 mechanisms that MUST be supported. P28L32 P28L33 6.2. Narrative P28L34 P28L35 When an initiating entity authenticates with a receiving entity using P28L36 SASL, the steps involved are as follows: P28L37 P28L38 1. The initiating entity requests SASL authentication by including P28L39 the 'version' attribute in the opening XML stream header sent to P28L40 the receiving entity, with the value set to "1.0". P28L41 P28L42 2. After sending an XML stream header in reply, the receiving entity P28L43 advertises a list of available SASL authentication mechanisms; P28L44 each of these is a element included as a child P28L45 within a container element qualified by the P28L46 'urn:ietf:params:xml:ns:xmpp-sasl' namespace, which in turn is a P28L47 child of a element in the streams namespace. If Use P28L48 of TLS (Section 5) needs to be established before a particular P29L1 authentication mechanism may be used, the receiving entity MUST P29L2 NOT provide that mechanism in the list of available SASL P29L3 authentication mechanisms prior to TLS negotiation. If the P29L4 initiating entity presents a valid certificate during prior TLS P29L5 negotiation, the receiving entity SHOULD offer the SASL EXTERNAL P29L6 mechanism to the initiating entity during SASL negotiation (refer P29L7 to [SASL]), although the EXTERNAL mechanism MAY be offered under P29L8 other circumstances as well. P29L9 P29L10 3. The initiating entity selects a mechanism by sending an P29L11 element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' P29L12 namespace to the receiving entity and including an appropriate P29L13 value for the 'mechanism' attribute. This element MAY contain P29L14 XML character data (in SASL terminology, the "initial response") P29L15 if the mechanism supports or requires it; if the initiating P29L16 entity needs to send a zero-length initial response, it MUST P29L17 transmit the response as a single equals sign ("="), which P29L18 indicates that the response is present but contains no data. P29L19 P29L20 4. If necessary, the receiving entity challenges the initiating P29L21 entity by sending a element qualified by the P29L22 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating P29L23 entity; this element MAY contain XML character data (which MUST P29L24 be computed in accordance with the definition of the SASL P29L25 mechanism chosen by the initiating entity). P29L26 P29L27 5. The initiating entity responds to the challenge by sending a P29L28 element qualified by the P29L29 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the receiving P29L30 entity; this element MAY contain XML character data (which MUST P29L31 be computed in accordance with the definition of the SASL P29L32 mechanism chosen by the initiating entity). P29L33 P29L34 6. If necessary, the receiving entity sends more challenges and the P29L35 initiating entity sends more responses. P29L36 P29L37 This series of challenge/response pairs continues until one of three P29L38 things happens: P29L39 P29L40 1. The initiating entity aborts the handshake by sending an P29L41 element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' P29L42 namespace to the receiving entity. Upon receiving an P29L43 element, the receiving entity SHOULD allow a configurable but P29L44 reasonable number of retries (at least 2), after which it MUST P29L45 terminate the TCP connection; this enables the initiating entity P29L46 (e.g., an end-user client) to tolerate incorrectly-provided P29L47 credentials (e.g., a mistyped password) without being forced to P29L48 reconnect. P30L1 2. The receiving entity reports failure of the handshake by sending P30L2 a element qualified by the P30L3 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating P30L4 entity (the particular cause of failure SHOULD be communicated in P30L5 an appropriate child element of the element as defined P30L6 under SASL Errors (Section 6.4)). If the failure case occurs, P30L7 the receiving entity SHOULD allow a configurable but reasonable P30L8 number of retries (at least 2), after which it MUST terminate the P30L9 TCP connection; this enables the initiating entity (e.g., an P30L10 end-user client) to tolerate incorrectly-provided credentials P30L11 (e.g., a mistyped password) without being forced to reconnect. P30L12 P30L13 3. The receiving entity reports success of the handshake by sending P30L14 a element qualified by the P30L15 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating P30L16 entity; this element MAY contain XML character data (in SASL P30L17 terminology, "additional data with success") if required by the P30L18 chosen SASL mechanism. Upon receiving the element, P30L19 the initiating entity MUST initiate a new stream by sending an P30L20 opening XML stream header to the receiving entity (it is not P30L21 necessary to send a closing tag first, since the P30L22 receiving entity and initiating entity MUST consider the original P30L23 stream to be closed upon sending or receiving the P30L24 element). Upon receiving the new stream header from the P30L25 initiating entity, the receiving entity MUST respond by sending a P30L26 new XML stream header to the initiating entity, along with any P30L27 available features (but not including the STARTTLS and SASL P30L28 features) or an empty element (to signify that no P30L29 additional features are available); any such additional features P30L30 not defined herein MUST be defined by the relevant extension to P30L31 XMPP. P30L32 P30L33 6.3. SASL Definition P30L34 P30L35 The profiling requirements of [SASL] require that the following P30L36 information be supplied by a protocol definition: P30L37 P30L38 service name: "xmpp" P30L39 P30L40 initiation sequence: After the initiating entity provides an opening P30L41 XML stream header and the receiving entity replies in kind, the P30L42 receiving entity provides a list of acceptable authentication P30L43 methods. The initiating entity chooses one method from the list P30L44 and sends it to the receiving entity as the value of the P30L45 'mechanism' attribute possessed by an element, optionally P30L46 including an initial response to avoid a round trip. P30L47 P30L48 P31L1 exchange sequence: Challenges and responses are carried through the P31L2 exchange of elements from receiving entity to P31L3 initiating entity and elements from initiating entity P31L4 to receiving entity. The receiving entity reports failure by P31L5 sending a element and success by sending a P31L6 element; the initiating entity aborts the exchange by sending an P31L7 element. Upon successful negotiation, both sides P31L8 consider the original XML stream to be closed and new stream P31L9 headers are sent by both entities. P31L10 P31L11 security layer negotiation: The security layer takes effect P31L12 immediately after sending the closing ">" character of the P31L13 element for the receiving entity, and immediately after P31L14 receiving the closing ">" character of the element for P31L15 the initiating entity. The order of layers is first [TCP], then P31L16 [TLS], then [SASL], then XMPP. P31L17 P31L18 use of the authorization identity: The authorization identity may be P31L19 used by xmpp to denote the non-default of a client P31L20 or the sending of a server. P31L21 P31L22 6.4. SASL Errors P31L23 P31L24 The following SASL-related error conditions are defined: P31L25 P31L26 o -- The receiving entity acknowledges an P31L27 element sent by the initiating entity; sent in reply to the P31L28 element. P31L29 P31L30 o -- The data provided by the initiating P31L31 entity could not be processed because the [BASE64] encoding is P31L32 incorrect (e.g., because the encoding does not adhere to the P31L33 definition in Section 3 of [BASE64]); sent in reply to a P31L34 element or an element with initial response P31L35 data. P31L36 P31L37 o -- The authzid provided by the initiating P31L38 entity is invalid, either because it is incorrectly formatted or P31L39 because the initiating entity does not have permissions to P31L40 authorize that ID; sent in reply to a element or an P31L41 element with initial response data. P31L42 P31L43 o -- The initiating entity did not provide a P31L44 mechanism or requested a mechanism that is not supported by the P31L45 receiving entity; sent in reply to an element. P31L46 P31L47 P31L48 P32L1 o -- The mechanism requested by the initiating P32L2 entity is weaker than server policy permits for that initiating P32L3 entity; sent in reply to a element or an P32L4 element with initial response data. P32L5 P32L6 o -- The authentication failed because the P32L7 initiating entity did not provide valid credentials (this includes P32L8 but is not limited to the case of an unknown username); sent in P32L9 reply to a element or an element with initial P32L10 response data. P32L11 P32L12 o -- The authentication failed because of P32L13 a temporary error condition within the receiving entity; sent in P32L14 reply to an element or element. P32L15 P32L16 6.5. Client-to-Server Example P32L17 P32L18 The following example shows the data flow for a client authenticating P32L19 with a server using SASL, normally after successful TLS negotiation P32L20 (note: the alternate steps shown below are provided to illustrate the P32L21 protocol for failure cases; they are not exhaustive and would not P32L22 necessarily be triggered by the data sent in the example). P32L23 P32L24 Step 1: Client initiates stream to server: P32L25 P32L26 P32L31 P32L32 Step 2: Server responds with a stream tag sent to client: P32L33 P32L34 P32L40 P32L41 Step 3: Server informs client of available authentication mechanisms: P32L42 P32L43 P32L44 P32L45 DIGEST-MD5 P32L46 PLAIN P32L47 P32L48 P33L1 Step 4: Client selects an authentication mechanism: P33L2 P33L3 P33L5 P33L6 Step 5: Server sends a [BASE64] encoded challenge to client: P33L7 P33L8 P33L9 cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi P33L10 LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg== P33L11 P33L12 P33L13 The decoded challenge is: P33L14 P33L15 realm="somerealm",nonce="OA6MG9tEQGm2hh",\ P33L16 qop="auth",charset=utf-8,algorithm=md5-sess P33L17 P33L18 Step 5 (alt): Server returns error to client: P33L19 P33L20 P33L21 P33L22 P33L23 P33L24 P33L25 Step 6: Client sends a [BASE64] encoded response to the challenge: P33L26 P33L27 P33L28 dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i P33L29 T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw P33L30 MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i P33L31 LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo P33L32 YXJzZXQ9dXRmLTgK P33L33 P33L34 P33L35 The decoded response is: P33L36 P33L37 username="somenode",realm="somerealm",\ P33L38 nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\ P33L39 nc=00000001,qop=auth,digest-uri="xmpp/example.com",\ P33L40 response=d388dad90d4bbd760a152321f2143af7,charset=utf-8 P33L41 P33L42 Step 7: Server sends another [BASE64] encoded challenge to client: P33L43 P33L44 P33L45 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= P33L46 P33L47 P33L48 P34L1 The decoded challenge is: P34L2 P34L3 rspauth=ea40f60335c427b5527b84dbabcdfffd P34L4 P34L5 Step 7 (alt): Server returns error to client: P34L6 P34L7 P34L8 P34L9 P34L10 P34L11 P34L12 Step 8: Client responds to the challenge: P34L13 P34L14 P34L15 P34L16 Step 9: Server informs client of successful authentication: P34L17 P34L18 P34L19 P34L20 Step 9 (alt): Server informs client of failed authentication: P34L21 P34L22 P34L23 P34L24 P34L25 P34L26 P34L27 Step 10: Client initiates a new stream to server: P34L28 P34L29 P34L34 P34L35 Step 11: Server responds by sending a stream header to client along P34L36 with any additional features (or an empty features element): P34L37 P34L38 P34L44 P34L45 P34L46 P34L47 P34L48 P35L1 6.6. Server-to-Server Example P35L2 P35L3 The following example shows the data flow for a server authenticating P35L4 with another server using SASL, normally after successful TLS P35L5 negotiation (note: the alternate steps shown below are provided to P35L6 illustrate the protocol for failure cases; they are not exhaustive P35L7 and would not necessarily be triggered by the data sent in the P35L8 example). P35L9 P35L10 Step 1: Server1 initiates stream to Server2: P35L11 P35L12 P35L17 P35L18 Step 2: Server2 responds with a stream tag sent to Server1: P35L19 P35L20 P35L26 P35L27 Step 3: Server2 informs Server1 of available authentication P35L28 mechanisms: P35L29 P35L30 P35L31 P35L32 DIGEST-MD5 P35L33 KERBEROS_V4 P35L34 P35L35 P35L36 P35L37 Step 4: Server1 selects an authentication mechanism: P35L38 P35L39 P35L41 P35L42 Step 5: Server2 sends a [BASE64] encoded challenge to Server1: P35L43 P35L44 P35L45 cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9 P35L46 ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz P35L47 P35L48 P36L1 The decoded challenge is: P36L2 P36L3 realm="somerealm",nonce="OA6MG9tEQGm2hh",\ P36L4 qop="auth",charset=utf-8,algorithm=md5-sess P36L5 P36L6 Step 5 (alt): Server2 returns error to Server1: P36L7 P36L8 P36L9 P36L10 P36L11 P36L12 P36L13 Step 6: Server1 sends a [BASE64] encoded response to the challenge: P36L14 P36L15 P36L16 dXNlcm5hbWU9ImV4YW1wbGUub3JnIixyZWFsbT0ic29tZXJlYWxtIixub25j P36L17 ZT0iT0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5j P36L18 PTAwMDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5v P36L19 cmciLHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3 P36L20 LGNoYXJzZXQ9dXRmLTgK P36L21 P36L22 P36L23 The decoded response is: P36L24 P36L25 username="example.org",realm="somerealm",\ P36L26 nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\ P36L27 nc=00000001,qop=auth,digest-uri="xmpp/example.org",\ P36L28 response=d388dad90d4bbd760a152321f2143af7,charset=utf-8 P36L29 P36L30 Step 7: Server2 sends another [BASE64] encoded challenge to Server1: P36L31 P36L32 P36L33 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= P36L34 P36L35 P36L36 The decoded challenge is: P36L37 P36L38 rspauth=ea40f60335c427b5527b84dbabcdfffd P36L39 P36L40 Step 7 (alt): Server2 returns error to Server1: P36L41 P36L42 P36L43 P36L44 P36L45 P36L46 P36L47 P36L48 P37L1 Step 8: Server1 responds to the challenge: P37L2 P37L3 P37L4 P37L5 Step 8 (alt): Server1 aborts negotiation: P37L6 P37L7 P37L8 P37L9 Step 9: Server2 informs Server1 of successful authentication: P37L10 P37L11 P37L12 P37L13 Step 9 (alt): Server2 informs Server1 of failed authentication: P37L14 P37L15 P37L16 P37L17 P37L18 P37L19 P37L20 Step 10: Server1 initiates a new stream to Server2: P37L21 P37L22 P37L27 P37L28 Step 11: Server2 responds by sending a stream header to Server1 along P37L29 with any additional features (or an empty features element): P37L30 P37L31 P37L37 P37L38 P37L39 7. Resource Binding P37L40 P37L41 After SASL negotiation (Section 6) with the receiving entity, the P37L42 initiating entity MAY want or need to bind a specific resource to P37L43 that stream. In general this applies only to clients: in order to P37L44 conform to the addressing format (Section 3) and stanza delivery P37L45 rules (Section 10) specified herein, there MUST be a resource P37L46 identifier associated with the of the client (which is P37L47 P37L48 P38L1 either generated by the server or provided by the client P38L2 application); this ensures that the address for use over that stream P38L3 is a "full JID" of the form . P38L4 P38L5 Upon receiving a success indication within the SASL negotiation, the P38L6 client MUST send a new stream header to the server, to which the P38L7 server MUST respond with a stream header as well as a list of P38L8 available stream features. Specifically, if the server requires the P38L9 client to bind a resource to the stream after successful SASL P38L10 negotiation, it MUST include an empty element qualified by P38L11 the 'urn:ietf:params:xml:ns:xmpp-bind' namespace in the stream P38L12 features list it presents to the client upon sending the header for P38L13 the response stream sent after successful SASL negotiation (but not P38L14 before): P38L15 P38L16 Server advertises resource binding feature to client: P38L17 P38L18 P38L24 P38L25 P38L26 P38L27 P38L28 Upon being so informed that resource binding is required, the client P38L29 MUST bind a resource to the stream by sending to the server an IQ P38L30 stanza of type "set" (see IQ Semantics (Section 9.2.3)) containing P38L31 data qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace. P38L32 P38L33 If the client wishes to allow the server to generate the resource P38L34 identifier on its behalf, it sends an IQ stanza of type "set" that P38L35 contains an empty element: P38L36 P38L37 Client asks server to bind a resource: P38L38 P38L39 P38L40 P38L41 P38L42 P38L43 A server that supports resource binding MUST be able to generate a P38L44 resource identifier on behalf of a client. A resource identifier P38L45 generated by the server MUST be unique for that . P38L46 P38L47 P38L48 P39L1 If the client wishes to specify the resource identifier, it sends an P39L2 IQ stanza of type "set" that contains the desired resource identifier P39L3 as the XML character data of a element that is a child of P39L4 the element: P39L5 P39L6 Client binds a resource: P39L7 P39L8 P39L9 P39L10 someresource P39L11 P39L12 P39L13 P39L14 Once the server has generated a resource identifier for the client or P39L15 accepted the resource identifier provided by the client, it MUST P39L16 return an IQ stanza of type "result" to the client, which MUST P39L17 include a child element that specifies the full JID for the P39L18 connected resource as determined by the server: P39L19 P39L20 Server informs client of successful resource binding: P39L21 P39L22 P39L23 P39L24 somenode@example.com/someresource P39L25 P39L26 P39L27 P39L28 A server SHOULD accept the resource identifier provided by the P39L29 client, but MAY override it with a resource identifier that the P39L30 server generates; in this case, the server SHOULD NOT return a stanza P39L31 error (e.g., ) to the client but instead SHOULD P39L32 communicate the generated resource identifier to the client in the IQ P39L33 result as shown above. P39L34 P39L35 When a client supplies a resource identifier, the following stanza P39L36 error conditions are possible (see Stanza Errors (Section 9.3)): P39L37 P39L38 o The provided resource identifier cannot be processed by the server P39L39 in accordance with Resourceprep (Appendix B). P39L40 P39L41 o The client is not allowed to bind a resource to the stream (e.g., P39L42 because the node or user has reached a limit on the number of P39L43 connected resources allowed). P39L44 P39L45 o The provided resource identifier is already in use but the server P39L46 does not allow binding of multiple connected resources with the P39L47 same identifier. P39L48 P40L1 The protocol for these error conditions is shown below. P40L2 P40L3 Resource identifier cannot be processed: P40L4 P40L5 P40L6 P40L7 someresource P40L8 P40L9 P40L10 P40L11 P40L12 P40L13 P40L14 Client is not allowed to bind a resource: P40L15 P40L16 P40L17 P40L18 someresource P40L19 P40L20 P40L21 P40L22 P40L23 P40L24 P40L25 Resource identifier is in use: P40L26 P40L27 P40L28 P40L29 someresource P40L30 P40L31 P40L32 P40L33 P40L34 P40L35 P40L36 If, before completing the resource binding step, the client attempts P40L37 to send an XML stanza other than an IQ stanza with a child P40L38 qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace, the P40L39 server MUST NOT process the stanza and SHOULD return a P40L40 stanza error to the client. P40L41 P40L42 P40L43 P40L44 P40L45 P40L46 P40L47 P40L48 P41L1 8. Server Dialback P41L2 P41L3 8.1. Overview P41L4 P41L5 The Jabber protocols from which XMPP was adapted include a "server P41L6 dialback" method for protecting against domain spoofing, thus making P41L7 it more difficult to spoof XML stanzas. Server dialback is not a P41L8 security mechanism, and results in weak verification of server P41L9 identities only (see Server-to-Server Communications (Section 14.4) P41L10 regarding this method's security characteristics). Domains requiring P41L11 robust security SHOULD use TLS and SASL; see Server-to-Server P41L12 Communications (Section 14.4) for details. If SASL is used for P41L13 server-to-server authentication, dialback SHOULD NOT be used since it P41L14 is unnecessary. Documentation of dialback is included mainly for the P41L15 sake of backward-compatibility with existing implementations and P41L16 deployments. P41L17 P41L18 The server dialback method is made possible by the existence of the P41L19 Domain Name System (DNS), since one server can (normally) discover P41L20 the authoritative server for a given domain. Because dialback P41L21 depends on DNS, inter-domain communications MUST NOT proceed until P41L22 the Domain Name System (DNS) hostnames asserted by the servers have P41L23 been resolved (see Server-to-Server Communications (Section 14.4)). P41L24 P41L25 Server dialback is uni-directional, and results in (weak) P41L26 verification of identities for one stream in one direction. Because P41L27 server dialback is not an authentication mechanism, mutual P41L28 authentication is not possible via dialback. Therefore, server P41L29 dialback MUST be completed in each direction in order to enable P41L30 bi-directional communications between two domains. P41L31 P41L32 The method for generating and verifying the keys used in server P41L33 dialback MUST take into account the hostnames being used, the stream P41L34 ID generated by the receiving server, and a secret known by the P41L35 authoritative server's network. The stream ID is security-critical P41L36 in server dialback and therefore MUST be both unpredictable and P41L37 non-repeating (see [RANDOM] for recommendations regarding randomness P41L38 for security purposes). P41L39 P41L40 Any error that occurs during dialback negotiation MUST be considered P41L41 a stream error, resulting in termination of the stream and of the P41L42 underlying TCP connection. The possible error conditions are P41L43 specified in the protocol description below. P41L44 P41L45 The following terminology applies: P41L46 P41L47 o Originating Server -- the server that is attempting to establish a P41L48 connection between two domains. P42L1 o Receiving Server -- the server that is trying to authenticate that P42L2 the Originating Server represents the domain which it claims to P42L3 be. P42L4 P42L5 o Authoritative Server -- the server that answers to the DNS P42L6 hostname asserted by the Originating Server; for basic P42L7 environments this will be the Originating Server, but it could be P42L8 a separate machine in the Originating Server's network. P42L9 P42L10 8.2. Order of Events P42L11 P42L12 The following is a brief summary of the order of events in dialback: P42L13 P42L14 1. The Originating Server establishes a connection to the Receiving P42L15 Server. P42L16 P42L17 2. The Originating Server sends a 'key' value over the connection to P42L18 the Receiving Server. P42L19 P42L20 3. The Receiving Server establishes a connection to the P42L21 Authoritative Server. P42L22 P42L23 4. The Receiving Server sends the same 'key' value to the P42L24 Authoritative Server. P42L25 P42L26 5. The Authoritative Server replies that key is valid or invalid. P42L27 P42L28 6. The Receiving Server informs the Originating Server whether it is P42L29 authenticated or not. P42L30 P42L31 P42L32 P42L33 P42L34 P42L35 P42L36 P42L37 P42L38 P42L39 P42L40 P42L41 P42L42 P42L43 P42L44 P42L45 P42L46 P42L47 P42L48 P43L1 We can represent this flow of events graphically as follows: P43L2 P43L3 Originating Receiving P43L4 Server Server P43L5 ----------- --------- P43L6 | | P43L7 | establish connection | P43L8 | ----------------------> | P43L9 | | P43L10 | send stream header | P43L11 | ----------------------> | P43L12 | | P43L13 | send stream header | P43L14 | <---------------------- | P43L15 | | Authoritative P43L16 | send dialback key | Server P43L17 | ----------------------> | ------------- P43L18 | | | P43L19 | establish connection | P43L20 | ----------------------> | P43L21 | | P43L22 | send stream header | P43L23 | ----------------------> | P43L24 | | P43L25 | send stream header | P43L26 | <---------------------- | P43L27 | | P43L28 | send verify request | P43L29 | ----------------------> | P43L30 | | P43L31 | send verify response | P43L32 | <---------------------- | P43L33 | P43L34 | report dialback result | P43L35 | <---------------------- | P43L36 | | P43L37 P43L38 8.3. Protocol P43L39 P43L40 The detailed protocol interaction between the servers is as follows: P43L41 P43L42 1. The Originating Server establishes TCP connection to the P43L43 Receiving Server. P43L44 P43L45 P43L46 P43L47 P43L48 P44L1 2. The Originating Server sends a stream header to the Receiving P44L2 Server: P44L3 P44L4 P44L8 P44L9 Note: The 'to' and 'from' attributes are OPTIONAL on the root stream P44L10 element. The inclusion of the xmlns:db namespace declaration with P44L11 the name shown indicates to the Receiving Server that the Originating P44L12 Server supports dialback. If the namespace name is incorrect, then P44L13 the Receiving Server MUST generate an stream P44L14 error condition and terminate both the XML stream and the underlying P44L15 TCP connection. P44L16 P44L17 3. The Receiving Server SHOULD send a stream header back to the P44L18 Originating Server, including a unique ID for this interaction: P44L19 P44L20 P44L25 P44L26 Note: The 'to' and 'from' attributes are OPTIONAL on the root stream P44L27 element. If the namespace name is incorrect, then the Originating P44L28 Server MUST generate an stream error condition P44L29 and terminate both the XML stream and the underlying TCP connection. P44L30 Note well that the Receiving Server SHOULD reply but MAY silently P44L31 terminate the XML stream and underlying TCP connection depending on P44L32 security policies in place; however, if the Receiving Server desires P44L33 to proceed, it MUST send a stream header back to the Originating P44L34 Server. P44L35 P44L36 4. The Originating Server sends a dialback key to the Receiving P44L37 Server: P44L38 P44L39 P44L42 98AF014EDC0... P44L43 P44L44 P44L45 Note: This key is not examined by the Receiving Server, since the P44L46 Receiving Server does not keep information about the Originating P44L47 Server between sessions. The key generated by the Originating Server P44L48 MUST be based in part on the value of the ID provided by the P45L1 Receiving Server in the previous step, and in part on a secret shared P45L2 by the Originating Server and Authoritative Server. If the value of P45L3 the 'to' address does not match a hostname recognized by the P45L4 Receiving Server, then the Receiving Server MUST generate a P45L5 stream error condition and terminate both the XML P45L6 stream and the underlying TCP connection. If the value of the 'from' P45L7 address matches a domain with which the Receiving Server already has P45L8 an established connection, then the Receiving Server MUST maintain P45L9 the existing connection until it validates whether the new connection P45L10 is legitimate; additionally, the Receiving Server MAY choose to P45L11 generate a stream error condition for the new P45L12 connection and then terminate both the XML stream and the underlying P45L13 TCP connection related to the new request. P45L14 P45L15 5. The Receiving Server establishes a TCP connection back to the P45L16 domain name asserted by the Originating Server, as a result of P45L17 which it connects to the Authoritative Server. (Note: As an P45L18 optimization, an implementation MAY reuse an existing connection P45L19 here.) P45L20 P45L21 6. The Receiving Server sends the Authoritative Server a stream P45L22 header: P45L23 P45L24 P45L28 P45L29 Note: The 'to' and 'from' attributes are OPTIONAL on the root stream P45L30 element. If the namespace name is incorrect, then the Authoritative P45L31 Server MUST generate an stream error condition P45L32 and terminate both the XML stream and the underlying TCP connection. P45L33 P45L34 7. The Authoritative Server sends the Receiving Server a stream P45L35 header: P45L36 P45L37 P45L42 P45L43 Note: If the namespace name is incorrect, then the Receiving Server P45L44 MUST generate an stream error condition and P45L45 terminate both the XML stream and the underlying TCP connection P45L46 between it and the Authoritative Server. If a stream error occurs P45L47 between the Receiving Server and the Authoritative Server, then the P45L48 Receiving Server MUST generate a stream P46L1 error condition and terminate both the XML stream and the underlying P46L2 TCP connection between it and the Originating Server. P46L3 P46L4 8. The Receiving Server sends the Authoritative Server a request for P46L5 verification of a key: P46L6 P46L7 P46L11 98AF014EDC0... P46L12 P46L13 P46L14 Note: Passed here are the hostnames, the original identifier from the P46L15 Receiving Server's stream header to the Originating Server in Step 3, P46L16 and the key that the Originating Server sent to the Receiving Server P46L17 in Step 4. Based on this information, as well as shared secret P46L18 information within the Authoritative Server's network, the key is P46L19 verified. Any verifiable method MAY be used to generate the key. If P46L20 the value of the 'to' address does not match a hostname recognized by P46L21 the Authoritative Server, then the Authoritative Server MUST generate P46L22 a stream error condition and terminate both the XML P46L23 stream and the underlying TCP connection. If the value of the 'from' P46L24 address does not match the hostname represented by the Receiving P46L25 Server when opening the TCP connection (or any validated domain P46L26 thereof, such as a validated subdomain of the Receiving Server's P46L27 hostname or another validated domain hosted by the Receiving Server), P46L28 then the Authoritative Server MUST generate an stream P46L29 error condition and terminate both the XML stream and the underlying P46L30 TCP connection. P46L31 P46L32 9. The Authoritative Server verifies whether the key was valid or P46L33 invalid: P46L34 P46L35 P46L40 P46L41 or P46L42 P46L43 P46L48 P47L1 Note: If the ID does not match that provided by the Receiving Server P47L2 in Step 3, then the Receiving Server MUST generate an P47L3 stream error condition and terminate both the XML stream and the P47L4 underlying TCP connection. If the value of the 'to' address does not P47L5 match a hostname recognized by the Receiving Server, then the P47L6 Receiving Server MUST generate a stream error P47L7 condition and terminate both the XML stream and the underlying TCP P47L8 connection. If the value of the 'from' address does not match the P47L9 hostname represented by the Originating Server when opening the TCP P47L10 connection (or any validated domain thereof, such as a validated P47L11 subdomain of the Originating Server's hostname or another validated P47L12 domain hosted by the Originating Server), then the Receiving Server P47L13 MUST generate an stream error condition and terminate P47L14 both the XML stream and the underlying TCP connection. After P47L15 returning the verification to the Receiving Server, the Authoritative P47L16 Server SHOULD terminate the stream between them. P47L17 P47L18 10. The Receiving Server informs the Originating Server of the P47L19 result: P47L20 P47L21 P47L25 P47L26 Note: At this point, the connection has either been validated via a P47L27 type='valid', or reported as invalid. If the connection is invalid, P47L28 then the Receiving Server MUST terminate both the XML stream and the P47L29 underlying TCP connection. If the connection is validated, data can P47L30 be sent by the Originating Server and read by the Receiving Server; P47L31 before that, all XML stanzas sent to the Receiving Server SHOULD be P47L32 silently dropped. P47L33 P47L34 The result of the foregoing is that the Receiving Server has verified P47L35 the identity of the Originating Server, so that the Originating P47L36 Server can send, and the Receiving Server can accept, XML stanzas P47L37 over the "initial stream" (i.e., the stream from the Originating P47L38 Server to the Receiving Server). In order to verify the identities P47L39 of the entities using the "response stream" (i.e., the stream from P47L40 the Receiving Server to the Originating Server), dialback MUST be P47L41 completed in the opposite direction as well. P47L42 P47L43 After successful dialback negotiation, the Receiving Server SHOULD P47L44 accept subsequent packets (e.g., validation requests P47L45 sent to a subdomain or other hostname serviced by the Receiving P47L46 Server) from the Originating Server over the existing validated P47L47 connection; this enables "piggybacking" of the original validated P47L48 connection in one direction. P48L1 Even if dialback negotiation is successful, a server MUST verify that P48L2 all XML stanzas received from the other server include a 'from' P48L3 attribute and a 'to' attribute; if a stanza does not meet this P48L4 restriction, the server that receives the stanza MUST generate an P48L5 stream error condition and terminate both the P48L6 XML stream and the underlying TCP connection. Furthermore, a server P48L7 MUST verify that the 'from' attribute of stanzas received from the P48L8 other server includes a validated domain for the stream; if a stanza P48L9 does not meet this restriction, the server that receives the stanza P48L10 MUST generate an stream error condition and terminate P48L11 both the XML stream and the underlying TCP connection. Both of these P48L12 checks help to prevent spoofing related to particular stanzas. P48L13 P48L14 9. XML Stanzas P48L15 P48L16 After TLS negotiation (Section 5) if desired, SASL negotiation P48L17 (Section 6), and Resource Binding (Section 7) if necessary, XML P48L18 stanzas can be sent over the streams. Three kinds of XML stanza are P48L19 defined for the 'jabber:client' and 'jabber:server' namespaces: P48L20 , , and . In addition, there are five P48L21 common attributes for these kinds of stanza. These common P48L22 attributes, as well as the basic semantics of the three stanza kinds, P48L23 are defined herein; more detailed information regarding the syntax of P48L24 XML stanzas in relation to instant messaging and presence P48L25 applications is provided in [XMPP-IM]. P48L26 P48L27 9.1. Common Attributes P48L28 P48L29 The following five attributes are common to message, presence, and IQ P48L30 stanzas: P48L31 P48L32 9.1.1. to P48L33 P48L34 The 'to' attribute specifies the JID of the intended recipient for P48L35 the stanza. P48L36 P48L37 In the 'jabber:client' namespace, a stanza SHOULD possess a 'to' P48L38 attribute, although a stanza sent from a client to a server for P48L39 handling by that server (e.g., presence sent to the server for P48L40 broadcasting to other entities) SHOULD NOT possess a 'to' attribute. P48L41 P48L42 In the 'jabber:server' namespace, a stanza MUST possess a 'to' P48L43 attribute; if a server receives a stanza that does not meet this P48L44 restriction, it MUST generate an stream error P48L45 condition and terminate both the XML stream and the underlying TCP P48L46 connection with the offending server. P48L47 P48L48 P49L1 If the value of the 'to' attribute is invalid or cannot be contacted, P49L2 the entity discovering that fact (usually the sender's or recipient's P49L3 server) MUST return an appropriate error to the sender, setting the P49L4 'from' attribute of the error stanza to the value provided in the P49L5 'to' attribute of the offending stanza. P49L6 P49L7 9.1.2. from P49L8 P49L9 The 'from' attribute specifies the JID of the sender. P49L10 P49L11 When a server receives an XML stanza within the context of an P49L12 authenticated stream qualified by the 'jabber:client' namespace, it P49L13 MUST do one of the following: P49L14 P49L15 1. validate that the value of the 'from' attribute provided by the P49L16 client is that of a connected resource for the associated entity P49L17 P49L18 2. add a 'from' address to the stanza whose value is the bare JID P49L19 () or the full JID () P49L20 determined by the server for the connected resource that P49L21 generated the stanza (see Determination of Addresses (Section P49L22 3.5)) P49L23 P49L24 If a client attempts to send an XML stanza for which the value of the P49L25 'from' attribute does not match one of the connected resources for P49L26 that entity, the server SHOULD return an stream error P49L27 to the client. If a client attempts to send an XML stanza over a P49L28 stream that is not yet authenticated, the server SHOULD return a P49L29 stream error to the client. If generated, both of P49L30 these conditions MUST result in closure of the stream and termination P49L31 of the underlying TCP connection; this helps to prevent a denial of P49L32 service attack launched from a rogue client. P49L33 P49L34 When a server generates a stanza from the server itself for delivery P49L35 to a connected client (e.g., in the context of data storage services P49L36 provided by the server on behalf of the client), the stanza MUST P49L37 either (1) not include a 'from' attribute or (2) include a 'from' P49L38 attribute whose value is the account's bare JID () or P49L39 client's full JID (). A server MUST NOT send P49L40 to the client a stanza without a 'from' attribute if the stanza was P49L41 not generated by the server itself. When a client receives a stanza P49L42 that does not include a 'from' attribute, it MUST assume that the P49L43 stanza is from the server to which the client is connected. P49L44 P49L45 In the 'jabber:server' namespace, a stanza MUST possess a 'from' P49L46 attribute; if a server receives a stanza that does not meet this P49L47 restriction, it MUST generate an stream error P49L48 condition. Furthermore, the domain identifier portion of the JID P50L1 contained in the 'from' attribute MUST match the hostname of the P50L2 sending server (or any validated domain thereof, such as a validated P50L3 subdomain of the sending server's hostname or another validated P50L4 domain hosted by the sending server) as communicated in the SASL P50L5 negotiation or dialback negotiation; if a server receives a stanza P50L6 that does not meet this restriction, it MUST generate an P50L7 stream error condition. Both of these conditions P50L8 MUST result in closing of the stream and termination of the P50L9 underlying TCP connection; this helps to prevent a denial of service P50L10 attack launched from a rogue server. P50L11 P50L12 9.1.3. id P50L13 P50L14 The optional 'id' attribute MAY be used by a sending entity for P50L15 internal tracking of stanzas that it sends and receives (especially P50L16 for tracking the request-response interaction inherent in the P50L17 semantics of IQ stanzas). It is OPTIONAL for the value of the 'id' P50L18 attribute to be unique globally, within a domain, or within a stream. P50L19 The semantics of IQ stanzas impose additional restrictions; see IQ P50L20 Semantics (Section 9.2.3). P50L21 P50L22 9.1.4. type P50L23 P50L24 The 'type' attribute specifies detailed information about the purpose P50L25 or context of the message, presence, or IQ stanza. The particular P50L26 allowable values for the 'type' attribute vary depending on whether P50L27 the stanza is a message, presence, or IQ; the values for message and P50L28 presence stanzas are specific to instant messaging and presence P50L29 applications and therefore are defined in [XMPP-IM], whereas the P50L30 values for IQ stanzas specify the role of an IQ stanza in a P50L31 structured request-response "conversation" and thus are defined under P50L32 IQ Semantics (Section 9.2.3) below. The only 'type' value common to P50L33 all three stanzas is "error"; see Stanza Errors (Section 9.3). P50L34 P50L35 9.1.5. xml:lang P50L36 P50L37 A stanza SHOULD possess an 'xml:lang' attribute (as defined in P50L38 Section 2.12 of [XML]) if the stanza contains XML character data that P50L39 is intended to be presented to a human user (as explained in RFC 2277 P50L40 [CHARSET], "internationalization is for humans"). The value of the P50L41 'xml:lang' attribute specifies the default language of any such P50L42 human-readable XML character data, which MAY be overridden by the P50L43 'xml:lang' attribute of a specific child element. If a stanza does P50L44 not possess an 'xml:lang' attribute, an implementation MUST assume P50L45 that the default language is that specified for the stream as defined P50L46 under Stream Attributes (Section 4.4) above. The value of the P50L47 'xml:lang' attribute MUST be an NMTOKEN and MUST conform to the P50L48 format defined in RFC 3066 [LANGTAGS]. P51L1 9.2. Basic Semantics P51L2 P51L3 9.2.1. Message Semantics P51L4 P51L5 The stanza kind can be seen as a "push" mechanism whereby P51L6 one entity pushes information to another entity, similar to the P51L7 communications that occur in a system such as email. All message P51L8 stanzas SHOULD possess a 'to' attribute that specifies the intended P51L9 recipient of the message; upon receiving such a stanza, a server P51L10 SHOULD route or deliver it to the intended recipient (see Server P51L11 Rules for Handling XML Stanzas (Section 10) for general routing and P51L12 delivery rules related to XML stanzas). P51L13 P51L14 9.2.2. Presence Semantics P51L15 P51L16 The element can be seen as a basic broadcast or P51L17 "publish-subscribe" mechanism, whereby multiple entities receive P51L18 information about an entity to which they have subscribed (in this P51L19 case, network availability information). In general, a publishing P51L20 entity SHOULD send a presence stanza with no 'to' attribute, in which P51L21 case the server to which the entity is connected SHOULD broadcast or P51L22 multiplex that stanza to all subscribing entities. However, a P51L23 publishing entity MAY also send a presence stanza with a 'to' P51L24 attribute, in which case the server SHOULD route or deliver that P51L25 stanza to the intended recipient. See Server Rules for Handling XML P51L26 Stanzas (Section 10) for general routing and delivery rules related P51L27 to XML stanzas, and [XMPP-IM] for presence-specific rules in the P51L28 context of an instant messaging and presence application. P51L29 P51L30 9.2.3. IQ Semantics P51L31 P51L32 Info/Query, or IQ, is a request-response mechanism, similar in some P51L33 ways to [HTTP]. The semantics of IQ enable an entity to make a P51L34 request of, and receive a response from, another entity. The data P51L35 content of the request and response is defined by the namespace P51L36 declaration of a direct child element of the IQ element, and the P51L37 interaction is tracked by the requesting entity through use of the P51L38 'id' attribute. Thus, IQ interactions follow a common pattern of P51L39 structured data exchange such as get/result or set/result (although P51L40 an error may be returned in reply to a request if appropriate): P51L41 P51L42 P51L43 P51L44 P51L45 P51L46 P51L47 P51L48 P52L1 Requesting Responding P52L2 Entity Entity P52L3 ---------- ---------- P52L4 | | P52L5 | | P52L6 | ------------------------> | P52L7 | | P52L8 | | P52L9 | <------------------------ | P52L10 | | P52L11 | | P52L12 | ------------------------> | P52L13 | | P52L14 | | P52L15 | <------------------------ | P52L16 | | P52L17 P52L18 In order to enforce these semantics, the following rules apply: P52L19 P52L20 1. The 'id' attribute is REQUIRED for IQ stanzas. P52L21 P52L22 2. The 'type' attribute is REQUIRED for IQ stanzas. The value MUST P52L23 be one of the following: P52L24 P52L25 * get -- The stanza is a request for information or P52L26 requirements. P52L27 P52L28 * set -- The stanza provides required data, sets new values, or P52L29 replaces existing values. P52L30 P52L31 * result -- The stanza is a response to a successful get or set P52L32 request. P52L33 P52L34 * error -- An error has occurred regarding processing or P52L35 delivery of a previously-sent get or set (see Stanza Errors P52L36 (Section 9.3)). P52L37 P52L38 3. An entity that receives an IQ request of type "get" or "set" MUST P52L39 reply with an IQ response of type "result" or "error" (the P52L40 response MUST preserve the 'id' attribute of the request). P52L41 P52L42 4. An entity that receives a stanza of type "result" or "error" MUST P52L43 NOT respond to the stanza by sending a further IQ response of P52L44 type "result" or "error"; however, as shown above, the requesting P52L45 entity MAY send another request (e.g., an IQ of type "set" in P52L46 order to provide required information discovered through a P52L47 get/result pair). P52L48 P53L1 5. An IQ stanza of type "get" or "set" MUST contain one and only one P53L2 child element that specifies the semantics of the particular P53L3 request or response. P53L4 P53L5 6. An IQ stanza of type "result" MUST include zero or one child P53L6 elements. P53L7 P53L8 7. An IQ stanza of type "error" SHOULD include the child element P53L9 contained in the associated "get" or "set" and MUST include an P53L10 child; for details, see Stanza Errors (Section 9.3). P53L11 P53L12 9.3. Stanza Errors P53L13 P53L14 Stanza-related errors are handled in a manner similar to stream P53L15 errors (Section 4.7). However, unlike stream errors, stanza errors P53L16 are recoverable; therefore error stanzas include hints regarding P53L17 actions that the original sender can take in order to remedy the P53L18 error. P53L19 P53L20 9.3.1. Rules P53L21 P53L22 The following rules apply to stanza-related errors: P53L23 P53L24 o The receiving or processing entity that detects an error condition P53L25 in relation to a stanza MUST return to the sending entity a stanza P53L26 of the same kind (message, presence, or IQ), whose 'type' P53L27 attribute is set to a value of "error" (such a stanza is called an P53L28 "error stanza" herein). P53L29 P53L30 o The entity that generates an error stanza SHOULD include the P53L31 original XML sent so that the sender can inspect and, if P53L32 necessary, correct the XML before attempting to resend. P53L33 P53L34 o An error stanza MUST contain an child element. P53L35 P53L36 o An child MUST NOT be included if the 'type' attribute has P53L37 a value other than "error" (or if there is no 'type' attribute). P53L38 P53L39 o An entity that receives an error stanza MUST NOT respond to the P53L40 stanza with a further error stanza; this helps to prevent looping. P53L41 P53L42 P53L43 P53L44 P53L45 P53L46 P53L47 P53L48 P54L1 9.3.2. Syntax P54L2 P54L3 The syntax for stanza-related errors is as follows: P54L4 P54L5 P54L6 [RECOMMENDED to include sender XML here] P54L7 P54L8 P54L9 P54L11 OPTIONAL descriptive text P54L12 P54L13 [OPTIONAL application-specific condition element] P54L14 P54L15 P54L16 P54L17 The stanza-kind is one of message, presence, or iq. P54L18 P54L19 The value of the element's 'type' attribute MUST be one of P54L20 the following: P54L21 P54L22 o cancel -- do not retry (the error is unrecoverable) P54L23 o continue -- proceed (the condition was only a warning) P54L24 o modify -- retry after changing the data sent P54L25 o auth -- retry after providing credentials P54L26 o wait -- retry after waiting (the error is temporary) P54L27 P54L28 The element: P54L29 P54L30 o MUST contain a child element corresponding to one of the defined P54L31 stanza error conditions specified below; this element MUST be P54L32 qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace. P54L33 P54L34 o MAY contain a child containing XML character data that P54L35 describes the error in more detail; this element MUST be qualified P54L36 by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace and SHOULD P54L37 possess an 'xml:lang' attribute. P54L38 P54L39 o MAY contain a child element for an application-specific error P54L40 condition; this element MUST be qualified by an P54L41 application-defined namespace, and its structure is defined by P54L42 that namespace. P54L43 P54L44 The element is OPTIONAL. If included, it SHOULD be used only P54L45 to provide descriptive or diagnostic information that supplements the P54L46 meaning of a defined condition or application-specific condition. It P54L47 SHOULD NOT be interpreted programmatically by an application. It P54L48 P55L1 SHOULD NOT be used as the error message presented to a user, but MAY P55L2 be shown in addition to the error message associated with the P55L3 included condition element (or elements). P55L4 P55L5 Finally, to maintain backward compatibility, the schema (specified in P55L6 [XMPP-IM]) allows the optional inclusion of a 'code' attribute on the P55L7 element. P55L8 P55L9 9.3.3. Defined Conditions P55L10 P55L11 The following conditions are defined for use in stanza errors. P55L12 P55L13 o -- the sender has sent XML that is malformed or P55L14 that cannot be processed (e.g., an IQ stanza that includes an P55L15 unrecognized value of the 'type' attribute); the associated error P55L16 type SHOULD be "modify". P55L17 P55L18 o -- access cannot be granted because an existing P55L19 resource or session exists with the same name or address; the P55L20 associated error type SHOULD be "cancel". P55L21 P55L22 o -- the feature requested is not P55L23 implemented by the recipient or server and therefore cannot be P55L24 processed; the associated error type SHOULD be "cancel". P55L25 P55L26 o -- the requesting entity does not possess the P55L27 required permissions to perform the action; the associated error P55L28 type SHOULD be "auth". P55L29 P55L30 o -- the recipient or server can no longer be contacted at P55L31 this address (the error stanza MAY contain a new address in the P55L32 XML character data of the element); the associated error P55L33 type SHOULD be "modify". P55L34 P55L35 o -- the server could not process the P55L36 stanza because of a misconfiguration or an otherwise-undefined P55L37 internal server error; the associated error type SHOULD be "wait". P55L38 P55L39 o -- the addressed JID or item requested cannot be P55L40 found; the associated error type SHOULD be "cancel". P55L41 P55L42 o -- the sending entity has provided or P55L43 communicated an XMPP address (e.g., a value of the 'to' attribute) P55L44 or aspect thereof (e.g., a resource identifier) that does not P55L45 adhere to the syntax defined in Addressing Scheme (Section 3); the P55L46 associated error type SHOULD be "modify". P55L47 P55L48 P56L1 o -- the recipient or server understands the P56L2 request but is refusing to process it because it does not meet P56L3 criteria defined by the recipient or server (e.g., a local policy P56L4 regarding acceptable words in messages); the associated error type P56L5 SHOULD be "modify". P56L6 P56L7 o -- the recipient or server does not allow any P56L8 entity to perform the action; the associated error type SHOULD be P56L9 "cancel". P56L10 P56L11 o -- the sender must provide proper credentials P56L12 before being allowed to perform the action, or has provided P56L13 improper credentials; the associated error type SHOULD be "auth". P56L14 P56L15 o -- the requesting entity is not authorized to P56L16 access the requested service because payment is required; the P56L17 associated error type SHOULD be "auth". P56L18 P56L19 o -- the intended recipient is temporarily P56L20 unavailable; the associated error type SHOULD be "wait" (note: an P56L21 application MUST NOT return this error if doing so would provide P56L22 information about the intended recipient's network availability to P56L23 an entity that is not authorized to know such information). P56L24 P56L25 o -- the recipient or server is redirecting requests for P56L26 this information to another entity, usually temporarily (the error P56L27 stanza SHOULD contain the alternate address, which MUST be a valid P56L28 JID, in the XML character data of the element); the P56L29 associated error type SHOULD be "modify". P56L30 P56L31 o -- the requesting entity is not P56L32 authorized to access the requested service because registration is P56L33 required; the associated error type SHOULD be "auth". P56L34 P56L35 o -- a remote server or service specified P56L36 as part or all of the JID of the intended recipient does not P56L37 exist; the associated error type SHOULD be "cancel". P56L38 P56L39 o -- a remote server or service specified P56L40 as part or all of the JID of the intended recipient (or required P56L41 to fulfill a request) could not be contacted within a reasonable P56L42 amount of time; the associated error type SHOULD be "wait". P56L43 P56L44 o -- the server or recipient lacks the system P56L45 resources necessary to service the request; the associated error P56L46 type SHOULD be "wait". P56L47 P56L48 P57L1 o -- the server or recipient does not P57L2 currently provide the requested service; the associated error type P57L3 SHOULD be "cancel". P57L4 P57L5 o -- the requesting entity is not P57L6 authorized to access the requested service because a subscription P57L7 is required; the associated error type SHOULD be "auth". P57L8 P57L9 o -- the error condition is not one of those P57L10 defined by the other conditions in this list; any error type may P57L11 be associated with this condition, and it SHOULD be used only in P57L12 conjunction with an application-specific condition. P57L13 P57L14 o -- the recipient or server understood the P57L15 request but was not expecting it at this time (e.g., the request P57L16 was out of order); the associated error type SHOULD be "wait". P57L17 P57L18 9.3.4. Application-Specific Conditions P57L19 P57L20 As noted, an application MAY provide application-specific stanza P57L21 error information by including a properly-namespaced child in the P57L22 error element. The application-specific element SHOULD supplement or P57L23 further qualify a defined element. Thus, the element will P57L24 contain two or three child elements: P57L25 P57L26 P57L27 P57L28 P57L29 P57L30 P57L31 P57L32 P57L33 P57L34 P57L35 P57L37 P57L39 Some special application diagnostic information... P57L40 P57L41 P57L42 P57L43 P57L44 P57L45 P57L46 P57L47 P57L48 P58L1 10. Server Rules for Handling XML Stanzas P58L2 P58L3 Compliant server implementations MUST ensure in-order processing of P58L4 XML stanzas between any two entities. P58L5 P58L6 Beyond the requirement for in-order processing, each server P58L7 implementation will contain its own "delivery tree" for handling P58L8 stanzas it receives. Such a tree determines whether a stanza needs P58L9 to be routed to another domain, processed internally, or delivered to P58L10 a resource associated with a connected node. The following rules P58L11 apply: P58L12 P58L13 10.1. No 'to' Address P58L14 P58L15 If the stanza possesses no 'to' attribute, the server SHOULD process P58L16 it on behalf of the entity that sent it. Because all stanzas P58L17 received from other servers MUST possess a 'to' attribute, this rule P58L18 applies only to stanzas received from a registered entity (such as a P58L19 client) that is connected to the server. If the server receives a P58L20 presence stanza with no 'to' attribute, the server SHOULD broadcast P58L21 it to the entities that are subscribed to the sending entity's P58L22 presence, if applicable (the semantics of presence broadcast for P58L23 instant messaging and presence applications are defined in P58L24 [XMPP-IM]). If the server receives an IQ stanza of type "get" or P58L25 "set" with no 'to' attribute and it understands the namespace that P58L26 qualifies the content of the stanza, it MUST either process the P58L27 stanza on behalf of the sending entity (where the meaning of P58L28 "process" is determined by the semantics of the qualifying namespace) P58L29 or return an error to the sending entity. P58L30 P58L31 10.2. Foreign Domain P58L32 P58L33 If the hostname of the domain identifier portion of the JID contained P58L34 in the 'to' attribute does not match one of the configured hostnames P58L35 of the server itself or a subdomain thereof, the server SHOULD route P58L36 the stanza to the foreign domain (subject to local service P58L37 provisioning and security policies regarding inter-domain P58L38 communication). There are two possible cases: P58L39 P58L40 A server-to-server stream already exists between the two domains: The P58L41 sender's server routes the stanza to the authoritative server for P58L42 the foreign domain over the existing stream P58L43 P58L44 There exists no server-to-server stream between the two domains: The P58L45 sender's server (1) resolves the hostname of the foreign domain P58L46 (as defined under Server-to-Server Communications (Section 14.4)), P58L47 (2) negotiates a server-to-server stream between the two domains P58L48 (as defined under Use of TLS (Section 5) and Use of SASL (Section P59L1 6)), and (3) routes the stanza to the authoritative server for the P59L2 foreign domain over the newly-established stream P59L3 P59L4 If routing to the recipient's server is unsuccessful, the sender's P59L5 server MUST return an error to the sender; if the recipient's server P59L6 can be contacted but delivery by the recipient's server to the P59L7 recipient is unsuccessful, the recipient's server MUST return an P59L8 error to the sender by way of the sender's server. P59L9 P59L10 10.3. Subdomain P59L11 P59L12 If the hostname of the domain identifier portion of the JID contained P59L13 in the 'to' attribute matches a subdomain of one of the configured P59L14 hostnames of the server itself, the server MUST either process the P59L15 stanza itself or route the stanza to a specialized service that is P59L16 responsible for that subdomain (if the subdomain is configured), or P59L17 return an error to the sender (if the subdomain is not configured). P59L18 P59L19 10.4. Mere Domain or Specific Resource P59L20 P59L21 If the hostname of the domain identifier portion of the JID contained P59L22 in the 'to' attribute matches a configured hostname of the server P59L23 itself and the JID contained in the 'to' attribute is of the form P59L24 or , the server (or a defined resource P59L25 thereof) MUST either process the stanza as appropriate for the stanza P59L26 kind or return an error stanza to the sender. P59L27 P59L28 10.5. Node in Same Domain P59L29 P59L30 If the hostname of the domain identifier portion of the JID contained P59L31 in the 'to' attribute matches a configured hostname of the server P59L32 itself and the JID contained in the 'to' attribute is of the form P59L33 or , the server SHOULD deliver P59L34 the stanza to the intended recipient of the stanza as represented by P59L35 the JID contained in the 'to' attribute. The following rules apply: P59L36 P59L37 1. If the JID contains a resource identifier (i.e., is of the form P59L38 ) and there exists a connected resource P59L39 that matches the full JID, the recipient's server SHOULD deliver P59L40 the stanza to the stream or session that exactly matches the P59L41 resource identifier. P59L42 P59L43 2. If the JID contains a resource identifier and there exists no P59L44 connected resource that matches the full JID, the recipient's P59L45 server SHOULD return a stanza error to the P59L46 sender. P59L47 P59L48 P60L1 3. If the JID is of the form and there exists at least P60L2 one connected resource for the node, the recipient's server P60L3 SHOULD deliver the stanza to at least one of the connected P60L4 resources, according to application-specific rules (a set of P60L5 delivery rules for instant messaging and presence applications is P60L6 defined in [XMPP-IM]). P60L7 P60L8 11. XML Usage within XMPP P60L9 P60L10 11.1. Restrictions P60L11 P60L12 XMPP is a simplified and specialized protocol for streaming XML P60L13 elements in order to exchange structured information in close to real P60L14 time. Because XMPP does not require the parsing of arbitrary and P60L15 complete XML documents, there is no requirement that XMPP needs to P60L16 support the full feature set of [XML]. In particular, the following P60L17 restrictions apply. P60L18 P60L19 With regard to XML generation, an XMPP implementation MUST NOT inject P60L20 into an XML stream any of the following: P60L21 P60L22 o comments (as defined in Section 2.5 of [XML]) P60L23 P60L24 o processing instructions (Section 2.6 therein) P60L25 P60L26 o internal or external DTD subsets (Section 2.8 therein) P60L27 P60L28 o internal or external entity references (Section 4.2 therein) with P60L29 the exception of predefined entities (Section 4.6 therein) P60L30 P60L31 o character data or attribute values containing unescaped characters P60L32 that map to the predefined entities (Section 4.6 therein); such P60L33 characters MUST be escaped P60L34 P60L35 With regard to XML processing, if an XMPP implementation receives P60L36 such restricted XML data, it MUST ignore the data. P60L37 P60L38 11.2. XML Namespace Names and Prefixes P60L39 P60L40 XML Namespaces [XML-NAMES] are used within all XMPP-compliant XML to P60L41 create strict boundaries of data ownership. The basic function of P60L42 namespaces is to separate different vocabularies of XML elements that P60L43 are structurally mixed together. Ensuring that XMPP-compliant XML is P60L44 namespace-aware enables any allowable XML to be structurally mixed P60L45 with any data element within XMPP. Rules for XML namespace names and P60L46 prefixes are defined in the following subsections. P60L47 P60L48 P61L1 11.2.1. Streams Namespace P61L2 P61L3 A streams namespace declaration is REQUIRED in all XML stream P61L4 headers. The name of the streams namespace MUST be P61L5 'http://etherx.jabber.org/streams'. The element names of the P61L6 element and its and children MUST be P61L7 qualified by the streams namespace prefix in all instances. An P61L8 implementation SHOULD generate only the 'stream:' prefix for these P61L9 elements, and for historical reasons MAY accept only the 'stream:' P61L10 prefix. P61L11 P61L12 11.2.2. Default Namespace P61L13 P61L14 A default namespace declaration is REQUIRED and is used in all XML P61L15 streams in order to define the allowable first-level children of the P61L16 root stream element. This namespace declaration MUST be the same for P61L17 the initial stream and the response stream so that both streams are P61L18 qualified consistently. The default namespace declaration applies to P61L19 the stream and all stanzas sent within a stream (unless explicitly P61L20 qualified by another namespace, or by the prefix of the streams P61L21 namespace or the dialback namespace). P61L22 P61L23 A server implementation MUST support the following two default P61L24 namespaces (for historical reasons, some implementations MAY support P61L25 only these two default namespaces): P61L26 P61L27 o jabber:client -- this default namespace is declared when the P61L28 stream is used for communications between a client and a server P61L29 P61L30 o jabber:server -- this default namespace is declared when the P61L31 stream is used for communications between two servers P61L32 P61L33 A client implementation MUST support the 'jabber:client' default P61L34 namespace, and for historical reasons MAY support only that default P61L35 namespace. P61L36 P61L37 An implementation MUST NOT generate namespace prefixes for elements P61L38 in the default namespace if the default namespace is 'jabber:client' P61L39 or 'jabber:server'. An implementation SHOULD NOT generate namespace P61L40 prefixes for elements qualified by content (as opposed to stream) P61L41 namespaces other than 'jabber:client' and 'jabber:server'. P61L42 P61L43 Note: The 'jabber:client' and 'jabber:server' namespaces are nearly P61L44 identical but are used in different contexts (client-to-server P61L45 communications for 'jabber:client' and server-to-server P61L46 communications for 'jabber:server'). The only difference between the P61L47 two is that the 'to' and 'from' attributes are OPTIONAL on stanzas P61L48 sent within 'jabber:client', whereas they are REQUIRED on stanzas P62L1 sent within 'jabber:server'. If a compliant implementation accepts a P62L2 stream that is qualified by the 'jabber:client' or 'jabber:server' P62L3 namespace, it MUST support the common attributes (Section 9.1) and P62L4 basic semantics (Section 9.2) of all three core stanza kinds P62L5 (message, presence, and IQ). P62L6 P62L7 11.2.3. Dialback Namespace P62L8 P62L9 A dialback namespace declaration is REQUIRED for all elements used in P62L10 server dialback (Section 8). The name of the dialback namespace MUST P62L11 be 'jabber:server:dialback'. All elements qualified by this P62L12 namespace MUST be prefixed. An implementation SHOULD generate only P62L13 the 'db:' prefix for such elements and MAY accept only the 'db:' P62L14 prefix. P62L15 P62L16 11.3. Validation P62L17 P62L18 Except as noted with regard to 'to' and 'from' addresses for stanzas P62L19 within the 'jabber:server' namespace, a server is not responsible for P62L20 validating the XML elements forwarded to a client or another server; P62L21 an implementation MAY choose to provide only validated data elements P62L22 but this is OPTIONAL (although an implementation MUST NOT accept XML P62L23 that is not well-formed). Clients SHOULD NOT rely on the ability to P62L24 send data which does not conform to the schemas, and SHOULD ignore P62L25 any non-conformant elements or attributes on the incoming XML stream. P62L26 Validation of XML streams and stanzas is OPTIONAL, and schemas are P62L27 included herein for descriptive purposes only. P62L28 P62L29 11.4. Inclusion of Text Declaration P62L30 P62L31 Implementations SHOULD send a text declaration before sending a P62L32 stream header. Applications MUST follow the rules in [XML] regarding P62L33 the circumstances under which a text declaration is included. P62L34 P62L35 11.5. Character Encoding P62L36 P62L37 Implementations MUST support the UTF-8 (RFC 3629 [UTF-8]) P62L38 transformation of Universal Character Set (ISO/IEC 10646-1 [UCS2]) P62L39 characters, as required by RFC 2277 [CHARSET]. Implementations MUST P62L40 NOT attempt to use any other encoding. P62L41 P62L42 12. Core Compliance Requirements P62L43 P62L44 This section summarizes the specific aspects of the Extensible P62L45 Messaging and Presence Protocol that MUST be supported by servers and P62L46 clients in order to be considered compliant implementations, as well P62L47 as additional protocol aspects that SHOULD be supported. For P62L48 compliance purposes, we draw a distinction between core protocols P63L1 (which MUST be supported by any server or client, regardless of the P63L2 specific application) and instant messaging protocols (which MUST be P63L3 supported only by instant messaging and presence applications built P63L4 on top of the core protocols). Compliance requirements that apply to P63L5 all servers and clients are specified in this section; compliance P63L6 requirements for instant messaging servers and clients are specified P63L7 in the corresponding section of [XMPP-IM]. P63L8 P63L9 12.1. Servers P63L10 P63L11 In addition to all defined requirements with regard to security, XML P63L12 usage, and internationalization, a server MUST support the following P63L13 core protocols in order to be considered compliant: P63L14 P63L15 o Application of the [NAMEPREP], Nodeprep (Appendix A), and P63L16 Resourceprep (Appendix B) profiles of [STRINGPREP] to addresses P63L17 (including ensuring that domain identifiers are internationalized P63L18 domain names as defined in [IDNA]) P63L19 P63L20 o XML streams (Section 4), including Use of TLS (Section 5), Use of P63L21 SASL (Section 6), and Resource Binding (Section 7) P63L22 P63L23 o The basic semantics of the three defined stanza kinds (i.e., P63L24 , , and ) as specified in stanza P63L25 semantics (Section 9.2) P63L26 P63L27 o Generation (and, where appropriate, handling) of error syntax and P63L28 semantics related to streams, TLS, SASL, and XML stanzas P63L29 P63L30 In addition, a server MAY support the following core protocol: P63L31 P63L32 o Server dialback (Section 8) P63L33 P63L34 12.2. Clients P63L35 P63L36 A client MUST support the following core protocols in order to be P63L37 considered compliant: P63L38 P63L39 o XML streams (Section 4), including Use of TLS (Section 5), Use of P63L40 SASL (Section 6), and Resource Binding (Section 7) P63L41 P63L42 o The basic semantics of the three defined stanza kinds (i.e., P63L43 , , and ) as specified in stanza P63L44 semantics (Section 9.2) P63L45 P63L46 o Handling (and, where appropriate, generation) of error syntax and P63L47 semantics related to streams, TLS, SASL, and XML stanzas P63L48 P64L1 In addition, a client SHOULD support the following core protocols: P64L2 P64L3 o Generation of addresses to which the [NAMEPREP], Nodeprep P64L4 (Appendix A), and Resourceprep (Appendix B) profiles of P64L5 [STRINGPREP] can be applied without failing P64L6 P64L7 13. Internationalization Considerations P64L8 P64L9 XML streams MUST be encoded in UTF-8 as specified under Character P64L10 Encoding (Section 11.5). As specified under Stream Attributes P64L11 (Section 4.4), an XML stream SHOULD include an 'xml:lang' attribute P64L12 that is treated as the default language for any XML character data P64L13 sent over the stream that is intended to be presented to a human P64L14 user. As specified under xml:lang (Section 9.1.5), an XML stanza P64L15 SHOULD include an 'xml:lang' attribute if the stanza contains XML P64L16 character data that is intended to be presented to a human user. A P64L17 server SHOULD apply the default 'xml:lang' attribute to stanzas it P64L18 routes or delivers on behalf of connected entities, and MUST NOT P64L19 modify or delete 'xml:lang' attributes from stanzas it receives from P64L20 other entities. P64L21 P64L22 14. Security Considerations P64L23 P64L24 14.1. High Security P64L25 P64L26 For the purposes of XMPP communications (client-to-server and P64L27 server-to-server), the term "high security" refers to the use of P64L28 security technologies that provide both mutual authentication and P64L29 integrity-checking; in particular, when using certificate-based P64L30 authentication to provide high security, a chain-of-trust SHOULD be P64L31 established out-of-band, although a shared certificate authority P64L32 signing certificates could allow a previously unknown certificate to P64L33 establish trust in-band. See Section 14.2 below regarding P64L34 certificate validation procedures. P64L35 P64L36 Implementations MUST support high security. Service provisioning P64L37 SHOULD use high security, subject to local security policies. P64L38 P64L39 14.2. Certificate Validation P64L40 P64L41 When an XMPP peer communicates with another peer securely, it MUST P64L42 validate the peer's certificate. There are three possible cases: P64L43 P64L44 Case #1: The peer contains an End Entity certificate which appears to P64L45 be certified by a chain of certificates terminating in a trust P64L46 anchor (as described in Section 6.1 of [X509]). P64L47 P64L48 P65L1 Case #2: The peer certificate is certified by a Certificate Authority P65L2 not known to the validating peer. P65L3 P65L4 Case #3: The peer certificate is self-signed. P65L5 P65L6 In Case #1, the validating peer MUST do one of two things: P65L7 P65L8 1. Verify the peer certificate according to the rules of [X509]. P65L9 The certificate SHOULD then be checked against the expected P65L10 identity of the peer following the rules described in [HTTP-TLS], P65L11 except that a subjectAltName extension of type "xmpp" MUST be P65L12 used as the identity if present. If one of these checks fails, P65L13 user-oriented clients MUST either notify the user (clients MAY P65L14 give the user the opportunity to continue with the connection in P65L15 any case) or terminate the connection with a bad certificate P65L16 error. Automated clients SHOULD terminate the connection (with a P65L17 bad certificate error) and log the error to an appropriate audit P65L18 log. Automated clients MAY provide a configuration setting that P65L19 disables this check, but MUST provide a setting that enables it. P65L20 P65L21 2. The peer SHOULD show the certificate to a user for approval, P65L22 including the entire certificate chain. The peer MUST cache the P65L23 certificate (or some non-forgeable representation such as a P65L24 hash). In future connections, the peer MUST verify that the same P65L25 certificate was presented and MUST notify the user if it has P65L26 changed. P65L27 P65L28 In Case #2 and Case #3, implementations SHOULD act as in (2) above. P65L29 P65L30 14.3. Client-to-Server Communications P65L31 P65L32 A compliant client implementation MUST support both TLS and SASL for P65L33 connections to a server. P65L34 P65L35 The TLS protocol for encrypting XML streams (defined under Use of TLS P65L36 (Section 5)) provides a reliable mechanism for helping to ensure the P65L37 confidentiality and data integrity of data exchanged between two P65L38 entities. P65L39 P65L40 The SASL protocol for authenticating XML streams (defined under Use P65L41 of SASL (Section 6)) provides a reliable mechanism for validating P65L42 that a client connecting to a server is who it claims to be. P65L43 P65L44 Client-to-server communications MUST NOT proceed until the DNS P65L45 hostname asserted by the server has been resolved. Such resolutions P65L46 SHOULD first attempt to resolve the hostname using an [SRV] Service P65L47 of "xmpp-client" and Proto of "tcp", resulting in resource records P65L48 such as "_xmpp-client._tcp.example.com." (the use of the string P66L1 "xmpp-client" for the service identifier is consistent with the IANA P66L2 registration). If the SRV lookup fails, the fallback is a normal P66L3 IPv4/IPv6 address record resolution to determine the IP address, P66L4 using the "xmpp-client" port of 5222, registered with the IANA. P66L5 P66L6 The IP address and method of access of clients MUST NOT be made P66L7 public by a server, nor are any connections other than the original P66L8 server connection required. This helps to protect the client's P66L9 server from direct attack or identification by third parties. P66L10 P66L11 14.4. Server-to-Server Communications P66L12 P66L13 A compliant server implementation MUST support both TLS and SASL for P66L14 inter-domain communications. For historical reasons, a compliant P66L15 implementation SHOULD also support Server Dialback (Section 8). P66L16 P66L17 Because service provisioning is a matter of policy, it is OPTIONAL P66L18 for any given domain to communicate with other domains, and P66L19 server-to-server communications MAY be disabled by the administrator P66L20 of any given deployment. If a particular domain enables inter-domain P66L21 communications, it SHOULD enable high security. P66L22 P66L23 Administrators may want to require use of SASL for server-to-server P66L24 communications in order to ensure both authentication and P66L25 confidentiality (e.g., on an organization's private network). P66L26 Compliant implementations SHOULD support SASL for this purpose. P66L27 P66L28 Inter-domain connections MUST NOT proceed until the DNS hostnames P66L29 asserted by the servers have been resolved. Such resolutions MUST P66L30 first attempt to resolve the hostname using an [SRV] Service of P66L31 "xmpp-server" and Proto of "tcp", resulting in resource records such P66L32 as "_xmpp-server._tcp.example.com." (the use of the string P66L33 "xmpp-server" for the service identifier is consistent with the IANA P66L34 registration; note well that the "xmpp-server" service identifier P66L35 supersedes the earlier use of a "jabber" service identifier, since P66L36 the earlier usage did not conform to [SRV]; implementations desiring P66L37 to be backward compatible should continue to look for or answer to P66L38 the "jabber" service identifier as well). If the SRV lookup fails, P66L39 the fallback is a normal IPv4/IPv6 address record resolution to P66L40 determine the IP address, using the "xmpp-server" port 5269, P66L41 registered with the IANA. P66L42 P66L43 Server dialback helps protect against domain spoofing, thus making it P66L44 more difficult to spoof XML stanzas. It is not a mechanism for P66L45 authenticating, securing, or encrypting streams between servers as is P66L46 done via SASL and TLS, and results in weak verification of server P66L47 identities only. Furthermore, it is susceptible to DNS poisoning P66L48 attacks unless DNSSec [DNSSEC] is used, and even if the DNS P67L1 information is accurate, dialback cannot protect from attacks where P67L2 the attacker is capable of hijacking the IP address of the remote P67L3 domain. Domains requiring robust security SHOULD use TLS and SASL. P67L4 If SASL is used for server-to-server authentication, dialback SHOULD P67L5 NOT be used since it is unnecessary. P67L6 P67L7 14.5. Order of Layers P67L8 P67L9 The order of layers in which protocols MUST be stacked is as follows: P67L10 P67L11 1. TCP P67L12 2. TLS P67L13 3. SASL P67L14 4. XMPP P67L15 P67L16 The rationale for this order is that [TCP] is the base connection P67L17 layer used by all of the protocols stacked on top of TCP, [TLS] is P67L18 often provided at the operating system layer, [SASL] is often P67L19 provided at the application layer, and XMPP is the application P67L20 itself. P67L21 P67L22 14.6. Lack of SASL Channel Binding to TLS P67L23 P67L24 The SASL framework does not provide a mechanism to bind SASL P67L25 authentication to a security layer providing confidentiality and P67L26 integrity protection that was negotiated at a lower layer. This lack P67L27 of a "channel binding" prevents SASL from being able to verify that P67L28 the source and destination end points to which the lower layer's P67L29 security is bound are equivalent to the end points that SASL is P67L30 authenticating. If the end points are not identical, the lower P67L31 layer's security cannot be trusted to protect data transmitted P67L32 between the SASL authenticated entities. In such a situation, a SASL P67L33 security layer should be negotiated that effectively ignores the P67L34 presence of the lower layer security. P67L35 P67L36 14.7. Mandatory-to-Implement Technologies P67L37 P67L38 At a minimum, all implementations MUST support the following P67L39 mechanisms: P67L40 P67L41 for authentication: the SASL [DIGEST-MD5] mechanism P67L42 P67L43 for confidentiality: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA P67L44 cipher) P67L45 P67L46 for both: TLS plus SASL EXTERNAL(using the P67L47 TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side P67L48 certificates) P68L1 14.8. Firewalls P68L2 P68L3 Communications using XMPP normally occur over [TCP] connections on P68L4 port 5222 (client-to-server) or port 5269 (server-to-server), as P68L5 registered with the IANA (see IANA Considerations (Section 15)). Use P68L6 of these well-known ports allows administrators to easily enable or P68L7 disable XMPP activity through existing and commonly-deployed P68L8 firewalls. P68L9 P68L10 14.9. Use of base64 in SASL P68L11 P68L12 Both the client and the server MUST verify any [BASE64] data received P68L13 during SASL negotiation. An implementation MUST reject (not ignore) P68L14 any characters that are not explicitly allowed by the base64 P68L15 alphabet; this helps to guard against creation of a covert channel P68L16 that could be used to "leak" information. An implementation MUST NOT P68L17 break on invalid input and MUST reject any sequence of base64 P68L18 characters containing the pad ('=') character if that character is P68L19 included as something other than the last character of the data P68L20 (e.g., "=AAA" or "BBBB=CCC"); this helps to guard against buffer P68L21 overflow attacks and other attacks on the implementation. Base 64 P68L22 encoding visually hides otherwise easily recognized information, such P68L23 as passwords, but does not provide any computational confidentiality. P68L24 Base 64 encoding MUST follow the definition in Section 3 of RFC 3548 P68L25 [BASE64]. P68L26 P68L27 14.10. Stringprep Profiles P68L28 P68L29 XMPP makes use of the [NAMEPREP] profile of [STRINGPREP] for the P68L30 processing of domain identifiers; for security considerations related P68L31 to Nameprep, refer to the appropriate section of [NAMEPREP]. P68L32 P68L33 In addition, XMPP defines two profiles of [STRINGPREP]: Nodeprep P68L34 (Appendix A) for node identifiers and Resourceprep (Appendix B) for P68L35 resource identifiers. P68L36 P68L37 The Unicode and ISO/IEC 10646 repertoires have many characters that P68L38 look similar. In many cases, users of security protocols might do P68L39 visual matching, such as when comparing the names of trusted third P68L40 parties. Because it is impossible to map similar-looking characters P68L41 without a great deal of context, such as knowing the fonts used, P68L42 stringprep does nothing to map similar-looking characters together, P68L43 nor to prohibit some characters because they look like others. P68L44 P68L45 A node identifier can be employed as one part of an entity's address P68L46 in XMPP. One common usage is as the username of an instant messaging P68L47 user; another is as the name of a multi-user chat room; many other P68L48 kinds of entities could use node identifiers as part of their P69L1 addresses. The security of such services could be compromised based P69L2 on different interpretations of the internationalized node P69L3 identifier; for example, a user entering a single internationalized P69L4 node identifier could access another user's account information, or a P69L5 user could gain access to an otherwise restricted chat room or P69L6 service. P69L7 P69L8 A resource identifier can be employed as one part of an entity's P69L9 address in XMPP. One common usage is as the name for an instant P69L10 messaging user's connected resource (active session); another is as P69L11 the nickname of a user in a multi-user chat room; many other kinds of P69L12 entities could use resource identifiers as part of their addresses. P69L13 The security of such services could be compromised based on different P69L14 interpretations of the internationalized resource identifier; for P69L15 example, a user could attempt to initiate multiple sessions with the P69L16 same name, or a user could send a message to someone other than the P69L17 intended recipient in a multi-user chat room. P69L18 P69L19 15. IANA Considerations P69L20 P69L21 15.1. XML Namespace Name for TLS Data P69L22 P69L23 A URN sub-namespace for TLS-related data in the Extensible Messaging P69L24 and Presence Protocol (XMPP) is defined as follows. (This namespace P69L25 name adheres to the format defined in The IETF XML Registry P69L26 [XML-REG].) P69L27 P69L28 URI: urn:ietf:params:xml:ns:xmpp-tls P69L29 Specification: RFC 3920 P69L30 Description: This is the XML namespace name for TLS-related data in P69L31 the Extensible Messaging and Presence Protocol (XMPP) as defined P69L32 by RFC 3920. P69L33 Registrant Contact: IETF, XMPP Working Group, P69L34 P69L35 15.2. XML Namespace Name for SASL Data P69L36 P69L37 A URN sub-namespace for SASL-related data in the Extensible Messaging P69L38 and Presence Protocol (XMPP) is defined as follows. (This namespace P69L39 name adheres to the format defined in [XML-REG].) P69L40 P69L41 URI: urn:ietf:params:xml:ns:xmpp-sasl P69L42 Specification: RFC 3920 P69L43 Description: This is the XML namespace name for SASL-related data in P69L44 the Extensible Messaging and Presence Protocol (XMPP) as defined P69L45 by RFC 3920. P69L46 Registrant Contact: IETF, XMPP Working Group, P69L47 P69L48 P70L1 15.3. XML Namespace Name for Stream Errors P70L2 P70L3 A URN sub-namespace for stream-related error data in the Extensible P70L4 Messaging and Presence Protocol (XMPP) is defined as follows. (This P70L5 namespace name adheres to the format defined in [XML-REG].) P70L6 P70L7 URI: urn:ietf:params:xml:ns:xmpp-streams P70L8 Specification: RFC 3920 P70L9 Description: This is the XML namespace name for stream-related error P70L10 data in the Extensible Messaging and Presence Protocol (XMPP) as P70L11 defined by RFC 3920. P70L12 Registrant Contact: IETF, XMPP Working Group, P70L13 P70L14 15.4. XML Namespace Name for Resource Binding P70L15 P70L16 A URN sub-namespace for resource binding in the Extensible Messaging P70L17 and Presence Protocol (XMPP) is defined as follows. (This namespace P70L18 name adheres to the format defined in [XML-REG].) P70L19 P70L20 URI: urn:ietf:params:xml:ns:xmpp-bind P70L21 Specification: RFC 3920 P70L22 Description: This is the XML namespace name for resource binding in P70L23 the Extensible Messaging and Presence Protocol (XMPP) as defined P70L24 by RFC 3920. P70L25 Registrant Contact: IETF, XMPP Working Group, P70L26 P70L27 15.5. XML Namespace Name for Stanza Errors P70L28 P70L29 A URN sub-namespace for stanza-related error data in the Extensible P70L30 Messaging and Presence Protocol (XMPP) is defined as follows. (This P70L31 namespace name adheres to the format defined in [XML-REG].) P70L32 P70L33 URI: urn:ietf:params:xml:ns:xmpp-stanzas P70L34 Specification: RFC 3920 P70L35 Description: This is the XML namespace name for stanza-related error P70L36 data in the Extensible Messaging and Presence Protocol (XMPP) as P70L37 defined by RFC 3920. P70L38 Registrant Contact: IETF, XMPP Working Group, P70L39 P70L40 15.6. Nodeprep Profile of Stringprep P70L41 P70L42 The Nodeprep profile of stringprep is defined under Nodeprep P70L43 (Appendix A). The IANA has registered Nodeprep in the stringprep P70L44 profile registry. P70L45 P70L46 Name of this profile: P70L47 P70L48 Nodeprep P71L1 RFC in which the profile is defined: P71L2 P71L3 RFC 3920 P71L4 P71L5 Indicator whether or not this is the newest version of the profile: P71L6 P71L7 This is the first version of Nodeprep P71L8 P71L9 15.7. Resourceprep Profile of Stringprep P71L10 P71L11 The Resourceprep profile of stringprep is defined under Resourceprep P71L12 (Appendix B). The IANA has registered Resourceprep in the stringprep P71L13 profile registry. P71L14 P71L15 Name of this profile: P71L16 P71L17 Resourceprep P71L18 P71L19 RFC in which the profile is defined: P71L20 P71L21 RFC 3920 P71L22 P71L23 Indicator whether or not this is the newest version of the profile: P71L24 P71L25 This is the first version of Resourceprep P71L26 P71L27 15.8. GSSAPI Service Name P71L28 P71L29 The IANA has registered "xmpp" as a GSSAPI [GSS-API] service name, as P71L30 defined under SASL Definition (Section 6.3). P71L31 P71L32 15.9. Port Numbers P71L33 P71L34 The IANA has registered "xmpp-client" and "xmpp-server" as keywords P71L35 for [TCP] ports 5222 and 5269 respectively. P71L36 P71L37 These ports SHOULD be used for client-to-server and server-to-server P71L38 communications respectively, but their use is OPTIONAL. P71L39 P71L40 16. References P71L41 P71L42 16.1. Normative References P71L43 P71L44 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax P71L45 Specifications: ABNF", RFC 2234, November 1997. P71L46 P71L47 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data P71L48 Encodings", RFC 3548, July 2003. P72L1 [CHARSET] Alvestrand, H., "IETF Policy on Character Sets and P72L2 Languages", BCP 18, RFC 2277, January 1998. P72L3 P72L4 [DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication as P72L5 a SASL Mechanism", RFC 2831, May 2000. P72L6 P72L7 [DNS] Mockapetris, P., "Domain names - implementation and P72L8 specification", STD 13, RFC 1035, November 1987. P72L9 P72L10 [GSS-API] Linn, J., "Generic Security Service Application Program P72L11 Interface Version 2, Update 1", RFC 2743, January 2000. P72L12 P72L13 [HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. P72L14 P72L15 [IDNA] Faltstrom, P., Hoffman, P., and A. Costello, P72L16 "Internationalizing Domain Names in Applications P72L17 (IDNA)", RFC 3490, March 2003. P72L18 P72L19 [IPv6] Hinden, R. and S. Deering, "Internet Protocol Version 6 P72L20 (IPv6) Addressing Architecture", RFC 3513, April 2003. P72L21 P72L22 [LANGTAGS] Alvestrand, H., "Tags for the Identification of P72L23 Languages", BCP 47, RFC 3066, January 2001. P72L24 P72L25 [NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep P72L26 Profile for Internationalized Domain Names (IDN)", RFC P72L27 3491, March 2003. P72L28 P72L29 [RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller, P72L30 "Randomness Recommendations for Security", RFC 1750, P72L31 December 1994. P72L32 P72L33 [SASL] Myers, J., "Simple Authentication and Security Layer P72L34 (SASL)", RFC 2222, October 1997. P72L35 P72L36 [SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for P72L37 specifying the location of services (DNS SRV)", RFC P72L38 2782, February 2000. P72L39 P72L40 [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of P72L41 Internationalized Strings ("stringprep")", RFC 3454, P72L42 December 2002. P72L43 P72L44 [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC P72L45 793, September 1981. P72L46 P72L47 P72L48 P73L1 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate P73L2 Requirement Levels", BCP 14, RFC 2119, March 1997. P73L3 P73L4 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", P73L5 RFC 2246, January 1999. P73L6 P73L7 [UCS2] International Organization for Standardization, P73L8 "Information Technology - Universal Multiple-octet coded P73L9 Character Set (UCS) - Amendment 2: UCS Transformation P73L10 Format 8 (UTF-8)", ISO Standard 10646-1 Addendum 2, P73L11 October 1996. P73L12 P73L13 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO P73L14 10646", STD 63, RFC 3629, November 2003. P73L15 P73L16 [X509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet P73L17 X.509 Public Key Infrastructure Certificate and P73L18 Certificate Revocation List (CRL) Profile", RFC 3280, P73L19 April 2002. P73L20 P73L21 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, P73L22 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C P73L23 REC-xml, October 2000, . P73L24 P73L25 [XML-NAMES] Bray, T., Hollander, D., and A. Layman, "Namespaces in P73L26 XML", W3C REC-xml-names, January 1999, P73L27 . P73L28 P73L29 16.2. Informative References P73L30 P73L31 [ACAP] Newman, C. and J. Myers, "ACAP -- Application P73L32 Configuration Access Protocol", RFC 2244, November 1997. P73L33 P73L34 [ASN.1] CCITT, "Recommendation X.208: Specification of Abstract P73L35 Syntax Notation One (ASN.1)", 1988. P73L36 P73L37 [DNSSEC] Eastlake 3rd, D., "Domain Name System Security P73L38 Extensions", RFC 2535, March 1999. P73L39 P73L40 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., P73L41 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext P73L42 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. P73L43 P73L44 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION P73L45 4rev1", RFC 3501, March 2003. P73L46 P73L47 P73L48 P74L1 [IMP-REQS] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, P74L2 "Instant Messaging / Presence Protocol Requirements", P74L3 RFC 2779, February 2000. P74L4 P74L5 [IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat P74L6 Protocol", RFC 1459, May 1993. P74L7 P74L8 [JEP-0029] Kaes, C., "Definition of Jabber Identifiers (JIDs)", JSF P74L9 JEP 0029, October 2003. P74L10 P74L11 [JEP-0078] Saint-Andre, P., "Non-SASL Authentication", JSF JEP P74L12 0078, July 2004. P74L13 P74L14 [JEP-0086] Norris, R. and P. Saint-Andre, "Error Condition P74L15 Mappings", JSF JEP 0086, February 2004. P74L16 P74L17 [JSF] Jabber Software Foundation, "Jabber Software P74L18 Foundation", . P74L19 P74L20 [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version P74L21 3", STD 53, RFC 1939, May 1996. P74L22 P74L23 [SIMPLE] SIMPLE Working Group, "SIMPLE WG", P74L24 . P74L25 P74L26 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, P74L27 April 2001. P74L28 P74L29 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform P74L30 Resource Identifiers (URI): Generic Syntax", RFC 2396, P74L31 August 1998. P74L32 P74L33 [USINGTLS] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC P74L34 2595, June 1999. P74L35 P74L36 [XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, P74L37 January 2004. P74L38 P74L39 [XMPP-IM] Saint-Andre, P., Ed., "Extensible Messaging and Presence P74L40 Protocol (XMPP): Instant Messaging and Presence", RFC P74L41 3921, October 2004. P74L42 P74L43 P74L44 P74L45 P74L46 P74L47 P74L48 P75L1 Appendix A. Nodeprep P75L2 P75L3 A.1. Introduction P75L4 P75L5 This appendix defines the "Nodeprep" profile of [STRINGPREP]. As P75L6 such, it specifies processing rules that will enable users to enter P75L7 internationalized node identifiers in the Extensible Messaging and P75L8 Presence Protocol (XMPP) and have the highest chance of getting the P75L9 content of the strings correct. (An XMPP node identifier is the P75L10 optional portion of an XMPP address that precedes a domain identifier P75L11 and the '@' separator; it is often but not exclusively associated P75L12 with an instant messaging username.) These processing rules are P75L13 intended only for XMPP node identifiers and are not intended for P75L14 arbitrary text or any other aspect of an XMPP address. P75L15 P75L16 This profile defines the following, as required by [STRINGPREP]: P75L17 P75L18 o The intended applicability of the profile: internationalized node P75L19 identifiers within XMPP P75L20 o The character repertoire that is the input and output to P75L21 stringprep: Unicode 3.2, specified in Section 2 of this Appendix P75L22 o The mappings used: specified in Section 3 P75L23 o The Unicode normalization used: specified in Section 4 P75L24 o The characters that are prohibited as output: specified in Section P75L25 5 P75L26 o Bidirectional character handling: specified in Section 6 P75L27 P75L28 A.2. Character Repertoire P75L29 P75L30 This profile uses Unicode 3.2 with the list of unassigned code points P75L31 being Table A.1, both defined in Appendix A of [STRINGPREP]. P75L32 P75L33 A.3. Mapping P75L34 P75L35 This profile specifies mapping using the following tables from P75L36 [STRINGPREP]: P75L37 P75L38 Table B.1 P75L39 Table B.2 P75L40 P75L41 A.4. Normalization P75L42 P75L43 This profile specifies the use of Unicode normalization form KC, as P75L44 described in [STRINGPREP]. P75L45 P75L46 P75L47 P75L48 P76L1 A.5. Prohibited Output P76L2 P76L3 This profile specifies the prohibition of using the following tables P76L4 from [STRINGPREP]. P76L5 P76L6 Table C.1.1 P76L7 Table C.1.2 P76L8 Table C.2.1 P76L9 Table C.2.2 P76L10 Table C.3 P76L11 Table C.4 P76L12 Table C.5 P76L13 Table C.6 P76L14 Table C.7 P76L15 Table C.8 P76L16 Table C.9 P76L17 P76L18 In addition, the following Unicode characters are also prohibited: P76L19 P76L20 #x22 (") P76L21 #x26 (&) P76L22 #x27 (') P76L23 #x2F (/) P76L24 #x3A (:) P76L25 #x3C (<) P76L26 #x3E (>) P76L27 #x40 (@) P76L28 P76L29 A.6. Bidirectional Characters P76L30 P76L31 This profile specifies the checking of bidirectional strings, as P76L32 described in Section 6 of [STRINGPREP]. P76L33 P76L34 Appendix B. Resourceprep P76L35 P76L36 B.1. Introduction P76L37 P76L38 This appendix defines the "Resourceprep" profile of [STRINGPREP]. As P76L39 such, it specifies processing rules that will enable users to enter P76L40 internationalized resource identifiers in the Extensible Messaging P76L41 and Presence Protocol (XMPP) and have the highest chance of getting P76L42 the content of the strings correct. (An XMPP resource identifier is P76L43 the optional portion of an XMPP address that follows a domain P76L44 identifier and the '/' separator; it is often but not exclusively P76L45 associated with an instant messaging session name.) These processing P76L46 rules are intended only for XMPP resource identifiers and are not P76L47 intended for arbitrary text or any other aspect of an XMPP address. P76L48 P77L1 This profile defines the following, as required by [STRINGPREP]: P77L2 P77L3 o The intended applicability of the profile: internationalized P77L4 resource identifiers within XMPP P77L5 P77L6 o The character repertoire that is the input and output to P77L7 stringprep: Unicode 3.2, specified in Section 2 of this Appendix P77L8 P77L9 o The mappings used: specified in Section 3 P77L10 P77L11 o The Unicode normalization used: specified in Section 4 P77L12 P77L13 o The characters that are prohibited as output: specified in Section P77L14 5 P77L15 P77L16 o Bidirectional character handling: specified in Section 6 P77L17 P77L18 B.2. Character Repertoire P77L19 P77L20 This profile uses Unicode 3.2 with the list of unassigned code points P77L21 being Table A.1, both defined in Appendix A of [STRINGPREP]. P77L22 P77L23 B.3. Mapping P77L24 P77L25 This profile specifies mapping using the following tables from P77L26 [STRINGPREP]: P77L27 P77L28 Table B.1 P77L29 P77L30 B.4. Normalization P77L31 P77L32 This profile specifies using Unicode normalization form KC, as P77L33 described in [STRINGPREP]. P77L34 P77L35 P77L36 P77L37 P77L38 P77L39 P77L40 P77L41 P77L42 P77L43 P77L44 P77L45 P77L46 P77L47 P77L48 P78L1 B.5. Prohibited Output P78L2 P78L3 This profile specifies prohibiting use of the following tables from P78L4 [STRINGPREP]. P78L5 P78L6 Table C.1.2 P78L7 Table C.2.1 P78L8 Table C.2.2 P78L9 Table C.3 P78L10 Table C.4 P78L11 Table C.5 P78L12 Table C.6 P78L13 Table C.7 P78L14 Table C.8 P78L15 Table C.9 P78L16 P78L17 B.6. Bidirectional Characters P78L18 P78L19 This profile specifies checking bidirectional strings as described in P78L20 Section 6 of [STRINGPREP]. P78L21 P78L22 Appendix C. XML Schemas P78L23 P78L24 The following XML schemas are descriptive, not normative. For P78L25 schemas defining the 'jabber:client' and 'jabber:server' namespaces, P78L26 refer to [XMPP-IM]. P78L27 P78L28 C.1. Streams namespace P78L29 P78L30 P78L31 P78L32 P78L37 P78L38 P78L39 P78L40 P78L43 P78L44 P78L47 P79L2 P79L3 P79L4 P79L5 P79L6 P79L7 P79L8 P79L9 P79L10 P79L11 P79L12 P79L13 P79L14 P79L15 P79L16 P79L17 P79L18 P79L19 P79L20 P79L21 P79L22 P79L23 P79L24 P79L25 P79L26 P79L27 P79L28 P79L32 P79L33 P79L34 P79L35 P79L36 P79L37 P79L38 P79L39 P79L40 P79L41 P79L42 P79L43 P79L44 P79L47 P79L48 P80L1 P80L2 P80L3 P80L4 P80L5 C.2. Stream error namespace P80L6 P80L7 P80L8 P80L9 P80L14 P80L15 P80L16 P80L17 P80L18 P80L19 P80L20 P80L21 P80L22 P80L23 P80L24 P80L25 P80L26 P80L27 P80L28 P80L29 P80L30 P80L31 P80L32 P80L33 P80L34 P80L35 P80L36 P80L37 P80L38 P80L39 P80L40 P80L41 P80L42 P80L43 P80L44 P80L45 P80L46 P80L47 P80L48 P81L1 P81L2 P81L3 P81L4 P81L5 P81L6 P81L7 P81L8 P81L9 P81L10 P81L11 P81L12 P81L13 P81L14 P81L15 P81L16 P81L17 P81L18 P81L19 P81L20 P81L21 P81L22 P81L23 P81L24 P81L25 P81L26 P81L27 P81L28 P81L29 P81L30 P81L31 P81L32 P81L33 P81L34 P81L35 P81L36 P81L37 P81L38 P81L39 C.3. TLS namespace P81L40 P81L41 P81L42 P81L43 P81L48 P82L1 P82L2 P82L3 P82L4 P82L9 P82L10 P82L11 P82L12 P82L13 P82L14 P82L15 P82L16 P82L17 P82L18 P82L19 P82L20 P82L21 P82L22 P82L23 P82L24 C.4. SASL namespace P82L25 P82L26 P82L27 P82L28 P82L33 P82L34 P82L35 P82L36 P82L37 P82L40 P82L41 P82L42 P82L43 P82L44 P82L45 P82L46 P82L47 P82L48 P83L3 P83L4 P83L5 P83L6 P83L7 P83L8 P83L9 P83L10 P83L11 P83L12 P83L13 P83L14 P83L15 P83L16 P83L17 P83L18 P83L19 P83L20 P83L21 P83L22 P83L23 P83L24 P83L25 P83L26 P83L27 P83L28 P83L29 P83L30 P83L31 P83L32 P83L33 P83L34 C.5. Resource binding namespace P83L35 P83L36 P83L37 P83L38 P83L43 P83L44 P83L45 P83L46 P83L47 P83L48 P84L1 P84L2 P84L3 P84L4 P84L5 P84L6 P84L7 C.6. Dialback namespace P84L8 P84L9 P84L10 P84L11 P84L16 P84L17 P84L18 P84L19 P84L20 P84L21 P84L22 P84L23 P84L24 P84L25 P84L26 P84L27 P84L28 P84L29 P84L30 P84L31 P84L32 P84L33 P84L34 P84L35 P84L36 P84L37 P84L38 P84L39 P84L40 P84L41 P84L42 P84L43 P84L44 P84L45 P84L46 P84L47 P84L48 P85L1 P85L2 P85L3 P85L4 P85L5 P85L6 P85L7 P85L8 P85L9 P85L10 C.7. Stanza error namespace P85L11 P85L12 P85L13 P85L14 P85L19 P85L20 P85L21 P85L22 P85L23 P85L24 P85L25 P85L26 P85L27 P85L28 P85L29 P85L30 P85L31 P85L32 P85L33 P85L34 P85L35 P85L36 P85L37 P85L38 P85L39 P85L40 P85L41 P85L42 P85L43 P85L44 P85L45 P85L46 P85L47 P85L48 P86L1 P86L2 P86L3 P86L4 P86L5 P86L6 P86L7 P86L8 P86L9 P86L10 P86L11 P86L12 P86L13 P86L14 P86L15 P86L16 P86L17 P86L18 P86L19 P86L20 P86L21 P86L22 P86L23 P86L24 P86L25 P86L26 P86L27 P86L28 P86L29 P86L30 P86L31 P86L32 P86L33 P86L34 P86L35 P86L36 P86L37 P86L38 P86L39 P86L40 P86L41 P86L42 P86L43 P86L44 P86L45 P86L46 P86L47 P86L48 P87L1 Appendix D. Differences Between Core Jabber Protocols and XMPP P87L2 P87L3 This section is non-normative. P87L4 P87L5 XMPP has been adapted from the protocols originally developed in the P87L6 Jabber open-source community, which can be thought of as "XMPP 0.9". P87L7 Because there exists a large installed base of Jabber implementations P87L8 and deployments, it may be helpful to specify the key differences P87L9 between the relevant Jabber protocols and XMPP in order to expedite P87L10 and encourage upgrades of those implementations and deployments to P87L11 XMPP. This section summarizes the core differences, while the P87L12 corresponding section of [XMPP-IM] summarizes the differences that P87L13 relate specifically to instant messaging and presence applications. P87L14 P87L15 D.1. Channel Encryption P87L16 P87L17 It was common practice in the Jabber community to use SSL for channel P87L18 encryption on ports other than 5222 and 5269 (the convention is to P87L19 use ports 5223 and 5270). XMPP uses TLS over the IANA-registered P87L20 ports for channel encryption, as defined under Use of TLS (Section 5) P87L21 herein. P87L22 P87L23 D.2. Authentication P87L24 P87L25 The client-server authentication protocol developed in the Jabber P87L26 community used a basic IQ interaction qualified by the P87L27 'jabber:iq:auth' namespace (documentation of this protocol is P87L28 contained in [JEP-0078], published by the Jabber Software Foundation P87L29 [JSF]). XMPP uses SASL for authentication, as defined under Use of P87L30 SASL (Section 6) herein. P87L31 P87L32 The Jabber community did not develop an authentication protocol for P87L33 server-to-server communications, only the Server Dialback (Section 8) P87L34 protocol to prevent server spoofing. XMPP supersedes Server Dialback P87L35 with a true server-to-server authentication protocol, as defined P87L36 under Use of SASL (Section 6) herein. P87L37 P87L38 D.3. Resource Binding P87L39 P87L40 Resource binding in the Jabber community was handled via the P87L41 'jabber:iq:auth' namespace (which was also used for client P87L42 authentication with a server). XMPP defines a dedicated namespace P87L43 for resource binding as well as the ability for a server to generate P87L44 a resource identifier on behalf of a client, as defined under P87L45 Resource Binding (Section 7). P87L46 P87L47 P87L48 P88L1 D.4. JID Processing P88L2 P88L3 JID processing was somewhat loosely defined by the Jabber community P88L4 (documentation of forbidden characters and case handling is contained P88L5 in [JEP-0029], published by the Jabber Software Foundation [JSF]). P88L6 XMPP specifies the use of [NAMEPREP] for domain identifiers and P88L7 supplements Nameprep with two additional [STRINGPREP] profiles for P88L8 JID processing: Nodeprep (Appendix A) for node identifiers and P88L9 Resourceprep (Appendix B) for resource identifiers. P88L10 P88L11 D.5. Error Handling P88L12 P88L13 Stream-related errors were handled in the Jabber community via XML P88L14 character data text in a element. In XMPP, P88L15 stream-related errors are handled via an extensible mechanism defined P88L16 under Stream Errors (Section 4.7) herein. P88L17 P88L18 Stanza-related errors were handled in the Jabber community via P88L19 HTTP-style error codes. In XMPP, stanza-related errors are handled P88L20 via an extensible mechanism defined under Stanza Errors (Section 9.3) P88L21 herein. (Documentation of a mapping between Jabber and XMPP error P88L22 handling mechanisms is contained in [JEP-0086], published by the P88L23 Jabber Software Foundation [JSF].) P88L24 P88L25 D.6. Internationalization P88L26 P88L27 Although use of UTF-8 has always been standard practice within the P88L28 Jabber community, the community did not define mechanisms for P88L29 specifying the language of human-readable text provided in XML P88L30 character data. XMPP specifies the use of the 'xml:lang' attribute P88L31 in such contexts, as defined under Stream Attributes (Section 4.4) P88L32 and xml:lang (Section 9.1.5) herein. P88L33 P88L34 D.7. Stream Version Attribute P88L35 P88L36 The Jabber community did not include a 'version' attribute in stream P88L37 headers. XMPP specifies inclusion of that attribute as a way to P88L38 signal support for the stream features (authentication, encryption, P88L39 etc.) defined under Version Support (Section 4.4.1) herein. P88L40 P88L41 P88L42 P88L43 P88L44 P88L45 P88L46 P88L47 P88L48 P89L1 Contributors P89L2 P89L3 Most of the core aspects of the Extensible Messaging and Presence P89L4 Protocol were developed originally within the Jabber open-source P89L5 community in 1999. This community was founded by Jeremie Miller, who P89L6 released source code for the initial version of the jabber server in P89L7 January 1999. Major early contributors to the base protocol also P89L8 included Ryan Eatmon, Peter Millard, Thomas Muldowney, and Dave P89L9 Smith. Work by the XMPP Working Group has concentrated especially on P89L10 security and internationalization; in these areas, protocols for the P89L11 use of TLS and SASL were originally contributed by Rob Norris, and P89L12 stringprep profiles were originally contributed by Joe Hildebrand. P89L13 The error code syntax was suggested by Lisa Dusseault. P89L14 P89L15 Acknowledgements P89L16 P89L17 Thanks are due to a number of individuals in addition to the P89L18 contributors listed. Although it is difficult to provide a complete P89L19 list, the following individuals were particularly helpful in defining P89L20 the protocols or in commenting on the specifications in this memo: P89L21 Thomas Charron, Richard Dobson, Sam Hartman, Schuyler Heath, Jonathan P89L22 Hogg, Cullen Jennings, Craig Kaes, Jacek Konieczny, Alexey Melnikov, P89L23 Keith Minkler, Julian Missig, Pete Resnick, Marshall Rose, Alexey P89L24 Shchepin, Jean-Louis Seguineau, Iain Shigeoka, Greg Troxel, and David P89L25 Waite. Thanks also to members of the XMPP Working Group and the IETF P89L26 community for comments and feedback provided throughout the life of P89L27 this memo. P89L28 P89L29 Author's Address P89L30 P89L31 Peter Saint-Andre (editor) P89L32 Jabber Software Foundation P89L33 P89L34 EMail: stpeter@jabber.org P89L35 P89L36 P89L37 P89L38 P89L39 P89L40 P89L41 P89L42 P89L43 P89L44 P89L45 P89L46 P89L47 P89L48 P90L1 Full Copyright Statement P90L2 P90L3 Copyright (C) The Internet Society (2004). P90L4 P90L5 This document is subject to the rights, licenses and restrictions P90L6 contained in BCP 78, and except as set forth therein, the authors P90L7 retain all their rights. P90L8 P90L9 This document and the information contained herein are provided on an P90L10 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE P90L11 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE P90L12 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR P90L13 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF P90L14 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED P90L15 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. P90L16 P90L17 Intellectual Property P90L18 P90L19 The IETF takes no position regarding the validity or scope of any P90L20 Intellectual Property Rights or other rights that might be claimed to P90L21 pertain to the implementation or use of the technology described in P90L22 this document or the extent to which any license under such rights P90L23 might or might not be available; nor does it represent that it has P90L24 made any independent effort to identify any such rights. Information P90L25 on the IETF's procedures with respect to rights in IETF Documents can P90L26 be found in BCP 78 and BCP 79. P90L27 P90L28 Copies of IPR disclosures made to the IETF Secretariat and any P90L29 assurances of licenses to be made available, or the result of an P90L30 attempt made to obtain a general license or permission for the use of P90L31 such proprietary rights by implementers or users of this P90L32 specification can be obtained from the IETF on-line IPR repository at P90L33 http://www.ietf.org/ipr. P90L34 P90L35 The IETF invites any interested party to bring to its attention any P90L36 copyrights, patents or patent applications, or other proprietary P90L37 rights that may cover technology that may be required to implement P90L38 this standard. Please address the information to the IETF at ietf- P90L39 ipr@ietf.org. P90L40 P90L41 Acknowledgement P90L42 P90L43 Funding for the RFC Editor function is currently provided by the P90L44 Internet Society. P90L45 P90L46 P90L47 P90L48