moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 08:45:04 -05:00
Code Issues Releases Wiki Activity

Merge branch 'feature/protoxep-cb-pseudomechansims'

Browse Source
This commit is contained in:
Jonas Schäfer 2020-05-05 19:06:27 +02:00
commit da47f273db
1 changed files with 145 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

145
inbox/cb-pseudomechanisms.xml Normal file
View File

@ -0,0 +1,145 @@
<?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 &lt;<link url='https://www.iana.org/assignments/channel-binding-types'>https://www.iana.org/assignments/channel-binding-types</link>&gt;.</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 &lt;<link url='http://tools.ietf.org/html/rfc7677'>http://tools.ietf.org/html/rfc7677</link>&gt;.</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 &REGISTRAR;.</p>
</section1>
</xep>