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

Florian Schmaus 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
need xep440.

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

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 [1].

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
the gss-api.

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.

- Florian

1: Message-ID: <80bfd85e07c3154244709553a7c81c91703b875d.camel at ruff.mobi>

-------------- 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/20200716/6ccc928b/attachment-0001.sig>


More information about the Standards mailing list