[Standards] Proposed XMPP Extension: Channel Binding Pseudomechanisms
sam at samwhited.com
Thu May 7 16:34:22 UTC 2020
On Thu, May 7, 2020, at 12:21, Florian Schmaus wrote:
> That the remote entity, the server in c2s, supports those particular
> channel binding types.
Okay, I assumed you meant that this would be a separate stream feature,
but from the examples you gave it doesn't seem like that's what you're
suggesting. In that case, read on…
> <stream:features> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-
> sasl'> <mechanism>EXTERNAL</mechanism> <mechanism>SCRAM-SHA-1-
> PLUS</mechanism> <sasl-channel-binding xmlns='urn:ietf:params:xml:ns:xmpp-
> sasl'> <channel-binding type='tls-unique'/> </sasl-channel-binding>
> </mechanisms> </stream:features>
Can we modify the mechanisms feature? Having this be an extension to the
mechanisms feature seems problematic to me. If I have a stable library
that implements XMPP SASL can I add this new payload to my library
without making backwards incompatible changes? Do I have to maintain a
new feature that just advertises the same name as the old mechanisms
feature? This feels poor.
Also if you're someone using strict schema validation and you don't
support the sasl-channel-bindings extension yet, this will break you if
the other end does. We'd need a mechanisms version bump or some other
way to tell if we should expect this payload.
> As other said, I too find not necessary to plan for the world where a
> channel binding type exists that can only be used with a particular
> SASL mechanism.
The TLS Exporters channel binding mechanism, which in the future will
likely be the primary way any channel binding happens with TLS says that
you SHOULD mix in application level data, eg. data specific to SCRAM in
this case so that the binding is two ways. This means we need to plan
for people doing that, whether we intend to do it ourselves or not.
More information about the Standards