mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-24 00:28:50 -05:00
146 lines
6.2 KiB
XML
146 lines
6.2 KiB
XML
<?xml version='1.0' encoding='UTF-8'?>
|
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
|
%ents;
|
|
<!ENTITY ianacb "<span class='ref'><link url='https://www.iana.org/assignments/channel-binding-types'>IANA Channel-Binding Types Registry</link></span> <note>IANA registry of channel binding types <<link url='https://www.iana.org/assignments/channel-binding-types'>https://www.iana.org/assignments/channel-binding-types</link>>.</note>" >
|
|
<!ENTITY rfc7677 "<span class='ref'><link url='http://tools.ietf.org/html/rfc7677'>RFC 7677</link></span> <note>RFC 7677: SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms <<link url='http://tools.ietf.org/html/rfc7677'>http://tools.ietf.org/html/rfc7677</link>>.</note>" >
|
|
]>
|
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
|
<xep>
|
|
<header>
|
|
<title>Channel Binding Pseudomechanisms</title>
|
|
<abstract>
|
|
A method for advertising and negotiating types of channel binding supported
|
|
by SCRAM based SASL mechanisms.
|
|
</abstract>
|
|
&LEGALNOTICE;
|
|
<number>xxxx</number>
|
|
<status>ProtoXEP</status>
|
|
<type>Standards Track</type>
|
|
<sig>Standards</sig>
|
|
<approver>Council</approver>
|
|
<dependencies>
|
|
<spec>XMPP Core</spec>
|
|
</dependencies>
|
|
<supersedes/>
|
|
<supersededby/>
|
|
<shortname>pseudomechanisms</shortname>
|
|
&sam;
|
|
<revision>
|
|
<version>0.0.1</version>
|
|
<date>2020-05-01</date>
|
|
<initials>ssw</initials>
|
|
<remark><p>First draft.</p></remark>
|
|
</revision>
|
|
</header>
|
|
<section1 topic='Introduction' anchor='intro'>
|
|
<p>
|
|
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;.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='Requirements' anchor='reqs'>
|
|
<ul>
|
|
<li>
|
|
Servers must be able to advertise multiple channel binding mechanisms.
|
|
</li>
|
|
<li>
|
|
Clients must be able to pick a single supported SCRAM and channel binding
|
|
mechanism.
|
|
</li>
|
|
<li>
|
|
No extra round trips should be added to facilitate channel binding
|
|
negotiation.
|
|
</li>
|
|
</ul>
|
|
</section1>
|
|
<section1 topic='Use Cases' anchor='usecases'>
|
|
<p>
|
|
As a server operator I want to support different channel bindings depending
|
|
on what version of TLS was negotiated.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='Pseudomechanisms' anchor='mechanism'>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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:
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<example caption='Host Advertises Mechanisms'><![CDATA[
|
|
<stream:features>
|
|
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
|
|
<mechanism>SCRAM-SHA-256-PLUS</mechanism>
|
|
<mechanism>SCRAM-SHA-256-PLUS:tls-unique</mechanism>
|
|
<mechanism>SCRAM-SHA-256-PLUS:tls-server-end-point</mechanism>
|
|
<mechanism>SCRAM-SHA-1-PLUS</mechanism>
|
|
<mechanism>SCRAM-SHA-1-PLUS:tls-unique</mechanism>
|
|
<mechanism>SCRAM-SHA-1-PLUS:tls-server-end-point</mechanism>
|
|
<mechanism>SCRAM-SHA-256</mechanism>
|
|
<mechanism>SCRAM-SHA-1</mechanism>
|
|
</mechanisms>
|
|
</stream:features>]]></example>
|
|
<p>
|
|
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.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='Security Considerations' anchor='security'>
|
|
<p>
|
|
The Security Considerations sections from &rfc4422;, &rfc5802;, and
|
|
&rfc7677; apply to this document.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='IANA Considerations' anchor='iana'>
|
|
<p>This document has no actions for IANA.</p>
|
|
</section1>
|
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
|
<p>This document has no actions for the ®ISTRAR;.</p>
|
|
</section1>
|
|
</xep>
|