The SCRAM (&rfc5802;) family of SASL (&rfc4422;) mechanisms is widely used in XMPP. SCRAM supports channel binding to the underlying security layer to prevent replay attacks, but does not provide a means of negotiating the type of channel binding performed. Normally this means that XMPP defaults to the tls-unique channel binding method defined in &rfc5929;.

This specification provides servers with a way to advertise what forms of channel binding they support, and for clients to choose a channel binding mechanism to use.

• Servers must be able to advertise multiple channel binding mechanisms.
• Clients must be able to pick a single supported SCRAM and channel binding mechanism.
• No extra round trips should be added to facilitate channel binding negotiation.

As a server operator I want to support different channel bindings depending on what version of TLS was negotiated.

As a client I want to know if the server supports tls-server-end-point channel binding to verify that the server's certificate has not changed between negotiation attempts.

The SCRAM based mechanisms advertise their channel binding support by listing themselves with an added suffix, "-PLUS". This advertises that channel binding is possible, but not the actual channel binding types supported by the server. The "SCRAM-SHA-1-PLUS" mechanism is the same as the "SCRAM-SHA-1" mechanism, the "-PLUS" suffix does not fundamentally change the mechanisms behavior. This concept of a "pseudomechanism", a mechanism that is implemented in terms of another mechanism with minor changes to the name and behavior, can be extended to allow for the advertising of specific channel binding types in addition to whether channel binding is supported or not.

To create such a pseudomechanism the server MUST concatenate the name of any "-PLUS" suffixed mechanism that it supports from the IANA SASL SCRAM Family Mechanisms Subregistry of the &ianasasl; with a colon (":") followed by the name of any channel binding data that it supports with the currently negotiated security layer from the &ianacb;. For example, if a TLS connection has been established and the server wants to advertise that it supports the SCRAM-SHA-1-PLUS and SCRAM-SHA-256-PLUS mechanisms with the tls-unique and tls-server-end-point channel binding types, it would list the following mechanisms:

While the channel binding variants of SCRAM are registered in the &ianasasl;, the pseudomechanisms described in this document depend on values in the registry themselves and so are explicitly not meant to be listed. A mechanism with a conflicting name cannot be registered because these pseudomechanisms are deliberately in violation of the naming convention of the SCRAM family of mechanisms as defined in &rfc7677; to prevent such conflicts. Because they are not meant to represent full mechanisms for use outside of XMPP, they do not require registration or the issuance of a GSS-API mechanism OID.

The original "-PLUS" suffixed mechanisms SHOULD continue to be listed and function as they did before (likely by defaulting to tls-unique) for the purpose of backwards compatibility.

The Security Considerations sections from &rfc4422;, &rfc5802;, and &rfc7677; apply to this document.

This document has no actions for IANA.

This document has no actions for the ®ISTRAR;.