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

Florian Schmaus flo at geekplace.eu
Thu Jul 2 09:23:10 UTC 2020


On 01.07.20 22:01, Ruslan N. Marchenko wrote:
> 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? […] If I send n, - that's a downgrade,

I am not sure if this is a downgrade attack (at least a full-blown), or,
if it is, if it. Without xep440 the client would have send 'p' in the
case you described, with a channel-binding type not supported by the
server and hence SASL authentication would fail.

We could say xep440 modifies the semantic of the 'n' value of the
gs2-cbind-flag from

"n" -> client doesn't support channel binding.

to

"n" -> client doesn't support any channel binding announced/supported by
       the server.


Maybe there are other options, like extending the gs2 header with a flag
that explicitly states that the client believes that there are no mutual
supported channel-binding types by client and server.

But right now, I lean towards explicitly stating in xep440 that the
semantic of 'n' is modified in the way I mentioned above.

Happy to hear more voices on this. :)

- 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/20200702/46d1694a/attachment.sig>


More information about the Standards mailing list