[Standards] Proposed XMPP Extension: Channel Binding Pseudomechanisms

Florian Schmaus flo at geekplace.eu
Thu May 7 17:11:22 UTC 2020


On 5/7/20 6:34 PM, Sam Whited wrote:
> 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…

I did, at first. It is totally irrelevant if it is an extra stream
feature or not. This just seemed a little bit more esthetic.


>> <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?

Yes, we can. Extensibility is one if the key concepts of XMPP.


> Having this be an extension to the
> mechanisms feature seems problematic to me.

It is not.


> 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.

If you do a strict schema validation that errors out as soon as it finds
an unknown element or attributed (prefixed or not), then you have
already lost in XMPP.


> We'd need a mechanisms version bump or some other
> way to tell if we should expect this payload.

I don't think we do. Even though it means an enforcing server would
*potentially* block clients unaware of this extension. But if you
server-side enforce it, then you kinda accept that.


>> 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.

What I said in my previous mail still applies. You either want always
that hypothetical new channel binding type or, you want it and
eventually others for backwards compatibility. The initiating entity,
the client in c2s, has an incentive to select what he finds most secure.


- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200507/bf9ede1d/attachment.sig>


More information about the Standards mailing list