[Standards] NEW: XEP-0440 (SASL Channel-Binding Type Capability)
flo at geekplace.eu
Thu Jul 16 11:09:54 UTC 2020
On 7/16/20 12:33 PM, Daniel Gultsch wrote:
> Am Do., 16. Juli 2020 um 10:13 Uhr schrieb Florian Schmaus <flo at geekplace.eu>:
>> 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.
> Yes. But that's the desired behaviour, no?
Not if you want to continue authentication if there is no matching
channel binding type.
I noticed that you wrote "This means that you as a client just need to
make sure that you support at least one that is commonly supported.",
and I am not sure if I agree with that sentiment. Mostly because if such
a commonly supported channel-binding type(s) existed, then you would not
I'll also repeat what I already said elsewhere: In my experience, most
TLS APIs make it easy to implement tls-server-end-point, but often
tls-unique is non-trivial to implement. Even though tls-server-end-point
has some flaws, it is, to the best of my knowledge, still better than no
So for we have tls-unique, which is mandatory to implement by servers as
per RFC 5802, but actually non trivial to implement, and
tls-server-end-point, which is basically the opposite. Hence I do no
think that we will find a common channel-binding type here. I hope that
xep440 increases the chances of a successful SASL authentication with
channel-binding, while sacrificing a bit of security by introducing the
downgrade attack vector pointed out by Ruslan in .
But, as nobody forces you to consume the xep440 information, you can
simply ignore it if your use-case can not tolerate that vector. And I'd
assume most use-cases where this is not tolerable, are ones where it is
easy to enforce a common channel-binding type, e.g. closed networks,
which are more-or-less under the control of the same entity.
But for open, federated networks, I think it is justifiable to mitigate
the attack vector by pinning the channel-binding types after they have
been discovered once. At least, until a proper fix is rolled out, which
would probably require mixing in the supported channel-binding types in
On the other hand, I recently pondered about adding a SASL specific
channel-binding-type-not-supported error as alternative to xep440. That
way, clients could attempt SASL auth with their most preferred
channel-binding type, and could try further ones, until they potentially
fall-back authentication without channel-binding. It appears that would
not inherit most (any?) issues of xep440, at the cost of more round trips.
1: Message-ID: <80bfd85e07c3154244709553a7c81c91703b875d.camel at ruff.mobi>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 618 bytes
Desc: OpenPGP digital signature
More information about the Standards