1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-04 16:35:07 -05:00
xeps/xep-0440.xml
2022-08-29 19:57:01 +02:00

190 lines
7.9 KiB
XML

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY rfc5056 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5056'>RFC 5056</link></span> <note>RFC 5056: On the Use of Channel Bindings to Secure Channels &lt;<link url='http://tools.ietf.org/html/rfc5056'>http://tools.ietf.org/html/rfc5056</link>&gt;.</note>" >
<!ENTITY iana-cb-types "<span class='ref'><link url='https://www.iana.org/assignments/channel-binding-types/channel-binding-types.xhtml'>IANA Channel-Binding Types Registry</link></span> <note>IANA Channel-Binding Types Registry &lt;<link url='https://www.iana.org/assignments/channel-binding-types/channel-binding-types.xhtml'>https://www.iana.org/assignments/channel-binding-types/channel-binding-types.xhtml</link>&gt;.</note>" >
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>SASL Channel-Binding Type Capability</title>
<abstract>This specification allows servers to annouce their supported SASL channel-binding types to clients.</abstract>
&LEGALNOTICE;
<number>0440</number>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>sasl-cb-types</shortname>
&flow;
<revision>
<version>0.3.0</version>
<date>2022-08-29</date>
<initials>tm</initials>
<remark>
Make implementation of tls-server-end-point a MUST for servers.
</remark>
</revision>
<revision>
<version>0.2.0</version>
<date>2020-08-04</date>
<initials>fs</initials>
<remark>
Discuss interaction with SASL mechanism and add security considerations.
Recommend implementation of tls-server-end-point.
</remark>
</revision>
<revision>
<version>0.1.0</version>
<date>2020-06-14</date>
<initials>XEP Editor (jsc)</initials>
<remark>Accepted by vote of Council on 2020-05-27.</remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2020-05-20</date>
<initials>fs</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>SASL channel-binding is a technique to increase the security of
connections (&rfc5056;). Unfortunately, the SASL profile specified
in &rfc6120; lacks a method for the server to announce its supported
channel-binding types. This hinders the adoption of channel-binding,
especially since the error protocol to execute after a client
requested a channel-binding type unsupported by the server is
basically unspecified.</p>
<p>The extension defined herein fills the gap left by &rfc6120;, by
allowing the server the announce its supported channel-binding
types.</p>
</section1>
<section1 topic='Announcing the SASL Channel-Binding Type Capability' anchor='sasl-cb-type'>
<p>This protocol consists of a single optional extension element
named 'sasl-channel-binding' qualified by the 'urn:xmpp:sasl-cb:0'
namespace. The 'sasl-channel-binding' element MUST contain one or
more 'channel-binding' elements, of which each MUST have an
attribute with the name 'type'. The value of the 'type' attribute
SHOULD be the "Channel-binding unique prefix" of a channel-binding
type which was registered with the &iana-cb-types;.</p>
<p>A server declares that it supports particular channel-binding
types by listing the supported types via the 'sasl-channel-binding'
element defined herein. The 'sasl-channel-binding' element could
appear as child element to the SASL &lt;mechanisms/&gt;
stream-feature element, qualified by the
'urn:ietf:params:xml:ns:xmpp-sasl' namespace, as specified in
&rfc6120;. Another potential appearance of
&lt;sasl-channel-binding&gt; is as child element of the
&lt;mechanisms/&gt; stream-feature element as specified in the
&xep0388;.</p>
<example caption='Example &lt;mechanisms/&gt; stream feature with SASL Channel-Binding Type Capability.'><![CDATA[
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>EXTERNAL</mechanism>
<mechanism>SCRAM-SHA-1-PLUS</mechanism>
<mechanism>PLAIN</mechanism>
<sasl-channel-binding xmlns='urn:xmpp:sasl-cb:0'>
<channel-binding type='tls-server-end-point'/>
<channel-binding type='tls-exporter'/>
</sasl-channel-binding>
</mechanisms>
</stream:features>]]></example>
</section1>
<section1 topic='Interaction with SASL mechanisms' anchor='sasl-mech-interaction'>
<p>Some channel-binding enabled SASL mechanisms reflect the server's
presumed channel-binding abilities back to the server. This prevents
SASL-mechanism stripping attacks, where a Man in the Middle (MITM)
removes certain SASL mechanisms in an attempt to downgrade the
mechanism choosen for authentication to a non-channel-binding enabled
one. An example of a SASL mechanism family with this feature is
&rfc5802;. This standard specifies the gs2-cbind-flag. The flag has a
tristate value of "I don't support channel-binding" (n), "I think you
do not support channel-binding, but I do" (y), or, "Let us use
channel-binding type X" (p).</p>
<p>Clients using the information provided
via &lt;sasl-channel-binding/&gt; MAY want to indicate to the server
that they do not support channel-binding (even if they do) if no
mutual supported channel-binding type was found. The only alternative
is, that the client signals the server that he believes that the server
does not support channel binding. But this may cause the server to
terminate the connection, because it indicates a potential ongoing
SASL-mechanism stripping attack.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>If a client signals to the server that he does not support
channel binding, because it found no mutual supported
channel-binding types, another MITM attack
vector is introduced. An active attacker could replace the
&lt;sasl-channel-binding;&gt; list with channel bindings unlikely
(or impossible) to be supported by the client. If the client is
configured to use non-channel-binding SASL mechanisms as a fallback,
this could be used to downgrade the connection security. Note that
this attack is a different one than the SASL-mechanism stripping one:
Here the attacker tempers with the announced channel-binding types,
i.e., the values within &lt;sasl-channel-binding;&gt;</p>
<p>Depending on the application's security policy, clients may
refrain from falling back to non-channel-binding SASL mechanisms
if no mutual supported channel-binding type is available.
Alternatively, they may try channel-binding with a supported type
nevertheless. To mitigate the attack describe above, clients
could "pin" the announced channel bindings types by a service. In that
case, implementations may want to allow the set of pinned channel-binding
types to be extended to stronger ones.</p>
<p>As further mitigation, servers MUST and clients are RECOMMENDED to
at least implement the channel-binding type tls-server-end-point (&rfc5929;)
to increase the probability of a mutual supported channel-binding type.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>This document requires no interaction with the XMPP registrar.</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<p>TODO: Add if the XEP is scheduled for the state after 'experimental'.</p>
</section1>
<section1 topic='Acknowledgements' anchor='acknowledgements'>
<p>Thanks to Sam Whited for the discussion about the underlying
issue and incentivizing me to come up with this extension. Further
thanks goes to Ruslan N. Marchenko for pointing out the possible
MITM attack vector. Last but not least, Dave Cridland and Thilo Molitor
provided valuable feedback.</p>
</section1>
</xep>