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 tls-server-end-point. > 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 _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
