From 3b781795d059afe160a82c38c44fbfe07f7b16a8 Mon Sep 17 00:00:00 2001 From: Thilo Molitor Date: Wed, 19 Oct 2022 19:35:18 +0200 Subject: [PATCH] New ProtoXEP: SASL2 SCRAM upgrade task --- inbox/xep-scram-upgrade.xml | 128 ++++++++++++++++++++++++++++++++++++ 1 file changed, 128 insertions(+) create mode 100644 inbox/xep-scram-upgrade.xml diff --git a/inbox/xep-scram-upgrade.xml b/inbox/xep-scram-upgrade.xml new file mode 100644 index 00000000..0a292200 --- /dev/null +++ b/inbox/xep-scram-upgrade.xml @@ -0,0 +1,128 @@ + + +%ents; +]> + + +
+ SCRAM Upgrade Tasks + This specification provides a way to upgrade to newer SCRAM hash algorithms using a SASL2 upgrade task. + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + RFC 5802 + XEP-0388 + + + + sut + &tmolitor; + + 0.0.1 + 2022-10-19 + tm + Initial version. + +
+ +

&xep0388; section 3 defines a way to upgrade to newer SASL mechanisms by providing the server with the needed data for that mechanism using upgrade tasks.

+

This specification uses those &xep0388; upgrade tasks to upgrade to newer SCRAM mechanisms using hash methods, which the server does not yet have the required data for.

+
+ + +

This protocol was designed to allow the client to upgrade to newer SCRAM mechanisms.

+
+ + +

For upgrades of SCRAM mechanisms as defined in &rfc5802;, the server has to provide the needed data for the client to calculate the SaltedPassword as defined in this RFC (or some RFC updating it), namely the iteration count and salt. To do so the server sends a <salt/> element namespaced to "urn:xmpp:scram-upgrade:0" containing the salt and an attribute named "iteration" containing the iteration count as defined in that RFC, omitting the "s=" and "i=" prefix. The <salt/> element is contained within a <task-data/> wrapper element as defined in &xep0388;.

+

The client then calculates the SaltedPassword and sends back its base64 encoded value inside a <hash/> element namespaced to "urn:xmpp:scram-upgrade:0". The <hash/> element is contained within a <task-data/> wrapper element as defined in &xep0388;.

+

The name of the upgrade task MUST NOT conain the "-PLUS" suffix, because channel-binding is not relevant for upgrade tasks.

+ element --> + + + + dj1tc1ZIcy9CeklPSERxWGVWSDdFbW1EdTlpZDg9 + + + UPGR-SCRAM-SHA-256 + + + + + + + + + + A_SXCRXQ6sek8bf_Z + + + + + + + BzOnw3Pc5H4bOLlPZ/8JAy6wnTpH05aH21KW2+Xfpaw= + + + + + + user@example.org + +]]> +
+ + +

Sending the password hash to the server (after authentication) is only protected by TLS and possibly channel-binding. Clients SHOULD use channel-binding, if available, to make sure no MITM can eavesdrop that hash and subsequently use it for authentication.

+

Note that a client can always choose to not take server-offered upgrades to newer SCRAM hash algorithms if it can not use channel-binding or the connection is otherwise deemed not secure enough.

+
+ +

This document requires no interaction with &IANA;.

+
+ +

This specification does not need any interaction with the ®ISTRAR;.

+
+ + + + + + + + + + + + + + + + + + + + + + + + + +]]> + +
\ No newline at end of file