From 5871d4d4d7943b06af016b5e3780daf8a7e5bb83 Mon Sep 17 00:00:00 2001 From: Sam Whited Date: Fri, 1 May 2020 17:55:24 -0400 Subject: [PATCH] Add Channel Binding Pseudomechanisms protoxep --- inbox/cb-pseudomechanisms.xml | 145 ++++++++++++++++++++++++++++++++++ 1 file changed, 145 insertions(+) create mode 100644 inbox/cb-pseudomechanisms.xml diff --git a/inbox/cb-pseudomechanisms.xml b/inbox/cb-pseudomechanisms.xml new file mode 100644 index 00000000..c38adc75 --- /dev/null +++ b/inbox/cb-pseudomechanisms.xml @@ -0,0 +1,145 @@ + + +%ents; +IANA Channel-Binding Types Registry IANA registry of channel binding types <https://www.iana.org/assignments/channel-binding-types>." > +RFC 7677 RFC 7677: SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms <http://tools.ietf.org/html/rfc7677>." > +]> + + +
+ Channel Binding Pseudomechanisms + + A method for advertising and negotiating types of channel binding supported + by SCRAM based SASL mechanisms. + + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + + + + pseudomechanisms + &sam; + + 0.0.1 + 2020-05-01 + ssw +

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

+ + +
    +
  • + 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. +

+ + + SCRAM-SHA-256-PLUS + SCRAM-SHA-256-PLUS:tls-unique + SCRAM-SHA-256-PLUS:tls-server-end-point + SCRAM-SHA-1-PLUS + SCRAM-SHA-1-PLUS:tls-unique + SCRAM-SHA-1-PLUS:tls-server-end-point + SCRAM-SHA-256 + SCRAM-SHA-1 + +]]> +

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

+ +