in the ’to’ attribute does not match one of the configured hostnames
of the server itself or a subdomain thereof, the server SHOULD route
the stanza to the foreign domain (subject to local service
provisioning and security policies regarding inter-domain
communication). There are two possible cases:
A server-to-server stream already exists between the two domains: The
sender’s server routes the stanza to the authoritative server for
the foreign domain over the existing stream
There exists no server-to-server stream between the two domains: The
sender’s server (1) resolves the hostname of the foreign domain
(as defined under Server-to-Server Communications (Section 14.4)),
(2) negotiates a server-to-server stream between the two domains
(as defined under Use of TLS (Section 5) and Use of SASL (Section
6)), and (3) routes the stanza to the authoritative server for the
foreign domain over the newly-established stream
If routing to the recipient’s server is unsuccessful, the sender’s
server MUST return an error to the sender; if the recipient’s server
can be contacted but delivery by the recipient’s server to the
recipient is unsuccessful, the recipient’s server MUST return an
error to the sender by way of the sender’s server.
10.3. Subdomain
If the hostname of the domain identifier portion of the JID contained
in the ’to’ attribute matches a subdomain of one of the configured
hostnames of the server itself, the server MUST either process the
stanza itself or route the stanza to a specialized service that is
responsible for that subdomain (if the subdomain is configured), or
return an error to the sender (if the subdomain is not configured).
10.4. Mere Domain or Specific Resource
If the hostname of the domain identifier portion of the JID contained
in the ’to’ attribute matches a configured hostname of the server
itself and the JID contained in the ’to’ attribute is of the form
<domain> or <domain/resource>, the server (or a defined resource
thereof) MUST either process the stanza as appropriate for the stanza
kind or return an error stanza to the sender.
10.5. Node in Same Domain
If the hostname of the domain identifier portion of the JID contained
in the ’to’ attribute matches a configured hostname of the server
itself and the JID contained in the ’to’ attribute is of the form
<node@domain> or <node@domain/resource>, the server SHOULD deliver
the stanza to the intended recipient of the stanza as represented by
the JID contained in the ’to’ attribute. The following rules apply:
1. If the JID contains a resource identifier (i.e., is of the form
<node@domain/resource>) and there exists a connected resource
that matches the full JID, the recipient’s server SHOULD deliver
the stanza to the stream or session that exactly matches the
resource identifier.
2. If the JID contains a resource identifier and there exists no
connected resource that matches the full JID, the recipient’s
server SHOULD return a <service-unavailable/> stanza error to the
sender.
3. If the JID is of the form <node@domain> and there exists at least
one connected resource for the node, the recipient’s server
SHOULD deliver the stanza to at least one of the connected
resources, according to application-specific rules (a set of
delivery rules for instant messaging and presence applications is
defined in [XMPP-IM]).
11. XML Usage within XMPP
11.1. Restrictions
XMPP is a simplified and specialized protocol for streaming XML
elements in order to exchange structured information in close to real
time. Because XMPP does not require the parsing of arbitrary and
complete XML documents, there is no requirement that XMPP needs to
support the full feature set of [XML]. In particular, the following
restrictions apply.
With regard to XML generation, an XMPP implementation MUST NOT inject
into an XML stream any of the following:
o comments (as defined in Section 2.5 of [XML])
o processing instructions (Section 2.6 therein)
o internal or external DTD subsets (Section 2.8 therein)
o internal or external entity references (Section 4.2 therein) with
the exception of predefined entities (Section 4.6 therein)
o character data or attribute values containing unescaped characters
that map to the predefined entities (Section 4.6 therein); such
characters MUST be escaped
With regard to XML processing, if an XMPP implementation receives
such restricted XML data, it MUST ignore the data.
11.2. XML Namespace Names and Prefixes
XML Namespaces [XML-NAMES] are used within all XMPP-compliant XML to
create strict boundaries of data ownership. The basic function of
namespaces is to separate different vocabularies of XML elements that
are structurally mixed together. Ensuring that XMPP-compliant XML is
namespace-aware enables any allowable XML to be structurally mixed
with any data element within XMPP. Rules for XML namespace names and
prefixes are defined in the following subsections.
11.2.1. Streams Namespace
A streams namespace declaration is REQUIRED in all XML stream
headers. The name of the streams namespace MUST be
’http://etherx.jabber.org/streams’. The element names of the
<stream/> element and its <features/> and <error/> children MUST be
qualified by the streams namespace prefix in all instances. An
implementation SHOULD generate only the ’stream:’ prefix for these
elements, and for historical reasons MAY accept only the ’stream:’
prefix.
11.2.2. Default Namespace
A default namespace declaration is REQUIRED and is used in all XML
streams in order to define the allowable first-level children of the
root stream element. This namespace declaration MUST be the same for
the initial stream and the response stream so that both streams are
qualified consistently. The default namespace declaration applies to
the stream and all stanzas sent within a stream (unless explicitly
qualified by another namespace, or by the prefix of the streams
namespace or the dialback namespace).
A server implementation MUST support the following two default
namespaces (for historical reasons, some implementations MAY support
only these two default namespaces):
o jabber:client -- this default namespace is declared when the
stream is used for communications between a client and a server
o jabber:server -- this default namespace is declared when the
stream is used for communications between two servers
A client implementation MUST support the ’jabber:client’ default
namespace, and for historical reasons MAY support only that default
namespace.
An implementation MUST NOT generate namespace prefixes for elements
in the default namespace if the default namespace is ’jabber:client’
or ’jabber:server’. An implementation SHOULD NOT generate namespace
prefixes for elements qualified by content (as opposed to stream)
namespaces other than ’jabber:client’ and ’jabber:server’.
Note: The ’jabber:client’ and ’jabber:server’ namespaces are nearly
identical but are used in different contexts (client-to-server
communications for ’jabber:client’ and server-to-server
communications for ’jabber:server’). The only difference between the
two is that the ’to’ and ’from’ attributes are OPTIONAL on stanzas
sent within ’jabber:client’, whereas they are REQUIRED on stanzas
sent within ’jabber:server’. If a compliant implementation accepts a
stream that is qualified by the ’jabber:client’ or ’jabber:server’
namespace, it MUST support the common attributes (Section 9.1) and
basic semantics (Section 9.2) of all three core stanza kinds
(message, presence, and IQ).
11.2.3. Dialback Namespace
A dialback namespace declaration is REQUIRED for all elements used in
server dialback (Section 8). The name of the dialback namespace MUST
be ’jabber:server:dialback’. All elements qualified by this
namespace MUST be prefixed. An implementation SHOULD generate only
the ’db:’ prefix for such elements and MAY accept only the ’db:’
prefix.
11.3. Validation
Except as noted with regard to ’to’ and ’from’ addresses for stanzas
within the ’jabber:server’ namespace, a server is not responsible for
validating the XML elements forwarded to a client or another server;
an implementation MAY choose to provide only validated data elements
but this is OPTIONAL (although an implementation MUST NOT accept XML
that is not well-formed). Clients SHOULD NOT rely on the ability to
send data which does not conform to the schemas, and SHOULD ignore
any non-conformant elements or attributes on the incoming XML stream.
Validation of XML streams and stanzas is OPTIONAL, and schemas are
included herein for descriptive purposes only.
11.4. Inclusion of Text Declaration
Implementations SHOULD send a text declaration before sending a
stream header. Applications MUST follow the rules in [XML] regarding
the circumstances under which a text declaration is included.
11.5. Character Encoding
Implementations MUST support the UTF-8 (RFC 3629 [UTF-8])
transformation of Universal Character Set (ISO/IEC 10646-1 [UCS2])
characters, as required by RFC 2277 [CHARSET]. Implementations MUST
NOT attempt to use any other encoding.
12. Core Compliance Requirements
This section summarizes the specific aspects of the Extensible
Messaging and Presence Protocol that MUST be supported by servers and
clients in order to be considered compliant implementations, as well
as additional protocol aspects that SHOULD be supported. For
compliance purposes, we draw a distinction between core protocols
(which MUST be supported by any server or client, regardless of the
specific application) and instant messaging protocols (which MUST be
supported only by instant messaging and presence applications built
on top of the core protocols). Compliance requirements that apply to
all servers and clients are specified in this section; compliance
requirements for instant messaging servers and clients are specified
in the corresponding section of [XMPP-IM].
12.1. Servers
In addition to all defined requirements with regard to security, XML
usage, and internationalization, a server MUST support the following
core protocols in order to be considered compliant:
o Application of the [NAMEPREP], Nodeprep (Appendix A), and
Resourceprep (Appendix B) profiles of [STRINGPREP] to addresses
(including ensuring that domain identifiers are internationalized
domain names as defined in [IDNA])
o XML streams (Section 4), including Use of TLS (Section 5), Use of
SASL (Section 6), and Resource Binding (Section 7)
o The basic semantics of the three defined stanza kinds (i.e.,
<message/>, <presence/>, and <iq/>) as specified in stanza
semantics (Section 9.2)
o Generation (and, where appropriate, handling) of error syntax and
semantics related to streams, TLS, SASL, and XML stanzas
In addition, a server MAY support the following core protocol:
o Server dialback (Section 8)
12.2. Clients
A client MUST support the following core protocols in order to be
considered compliant:
o XML streams (Section 4), including Use of TLS (Section 5), Use of
SASL (Section 6), and Resource Binding (Section 7)
o The basic semantics of the three defined stanza kinds (i.e.,
<message/>, <presence/>, and <iq/>) as specified in stanza
semantics (Section 9.2)
o Handling (and, where appropriate, generation) of error syntax and
semantics related to streams, TLS, SASL, and XML stanzas
In addition, a client SHOULD support the following core protocols:
o Generation of addresses to which the [NAMEPREP], Nodeprep
(Appendix A), and Resourceprep (Appendix B) profiles of
[STRINGPREP] can be applied without failing
13. Internationalization Considerations
XML streams MUST be encoded in UTF-8 as specified under Character
Encoding (Section 11.5). As specified under Stream Attributes
(Section 4.4), an XML stream SHOULD include an ’xml:lang’ attribute
that is treated as the default language for any XML character data
sent over the stream that is intended to be presented to a human
user. As specified under xml:lang (Section 9.1.5), an XML stanza
SHOULD include an ’xml:lang’ attribute if the stanza contains XML
character data that is intended to be presented to a human user. A
server SHOULD apply the default ’xml:lang’ attribute to stanzas it
routes or delivers on behalf of connected entities, and MUST NOT
modify or delete ’xml:lang’ attributes from stanzas it receives from
other entities.
14. Security Considerations
14.1. High Security
For the purposes of XMPP communications (client-to-server and
server-to-server), the term "high security" refers to the use of
security technologies that provide both mutual authentication and
integrity-checking; in particular, when using certificate-based
authentication to provide high security, a chain-of-trust SHOULD be
established out-of-band, although a shared certificate authority
signing certificates could allow a previously unknown certificate to
establish trust in-band. See Section 14.2 below regarding
certificate validation procedures.
Implementations MUST support high security. Service provisioning
SHOULD use high security, subject to local security policies.
14.2. Certificate Validation
When an XMPP peer communicates with another peer securely, it MUST
validate the peer’s certificate. There are three possible cases:
Case #1: The peer contains an End Entity certificate which appears to
be certified by a chain of certificates terminating in a trust
anchor (as described in Section 6.1 of [X509]).
Case #2: The peer certificate is certified by a Certificate Authority
not known to the validating peer.
Case #3: The peer certificate is self-signed.
In Case #1, the validating peer MUST do one of two things:
1. Verify the peer certificate according to the rules of [X509].
The certificate SHOULD then be checked against the expected
identity of the peer following the rules described in [HTTP-TLS],
except that a subjectAltName extension of type "xmpp" MUST be
used as the identity if present. If one of these checks fails,
user-oriented clients MUST either notify the user (clients MAY
give the user the opportunity to continue with the connection in
any case) or terminate the connection with a bad certificate
error. Automated clients SHOULD terminate the connection (with a
bad certificate error) and log the error to an appropriate audit
log. Automated clients MAY provide a configuration setting that
disables this check, but MUST provide a setting that enables it.
2. The peer SHOULD show the certificate to a user for approval,
including the entire certificate chain. The peer MUST cache the
certificate (or some non-forgeable representation such as a
hash). In future connections, the peer MUST verify that the same
certificate was presented and MUST notify the user if it has
changed.
In Case #2 and Case #3, implementations SHOULD act as in (2) above.
14.3. Client-to-Server Communications
A compliant client implementation MUST support both TLS and SASL for
connections to a server.
The TLS protocol for encrypting XML streams (defined under Use of TLS
(Section 5)) provides a reliable mechanism for helping to ensure the
confidentiality and data integrity of data exchanged between two
entities.
The SASL protocol for authenticating XML streams (defined under Use
of SASL (Section 6)) provides a reliable mechanism for validating
that a client connecting to a server is who it claims to be.
Client-to-server communications MUST NOT proceed until the DNS
hostname asserted by the server has been resolved. Such resolutions
SHOULD first attempt to resolve the hostname using an [SRV] Service
of "xmpp-client" and Proto of "tcp", resulting in resource records
such as "_xmpp-client._tcp.example.com." (the use of the string
"xmpp-client" for the service identifier is consistent with the IANA
registration). If the SRV lookup fails, the fallback is a normal
IPv4/IPv6 address record resolution to determine the IP address,
using the "xmpp-client" port of 5222, registered with the IANA.
The IP address and method of access of clients MUST NOT be made
public by a server, nor are any connections other than the original
server connection required. This helps to protect the client’s
server from direct attack or identification by third parties.
14.4. Server-to-Server Communications
A compliant server implementation MUST support both TLS and SASL for
inter-domain communications. For historical reasons, a compliant
implementation SHOULD also support Server Dialback (Section 8).
Because service provisioning is a matter of policy, it is OPTIONAL
for any given domain to communicate with other domains, and
server-to-server communications MAY be disabled by the administrator
of any given deployment. If a particular domain enables inter-domain
communications, it SHOULD enable high security.
Administrators may want to require use of SASL for server-to-server
communications in order to ensure both authentication and
confidentiality (e.g., on an organization’s private network).
Compliant implementations SHOULD support SASL for this purpose.
Inter-domain connections MUST NOT proceed until the DNS hostnames
asserted by the servers have been resolved. Such resolutions MUST
first attempt to resolve the hostname using an [SRV] Service of
"xmpp-server" and Proto of "tcp", resulting in resource records such
as "_xmpp-server._tcp.example.com." (the use of the string
"xmpp-server" for the service identifier is consistent with the IANA
registration; note well that the "xmpp-server" service identifier
supersedes the earlier use of a "jabber" service identifier, since
the earlier usage did not conform to [SRV]; implementations desiring
to be backward compatible should continue to look for or answer to
the "jabber" service identifier as well). If the SRV lookup fails,
the fallback is a normal IPv4/IPv6 address record resolution to
determine the IP address, using the "xmpp-server" port 5269,
registered with the IANA.
Server dialback helps protect against domain spoofing, thus making it
more difficult to spoof XML stanzas. It is not a mechanism for
authenticating, securing, or encrypting streams between servers as is
done via SASL and TLS, and results in weak verification of server
identities only. Furthermore, it is susceptible to DNS poisoning
attacks unless DNSSec [DNSSEC] is used, and even if the DNS
information is accurate, dialback cannot protect from attacks where
the attacker is capable of hijacking the IP address of the remote
domain. Domains requiring robust security SHOULD use TLS and SASL.
If SASL is used for server-to-server authentication, dialback SHOULD
NOT be used since it is unnecessary.
14.5. Order of Layers
The order of layers in which protocols MUST be stacked is as follows:
1. TCP
2. TLS
3. SASL
4. XMPP
The rationale for this order is that [TCP] is the base connection
layer used by all of the protocols stacked on top of TCP, [TLS] is
often provided at the operating system layer, [SASL] is often
provided at the application layer, and XMPP is the application
itself.
14.6. Lack of SASL Channel Binding to TLS
The SASL framework does not provide a mechanism to bind SASL
authentication to a security layer providing confidentiality and
integrity protection that was negotiated at a lower layer. This lack
of a "channel binding" prevents SASL from being able to verify that
the source and destination end points to which the lower layer’s
security is bound are equivalent to the end points that SASL is
authenticating. If the end points are not identical, the lower
layer’s security cannot be trusted to protect data transmitted
between the SASL authenticated entities. In such a situation, a SASL
security layer should be negotiated that effectively ignores the
presence of the lower layer security.
14.7. Mandatory-to-Implement Technologies
At a minimum, all implementations MUST support the following
mechanisms:
for authentication: the SASL [DIGEST-MD5] mechanism
for confidentiality: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA
cipher)
for both: TLS plus SASL EXTERNAL(using the
TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side
certificates)
14.8. Firewalls
Communications using XMPP normally occur over [TCP] connections on
port 5222 (client-to-server) or port 5269 (server-to-server), as
registered with the IANA (see IANA Considerations (Section 15)). Use
of these well-known ports allows administrators to easily enable or
disable XMPP activity through existing and commonly-deployed
firewalls.
14.9. Use of base64 in SASL
Both the client and the server MUST verify any [BASE64] data received
during SASL negotiation. An implementation MUST reject (not ignore)
any characters that are not explicitly allowed by the base64
alphabet; this helps to guard against creation of a covert channel
that could be used to "leak" information. An implementation MUST NOT
break on invalid input and MUST reject any sequence of base64
characters containing the pad (’=’) character if that character is
included as something other than the last character of the data
(e.g., "=AAA" or "BBBB=CCC"); this helps to guard against buffer
overflow attacks and other attacks on the implementation. Base 64
encoding visually hides otherwise easily recognized information, such
as passwords, but does not provide any computational confidentiality.
Base 64 encoding MUST follow the definition in Section 3 of RFC 3548
[BASE64].
14.10. Stringprep Profiles
XMPP makes use of the [NAMEPREP] profile of [STRINGPREP] for the
processing of domain identifiers; for security considerations related
to Nameprep, refer to the appropriate section of [NAMEPREP].
In addition, XMPP defines two profiles of [STRINGPREP]: Nodeprep
(Appendix A) for node identifiers and Resourceprep (Appendix B) for
resource identifiers.
The Unicode and ISO/IEC 10646 repertoires have many characters that
look similar. In many cases, users of security protocols might do
visual matching, such as when comparing the names of trusted third
parties. Because it is impossible to map similar-looking characters
without a great deal of context, such as knowing the fonts used,
stringprep does nothing to map similar-looking characters together,
nor to prohibit some characters because they look like others.
A node identifier can be employed as one part of an entity’s address
in XMPP. One common usage is as the username of an instant messaging
user; another is as the name of a multi-user chat room; many other
kinds of entities could use node identifiers as part of their
addresses. The security of such services could be compromised based
on different interpretations of the internationalized node
identifier; for example, a user entering a single internationalized
node identifier could access another user’s account information, or a
user could gain access to an otherwise restricted chat room or
service.
A resource identifier can be employed as one part of an entity’s
address in XMPP. One common usage is as the name for an instant
messaging user’s connected resource (active session); another is as
the nickname of a user in a multi-user chat room; many other kinds of
entities could use resource identifiers as part of their addresses.
The security of such services could be compromised based on different
interpretations of the internationalized resource identifier; for
example, a user could attempt to initiate multiple sessions with the
same name, or a user could send a message to someone other than the
intended recipient in a multi-user chat room.
15. IANA Considerations
15.1. XML Namespace Name for TLS Data
A URN sub-namespace for TLS-related data in the Extensible Messaging
and Presence Protocol (XMPP) is defined as follows. (This namespace
name adheres to the format defined in The IETF XML Registry
[XML-REG].)
URI: urn:ietf:params:xml:ns:xmpp-tls
Specification: RFC 3920
Description: This is the XML namespace name for TLS-related data in
the Extensible Messaging and Presence Protocol (XMPP) as defined
by RFC 3920.
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
15.2. XML Namespace Name for SASL Data
A URN sub-namespace for SASL-related data in the Extensible Messaging