Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XEP-0198: Add section defining SASL2 and BIND2 interaction #1215

Closed
wants to merge 5 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
94 changes: 94 additions & 0 deletions xep-0198.xml
Original file line number Diff line number Diff line change
Expand Up @@ -28,6 +28,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>
Expand Down Expand Up @@ -552,8 +559,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;resume/> element in the namespace "urn:xmpp:sm:3" to the &lt;inline/> element of SASL2.</p>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The example uses a <sm/> element and so do Conversations and prosody

<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>[email protected]/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>[email protected]/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>[email protected]/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, they 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'>
Expand Down
Loading