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

Florian Schmaus flo at geekplace.eu
Thu Jul 2 15:37:21 UTC 2020

On 7/2/20 1:26 PM, Ruslan N. Marchenko wrote:
> 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.

Some implementations only support tls-server-end-point and not
tls-unique, even though the latter is mandatory to implement. But in
reality, it is often impossible to get the data required for tls-unique
from the TLS stack, or at least it is far easier to get the data for

> 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-
> 512</mechanisms>
> 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-
> binding></mechanisms>
> MITM: <stream><features><mechanisms>SCRAM-SHA-512-PLUS SCRAM-SHA-
> 512<sasl-binding><binding type="tls-unqiue-for-telnet"></sasl-
> binding></mechanisms>
> Me (what?!?!, ok): <auth mechanism="SCRAM-SHA-
> 512">n,,n=me,r=blah</auth>
> Server: <success/>
> MITM: <message><body>thanks man, now I'll take it from
> here</body></message></stream>

Thanks for the examples. Those made it clear which attack vector you
have in mind.

I think your example is correct: if the MITM replaces the list of
supported channel-binding types announced to the client, then the
security downgrade you described is possible.

>> 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
> y=dGxzLXVuaXF1ZS1mb3ItdGVsbmV0LHRscy1zZXJ2ZXItZW5kLXBvaW50Cg
> - b64(tls-unique-for-telnet,tls-server-end-point) - eg I hear you but i
> don't support that stuff.

Adding the server's supported channel-binding types the client observed
to the channel binding data would probably be the correct solution.
Newer SASL mechanisms should consider it. I wonder if SCRAM could be
retrofitted for this to by exploiting SCRAM's extendability, for example
as it allows for as-yet unspecified mandatory and optional extensions.

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

I think this is ultimately an issue on the SASL layer, and not
necessarily in xep440. Clients are free to ignore the xep440 information.

A pragmatic middle-ground, which mitigates the impact of the downgrade
attack vector you described, would be if clients remember and pin the
announced and used SASL mechanisms and channel-binding types (This may
be a good recommendation for certain setups irregardless of xep440 anyway.).

The security section of xep440 should definitely discuss the downgrade
attack vector you described and potentially recommend SASL mechanism and
channel-binding type pinning as mitigation.

- Florian

More information about the Standards mailing list