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

1.8rc5

This commit is contained in:
stpeter 2011-04-12 11:23:53 -06:00
parent a6cdd83386
commit bf56a93921
1 changed files with 14 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
xep-0065.xml
View File

@ -31,8 +31,8 @@
&stpeter;
&infiniti;
<revision>
<version>1.8rc4</version>
<date>in progress, last updated 2011-03-21</date>
<version>1.8rc5</version>
<date>in progress, last updated 2011-04-12</date>
<initials>psa</initials>
<remark>
<ul>
@ -45,6 +45,7 @@
<li>Removed the anomalous Formal Use Case text for consistency with all other XEPs.</li>
<li>Refactored the text in various ways to make it more readable.</li>
<li>Changed Initiator to Requester to remove ambiguity in Jingle use cases.</li>
<li>Clarified a number of small technical points in the text and examples.</li>
</ul>
</remark>
</revision>
@ -181,7 +182,7 @@
<dd>A relatively unique Stream ID for this connection; this is generated by the Requester for tracking purposes.</dd>
</di>
</dl>
<p>Note: Because either party can attempt to establish a bytestream (this is formalized in &xep0260;), the Requester and the Target roles apply to a particular S5B negotiation, and do not map to the Initiator and Responder roles from &xep0166; in a fixed way. For example, during a Jingle negotiation the Jingle Initiator might first take on the role of an S5B Requester but if that first bytestreams negotiation fails then the Jingle Responder might take on the role of an S5B Requester.</p>
<p>Note: Because either party can attempt to establish a bytestream (this is formalized in &xep0260;), the Requester and the Target roles apply to a particular S5B negotiation, and do not map to the Initiator and Responder roles from &xep0166; in a fixed way. For example, during a Jingle negotiation the Jingle Initiator might first take on the role of an S5B Requester (with the Jingle Responder being the S5B Target) but if that first bytestreams negotiation fails (the so-called "fallback scenario") then the Jingle Responder might take on the role of an S5B Requester (with the Jingle Initiator being the S5B Target).</p>
<p>In the protocol flow diagrams, the line types have the following meaning:</p>
<ul>
<li>"----" ... communications over XMPP</li>
@ -273,7 +274,7 @@
]]></example>
<p>The Proxy replies by returning an IQ-result that contains its network address, structured using the &lt;streamhost/&gt; child of the &QUERY; element; the &lt;streamhost/&gt; element MUST possess the following attributes:</p>
<ul>
<li><cite>host</cite> = the IP address or DNS domain name of the StreamHost for SOCKS5 communication over TCP</li>
<li><cite>host</cite> = the IP address or DNS domain name of the StreamHost for SOCKS5 communication over TCP (if the value is an IPv6 address, it MUST be formatted according to &rfc5952;, as is done in &xmppcore;)</li>
<li><cite>jid</cite> = the JabberID of the StreamHost for communication over XMPP</li>
<li><cite>port</cite> = the port on which to connect for SOCKS5 communication over TCP</li>
</ul>
@ -396,8 +397,8 @@ Requester Target
<ol>
<li>The hostname MUST be SHA1(SID + Requester JID + Target JID) where the definition of the SHA1 hashing algorithm is as specified by &rfc3174; and the output is hexadecimal-encoded (not binary); as noted above and under <link url='#muc'>Use with Multi-User Chat</link>, the DST.ADDR value might have been provided directly from the Requester to the Target).</li>
<li>The port MUST be 0 (zero).</li>
<li>The JIDs provided MUST be the JIDs used for the IQ exchange between the Requester and the Target, which MAY be full JIDs &FULLJID; or bare JIDs &BAREJID;.</li>
<li>The appropriate stringprep profiles (as specified in &xmppcore;) MUST be applied to the JIDs before application of the SHA1 hashing algorithm.</li>
<li>The JIDs used as input to the hash function MUST be the actual JIDs used for the IQ exchange between the Requester and the Target (these might be full JIDs &FULLJID; or bare JIDs &BAREJID; depending on the addresses of the entities involved in the negotiation).</li>
<li>The appropriate stringprep profiles (as specified in &rfc3920;) MUST be applied to the JIDs before application of the SHA1 hashing algorithm.</li>
</ol>
<example caption='Target Establishes SOCKS5 Connection with StreamHost'><![CDATA[
CMD = X'01'
@ -528,7 +529,7 @@ Requester Proxy Target
<li>The hostname MUST be SHA1(SID + Requester JID + Target JID) where the definition of the SHA1 hashing algorithm is as specified by &rfc3174; and the output is hexadecimal-encoded (not binary); as noted above and under <link url='#muc'>Use with Multi-User Chat</link>, the DST.ADDR value might have been provided directly from the Requester to the Target).</li>
<li>The port MUST be 0 (zero).</li>
<li>The JIDs provided MUST be the JIDs used for the IQ exchange between the Requester and the Target, which MAY be full JIDs &FULLJID; or bare JIDs &BAREJID;.</li>
<li>The appropriate stringprep profiles (as specified in <cite>XMPP Core</cite>) MUST be applied to the JIDs before application of the SHA1 hashing algorithm.</li>
<li>The appropriate stringprep profiles (as specified in <cite>RFC 3920</cite>) MUST be applied to the JIDs before application of the SHA1 hashing algorithm.</li>
</ol>
<example caption='Target Establishes SOCKS5 Connection with StreamHost'><![CDATA[
CMD = X'01'
@ -764,7 +765,11 @@ DATA = (payload)
<p>The "jid" attribute specifies the JID of the StreamHost. This attribute MUST be present, and MUST be a valid JID for communication over XMPP.</p>
</section2>
<section2 topic='&lt;activate/&gt; Element' anchor='desc-activate'>
<p>The &lt;activate/&gt; element is sent from the Requester to the Proxy in order to formally start the bytestream.</p>
<p>The &lt;activate/&gt; element is sent from the Requester to the Proxy in order to formally start the bytestream. This element is always empty and has no defined attributes.</p>
</section2>
<section2 topic='&lt;udpsuccess/&gt; Element' anchor='desc-udpsuccess'>
<p>The &lt;udpsuccess/&gt; element is sent from the StreamHost to the Target or Requester to indicate that the StreamHost has received a UDP initialization packet.</p>
<p>This element is always empty and has one defined attribute, "dstaddr", which specifies the DST.ADDR that was used in the UDP datagram that the StreamHost received.</p>
</section2>
</section1>
@ -817,7 +822,7 @@ DATA = (payload)
<p>In the absence of end-to-end encryption of the negotiation stanzas between the Requester and the Target, a passive attacker (eavesdropper) could authenticate to the bytestream before the Target, thus preventing the Target from connecting and also hijacking the data sent from the Requester.</p>
</section2>
<section2 topic='Denial of Service' anchor='security-dos'>
<p>A SOCKS5 Bytestreams Proxy can be subject to denial of service attacks (e.g., generating a large number of session requests that are never activated). A Proxy SHOULD monitor usage from particular Requesters and blacklist them if their usage is excessive.</p>
<p>A SOCKS5 Bytestreams Proxy can be subject to denial of service attacks (e.g., generating a large number of session requests that are never activated). Proxy deployments are advised to monitor usage from particular entities and blacklist them if their usage is excessive.</p>
</section2>
<section2 topic='Use of SHA-1' anchor='security-sha1'>
<p>The use of the SHA-1 algorithm to hash the SID, Requester's JID, and Target's JID is not security-critical. Therefore, the known weaknesses of SHA-1 are not of significant concern in this protocol.</p>