On Tue, Aug 19, 2008 at 11:44 AM, Dirk Meyer <[EMAIL PROTECTED]> wrote: > "Eric Rescorla" wrote: >> What Dave is suggesting, I think, would be a garden variety TLS handshake >> with >> whatever ciphersuites you already support and self-signed certs. Then you'd >> run >> SASL with some challenge/response protocol and channel bindings (you'd >> almost certainly want mutual auth here) and then on the basis of the C/R >> note that you trusted the peer's self-signed cert. > > That does no work, SASL is not man-in-the-middle-proof: > > user 1 <--> man-in-the-middle <--> user 2 > > Now both the keys they do not know. But they are from the attacker. If > they use SASL on that link they only know that somewhere in the line > is the user user, they do not know that they talk direct. In this > scenario you would store the man-in-the-middle keys as verified. > > One idea: user 1 sends a challenge to user 2. The min-in-the-middle > can see it. Now user 2 generates an answer with password, his public > key and the challenge. Now it generates the md5 sum and sends it > back. user 1 does the same. A min-in-the-middle can not create a valid > md5 because he is missing the password, if there is a > man-in-the-middle user 2 would use a different public key than user 1. > This could work.
What David is suggesting is what's called a "channel binding". Basically, the SASL C/R is tied to the TLS handshake in a way that prevents this MITM attack. -Ekr
