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.

Sign up for GitHub

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

Jump to bottom

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

Closed
wants to merge 5 commits into from
Closed

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

Changes from 4 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
c9c03e8
Update XEP-0198 to define SASL2 and BIND2 interaction
tmolitor-stud-tu Oct 4, 2022
c67102c
Add note as discussed at council meeting
tmolitor-stud-tu Oct 19, 2022
ab382f0
Clarify interaction with stream features after auth
tmolitor-stud-tu Nov 17, 2022
1a42195
Fix errors in bind2/sasl2 examples
tmolitor-stud-tu Dec 10, 2022
12ebe77
Address feedback
tmolitor-stud-tu Sep 8, 2023
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
View file
Open in desktop
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 in the namespace "urn:xmpp:sm:3" into the &lt;inline/> element of BIND2 which is sent in the stream features.</p>
tmolitor-stud-tu marked this conversation as resolved.
Show resolved Hide resolved
<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