moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

3920 to 6120

This commit is contained in:
Peter Saint-Andre 2013-05-18 08:10:10 -06:00
parent a18dc452b2
commit 116d67aeec
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

@ -156,8 +156,8 @@
<section1 topic='Introduction' anchor='intro'>
<section2 topic='Motivation' anchor='motivation'>
<p>The Extensible Messaging and Presence Protocol (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 after it has authenticated with a server, and the server will 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 unless it first authenticates with a server.</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>The Extensible Messaging and Presence Protocol (XMPP) as defined in &xmppcore; 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 after it has authenticated with a server, and the server will 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 unless it first authenticates with a server.</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 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 since 2002. 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>
@ -359,7 +359,7 @@ juliet@pronto._presence._tcp.local. IN TXT
</section1>
<section1 topic='Initiating an XML Stream' anchor='initiate'>
<p>In order to exchange serverless messages, the initiator and recipient MUST first establish XML streams between themselves, as is familiar from <cite>RFC 3920</cite>.</p>
<p>In order to exchange serverless messages, the initiator and recipient MUST first establish XML streams between themselves, as is familiar from <cite>RFC 6120</cite>.</p>
<p>First, the initiator opens a TCP connection at the IP address and port discovered via the DNS lookup for an entity and opens an XML stream to the recipient, which SHOULD include 'to' and 'from' address:</p>
<example caption="Initiator Opens a Stream"><![CDATA[
I: <stream:stream
@ -369,7 +369,7 @@ I: <stream:stream
to='juliet@pronto'
version='1.0'>
]]></example>
<p>Note: If the initiator supports stream features and the other stream-related aspects of XMPP 1.0 as specified in <cite>RFC 3920</cite>, then it SHOULD include the version='1.0' flag as shown in the previous example.</p>
<p>Note: If the initiator supports stream features and the other stream-related aspects of XMPP 1.0 as specified in <cite>RFC 6120</cite>, then it SHOULD include the version='1.0' flag as shown in the previous example.</p>
<p>The recipient then responds with a stream header as well:</p>
<example caption="Recipient Sends Stream Header Response"><![CDATA[
R: <stream:stream
@ -379,7 +379,7 @@ R: <stream:stream
to='romeo@forza'
version='1.0'>
]]></example>
<p>If both the initiator and recipient included the version='1.0' flag, the recipient SHOULD also send stream features as specified in <cite>RFC 3920</cite>:</p>
<p>If both the initiator and recipient included the version='1.0' flag, the recipient SHOULD also send stream features as specified in <cite>RFC 6120</cite>:</p>
<example caption="Recipient Sends Stream Features"><![CDATA[
R: <stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
@ -499,10 +499,10 @@ _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 (&rfc5246;) 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>To secure communications between serverless entities, it is RECOMMENDED to negotiate the use of TLS and SASL for the XML stream as described in <cite>RFC 3920</cite>. However, subject to client configuration and local service policies, an entity MAY accept an unauthenticated and unencrypted channel, in which case the client SHOULD warn the human user that the channel is unauthenticated and unencrypted.</p>
<p>To secure communications between serverless entities, it is RECOMMENDED to negotiate the use of TLS and SASL for the XML stream as described in <cite>RFC 6120</cite>. However, subject to client configuration and local service policies, an entity MAY accept an unauthenticated and unencrypted channel, in which case the 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 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>
<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 6120</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 Parameters' 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>