Am Samstag, dem 28.10.2023 um 14:40 +0100 schrieb Matthew Wild: > > So, SSDP "only" allows the client to detect the difference between > two cases: > > 1) The real server advertises new channel binding methods the client > does not understand > 2) An MITM is trying to trick the client into authenticating > > In both cases the client must abort the authentication. What's > gained? > No
> Or are you saying that in case 1 the client should feel free to try a > SASL mechanism that does not do channel binding? Hi Matthew, Client is always free to use whatever method and mechanism it wants. SSDP just allows extending SASL SCRAM tampering protection to application layer. Meaning the client made mech/tls-binding selection while being fully aware of all available alternatives and nothing outside of the existing security context influenced that decision. And tampering protection is common for SASL SCRAM, tampered communication should result in failed authentication and hence no access to protected data (eg unencrypted communication). Regardless what exactly is being tampered with (ClientProof/ServerSignature mismatch). Regards, Ruslan
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Standards mailing list -- standards@xmpp.org Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s _______________________________________________
