First draft.
+ 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. +
++ 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;.
+