Extensible Messaging and Presence Protocol (XMPP): Core
obsoleted by
- rfc-6120 — Extensible Messaging and Presence Protocol (XMPP): Core
updated by
- rfc-6122 — Extensible Messaging and Presence Protocol (XMPP): Address Format
Extracted elements (28)
Server dialback is documented primarily for backward-compatibility with existing Jabber deployments. It is explicitly not a security mechanism and provides only weak domain identity verification. Domains requiring robust security SHOULD use TLS and SASL; when SASL is used for server-to-server authentication, dialback SHOULD NOT be used as it is unnecessary.
The initial stream and response stream MUST be secured separately even though mutual authentication may be negotiated in a single step. This design ensures each direction's security properties are independently established and prevents unverified data from leaking across the TLS/SASL negotiation boundary.
For server-to-server communications, DNS hostnames asserted by both servers MUST be resolved before TLS or SASL negotiations proceed. Certificates during server-to-server TLS MUST also be checked against the asserted hostname rather than the resolved address.
A node identifier MUST be formatted so that the Nodeprep profile of STRINGPREP can be applied without failing. A server MUST (and a client SHOULD) apply Nodeprep before comparing two node identifiers.
A resource identifier MUST be formatted so that the Resourceprep profile of STRINGPREP can be applied without failing. A server MUST (and a client SHOULD) apply Resourceprep before comparing two resource identifiers.
After SASL success, if the server requires resource binding, it MUST advertise an empty <bind/> element (qualified by 'urn:ietf:params:xml:ns:xmpp-bind') in stream features. The client MUST bind a resource via an IQ 'set' stanza; the server MUST be able to generate a unique resource identifier on behalf of the client.
All XML character data within SASL negotiation elements MUST be base64-encoded per RFC 3548 Section 3. A zero-length initial response MUST be transmitted as a single equals sign ('=') to distinguish its presence from absence of data. White space MUST NOT be sent within the stream root element during SASL negotiation.
Each allowable portion of a JID (node identifier, domain identifier, resource identifier) MUST NOT be more than 1023 bytes in length, yielding a maximum total JID size of 3071 bytes including the '@' and '/' separator characters.
If an initiating entity chooses to use TLS, TLS negotiation MUST be completed before proceeding to SASL negotiation. This ordering protects authentication credentials and enables the SASL EXTERNAL mechanism to be based on a certificate presented during TLS.
If TLS negotiation is successful, both the receiving entity and the initiating entity MUST discard any knowledge obtained insecurely from the other entity before TLS took effect, ensuring the post-TLS session state is derived only from secured exchanges.
Stream-level errors are unrecoverable: the detecting entity MUST send a <stream:error> element, send a closing </stream> tag, and terminate the underlying TCP connection. If the error occurs during stream setup, the receiving entity must still send the opening <stream> tag before including the error.
The dialback key generation and verification method MUST take into account the hostnames, the stream ID generated by the receiving server, and a secret known by the authoritative server's network. Because server dialback is uni-directional, it MUST be completed in each direction separately to enable bidirectional server-to-server communications.
The initiating entity MUST validate the TLS certificate presented by the receiving entity. Certificates MUST be checked against the hostname as provided by the initiating entity (user-supplied), not the DNS-resolved hostname — e.g., 'example.com' even when SRV lookup returned 'im.example.com'.
The stream 'id' attribute MUST be unique within the receiving application and MUST be both unpredictable and nonrepeating, because it is security-critical — relied upon by server dialback and used as a session key.
When negotiating XMPP 1.0 streams, TLS SHOULD be used and SASL MUST be used. An entity SHOULD NOT send XML stanzas before stream authentication; if it does, the receiving entity MUST NOT accept such stanzas and SHOULD return <not-authorized/> and terminate the stream and TCP connection.
A Jabber Identifier (JID) consists of an optional node identifier (before '@'), a required domain identifier, and an optional resource identifier (after '/'), forming [node@]domain[/resource]. JIDs are the universal addressing scheme for all XMPP entities and are consistent with RFC 2396 URI syntax.
An XML stream is a container opened by a <stream> element and closed by </stream>; the initiating entity opens the initial stream, and the receiving entity MUST negotiate a response stream in the opposite direction to enable bidirectional exchange. XML stanzas (<message/>, <presence/>, <iq/>) are the discrete semantic units exchanged within streams.
JIDs included in X.509 certificates MUST be encoded as UTF8String within an otherName subjectAltName using ASN.1 OID 'id-on-xmppAddr' (dotted form: 1.3.6.1.5.5.7.8.5). The type is defined as XmppAddr ::= UTF8String.
Seven SASL error conditions are defined: <aborted/>, <incorrect-encoding/>, <invalid-authzid/>, <invalid-mechanism/>, <mechanism-too-weak/>, <not-authorized/>, and <temporary-auth-failure/>, all qualified by 'urn:ietf:params:xml:ns:xmpp-sasl'. On abort or failure the server SHOULD allow at least 2 retries before terminating the TCP connection.
Twenty-three stream-level error conditions are defined including <bad-format/>, <not-authorized/>, <conflict/>, <invalid-xml/>, <xml-not-well-formed/>, <unsupported-version/>, and <see-other-host/>. All conditions are qualified by 'urn:ietf:params:xml:ns:xmpp-streams'.
When the 'version' attribute is at least '1.0', the receiving entity MUST send a <features/> element (prefixed by the streams namespace) to advertise negotiable capabilities such as STARTTLS, SASL mechanisms, and resource binding. Non-security features SHOULD NOT be advertised before required security features are successfully negotiated.
IANA registers TCP port 5222 as the RECOMMENDED port for XMPP client-to-server connections and TCP port 5269 as the RECOMMENDED port for XMPP server-to-server connections.
The stream ID is security-critical for session management and server dialback; it MUST be both unpredictable and nonrepeating. Implementations SHOULD follow RFC 1750 (or successor) randomness recommendations. Weak or predictable stream IDs expose connections to session hijacking and dialback forgery.
TLS with certificate validation combined with SASL (preferably SASL EXTERNAL using the TLS certificate) provides the strongest XMPP security model. Server dialback relies on DNS and is susceptible to DNS spoofing; it MUST NOT be considered a substitute for TLS+SASL in environments requiring strong identity assurance.
SASL negotiation: receiving entity advertises mechanisms in <mechanisms/> → initiating entity sends <auth mechanism='...'> optionally with initial response → exchange of <challenge/>/<response/> pairs → receiving entity sends <success/> (with optional data) or <failure/> → upon <success/>, both entities MUST consider the original stream closed and initiating entity MUST restart the stream.
STARTTLS negotiation: initiating entity sends <starttls/> → receiving entity responds with <proceed/> (entities MUST complete TLS handshake, sending no further XML until done) or <failure/> (close stream and TCP) → on TLS success, initiating entity MUST restart the stream with a new opening header; receiving entity MUST NOT re-offer STARTTLS.
A <stream:error> element MUST contain one defined error condition child qualified by 'urn:ietf:params:xml:ns:xmpp-streams', MAY contain a <text/> child with human-readable detail (with xml:lang), and MAY contain an application-specific condition element in a custom namespace.
The opening <stream> element carries five attributes: 'to' (receiver hostname, set by initiator), 'from' (receiver hostname, set by receiver), 'id' (unique session key, set by receiver), 'xml:lang' (default natural language), and 'version' (e.g., '1.0' signals XMPP 1.0 stream feature support).