[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