[Standards] NEW: XEP-0440 (SASL Channel-Binding Type Capability)

Ruslan N. Marchenko me at ruff.mobi
Wed Jul 1 20:01:12 UTC 2020


Am Sonntag, den 14.06.2020, 13:05 +0000 schrieb XEP Editor Pipeline:
> Version 0.1.0 of XEP-0440 (SASL Channel-Binding Type Capability) has
> been released.
> 
> Abstract:
> This specification allows servers to annouce their supported SASL
> channel-binding types to clients.
> 
This describes advertisement semantic however it does not solve the
main problem which channel binding mechanism is trying to solve and
which is more or less broken currently - integrity and confidentiality.

I've tried to implement that and immediatelly stumbled upon gs2_flags -
how to handle _no-match_ case? As per [5802] client needs to send y
when it thinks server does not support binding, but client does support
it.

What to do when I can bind tls-server-end-point and server can bind
tls-unique? Or opposite, whatever. If I send n, - that's a downgrade,
if I send y, - that's a clear failure case (server will abort as it
advertised -PLUS). So the only outcome is not to use SCRAM whatsoever
but that's again a downgrade.

So in a nutshell this opens a way for MitM to disable channel bindings.

Am I missing something here?

[5802] https://tools.ietf.org/html/rfc5802#section-6

--rr



More information about the Standards mailing list