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

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