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

Merge pull request #1294 from iNPUTmice/smacks_inline 

XEP-0198: Add section defining SASL2 and BIND2 interaction
This commit is contained in:
Kevin Smith 2023-12-11 16:35:44 +00:00 committed by GitHub
parent 29eb6a08c8 c66af01f57
commit 11fb1016fe
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 95 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

95
xep-0198.xml
View File

@ -13,6 +13,7 @@
<status>Draft</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
</dependencies>
@ -28,6 +29,13 @@
&fabio;
&dcridland;
&mwild;
&tmolitor;
<revision>
<version>1.6.1</version>
<date>2022-10-05</date>
<initials>tm</initials>
<remark><p>Clarify SASL2 and BIND2 interaction.</p></remark>
</revision>
<revision>
<version>1.6</version>
<date>2018-07-25</date>
@ -552,8 +560,95 @@
</section2>
</section1>
<section1 topic="SASL2 And BIND2 Interaction" anchor="inline">
<p class='box'>This section is about &xep0388; (SASL2) and &xep0386; (BIND2) interaction. You don't have to implement this if you don't implement SASL2 and BIND2.</p>
<p>&xep0388; (SASL2) describes a way of inlining the stream resumption into the authentication process to reduce the round-trips needed for authentication and subsequent stream resumption. Similarly &xep0386; (BIND2) defines a way of inlining the stream management &lt;enable/> into the resource binding process to reduce round-trips.</p>
<section2 topic="Enable Stream Management Inline" anchor="inline-enable">
<p>To indicate support for inlining the activation of Stream Management into the resource binding process, the server adds a &lt;feature/> element with var attribute set to "urn:xmpp:sm:3" in the &lt;inline/> element of BIND2 which is sent in the stream features.</p>
<p>If the client wishes to begin a new session (i.e. it has no prior session to resume), it simply includes the &lt;enable/> element defined by this specification in its &xep0386; &lt;bind/> request which itself is a child of the &lt;authenticate/> element of SASL2.</p>
<section3 topic="Failed To Enable Stream Management">
<p>In the unexpected case where the server was able to bind a resource for the client, but unable to enable stream management, it will include a &lt;failed/> element as defined by this specification within the &lt;bound/> response defined by &xep0386;.</p>
</section3>
</section2>
<section2 topic="Inline Stream Resumption" anchor="inline-resume">
<p>To indicate support for inlining stream resumption into the authentication process, the server adds a &lt;sm/> element in the namespace "urn:xmpp:sm:3" to the &lt;inline/> element of SASL2.</p>
<p>If the client wishes to resume an existing session it, it simply includes the &lt;resume/> element defined by this specification in the SASL2 &lt;authenticate/> element.</p>
<p class="box">Note: If the client included a &lt;resume/> element in its SASL2 &lt;authenticate/> element, that MUST be processed first by the server. If that resumption is successful, the server MUST skip resource binding (a resumed session already has a resource bound) and MUST entirely ignore the &lt;bind/> request that might also be inlined in the &lt;authenticate/> element.</p>
<p>&xep0388; mandates that the &lt;success> element is immeditaly followed by stream features. If a former stream has been successfully resumed using this specification, the stream is considered re-established immediately after the &lt;success/> element instead and stream features MUST NOT be sent in this case.</p>
<section3 topic="Failed Resumption">
<p>Sometimes resumption might fail - for example, because the session has been disconnected longer than the server’s resumption timeout. In this case, the server MUST include the &lt;failed/> element defined by this specification in its SASL2 &lt;success/> response, but also MUST continue to process the &lt;bind/> in order to establish a new session for the client.</p>
<p>The client can find details about its new session in the &lt;bound/> response (defined by &xep0386;).</p>
</section3>
</section2>
<section2 topic="Inlining Examples" anchor="inline-examples">
<example caption='Server announces support for inlining activation of stream management and stream resumption'><![CDATA[
<stream:features>
<authentication xmlns="urn:xmpp:sasl:2">
<mechanism>SCRAM-SHA-1</mechanism>
<inline>
<sm xmlns="urn:xmpp:sm:3"/>
<bind xmlns="urn:xmpp:bind2:1">
<feature var='urn:xmpp:sm:3'/>
</bind>
</inline>
</authentication>
</stream:features>
]]></example>
<example caption='Client tries to resume stream and enables stream management inlined in its bind request'><![CDATA[
<authenticate xmlns='urn:xmpp:sasl:2' mechanism='SCRAM-SHA-1'>
<initial-response>[base64 encoded SASL data]</initial-response>
<resume xmlns="urn:xmpp:sm:3" h="some-sequence-number" previd="some-long-sm-id"/>
<bind xmlns="urn:xmpp:bind2:1">
<tag>AwesomeXMPP</tag>
<enable xmlns="urn:xmpp:sm:3"/>
</bind>
</authenticate>
]]></example>
<example caption='Client failed to enable stream management'><![CDATA[
<success xmlns='urn:xmpp:sasl:2'>
<additional-data>[base64 encoded SASL data]</additional-data>
<authorization-identifier>user@example.com/resource</authorization-identifier>
<bound xmlns='urn:xmpp:bind2:1'>
<failed xmlns='urn:xmpp:sm:3'>
<internal-server-error xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</failed>
<latest-id>0312a1b8</latest-id>
</bound>
</success>
]]></example>
<example caption='Client failed to resume stream'><![CDATA[
<success xmlns='urn:xmpp:sasl:2'>
<additional-data>[base64 encoded SASL data]</additional-data>
<authorization-identifier>user@example.com/resource</authorization-identifier>
<failed xmlns='urn:xmpp:sm:3' h='another-sequence-number'>
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</failed>
<bound xmlns='urn:xmpp:bind2:1'>
<latest-id>0312a1b8</latest-id>
</bound>
</success>
]]></example>
<example caption='Client failed to resume stream and to enable management of newly bound stream'><![CDATA[
<success xmlns='urn:xmpp:sasl:2'>
<additional-data>[base64 encoded SASL data]</additional-data>
<authorization-identifier>user@example.com/resource</authorization-identifier>
<failed xmlns='urn:xmpp:sm:3' h='another-sequence-number'>
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</failed>
<bound xmlns='urn:xmpp:bind2:1'>
<failed xmlns='urn:xmpp:sm:3'>
<internal-server-error xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</failed>
<latest-id>0312a1b8</latest-id>
</bound>
</success>
]]></example>
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>As noted, a server MUST NOT allow a client to resume a stream management session until after the client has authenticated (for some value of "authentication"); this helps to prevent session hijacking.</p>
<p>If SASL2 is used to inline stream resumption, implementations must adhere to the security considerations defined in &xep0388; regarding the inclusion of SASL2 requests and inline feature negotiation in TLS 0-RTT ("early data") extensions. That is, these elements MUST NOT be sent or processed if the stream would be resumed solely based on 0-RTT data, except when appropriate mitigations are in place (which are beyond the scope of this document, but may be defined by others).</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>