mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-11 11:55:06 -05:00
190 lines
7.9 KiB
XML
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 <<link url='http://tools.ietf.org/html/rfc5056'>http://tools.ietf.org/html/rfc5056</link>>.</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 <<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>>.</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 <mechanisms/>
|
|
stream-feature element, qualified by the
|
|
'urn:ietf:params:xml:ns:xmpp-sasl' namespace, as specified in
|
|
&rfc6120;. Another potential appearance of
|
|
<sasl-channel-binding> is as child element of the
|
|
<mechanisms/> stream-feature element as specified in the
|
|
&xep0388;.</p>
|
|
|
|
<example caption='Example <mechanisms/> 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 <sasl-channel-binding/> 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
|
|
<sasl-channel-binding;> 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 <sasl-channel-binding;></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>
|