[jdev] SASL EXTERNAL for s2s in jabberd14

[Matthias Wimmer]

Justin Karneges schrieb:

>On Friday 04 November 2005 15:22, Matthias Wimmer wrote:
>  
>
>>If there is no from attribute, I offer SASL EXTERNAL whenever I can
>>verify the certificate to be valid, doesn't matter for which identity it
>>is valid.
>>If there is a from attribute, I make the same checks as if there is no
>>from attribute, but in addition I check if the content of the from
>>attribute (after stringprep) matches one of the identities in the
>>certificate (after stringprep).
>>
>>With SASL EXTERNAL the client sends the authorization identity in the
>>initial response (base64 encoded as CDATA in the <auth/> element). At
>>that point I recheck the certificate, if it contains the authorization
>>identity and authenticate and authorize this ID (even if it differs from
>>the domain sent in the from attribute).
>>    
>>
>
>Since the authzid overrides the from attribute, what is the purpose of using 
>the from attribute at all?  What problem are you solving with this 
>mini-optimization?
>  
>
I do not want to offer SASL (EXTERNAL), if I already know that it will 
fail. Therefore force the peer not trying to use SASL, which would cause 
the stream to be closed / authentication to fail.
With this optimization, the connecting server can already use dialback 
on the first connection attempt.

You might argue, that all I should check is if I trust the CA of the 
certificate and make my decission based on this. But in reallity I see, 
that it seems to be common, that I get connects with certificates, that 
will fail on the domain check. Due to my logs all servers connecting 
with transport IDs at present use certificates for the server domain, 
not for the transport domain.
If I'd offer SASL to these connects, they'd all try SASL first, that 
would fail and the server would have to reconnect and try dialback.


Tot kijk
     Matthias