mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-21 23:28:51 -05:00
Merge branch 'feature/protoxep-cb-pseudomechansims'
This commit is contained in:
Jonas Schäfer
commit
da47f273db
145
inbox/cb-pseudomechanisms.xml
Normal file
145
inbox/cb-pseudomechanisms.xml
Normal 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 <<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>
|
||||
Loading…
Reference in New Issue
Block a user