[Standards-JIG] Re: stream:error for dialback with no SASL support

Peter Saint-Andre stpeter at jabber.org
Fri Jul 30 17:30:30 UTC 2004

In article <20040724182912.GA27003 at hermes.muc.charente.de>,
 Matthias Wimmer <m at tthias.net> wrote:

> The problem with it seems that XMPP is not very clear about using
> dialback and STARTTLS and in which order you should stack these two
> protocols. Maybe the authors even considered noone wants to combine
> these two protocols, but I think they can be useful. Correct me if I am
> wrong, but I think SASL can only be used if the two connecting parties
> know each other and have exchanged some authentication tokens. Therefore
> on the open public Jabber network I have no clue yet how we could use
> SASL authentication (beside using the ANONYMOUS mechanism or requiring
> all Jabber servers having trusted X.509 certificates.) - but
> STARTTLS is interesting in any case.

I would say STARTTLS first, then dialback. Essentially, SASL replaces 
dialback for s2s authentication (while dialback is not really an 
authentication mechanism, it was pretty much used as such in the older 
Jabber protocols). So to me it makes sense to do TLS then dialback just 
as we do TLS then SASL (which is the ordering of layers defined in XMPP 
Core). I will add something about this to the implementation guide.

> > The biggest pain with implementing SASL for S2S was the fallback
> > mechanism.  If your local system supports SASL, for external connections
> > you have to try SASL first and then drop back to dialback if the remote
> > system doesn't support SASL.  The problem is the different flavors of
> > servers will reject you in various ways.
> As I said implementing SASL will be my next step after STARTTLS works. I
> thought about the following bussiness logic for SASL/Dialback selection:
> Outgoing connection:
> - send xmlns:db namespace declaration and the XMPP version attribute
> - if I get <stream:features/> containing <starttls/> start the TLS
>   connection and start at the beginning again
> - if I get <stream:features/> containing <mechanisms/> check if I am
>   configured to do SASL authentication with this server. If yes: Start
>   SASL authentication
> - if I am configured to allow Non-SASL-but-Dialback-Connections, send
>   <db:result/> and do Dialback processing
> - Send stream error and close connection
> Incoming connection:
> - Check if xmlns:db is declared and if version attribute is present,
>   if both are missing check if we are configured to allow legacy jabberd
>   1.0 connections (disabled by default)
> - If the incoming connections had the version attribute with a value
>   starting with "1." send stream features. Containing <starttls/> if TLS
>   not yet established; and <mechanisms/> if stream not authenticated yet
>   and we are configured to do SASL authentication with the incoming
>   server.
> - If the other server requests STARTTLS, start the TLS layer and start
>   at the beginning again.
> - If the other server starts SASL authentication, process SASL
> - If the other server sends <db:result/>, process the dialback.
> Do you think I will get into problems with this logic?

This seems fine. I disagree with JD's comment that you won't receive the 
xmlns:db declaration -- you probably will at least receive it on the 
very first stream from another domain because for the sake of backwards 
compatibility all implementations will do both SASL and dialback for 
quite some time, I think.


More information about the Standards mailing list