On 7/16/20 12:33 PM, Daniel Gultsch wrote: > Am Do., 16. Juli 2020 um 10:13 Uhr schrieb Florian Schmaus > <[email protected]>: > >> If you send 'y', which implies that you, the client, did not select a >> -PLUS mechanism for authentication, while the server announces at least >> one SCRAM-*-PLUS mechanism, then the server may suspect a MitM attack >> and terminates the connection. > > Yes. But that's the desired behaviour, no?
Not if you want to continue authentication if there is no matching channel binding type. I noticed that you wrote "This means that you as a client just need to make sure that you support at least one that is commonly supported.", and I am not sure if I agree with that sentiment. Mostly because if such a commonly supported channel-binding type(s) existed, then you would not need xep440. I'll also repeat what I already said elsewhere: In my experience, most TLS APIs make it easy to implement tls-server-end-point, but often tls-unique is non-trivial to implement. Even though tls-server-end-point has some flaws, it is, to the best of my knowledge, still better than no channel binding. So for we have tls-unique, which is mandatory to implement by servers as per RFC 5802, but actually non trivial to implement, and tls-server-end-point, which is basically the opposite. Hence I do no think that we will find a common channel-binding type here. I hope that xep440 increases the chances of a successful SASL authentication with channel-binding, while sacrificing a bit of security by introducing the downgrade attack vector pointed out by Ruslan in [1]. But, as nobody forces you to consume the xep440 information, you can simply ignore it if your use-case can not tolerate that vector. And I'd assume most use-cases where this is not tolerable, are ones where it is easy to enforce a common channel-binding type, e.g. closed networks, which are more-or-less under the control of the same entity. But for open, federated networks, I think it is justifiable to mitigate the attack vector by pinning the channel-binding types after they have been discovered once. At least, until a proper fix is rolled out, which would probably require mixing in the supported channel-binding types in the gss-api. On the other hand, I recently pondered about adding a SASL specific channel-binding-type-not-supported error as alternative to xep440. That way, clients could attempt SASL auth with their most preferred channel-binding type, and could try further ones, until they potentially fall-back authentication without channel-binding. It appears that would not inherit most (any?) issues of xep440, at the cost of more round trips. - Florian 1: Message-ID: <[email protected]>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
