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
