0.9

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@297 4b5297f7-1745-476d-ba37-a9c6900126ab

xep-0174.xml

@@ -25,6 +25,12 @@
   <supersededby/>
   <shortname>N/A</shortname>
   &stpeter;
+  <revision>
+    <version>0.9</version>
+    <date>2006-12-22</date>
+    <initials>psa</initials>
+    <remark><p>Updated the security considerations to recommend either TLS+SASL at the stream layer or encrypted sessions at the messaging layer.</p></remark>
+  </revision>
   <revision>
     <version>0.8</version>
     <date>2006-07-31</date>
@@ -239,15 +245,7 @@ psa IN TXT "vc=CA!"
   <example caption="Stream Header Response"><![CDATA[
 <stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'>
   ]]></example>
-  <p>The exchange of stream headers results in an unencrypted and unauthenticated channel between the two entities. Subject to client configuration and local service policies, two entities MAY accept such a channel. However, it is RECOMMENDED to use Transport Layer Security (TLS) for channel encryption (see &rfc4346;) and the Simple Authentication and Security Layer (SASL) for authentication (see &rfc4422;), in a manner essentially the same as that defined in <cite>RFC 3920</cite>. If the initiating party wishes to TLS and SASL, it MUST include a 'version' attribute with a value of "1.0" in the stream header it sends:</p>
+  <p>The exchange of stream headers results in an unencrypted and unauthenticated channel between the two entities. See the <link url='#security'>Security Considerations</link> section of this document regarding methods for authenticating and encrypting the stream.</p>
-  <example caption="Opening a Stream (Version 1.0)"><![CDATA[
-<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
-  ]]></example>
-  <p>If the receiving entity supports TLS and SASL for stream security, it MUST also include the 'version' attribute:</p>
-  <example caption="Stream Header Response (Version 1.0)"><![CDATA[
-<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
-  ]]></example>
-  <p>The parties then can complete TLS and SASL negotiation (including stream feature advertisement) as specified in <cite>RFC 3920</cite>. A future version of this specification may include more detailed examples showing the relevant protocol flows. Handling of the 'version' attribute (or lack thereof) MUST follow the rules specified in <cite>RFC 3920</cite>.</p>
 </section1>
 <section1 topic='Exchanging Messages' anchor='comms'>
   <p>Once the streams are established, either entity then can send XMPP message or IQ stanzas by specifying 'to' and 'from' addresses using the logical local addresses: <note>The "JIDs" MUST be of the form "username@machine-name" as discovered via SRV (this is the &lt;Instance&gt; portion of the Service Instance Name).</note></p>
@@ -291,9 +289,21 @@ _presence._tcp.local. IN NULL raw-binary-data-here
   <p>Although <cite>RFC 1464</cite> does not allow characters outside the US-ASCII character range in TXT records, Section 6.5 of <cite>DNS-Based Service Discovery</cite> mentions support for UTF-8-encoded Unicode characters in text record values (e.g., values of the TXT "msg" name). This document adheres to the recommendation in <cite>DNS-Based Service Discovery</cite>.</p>
 </section1>
 <section1 topic='Security Considerations' anchor='security'>
-  <p>XMPP networks depend on TLS (&rfc2246;) for channel encryption, SASL (&rfc4422;) for authentication, and the Domain Name System (&rfc1034;) for validation of server hostnames; these technologies help to ensure the identity of sending entities. By contrast, zero-configuration networking uses dynamic discovery and asserted machine names as the basis of sender identity. Therefore, zero-configuration networking does not result in authenticated identities in the same way that XMPP itself does, nor does it provide for an encrypted channel between local entities. (TLS could be negotiated on the local streams, but is out of scope for this specification.)</p>
+  <section2 topic='Authentication and Encryption' anchor='security-auth'>
-  <p>Because of fundamental differences between a true XMPP network and a localized XMPP client "mesh", local entities MUST NOT attempt to inject local traffic onto an XMPP network and an XMPP server MUST reject communications until an entity is properly authenticated. However, a client on a local 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 local client mesh to a contact on an XMPP network).</p>
+    <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, link-local messaging does not result in authenticated identities in the same way that XMPP itself does, nor does it provide for an encrypted channel between local 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>
+      <li>Negotiate encryption with identity checking for the message exchange using &xep0116;.</li>
+    </ol>
+    <p>It is RECOMMENDED to use one of these methods to secure communications between local entities. However, subject to client configuration and local service policies, two entities MAY accept an unauthenticated and unencrypted channel; but a client MUST 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 localized XMPP client "mesh", local entities MUST NOT attempt to inject local 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 local 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 local client mesh to a contact on an XMPP network).</p>
+  </section2>
+  <section2 topic='Private Information' anchor='security-priv'>
     <p>The TXT records optionally advertised as part of this protocol MAY result in exposure of privacy-sensitive information about a human user (such as full name, email address, and Jabber ID). A client MUST allow a user to disable publication of this personal information (e.g., via client configuration).</p>
+  </section2>
 </section1>
 <section1 topic='IANA Considerations' anchor='iana'>
   <p>The p2pj port number 5298 is not included in the &ianaports; maintained by &IANA;. The author will investigate whether that port number (or some other port number) needs to be registered.</p>