Hello, Matthias! On Fri, 04 Nov 2005 21:33:20 +0100, you said:
MW> Hi! I have implemented SASL EXTERNAL on s2s connects in jabberd14 the MW> last days, and like to share some thoughts on this, as well as I'd like to MW> get thoughts of other developpers, that already implemented this. MW> - When do you offer SASL EXTERNAL on an incoming connection? I MW> implemented, that the s2s connection manager always checks the peers MW> certificate as soon as a TLS layer is established. Only if the certificate MW> could be validated (not expired, if the incoming stream had a from MW> attribute if this matches the certificate, signed by a trusted CA, ...) I MW> offer the peer to use SASL EXTERNAL. In all other cases I know that SASL MW> EXTERNAL would fail anyway so I do not have to offer it. Better for the MW> peer to try dialback. In latest SVN version of ejabberd, certificate on incoming S2S connection is checked right after receiving "<stream:stream>", but without using "from" attribute. MW> - What do you do if you connected to an other server which offered you MW> SASL auth but the authentication failed? Do you retry the connection using MW> dialback or do you consider it as a final auth failure? Currently I do not MW> retry it using dialback but bounce the stanza back to the sender. I am MW> aware that this might be wrong and retrying the connection using dialback MW> could be better. ejabberd retries connection using starttls+dialback. MW> - I guess at least for now we have to handle certificates, that do not MW> contain the id-on-xmppAddr object as well and therefore have to support MW> domains as commonName as well. Right? In that case, it is known practice MW> in such certificates to have wildcards in domains, MW> e.g. "*.example.com". Do you handle these? How do you handle these? I am MW> allowing this certificate for "subdomain.example.com", but not for MW> "example.com". I don't handle this case yet. MW> - If the certificate is for "example.com", do you accept this certificate MW> to be used for "service.example.com" as well? Currently I don't. But I am MW> not sure if this is correct/intended by RFC3920. Same here. MW> - Do you support having a SASL authenticated link in one direction and a MW> dialback "authenticated" link in the other direction between two servers? Yes. MW> Especially do you accept and process to receive db:verify requests on a MW> SASL link? Currently I do. Yes, ejabberd accepts it, but doesn't try to send db:verify in SASL links. MW> - Do you package a set of CA certificates with your server distribution? MW> Which CAs should be trusted/included? No. MW> What servers out there support SASL EXTERNAL already and are available for MW> at least evaluation? I'd like to do some interoperability tests? e.jabber.ru, but it doesn't process id-on-xmppAddr.
smime.p7s
Description: S/MIME cryptographic signature
