From c9c03e8f5c0f9053162e491024263828c2b44b54 Mon Sep 17 00:00:00 2001 From: Thilo Molitor Date: Tue, 4 Oct 2022 04:41:09 +0200 Subject: [PATCH 1/5] Update XEP-0198 to define SASL2 and BIND2 interaction --- xep-0198.xml | 92 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 92 insertions(+) diff --git a/xep-0198.xml b/xep-0198.xml index 1f0518971..6e2fd6e5a 100644 --- a/xep-0198.xml +++ b/xep-0198.xml @@ -28,6 +28,13 @@ &fabio; &dcridland; &mwild; + &tmolitor; + + 1.6.1 + 2022-10-05 + tm +

Clarify SASL2 and BIND" interaction.

 + 1.6 2018-07-25 @@ -552,8 +559,93 @@ + +

&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 <enable/> into the resource binding process to reduce round-trips.

+ +

To indicate support for inlining the activation of Stream Management into the resource binding process, the server adds a <feature/> element in the namespace "urn:xmpp:sm:3" into the <inline/> element of BIND2 which is sent in the stream features.

+

If the client wishes to begin a new session (i.e. it has no prior session to resume), it simply includes the <enable/> element defined by this specification in its &xep0386; <bind/> request which itself is a child of the <authenticate/> element of SASL2.

+ +

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 <failed/> element as defined by this specification within the <bound/> response defined by &xep0386;.

+ + + +

To indicate support for inlining stream resumption into the authentication process, the server adds a <resume/> element in the namespace "urn:xmpp:sm:3" to the <inline/> element of SASL2.

+

If the client wishes to resume an existing session it, it simply includes the <resume/> element defined by this specification in the SASL2 <authenticate/> element.

+

Note: If the client included a <resume/> element in its SASL2 <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 <bind/> request that might also be inlined in the <authenticate/> element.

+ +

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 <failed/> element defined by this specification in its SASL2 <success/> response, but also MUST continue to process the <bind/> in order to establish a new session for the client.

+

The client can find details about its new session in the <bound/> response (defined by &xep0386;).

+ + + + + + SCRAM-SHA-1 + + + + + + + + +]]> + + [base64 encoded SASL data] + + + AwesomeXMPP + + + +]]> + + [base64 encoded SASL data] + user@example.com/resource + + + + + 0312a1b8 + + +]]> + + [base64 encoded SASL data] + user@example.com/resource + + + + + 0312a1b8 + + +]]> + + [base64 encoded SASL data] + user@example.com/resource + + + + + + + + 0312a1b8 + + +]]> + + +

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.

+

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).

 From c67102cb71256bed6a4858a5b14f781ec9379ae6 Mon Sep 17 00:00:00 2001 From: Thilo Molitor Date: Wed, 19 Oct 2022 17:54:05 +0200 Subject: [PATCH 2/5] Add note as discussed at council meeting --- xep-0198.xml | 1 + 1 file changed, 1 insertion(+) diff --git a/xep-0198.xml b/xep-0198.xml index 6e2fd6e5a..b6e29980d 100644 --- a/xep-0198.xml +++ b/xep-0198.xml @@ -560,6 +560,7 @@ +

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.

&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 <enable/> into the resource binding process to reduce round-trips.

To indicate support for inlining the activation of Stream Management into the resource binding process, the server adds a <feature/> element in the namespace "urn:xmpp:sm:3" into the <inline/> element of BIND2 which is sent in the stream features.

From ab382f0b8a6729d6c7c5dbb3b56314a806e0e855 Mon Sep 17 00:00:00 2001 From: Thilo Molitor Date: Thu, 17 Nov 2022 21:43:43 +0100 Subject: [PATCH 3/5] Clarify interaction with stream features after auth --- xep-0198.xml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xep-0198.xml b/xep-0198.xml index b6e29980d..ce27e058d 100644 --- a/xep-0198.xml +++ b/xep-0198.xml @@ -33,7 +33,7 @@ 1.6.1 2022-10-05 tm -

Clarify SASL2 and BIND" interaction.

 +

Clarify SASL2 and BIND2 interaction.

 1.6 @@ -573,6 +573,7 @@

To indicate support for inlining stream resumption into the authentication process, the server adds a <resume/> element in the namespace "urn:xmpp:sm:3" to the <inline/> element of SASL2.

If the client wishes to resume an existing session it, it simply includes the <resume/> element defined by this specification in the SASL2 <authenticate/> element.

Note: If the client included a <resume/> element in its SASL2 <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 <bind/> request that might also be inlined in the <authenticate/> element.

+

&xep0388; mandates that the <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 <success/> element instead and stream features MUST NOT be sent in this case.

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 <failed/> element defined by this specification in its SASL2 <success/> response, but also MUST continue to process the <bind/> in order to establish a new session for the client.

The client can find details about its new session in the <bound/> response (defined by &xep0386;).

From 1a421956e9232a87f7f0c9d6ff5946afad94c6be Mon Sep 17 00:00:00 2001 From: Thilo Molitor Date: Sat, 10 Dec 2022 16:12:46 +0100 Subject: [PATCH 4/5] Fix errors in bind2/sasl2 examples --- xep-0198.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xep-0198.xml b/xep-0198.xml index ce27e058d..8a80e6ef1 100644 --- a/xep-0198.xml +++ b/xep-0198.xml @@ -585,7 +585,7 @@ SCRAM-SHA-1 - + @@ -597,7 +597,7 @@ [base64 encoded SASL data] - + AwesomeXMPP From 12ebe7758a8e7388c4746c2ed8a6863c07a1fa94 Mon Sep 17 00:00:00 2001 From: Thilo Molitor Date: Fri, 8 Sep 2023 02:39:02 +0200 Subject: [PATCH 5/5] Address feedback --- xep-0198.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0198.xml b/xep-0198.xml index 8a80e6ef1..49ebe1f94 100644 --- a/xep-0198.xml +++ b/xep-0198.xml @@ -563,7 +563,7 @@

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.

&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 <enable/> into the resource binding process to reduce round-trips.

-

To indicate support for inlining the activation of Stream Management into the resource binding process, the server adds a <feature/> element in the namespace "urn:xmpp:sm:3" into the <inline/> element of BIND2 which is sent in the stream features.

+

To indicate support for inlining the activation of Stream Management into the resource binding process, the server adds a <feature/> element with var attribute set to "urn:xmpp:sm:3" in the <inline/> element of BIND2 which is sent in the stream features.

If the client wishes to begin a new session (i.e. it has no prior session to resume), it simply includes the <enable/> element defined by this specification in its &xep0386; <bind/> request which itself is a child of the <authenticate/> element of SASL2.

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 <failed/> element as defined by this specification within the <bound/> response defined by &xep0386;.