moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-28 04:02:20 -05:00
Code Issues Releases Wiki Activity

updated TLS reference, added XEP-0246 reference

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2123 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-08-06 02:16:42 +00:00
parent 2c51b8c6ff
commit ef2ff705a8
1 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
xep-0174.xml
View File

@ -145,8 +145,8 @@
<section1 topic='Introduction' anchor='intro'>
<section2 topic='Motivation' anchor='motivation'>
<p>XMPP as defined in &rfc3920; does not support direct client-to-client interactions, since it requires authentication with a server: an XMPP client is allowed access to the network only once it has authenticated with a server, and the server must not grant access if authentication fails for any reason. If an unauthenticated client attempts to communicate directly with another client, such communication will fail because all XMPP communications are sent through one or more servers and a client cannot inject messages onto the network without first authenticating with a server.</p>
<p>However, it is possible to establish an XMPP-like communications system on a local (or even wide-area) network using the principles of zero-configuration networking. In this situation, the clients obviate the XMPP requirement for authentication with a server by relying on zero-configuration networking to establish serverless communication using the _presence._tcp DNS SRV service type. Once discovery has been completed, the clients are then able to exchange messages and other structured data using the XMPP &MESSAGE; and &IQ; stanzas.</p>
<p>Serverless messaging is restricted to a local network (or ad-hoc wide-area network) because of how zero-configuration networking works. It is impossible for clients that communicate via this serverless mode to insert messages into an XMPP network, which is why this kind of "mesh" is most accurately referred to as an XMPP-like system that exists outside the context of existing XMPP networks (though see the <link url='#security'>Security Considerations</link> regarding the ability to "forward" messages from a serverless mesh to an XMPP network or vice-versa).</p>
<p>However, it is possible to establish an XMPP-like communication system on a local (or even wide-area) network using the principles of zero-configuration networking. In this situation, the clients obviate the XMPP requirement for authentication with a server by relying on zero-configuration networking to establish serverless communication using the _presence._tcp DNS SRV service type. Once discovery has been completed, the clients are able to negotiate an XML stream between themselves (as generalized in &xep0246;) and then exchange messages and other structured data using the XMPP &MESSAGE; and &IQ; stanzas.</p>
<p>Serverless messaging is typically restricted to a local network (or ad-hoc wide-area network) because of how zero-configuration networking works. It is impossible for clients that communicate via this serverless mode to insert messages into an XMPP network, which is why this kind of "mesh" is most accurately referred to as an XMPP-like system that exists outside the context of existing XMPP networks (though see the <link url='#security'>Security Considerations</link> regarding the ability to "forward" messages from a serverless mesh to an XMPP network or vice-versa).</p>
<p>Such a "mesh" can be quite valuable in certain circumstances. For instance, participants in a trade show or conference, users of the same wifi hotspot, or employees on the same local area network can communicate without the need for a pre-configured server. For this reason, support for serverless messaging has been a feature of Apple's iChat client when operating in Bonjour (formerly Rendezvous) mode for many years. Because it is desirable for other Jabber/XMPP clients to support such functionality, this document describes how to use zero-configuration networking as the basis for serverless communication, mainly for use on local links (although the protocol can also be used on ad-hoc wide-area networks).</p>
</section2>
<section2 topic='How It Works' anchor='howitworks'>
@ -331,7 +331,7 @@ juliet IN TXT "ver=66/0NaeaBKkwk85efJTGmU47vXI="
</section1>
<section1 topic='Discovering Other Users' anchor='disco'>
<p>In order to discover other users, a client sends an mDNS request for PTR records that match "_presence._tcp.local.". The client then receives replies from all machines that advertise support for serverless messaging. <note>The replies will include a record corresponding the client itself; the client MUST filter out this result.</note> The client MAY then find out detailed information about each machine by sending SRV and TXT queries to "machine-name.local." for each machine (however, to preserve bandwidth, the client SHOULD NOT send these queries unless it is about to initiate communications with the other user, and it MUST cancel the queries after it has received a response). Note: The presence name to be used for display in a serverless "roster" SHOULD be obtained from the &lt;Instance&gt; portion of the received PTR record for each user; however, the client MAY instead display a name or nickname derived from the TXT records if available.</p>
<p>In order to discover other users, a client sends an mDNS request for PTR records that match "_presence._tcp.local.". The client then receives replies from all machines that advertise support for serverless messaging. <note>The replies will include a record corresponding the client itself; the client MUST filter out this result.</note> The client MAY then find out detailed information about each machine by sending SRV and TXT queries to "machine-name.local." for each machine (however, to preserve bandwidth, the client SHOULD NOT send these queries unless it is about to initiate communication with the other user, and it MUST cancel the queries after it has received a response). Note: The presence name to be used for display in a serverless "roster" SHOULD be obtained from the &lt;Instance&gt; portion of the received PTR record for each user; however, the client MAY instead display a name or nickname derived from the TXT records if available.</p>
</section1>
<section1 topic='Exchanging Presence' anchor='presence'>
@ -404,7 +404,7 @@ juliet IN TXT "ver=66/0NaeaBKkwk85efJTGmU47vXI="
<section1 topic='Implementation Notes' anchor='impl'>
<section2 topic='Multiple Network Interfaces' anchor='impl-network'>
<p>Devices that use serverless messaging may have multiple network interfaces. As a result, it is possible to discover the same entity multiple times. Even if a client discovers the same presence name on multiple network interfaces, it MUST show only one entity in the serverless roster. In addition, because local IP addresses can be dynamically re-assigned, the client SHOULD NOT store the IP address to be used for communications when it discovers that address in the initial DNS lookup phase; instead, it SHOULD delay sending the Multicast DNS query until the client is ready to communicate with the other entity.</p>
<p>Devices that use serverless messaging may have multiple network interfaces. As a result, it is possible to discover the same entity multiple times. Even if a client discovers the same presence name on multiple network interfaces, it MUST show only one entity in the serverless roster. In addition, because local IP addresses can be dynamically re-assigned, the client SHOULD NOT store the IP address to be used for communication when it discovers that address in the initial DNS lookup phase; instead, it SHOULD delay sending the Multicast DNS query until the client is ready to communicate with the other entity.</p>
</section2>
<section2 topic='Buddy Icons' anchor='impl-icons'>
<p>If an entity has an associated icon (e.g., a user avatar or photo), its client SHOULD publish the raw binary data for that image via a DNS NULL record of the following form:</p>
@ -431,7 +431,7 @@ _presence._tcp.local. IN NULL raw-binary-data-here
<section1 topic='Security Considerations' anchor='security'>
<section2 topic='Authentication and Encryption' anchor='security-auth'>
<p>XMPP networks use TLS (&rfc2246;) for channel encryption, SASL (&rfc4422;) for authentication, and the Domain Name System (&rfc1034;) for weak validation of server hostnames; these technologies help to ensure the identity of sending entities and to encrypt XML streams. By contrast, zero-configuration networking uses dynamic discovery and asserted machine names as the basis of sender identity. Therefore, serverless messaging does not result in authenticated identities in the same way that XMPP itself does, nor does it provide for an encrypted channel between entities.</p>
<p>XMPP networks use TLS (&rfc4346;) for channel encryption, SASL (&rfc4422;) for authentication, and the Domain Name System (&rfc1034;) for weak validation of server hostnames; these technologies help to ensure the identity of sending entities and to encrypt XML streams. By contrast, zero-configuration networking uses dynamic discovery and asserted machine names as the basis of sender identity. Therefore, serverless messaging does not result in authenticated identities in the same way that XMPP itself does, nor does it provide for an encrypted channel between entities.</p>
<p>There are two potential solutions to this problem:</p>
<ol>
<li>Negotiate the use of TLS and SASL for the XML stream as described in <cite>RFC 3920</cite>.</li>
@ -440,7 +440,7 @@ _presence._tcp.local. IN NULL raw-binary-data-here
<p>It is RECOMMENDED to use one of these methods to secure communications between serverless entities. However, subject to client configuration and local service policies, two entities MAY accept an unauthenticated and unencrypted channel; but a client SHOULD warn the human user that the channel is unauthenticated and unencrypted.</p>
</section2>
<section2 topic='Stanza Injection' anchor='security-inject'>
<p>Because of fundamental differences between a true XMPP network and a serverless client "mesh", entities communicating via serverless messagin MUST NOT attempt to inject serverless traffic onto an XMPP network and an XMPP server MUST reject communications until an entity is properly authenticated in accordance with the rules defined in <cite>RFC 3920</cite>. However, a client on a serverless mesh MAY forward traffic to an XMPP network after having properly authenticated on such a network (e.g., to forward a message received on a serverless client mesh to a contact on an XMPP network).</p>
<p>Because of fundamental differences between a true XMPP network and a serverless client "mesh", entities communicating via serverless messaging MUST NOT attempt to inject serverless traffic onto an XMPP network and an XMPP server MUST reject communications until an entity is properly authenticated in accordance with the rules defined in <cite>RFC 3920</cite>. However, a client on a serverless mesh MAY forward traffic to an XMPP network after having properly authenticated on such a network (e.g., to forward a message received on a serverless client mesh to a contact on an XMPP network).</p>
</section2>
<section2 topic='TXT Record Data' anchor='security-txt'>
<p>Because there is no mechanism for validating the information that is published in DNS TXT records, it is possible for clients to "poison" this information (e.g., by publishing email addresses or Jabber IDs that are controlled by or associated with other users).</p>
@ -591,7 +591,7 @@ _presence._tcp.local. IN NULL raw-binary-data-here
<record>
<name>port.p2pj</name>
<desc>
The port for serverless communications. This MUST be the same as the
The port for serverless communication. This MUST be the same as the
value provided for SRV lookups. Clients MUST use the port discovered
via SRV lookups and MUST ignore the value of this TXT record. However,
clients SHOULD advertise this TXT record if it is important to ensure