On 12/31/05, Matthias Wimmer <[EMAIL PROTECTED]> wrote: > HI Vinod! > > Vinod Panicker schrieb: > > >The RFC states that SASL must be done after TLS. Though its not > >expressly forbidden, I doubt that TLS+dialback was ever intended in > >the first place, since Dialback was written much before there was the > >question of TLS. > > > > > ... but you cannot tell me that TLS+dialback is worse than just > unencrypted dialback. Therefore I think it has been a good idea to use > the starttls extension on dialback as well.
If there is a consensus on this, then it should get a specific mention in the new RFC. Better to remove assumptions altogether. > >Regarding the issue of SASL EXTERNAL and support for subjectAltNames, > >I dont think it is currently possible to have a valid certificate with > >subjectAltName extensions since none of the CA's are supporting it. > > > > > Right. That's why as a fallback all server implementations I know check > the CN if there is no subjectAltName extension. But CN check fails when I'm running a xmpp service for a domain (eg. example.com), but using a different dns name (eg. im.example.com), since the cert will have the CN as im.example.com > >I think there should be something done for enabling federation between > >servers using DIGEST-MD5 or even PLAIN. Otherwise, this looks like a > >no-go. Servers will keep relying on dialback. > > > > > Using DIGEST-MD5 or PLAIN for interconnection between servers would mean > that EVERY PAIR of jabber servers would have to agree on a shared > secret. That's very much impractical. True, thats why I believe that something should be done to facilitate it. Otherwise, how about having TLS+SASL ANONYMOUS for s2s then? Regards, Vinod.
