Hi Brian!
Brian Campbell schrieb:
Out of that context, I think another interesting problem is this:
Think of two servers A and B, that require a SASL authenticated
connection. (No matter which one enforces this, or if both servers
enforce this.)
B trusts the certification authority of A, therefore A can deliver
stanzas to B. [EMAIL PROTECTED] can send a message to [EMAIL PROTECTED]
Shouldn't A refuse to send to B because B is unable to authenticate
itself? My reading of the RFC (section 4.3) is that both ends must
authenticate themselves, not just the server which initiates the
connection. This makes sense because A shouldn't be sending messages to
a potential imposter.
Well at the SASL layer, A does not have to validate the certificate of
B, when it connects to B. But you are right. When establishing the TLS
layer it already has to validate the certificate (RFC 3920, section 14.2).
But still the described situation may arrise. The certificate might be
valid to be used as server certificate (when you connect to), but not as
client certificate (when you are connecting). Accidently I tried my SASL
EXTERNAL implementation with such a certificate first and wondered why
the certificate validation worked in the one direction and not in the other.
But I see ([EMAIL PROTECTED] pointed it out to me), that the
problem might even be caused even in other situations: As SASL does not
require the dialback conenction, server A might just not be accepting
incoming connections. With the certificate it can connect and
authenticate with B, but B will not be able to connect back to A, e.g.
because A is not listening, behind a firewall or a NAT router. But
that's the same as with e-mail. If you can send a mail to someone, that
does not neccessarily mean, that this person is able to reply to you.
Tot kijk
Matthias
