[jdev] SASL EXTERNAL for s2s
Matthias Wimmer
m at tthias.net
Sat Nov 5 07:16:47 CST 2005
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. user1 at A can send a message to user2 at B.
>>
>>
>
>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 (fippo at goodadvice.pages.de 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
More information about the JDev
mailing list