[Standards] NEW: XEP-0440 (SASL Channel-Binding Type Capability)
flo at geekplace.eu
Thu Jul 16 10:11:31 UTC 2020
On 7/16/20 11:46 AM, Daniel Gultsch wrote:
> Am Mi., 1. Juli 2020 um 20:03 Uhr schrieb Ruslan N. Marchenko <me at ruff.mobi>:
>> 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.
>>> 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  client needs to send y
>> when it thinks server does not support binding, but client does support
>> 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.
> I think that as soon as you as a client support any kind of channel
> binding you need to send 'y'.
If you send 'y', which implies that you, the client, did not select a
-PLUS mechanism for authentication, while the server announces at least
one SCRAM-*-PLUS mechanism, then the server may suspect a MitM attack
and terminates the connection. The suspected attack being the MiTM
trying to downgrade SASL authentication to a non channel binding one by
stripping any -PLUS mechanisms from the servers announcement.
I am not sure if this behavior is spelled out in RFC 5802, but I always
assumed that this is the rationale behind the flag.
Hence I tend to say clients which find no matching channel binding type
need to send 'n' in this case. Which is also not ideal, as explained in
the other mail, but appears to be the lesser of the two evils.
But maybe I am missing something?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 618 bytes
Desc: OpenPGP digital signature
More information about the Standards