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

Ruslan N. Marchenko me at ruff.mobi
Thu Jul 2 11:26:31 UTC 2020

Am Donnerstag, den 02.07.2020, 11:23 +0200 schrieb Florian Schmaus:
> 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.
yes if server does not support tls unique - yes (which is mandatory to
support), fat chance. Known issue.

The point is - if we send n - it is a downgrade, because what happens
now is:
Me: <stream>

Server: <stream><features><mechanisms>SCRAM-SHA-512-PLUS SCRAM-SHA-

MITM: <stream><features><mechanisms>SCRAM-SHA-512</mechanisms>

Me: <auth mechanism="SCRAM-SHA-512">y,,n=me,r=blah</auth>

Server: <failure><not-authorized></failure>

any modification of the challenge (eg to swap my y with n) is protected
by hmac so will cause failure.

But now:

Server: <stream><features><mechanisms>SCRAM-SHA-512-PLUS SCRAM-SHA-
512<sasl-binding><binding type="tls-unqiue"></sasl-

MITM: <stream><features><mechanisms>SCRAM-SHA-512-PLUS SCRAM-SHA-
512<sasl-binding><binding type="tls-unqiue-for-telnet"></sasl-

Me (what?!?!, ok): <auth mechanism="SCRAM-SHA-

Server: <success/>

MITM: <message><body>thanks man, now I'll take it from

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

Like submit a change to IETF or something? Ideally it should be
- b64(tls-unique-for-telnet,tls-server-end-point) - eg I hear you but i
don't support that stuff.

> 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.
Yes, all the negotiation should be part of the exchange signed by hmac,
otherwise you can manipulate security context from outside of security

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

More information about the Standards mailing list