moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

rewrote introduction

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1987 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-06-17 18:05:50 +00:00
parent eb622ce41c
commit 947fc5a196
1 changed files with 85 additions and 53 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

138
xep-0220.xml
View File

@ -7,7 +7,7 @@
<xep>
<header>
<title>Server Dialback</title>
<abstract>This specification defines the server dialback protocol, which is used between XMPP servers to provide identity verification. Server dialback uses the Domain Name System (DNS) as the basis for verifying identity; the basic approach is that when a receiving server receives a server-to-server connection requesting from an originating server, it does not accept the request until it has verified a key with an authoritative server for the domain asserted by the originating server. Although server dialback does not provide strong authentication or trusted federation and although it is subject to DNS poisoning attacks, since its development in the year 2000 it has effectively prevented most instances of address spoofing on the XMPP network.</abstract>
<abstract>This specification defines the Server Dialback protocol, which is used between XMPP servers to provide identity verification. Server dialback uses the Domain Name System (DNS) as the basis for verifying identity; the basic approach is that when a receiving server receives a server-to-server connection requesting from an originating server, it does not accept the request until it has verified a key with an authoritative server for the domain asserted by the originating server. Although Server Dialback does not provide strong authentication or trusted federation and although it is subject to DNS poisoning attacks, since its development in the year 2000 it has effectively prevented most instances of address spoofing on the XMPP network.</abstract>
&LEGALNOTICE;
<number>0220</number>
<status>Experimental</status>
@ -20,13 +20,13 @@
<supersedes/>
<supersededby/>
<shortname>dialback</shortname>
&stpeter;
&jer;
&stpeter;
<revision>
<version>0.2</version>
<date>2007-12-26</date>
<date>2008-06-17</date>
<initials>psa</initials>
<remark><p>Separated sections into subsections, as has been done for xmppbis Internet-Drafts; explained and illustrated failure cases more completely; added motivating text about different federation models; added explanatory text about scenarios in which server dialback is used and not used.</p></remark>
<remark><p>Rewrote introduction; separated sections into subsections, as has been done for xmppbis Internet-Drafts; explained and illustrated failure cases more completely; added text about different federation models; added explanatory text about scenarios in which Server Dialback is used and not used.</p></remark>
</revision>
<revision>
<version>0.1</version>
@ -43,46 +43,75 @@
</header>
<section1 topic="Introduction" anchor="intro">
<p>The client-server architecture used by Jabber/XMPP technologies makes it desirable to enable communication among servers. Such server-to-server or inter-domain communication is often called "federation". This document defines server dialback, a native Jabber protocol for federation with weak identity verification between Jabber/XMPP servers.</p>
<p>Server dialback, which was formerly documented in &rfc3920; but now is canonically documented in this specification, is a weak identify verification method that is made possible by the existence of the Domain Name System (DNS), since one server can (normally) discover the authoritative server for a given domain. Dialback is a native XMPP method that occurs over XML streams, with the result that it is more difficult to spoof XMPP server domains and XML stanzas sent over XML streams between servers.</p>
<p>Server dialback is not a security mechanism, and results only in weak verification of server identities. 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. However, depending on local policies, a service may wish to use dialback to provide weak identity verification in cases where SASL negotiation would not result in strong authentication (e.g., because the certificate presented by the peer service during TLS negotiation is self-signed and thus provides even weaker identity verification than DNS).</p>
<p>Server dialback is uni-directional, and results in weak identity verification for one stream in one direction. Because server dialback is not an authentication mechanism, mutual authentication is not possible via dialback. Therefore, server dialback MUST be completed in each direction in order to enable bi-directional communications between two domains.</p>
<p>The method for generating and verifying the keys used in server dialback MUST take into account the hostnames being used, the stream ID generated by the receiving server, and a secret known by the authoritative server's network; see <link url='#generation'>Dialback Key Generation</link>.</p>
<p>Any error that occurs during dialback negotiation MUST be considered a stream error, resulting in termination of the stream and of the underlying TCP connection. The possible error conditions are specified in the protocol description below.</p>
</section1>
<section1 topic="Terminology" anchor="terms">
<p>The following terminology applies:</p>
<ul>
<li>ORIGINATING SERVER -- the server that is attempting to establish a connection between two domains.</li>
<li>RECEIVING SERVER -- the server that is trying to authenticate that the Originating Server represents the domain which it claims to be.</li>
<li>AUTHORITATIVE SERVER -- the server that answers to the DNS hostname asserted by the Originating Server; for basic environments this will be the Originating Server, but it could be a separate machine in the Originating Server's network (where "network" is defined by knowledge of a shared secret for verification of dialback keys).</li>
</ul>
</section1>
<section1 topic="Order of Events" anchor="order">
<p>The following is a brief summary of the order of events in dialback:</p>
<ol>
<li>The Originating Server establishes an XML stream with the Receiving Server.</li>
<li>The Originating Server sends a 'key' value over the connection to the Receiving Server.</li>
<li>The Receiving Server establishes an XML stream with the Authoritative Server.</li>
<li>The Receiving Server sends the same 'key' value to the Authoritative Server for verification.</li>
<li>The Authoritative Server replies that key is valid or invalid.</li>
<li>The Receiving Server informs the Originating Server whether it is authenticated or not.</li>
</ol>
<p>We can represent this flow of events graphically as follows.</p>
<code><![CDATA[
<section2 topic="Why Dialback?" anchor="intro-why">
<p>When Jabber technologies were first developed in 1998, they were conceived of as a client-server system similar to email, wherein a client would connect to a server in order to communicate with other clients. Similarly, servers would connect with peer servers to provide inter-domain communication (often called "federation"). In a system that allows federation, it is important for a server to be able to determine the identity of a peer server; accepting a connection from any peer without determining its identity would result in the use of merely asserted identities and a completely uncontrolled approach to federation, which would rapidly devolve into chaos on the open Internet. Clearly such a state of affairs would be unsustainable for a network protocol aiming for widespread deployment.</p>
<p>Unfortunately, that was the state of affairs on the Jabber network during the earliest releases of the original &jabberd; server codebase (up through the 1.0 release in May 2000). Therefore the open-source developer community designed a protocol ("Server Dialback") for weak identity verification based on the Domain Name System (DNS), built support for that protocol into the jabberd 1.2 server (released in October 2000), and mandated support for that protocol on the emerging Jabber server network.</p>
<p>When the core Jabber protocols were formalized by the XMPP Working Group of the &IETF; in 2002-2004, support for strong identity verification was added. That support takes the form of Transport Layer Security (TLS) for encryption of server-to-server XML streams and the Simple Authentication and Security Layer (SASL) for authentication of such streams, using digital certificates issued by trusted root certification authorities (CAs). Documentation of TLS and SASL within XMPP is provided in &xmppcore;. However, the Server Dialback protocol is still in wide use, and probably will be for the foreseeable future given the difficulty (real or perceived) of obtaining digital certificates issued by common certification authorities (CAs). Therefore it is important to maintain accurate documentation of the Server Dialback protocol. Such documentation was originally provided in &rfc3920;. Although that documentation was removed from &rfc3920bis;, it is still provided in this specification for the sake of interoperability.</p>
</section2>
<section2 topic="Federation Models" anchor="intro-models">
<p>There are at least four levels of server-to-server federation in Jabber/XMPP networks:</p>
<ol start='1'>
<li><p>Permissive Federation -- a server accepts a connection from any other peer on the network, even without verifiying the identity of the peer based on DNS lookups. The lack of peer verification or authentication means that domains can be spoofed.</p></li>
<li><p>Verified Federation -- a server accepts a connection from a peer only after the identity of the peer has been weakly verified via based on information obtained via the Domain Name System (DNS). However, the connection is not encrypted or authenticated. The use of identity verification effectively prevents domain spoofing, but federation requires proper DNS setup and is still subject to DNS poisoning attacks.</p></li>
<li><p>Encrypted Federation -- a server accepts a connection from a peer only if the peer supports Transport Layer Security (TLS) as defined for XMPP in &rfc3920; and the peer presents a digital certificate. However, the certificate may be self-signed, in which case mutual authentication is typically not possible. Therefore, after STARTTLS negotiation the parties proceed to weakly verify identity based on DNS information as under Verified Federation. This combination results in an encrypted connection with weak identity verification.</p></li>
<li><p>Trusted Federation -- a server accepts a connection from a peer only if the peer supports Transport Layer Security (TLS) and the peer presents a digital certificate issued by a trusted root certification authority (CA). The list of trusted root CAs is determined by local service policy, as is the level of trust accorded to various types of certificates (i.e., Class 1, Class 2, or Class 3). The use of trusted domain certificates effectively prevents DNS poisoning attacks and results in mutual authentication.</p></li>
</ol>
<p>This specification documents the technology that enabled the Jabber server network to advance beyond Permissive Federation to Verified Federation. Combined with the use of TLS, Server Dialback can also result in Encrypted Federation. However, Trusted Federation is not possible with Server Dialback.</p>
<p>Note: For detailed examples showing the protocol flows and outcomes of dialback negotiation for a wide variety of federation scenarios, refer to &xep0238;.</p>
</section2>
<section2 topic="What Dialback Accomplishes" anchor="intro-what">
<p>Server Dialback is a method for weak identify verification. Such verification depends on the Domain Name System (DNS) and the use of keys based on a shared secret known to all XMPP servers within a given trust domain (e.g., the trust domain associated with a given second-level DNS domain such as "example.com" and all of its subdomains).</p>
<p>Since October 2000, the use of Server Dialback has made it more difficult to spoof the hostnames of servers (and therefore the addresses of sent messages) on the XMPP network. However, Server Dialback does not provide authentication between servers and is not a security mechanism. Domains requiring high security are advised to use TLS and SASL with certificates issued by trusted roots.</p>
<p>Server Dialback is uni-directional, and results in weak identity verification for one XML stream in one direction. Because Server Dialback is not an authentication mechanism, mutual authentication is not possible via dialback. Therefore, Server Dialback must be completed in each direction in order to enable bi-directional communication between two domains.</p>
</section2>
<section2 topic="When Dialback Is Used" anchor="intro-when">
<p>Server Dialback is typically used in two scenarios:</p>
<ol start='1'>
<li><p>When a peer server does not support XMPP 1.0 as defined in <cite>RFC 3920</cite> or, more generally, does not offer negotiation of TLS.</p></li>
<li><p>When STARTTLS negotiation succeeds with a peer server but the peer's certificate is not strong enough to result in mutual authentication via SASL (e.g., because the certificate presented by the peer service during TLS negotiation is self-signed and thus provides even weaker identity verification than DNS).</p></li>
</ol>
<p>Both of these scenarios result in an untrusted connection (verified federation in the first scenario and encrypted federation in the second scenario). However, depending on local security policies, a server may accept such an untrusted connection if the use of Server Dialback results in weak identity verification.</p>
<p>Dialback is not used if SASL is used for server-to-server authentication, since SASL provides strong authentication using certificates, pre-established passwords, or other credentials.</p>
<p>Note: Use of Server Dialback cannot proceed unless a server determines that its peer supports the Server Dialback protocol. For details, see the <link url='support'>Determining Support</link> section of this document.</p>
</section2>
<section2 topic="How Dialback Works" anchor="intro-howitworks">
<p>The basic idea behind Server Dialback is that a receiving server does not accept XMPP traffic from a sending server until it has "called back" the authoritative server for the domain asserted by the sending server, and verified that the sending server is truly authorized to generate XMPP traffic for that domain.</p>
<p>A helpful analogy might be the following telephone scenario:</p>
<ol start='1'>
<li>A customer service representative from your bank calls you on the phone.</li>
<li>Rather than immediately accepting the phone call, you ask for his employee ID number and put him on hold.</li>
<li>You open the phone book, find the authoritative phone number for the bank's headquarters, and give them a call.</li>
<li>After being transferred to the customer service department, you ask if a rep with that particular ID number is authorized to be calling your number.</li>
<li>The bank tells you that the rep is authorized, so you thank them and hang up.</li>
<li>You then take the rep off hold and continue the conversation.</li>
</ol>
<p>In Server Dialback, the equivalent of the customer service representative is the ORIGINATING SERVER, i.e., the machine that wants to send a message to an entity at a destination domain and thus is attempting to establish a connection between the two servers. The equivalent of the person being called is the RECEIVING SERVER, i.e., the machine to which the originating server has opened a connection for the purpose of sending the message and thus is trying to authenticate that the Originating Server represents the domain which it claims to be. And the equivalent of the bank is the AUTHORITATIVE SERVER, i.e., the machine that answers to a DNS lookup for the domain asserted by the originating server (which is not necessarily the machine associated with the originating server); for basic environments this will be the Originating Server, but it could be a separate machine in the Originating Server's network (where "network" is defined by knowledge of a shared secret for verification of dialback keys).</p>
<p>The basic flow of events is as follows:</p>
<ol start='1'>
<li>The Originating Server performs a DNS lookup on the hostname of the Receiving Server, opens a TCP connection to the discovered IP address and port, and establishes an XML stream with the Receiving Server.</li>
<li>The Originating Server sends a locally-generated "key" value over its XML stream with the Receiving Server.</li>
<li>The Receiving Server does not immediately accept the connection but instead performs a DNS lookup on the hostname of the Authoritative Server, opens a TCP connection to the discovered IP address and port, and establishes an XML stream with the Authoritative Server.</li>
<li>The Receiving Server sends the same "key" value over its XML stream with the Authoritative Server for verification.</li>
<li>The Authoritative Server replies that key is valid or invalid.</li>
<li>The Receiving Server informs the Originating Server whether its identify has been verified or not.</li>
</ol>
<p>We can represent this flow of events graphically as follows.</p>
<code><![CDATA[
Originating Receiving
Server Server
----------- ---------
| |
| establish stream |
| perform DNS lookup, |
| open TCP connection, |
| and establish stream |
| ----------------------> |
| | Authoritative
| send dialback key | Server
| ----------------------> | -------------
| | |
| establish stream |
| perform DNS lookup, |
| open TCP connection, |
| and establish stream |
| ----------------------> |
| |
| send verify request |
@ -94,7 +123,9 @@ Originating Receiving
| report dialback result |
| <---------------------- |
| |
]]></code>
]]></code>
<p>Note: In Steps 1 and 3, it is not always necessary to open a new TCP connection and establish a new stream; for details, see the section on <link url='#reuse'>Reuse of Negotiated Connections</link>.</p>
</section2>
</section1>
<section1 topic="Protocol" anchor="protocol">
@ -102,8 +133,8 @@ Originating Receiving
<p>This section uses the following domain names, IP addresses, stream IDs, and shared secret in the examples:</p>
<ul>
<li>The Originating Server is "example.org" (there is no IP address associated with this domain since it is merely asserted by the Originating Server).</li>
<li>The Receiving Server is "xmpp.example.com" and its IP address is "192.0.2.0".</li>
<li>The Authoritative Server is "example.org" and its IP address is "192.0.2.1".</li>
<li>The Receiving Server is "xmpp.example.com" and the discovered IP address for the XMPP service at that domain is "192.0.2.0".</li>
<li>The Authoritative Server is "example.org" and the discovered IP address for the XMPP service at that domain is "192.0.2.1".</li>
<li>The stream ID of the stream from the Originating Server to the Receiving Server is "D60000229F".</li>
<li>The shared secret known by the Authoritative Server's network is "s3cr3tf0rd14lb4ck".</li>
</ul>
@ -114,11 +145,12 @@ Originating Receiving
<li>"R2A:" -- packets sent from the Receiving Server to the Authoritative Server.</li>
<li>"A2R:" -- packets sent from the Authoritative Server to the Receiving Server.</li>
</ul>
<p>Note: A dialback namespace declaration is REQUIRED for all elements used in server dialback. 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.</p>
<p>Note: A dialback namespace declaration is REQUIRED for all elements used in Server Dialback. 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.</p>
<p>Note: Any error that occurs during dialback negotiation MUST be considered a stream error, resulting in termination of the stream and potentially of the underlying TCP connection. The possible error conditions are specified in the protocol description below.</p>
<p>The flow of events is as follows.</p>
<section2 topic='Stream Setup Between Originating Server and Receiving Server' anchor='proto-setup-o2r'>
<p>The Originating Server (asserted to be "example.org") performs a DNS lookup for the Receiving Server (in accordance with the procedure described in RFC 3920) and establishes a TCP connection to the Receiving Server at the IP address and port discovered during the DNS lookup (here assumed to be "192.0.2.0" and "5269"). Alternatively, the Originating Server MAY reuse an existing TCP connnection to the Receiving Server here rather than opening a new TCP connection (see <link url='piggybacking'>Piggybacking</link>).</p>
<p>The Originating Server (asserted to be "example.org") performs a DNS lookup for the Receiving Server (in accordance with the procedure described in <cite>RFC 3920</cite>) and establishes a TCP connection to the Receiving Server at the IP address and port discovered during the DNS lookup (here assumed to be "192.0.2.0" and "5269"). Alternatively, the Originating Server MAY reuse an existing TCP connnection to the Receiving Server here rather than opening a new TCP connection (see <link url='piggybacking'>Piggybacking</link>).</p>
<p>The Originating Server then sends a stream header to the Receiving Server:</p>
<example caption="Stream Header"><![CDATA[
O2R: <stream:stream
@ -129,7 +161,7 @@ O2R: <stream:stream
to='xmpp.example.com'
version='1.0'>
]]></example>
<p>Note: The inclusion of the xmlns:db namespace declaration with the name shown indicates to the Receiving Server that the Originating Server supports server dialback. If any of the namespace names provided by the Originating Server is incorrect, then the Receiving Server MUST generate an &lt;invalid-namespace/&gt; stream error condition and terminate both the XML stream and the underlying TCP connection. If the value of the 'to' address provided by the Originating Server does not match a hostname serviced by the Receiving Server, then the Receiving Server MUST generate a &lt;host-unknown/&gt; stream error condition and terminate both the XML stream and the underlying TCP connection.</p>
<p>Note: The inclusion of the xmlns:db namespace declaration with the name shown indicates to the Receiving Server that the Originating Server supports Server Dialback. If any of the namespace names provided by the Originating Server is incorrect, then the Receiving Server MUST generate an &lt;invalid-namespace/&gt; stream error condition and terminate both the XML stream and the underlying TCP connection. If the value of the 'to' address provided by the Originating Server does not match a hostname serviced by the Receiving Server, then the Receiving Server MUST generate a &lt;host-unknown/&gt; stream error condition and terminate both the XML stream and the underlying TCP connection.</p>
<p>The Receiving Server SHOULD send a stream header back to the Originating Server over the same TCP connection, including a unique ID for this interaction:</p>
<example caption="Stream Header"><![CDATA[
R2O: <stream:stream
@ -244,11 +276,11 @@ R2O: <db:result
<p>Note: At this point, the connection from the Originating Server to the Receiving Server has either been validated or reported as invalid. If the connection is invalid, then the Receiving Server MUST terminate both the XML stream and the underlying TCP connection between itself and the Originating Server. If the connection is valid, the Receiving Server has verified the identity of the Originating Server; as a result, the Originating Server may now send XML stanzas to the Receiving Server over the validated connection (i.e., over the "initial stream" from the Originating Server to the Receiving Server).</p>
<p>Until the initial stream has been validated, the Originating Server MUST NOT send any further XML data to the Receiving Server. If it receives any XML stanzas from the Originating Server before the initial stream has been validated, the Receiving Server MUST silently drop them.</p>
<p>After successful dialback negotiation, the Receiving Server MUST follow the rules specified in RFC 3920 regarding inclusion and checking of 'from' and 'to' attributes on all XML stanzas it receives from the Originating Server. These checks help to prevent address spoofing.</p>
<p>As mentioned, server dialback results in weak identity verification in one direction only (in the foregoing text, verification of the Originating Server by the Receiving Server). In order to proceed with bi-directional communication so that the Receiving Server may sent XML stanzas to the Originating Server, the Receiving Server MUST now also initiate a dialback negotiation with the Originating Server (this happens on a different TCP connection).</p>
<p>As mentioned, Server Dialback results in weak identity verification in one direction only (in the foregoing text, verification of the Originating Server by the Receiving Server). In order to proceed with bi-directional communication so that the Receiving Server may sent XML stanzas to the Originating Server, the Receiving Server MUST now also initiate a dialback negotiation with the Originating Server (this happens on a different TCP connection).</p>
</section2>
</section1>
<section1 topic="Reuse of Negotiated Connections" anchor="dialback-reuse">
<section1 topic="Reuse of Negotiated Connections" anchor="reuse">
<p>After the Receiving Server has validated the connection from the Originating Server, the Originating Server may wish to reuse that connection for validation of additional domains. This feature is called PIGGYBACKING. Support for piggybacking is OPTIONAL.</p>
<p>One common motivation for such reuse is the existence of additional services associated with the Originating Server but hosted at subdomains of the Originating Server (the use of subdomains helps to ensure proper routing of XML stanzas to the hosted services). For example, the "example.org" XMPP server may host a groupchat service at "chat.example.org". In order to accept XML stanzas from rooms at "chat.example.org" intended for addresses at "xmpp.example.com", the "xmpp.example.com" domain will need to validate the "chat.example.org" domain (just as it already did for the "example.org" domain). Thus the "example.org" server would now initiate a dialback negotiation with "xmpp.example.com" but specify the Originating Server as "chat.example.org".</p>
<p>However, because the "example.org" server already has a validated connection open to the Receiving Server ("xmpp.example.com"), it MAY send a &lt;db:result/&gt; element with the key to be validated for the new Originating Server ("chat.example.org") over the XML stream that has already been negotiated, rather than opening a new TCP connection and XML stream.</p>
@ -280,14 +312,14 @@ R2O: <db:result
</section1>
<section1 topic="Dialback Key Generation" anchor="generation">
<p>As mentioned, the dialback key is generated based on four different pieces of information:</p>
<p>The method for generating and verifying the keys used in Server Dialback MUST take into account the following pieces of information:</p>
<ul>
<li>the hostname of the Originating Server</li>
<li>the hostname of the Receiving Server</li>
<li>the Stream ID</li>
<li>a shared secret known by the Authoritative Server's network</li>
</ul>
<p>The stream ID is security-critical in server dialback and therefore MUST be both unpredictable and non-repeating (see &rfc4086; for recommendations regarding randomness for security purposes).</p>
<p>The stream ID is security-critical in Server Dialback and therefore MUST be both unpredictable and non-repeating (see &rfc4086; for recommendations regarding randomness for security purposes).</p>
<p>It is RECOMMENDED for the dialback key to be the hexadecimal representation of a Keyed-Hash Message Authentication Code (see &nistfips198a;) generated using the SHA256 hashing algorithm (see &nistfips180-2;), as follows.</p>
<example caption="HMAC"><![CDATA[
HMAC-SHA256
@ -330,14 +362,14 @@ that is,
]]></example>
</section1>
<section1 topic="Advertisement" anchor="dialback-advertise">
<p>Support for the server dialback protocol can be indicated in two ways:</p>
<ol>
<li>By inclusion of the server dialback feature in a given set of stream features.</li>
<li>By inclusion of the dialback namespace declaration in the stream header.</li>
<section1 topic="Determining Support" anchor="support">
<p>Support for the Server Dialback protocol can be indicated in two ways:</p>
<ol start='1'>
<li>By inclusion of the Server Dialback feature in a given set of stream features; this is REQUIRED for XMPP 1.0 servers, but not supported by older implementations and deployments.</li>
<li>By inclusion of the dialback namespace declaration in the stream header; this is REQUIRED for all servers.</li>
</ol>
<p>The former method is preferred, but the latter method is also specified herein for the purpose of backwards-compatibility with older "XMPP 0.9" deployments.</p>
<p>The server dialback stream feature is advertised by including in any given set of stream features a &lt;dialback/&gt; element qualified by the 'urn:xmpp:features:dialback' namespace; the &lt;dialback/&gt; element MAY also include an empty &lt;required/&gt; element, indicating that the entity sending the stream features requires dialback to be negotiated for the stream.</p>
<p>The Server Dialback stream feature is advertised by including in any given set of stream features a &lt;dialback/&gt; element qualified by the 'urn:xmpp:features:dialback' namespace; the &lt;dialback/&gt; element MAY also include an empty &lt;required/&gt; element, indicating that the entity sending the stream features requires dialback to be negotiated for the stream.</p>
<example caption="Stream Features"><![CDATA[
<stream:features>
<dialback xmlns='urn:xmpp:features:dialback'>
@ -345,7 +377,7 @@ that is,
</dialback>
</stream:features>
]]></example>
<p>As mentioned, support for the server dialback protocol can also be advertised by including the dialback namespace declaration in a stream header.</p>
<p>As mentioned, support for the Server Dialback protocol can also be advertised by including the dialback namespace declaration in a stream header.</p>
<example caption="Stream Header"><![CDATA[
<stream:stream
xmlns='jabber:server'
@ -354,7 +386,7 @@ that is,
from='example.com'
to='example.net'>
]]></example>
<p>No matter which method is used, a service SHOULD advertise support for server dialback only at a point in the stream negotiation when it will accept negotiation of server dialback for that stream. For example, if a service wishes to be backwards-compatible with older "XMPP 0.9" deployments, it SHOULD include the server dialback namespace declaration in the initial stream header it sends to other servers (so that "XMPP 0.9" servers can proceed with dialback in the absence of TLS and SASL authentication). However, in the midst of stream negotiation with an XMPP 1.0 or higher server, a service SHOULD advertise the dialback stream feature only at a point when negotiation of server dialback is allowed in accordance with local service policies (e.g., after TLS negotiation in the case when a self-signed certificate was presented by the Originating Server and local service policies stipulate that it is preferable to weakly identify the Originating Server via server dialback rather than depend on the self-signed certificate for identity verification).</p>
<p>No matter which method is used, a service SHOULD advertise support for Server Dialback only at a point in the stream negotiation when it will accept negotiation of Server Dialback for that stream. For example, if a service wishes to be backwards-compatible with older "XMPP 0.9" deployments, it SHOULD include the Server Dialback namespace declaration in the initial stream header it sends to other servers (so that "XMPP 0.9" servers can proceed with dialback in the absence of TLS and SASL authentication). However, in the midst of stream negotiation with an XMPP 1.0 or higher server, a service SHOULD advertise the dialback stream feature only at a point when negotiation of Server Dialback is allowed in accordance with local service policies (e.g., after TLS negotiation in the case when a self-signed certificate was presented by the Originating Server and local service policies stipulate that it is preferable to weakly identify the Originating Server via Server Dialback rather than depend on the self-signed certificate for identity verification).</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>